Lean,

DevOps

og

høy

klisjéfaktor:

Velkommen

til

boksirkel!

Mars måned startet godt med gjennomføring av vår første fysiske boksirkel på det majestetiske Deichman bibliotek i Bjørvika. Omgitt av stressede studenter snek Progit seg inn på et lite grupperom i fjerde etasje, hang fra seg ytterjakkene og kjente på følelsen av å kunne møtes ansikt til ansikt igjen. Det lille grupperommet ble fylt opp av bokormer som har deltatt på Progit sin nye kompetansesatsing: Boksirkel - et tilbud for dem som er glad i å lese og ønsker å dele denne gleden med likesinnede.

På agendaen denne kveden var The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win. Det avlange bordet ble fylt med sammenbrettede tanker på papir og digitale tanker på maskin. Rommet ble fylt med egne erfaringer fra mange forskjellige prosjekter og praten gikk livlig. Whiteboardet på veggen ble et stort felles notat fylt med usymmetriske bokser og piler (som seg hør og bør på et whiteboard når praten går unna). Tiden går fort når man har det moro og praten ble med ut av det lille grupperommet og videre inn i den flotte restauranten Centropa som prydet førsteetasjen på Deichman.

Utstyrt med lesebrett og lydbok har vi blitt bedre kjent med Bill Palmer, den nyforfremmede visepresidenten for IT-drift i bedriften "Parts Unlimited". Med Erik som mentor prøver han å rydde opp i en kaotisk bedriftssituasjon med fiendtlig ledelse, lite samarbeid på tvers av avdelinger og mye uventet arbeid som kun kan gjennomføres av nøkkelpersonen Brent. På toppen av det hele ser ledelsen liten nytte i IT-avdelingen deres og truer med å avvikle den og i stedet skaffe tjenestene eksternt.

Problemene ligger hovedsaklig i utfordringer med menneskelige relasjoner internt i bedriften. Vi legger fort merke til at det er svært lav tillit på tvers av avdelingene (f.eks., mellom utvikling og drift). Avdelingene forstår ikke hverandres problemer som et resultat av mangel på et åpent sinn. Dette minner oss også om det klassiske utviklerproblemet der nye utviklere kommer inn på et prosjekt og klager på rot/dårlig design uten å ha forståelse for grunnlaget og mulighetene som fantes da designvalgene ble tatt. I løpet av boka skjer det en kulturforvandling av organisasjonen gjennom at ledelsen tar grep for å løse disse problemene. Løsningen består hovedsaklig i å skape forståelse og tillit for hverandres arbeid og se helheten fremfor kun sin avdeling.

Kort oppsummert forklarer boken oss at innen IT finnes det hovedsaklig fire typer arbeid:

• Forretningsprosjekter
• Interne prosjekter
• Endringer
• Ikke-planlagt arbeid

Videre framhever boken at påbegynt (ugjennomført) arbeid er en essensiell faktor for produktiviteten til en bedrift. For å begrense påbegynt arbeid kan man bruke kanban. Ved å benytte denne metoden kan man lettere danne seg et visuelt overblikk over bedriftens arbeidsoppgaver og deres status. Dette resulterer i at man lettere kan ta beslutninger om hvilke arbeidsoppgaver som bør prioriteres.

Bokens mentor, Erik, veileder oss via ulike analogier fra samlebåndsindustrien som til sammen utgjør lærdommen til det som er de viktigste prinsippene for å styre en IT-avdeling. Han mener de viktigste prinsippene for å styre en IT-avdeling (i følge boken) er de tre veiene. Prinsippene beskriver verdiene og filosofien som ligger bak prosessen og anvendelsen av DevOps.

• Den første veien omhandler arbeidsflyten fra utvikling til drift. For å maksimere flyten trenger vi lavt arbeidsvolum per oppgave og korte arbeidsintervaller. Utviklerne må unngå å fremlegge kode til drift som ikke fungerer i testmiljøene.
• Den andre veien dreier seg om en konstant flyt med rask tilbakemelding fra alle steg i verdistrømmen. Her er det viktig at feil dokumenteres skikkelig slik at man slipper å gjenta dem i fremtiden. Dette hjelper også for å raskere detektere feil og gjenopprette normal drift etter feil har oppstått.
• Den tredje veien handler om å skape en utforskende kultur med kontinuerlig eksperimentering. Her er det viktig å fokusere på å lære av både det som fungerer og det som ikke gjør det. Prøving og feiling er en forutsetning for å kontinuerlig forbedre arbeidsprosessene.

Til slutt kan vi også nevne at boken flere ganger nevner begrensingsteorien. Den ser i bunn og grunn på et system som ikke sterkere enn det svakeste ledd. Forbedringer av hva som helst annet enn det svakeste leddet har ingen innvirkning på systemet og er dermed kun en illusjon. For å forbedre systemet er det dermed essensielt å identifisere og redusere flaskehalsen.

Det er verdt å nevne at handlingen i denne boken er til tider triviell og full av klisjeer, og det er nesten morsomt hvor mye boken fokuserer på at karakterene har tidligere hatt ulike posisjoner i det amerikanske militæret. Men uansett gir denne boken rett og slett en grei introduksjon til agile prinsipper og DevOps generelt 👨‍💻.