Oppsummering av Accelerate: The Science of Lean Software and DevOps

En bok av Nicole Forsgren, Jez Humble og Gene Kim.

Accelerate handler om hvordan man kan levere IT-løsninger raskere og bedre. Detaljer om boken og hvor den kan kjøpes finner du her.

Accelerate er en bok som handler om hva som skal til for å bli en mer leveransedyktig og høytpresterende IT-organisasjon, som leverer mer verdi på kortere tid. Den baserer seg på State of DevOps-rapportene (global undersøkelse) fra 2014–2018.

Forfatterne går vitenskapelig til verks i å forklare hva, hvorfor og hvordan rundt både ledelse og tekniske metoder og praksiser.

Boken er tredelt:

1. Resultater fra undersøkelsene.
2. Vitenskapen bak undersøkelsene (hvordan stille riktige spørsmål på riktig måte, jobbe med statistikken med mer).
3. Case-studie fra ING (bank i Nederland), som har gjennomgått en smidig transformasjon.

Denne oppsummeringen tar for seg resultatene fra undersøkelsene.

TL;DR: Lean management, kultur og kontinuerlig leveranse har alt å si. For å være konkurransedyktig, holder det ikke lenger med business as usual. Store prosjekter med lang ledetid (tid fra start til kunde har noe kjørende) er avleggs. I stedet bør man ha små team som jobber i korte iterasjoner, med løpende feedback fra brukere, for å lage produkter og tjenester som brukerne liker og som skaper verdi. Kontinuerlig forbedring, i måten å jobbe på, er viktig.

Måling av prestasjon er brutt ned til fire separate målepunkter:

1. Delivery lead time
   Her er ledetid målt som tiden det tar fra kode lagres i versjonskontroll, til den kjører i produksjon. Kort ledetid er bra, da det muliggjør korte feedback loops (kjapp tilbakemelding fra brukere), slik at kursen kan korrigeres tidlig og ofte.
2. Deployment frequency / batch size
   Å levere få endringer i slengen (small batch size), gjør at en får dem ut raskere. Det gir bedre flyt, reduserer risiko og overhead, forbedrer effektiviteten, øker motivasjonen og reduserer kostnader. I boka er deployment frequency brukt som en proxy for batch size, da batch size er relativt og vanskelig å måle på tvers av de man undersøker.
3. Time to restore service
   Hvor lang tid tar det å gjenopprette når noe feiler eller går ned?
4. Change failure rate
   Hvor stor andel av endringene som gjøres, forårsaker feil?

Høytpresterende organisasjoner scorer bra på alt dette. Det viser at man ikke nødvendigvis må velge mellom hastighet, kvalitet og stabilitet. Man kan få alt. De siste årene har de høyest presterende organisasjonene rykket fra røkla, slik at forskjellen øker. De beste forbedrer seg kontinuerlig.

Høytpresterende organisasjoner har:

• 46 ganger hyppigere deploy av kode.
• 440 ganger kortere ledetid fra commit til deploy.
• 170 ganger raskere gjenoppretting etter feil og nedetid.
• 5 ganger lavere change/failure rate.

Boka avdekker 24 nøkkelegenskaper og drivere for høy prestasjon. Egenskapene er delt opp i fem kategorier:

• Kontinuerlig leveranse
• Arkitektur
• Produkt og prosess
• Lean management og monitorering
• Kultur

Kontinuerlig leveranse

Kontinuerlig leveranse er sett med egenskaper og teknikker som gjør det mulig å få alle slags endringer ut i produksjon på en kjapp, trygg og kontrollert måte. Prodsetting / release bør være en enkel rutine, som kan utføres når som helst og innenfor vanlig arbeidstid.

Kontinuerlig leveranse betyr at programvaren alltid er i en releasebar tilstand, og at teamet prioriterer releasebarhet over nye features. Informasjon om kvalitet og releasebarhet bør være tilgjengelig for alle teammedlemmer hele tiden. Når systemet ikke er i en releasebar tilstand, blir det fikset med en gang.

Disse fem prinsippene er selve kjernen av kontinuerlig leveranse:

• Innebygget kvalitet. Reduserer behovet for manuell testing og inspeksjon. Feil bør oppdages tidlig (gode automatiserte tester), slik at de kan fikses der og da, mens de fortsatt er billige å fikse.
• Arbeide med små bolker om gangen. Gir raskere målbar verdi (business outcomes) for kundene. Muliggjør også korte feedback loops, som muliggjør tidlig kursendring for å lage et bedre produkt.
• Datamaskiner gjør repeterende arbeid — mennesker løser problemer. Repeterende og tidkrevende arbeid, som regresjonstesting og deployment / installering, bør i størst mulig grad automatiseres, slik at kapasitet frigjøres til mer verdiskapende arbeid.
• Kontinuerlig forbedring. Ikke vær fornøyd, men press på for å forbedre og jobbe smartere hele tiden.
• Felles ansvar. En må samarbeide på tvers av avdelinger for å nå organisasjonens overordnede mål (system level outcomes). Det er et lederansvar å sørge for at alle til enhver tid vet hvordan organisasjonen ligger an med tanke på ønsket overordnet utfall. Ledere må jobbe med hele organisasjonen for å få definert målbare, oppnåelige og tidsbegrensede mål, slik at alle drar i samme retning. Typisk for byråkratiske organisasjoner, er at avdelinger måles på ulike og motstridende ting, slik at de i stedet ender med å motarbeide hverandre (for eksempel drift vs. utvikling).

De som er gode på kontinuerlig leveranse..

• Bruker mindre tid på ikke-planlagt arbeid og dobbeltarbeid, som kunne vært unngått, enn andre.
• Oppnår høyere prestasjon (lead time, deploy frequency, time to restore service).
• Har lav change / fail rate.
• Har en bedre og mer positiv og utforskende (generativ) kultur.
• Identifiserer seg sterkt med organisasjonen de jobber for.
• Har uproblematiske og enkle deploys. Ingen deployment pain (frykt og ubehag knyttet til deploy / release).
• Opplever mindre utbrenthet.

Innføring av kontinuerlig leveranse krever imidlertid ofte at en må tenke helt nytt — fra hvordan teamene fungerer og hvordan de samhandler med hverandre, til hvilke verktøy og prosesser de bruker. Resultatet er at det skapes et miljø hvor de i større grad tar ansvar for globale utfall som høy kvalitet og stabilitet.

Følgende er viktige drivere og egenskaper for kontinuerlig leveranse:

Nesten alt i versjonskontroll

Undersøkelsene viser at konfigurasjon i versjonskontroll, er sterkere korrelert til høy prestasjon enn kode i versjonskontroll. Miljøer bør kunne provisjoneres, og kode bør kunne bygges, testes og deployes automatisk fra versjonskontroll. Legg alt, bortsett fra data, i versjonskontroll.

Automatisert deploy

Deploy bør ikke kreve manuelle steg.

Continuous integration

Første steg på veien mot kontinuerlig leveranse. Det er en praksis hvor kode merges ofte til et delt repository. Hver endring trigger en bygge-, test- og deployprosess (til testmiljø eller lignende). Dersom noe feiler, fikses det der og da. Kortlevde brancher (under en dags arbeid) er enklere å integrere enn brancher som lever i flere dager og uker, og det skaper mindre overhead.

Trunk-based development

Undersøkelsene viser at kortlevde brancher er sterkt korrelert til høy prestasjon. De beste teamene har som regel færre enn tre aktive brancher på samme tid, og branchene lever typisk kortere enn en dag før de merges til master. Videre opplever disse teamene sjelden eller aldri kodefrysperioder. Dette er uavhengig av team- eller organisasjonsstørrelse og type industri.

Automatisiert testing

Automatiserte tester bør kjøres kontinuerlig gjennom hele utviklingsløpet og trigges automatisk ved commit / push, som del av deployment pipeline. De må være pålitelige og finne reelle feil, slik at bare releasebar kode godkjennes. Utviklere bør også kunne kjøre automatiske tester lokalt på / fra maskinene sine, for å være i stand til å vurdere, rangere og fikse defekter.

Slike tester bør skrives og vedlikeholdes av utviklere. Da oppnår en to viktige ting;

• Koden blir mer testbar. TDD tvinger frem mer testbar kode.
• Utviklerne bryr de seg mer om testene — og investerer dermed også mer tid og innsats i å vedlikeholde dem.

Automatiserte tester som lages og vedlikeholdes av QA-avdeling eller annen tredjepart har ingen korrelasjon til bra leveransetakt og -evne. Testere spiller fortsatt en viktig rolle. De bør gjøre manuell og utforskende testing, samt jobbe sammen med utviklere om å lage / definere automatiske tester. Siste bygg bør alltid være tilgjengelig for testing.

Test data management

En må ha nok testdata til å kjøre alle automatiske tester. Testdata, eller mangel på det, må ikke danne føringer og begrensninger for hvilke tester en kan kjøre. Samtidig er det poeng å ikke bikke over til å ha for mye testdata heller (vedlikehold og effektivitet). Testdata må være tilgjengelig på forespørsel og ved behov.

Test sikkerhet tidlig

Å integrere sikkerhet tidlig i utviklingsprosessen og gjennom hele livssyklusen til et produkt, er viktig for leveranseevne og kvalitet. Det gir mindre brannslukking.

Sikkerhetseksperter må være proaktive og bidra i applikasjonsdesign, gi feedback underveis i utviklingen, samt sørge for at sikkerhet inngår i den automatiserte testriggen. De må gjøre det enkelt for utviklere med flere å gjøre de rette tingene med tanke på sikkerhet.

Det er motsatt fra den mer tradisjonelle tilnærmingen, hvor en gjør sikkerhetsgjennomgang på tampen — når det er både dyrt og vanskelig å gjøre endringer.

Det samme kan sies om for eksempel universell utforming (red.anm).

Arkitektur

Høy leveransetakt og -evne er mulig med alle slags systemer, så fremt både systemene og teamene, som bygger og vedlikeholder de, er løst koblet. Det muliggjør at man enkelt kan teste og deploye individuelle komponenter og tjenester, selv om organisasjonen og antall systemer skaleres.

Følgende egenskaper (deployability and testability) er viktige for høy leveransetakt:

1. Teamet kan endre, deploye og release applikasjoner uten avhengigheter til andre applikasjoner og team.
2. Teamet kan gjøre release / prodsetting ved behov og på forespørsel. Det kan gjøres innenfor vanlig arbeidstid, uten nevneverdig nedetid.
3. Teamet kan gjøre større endringer i design av et system uten å måtte innhente godkjenning fra noen utenfor teamet.
4. Teamet kan ferdigstille arbeid uten å koordinere med utenforstående.
5. Teamet kan gjøre det meste av testing på sparket, uten behov for et integrert testmiljø (integrated test environment).
6. Teamene kan velge verktøyene sine selv.

Der en scorer høyt på slike arkitekturegenskaper, kreves lite kommunikasjon mellom teamene for å få jobben gjort. Arkitekturen er designet for at teamene skal kunne jobbe (endre, teste, deploye) selvstendig og uavhengig av andre. Både teamene og arkitekturen er da løst koblet.

En løst koblet og velfungerende IT-arkitektur med en matchende organisasjonsstruktur, muliggjør to ting:

1. Bedre leveranseevne med økt tempo og stabilitet, mens utbrenthet og deployment pain reduseres.
2. Organisasjonen kan vokse, mens produktiviteten samtidig øker lineært, eller bedre.

Det motsatte er gjerne tilfelle for low performers. Flere utviklere = færre deploys per tidsenhet per utvikler.

For å oppnå dette må vi ha kryssfunksjonelle team, som besitter all nødvendig kompetanse for å designe, utvikle, teste, deploye og drifte systemene.

Arkitektur gjenspeiler organisasjonsstruktur

Conways lov sier at IT-arkitekturen gjenspeiler organisasjonsstrukturen. Forskningen, som gjennomgås i boka, underbygger det som ofte kalles Inverse Conway maneuver; Organisasjons- og teamstruktur må designes etter den arkitekturen en ønsker å oppnå. Målet med IT-arkitekturen er å støtte teamene i å få jobben gjort — fra design til utrulling — med lav båndbredde på kommunikasjonen mellom teamene. Kommunikasjon mellom systemer løses med mikrotjenester og veldefinerte API-er.

Teamene bør snakke sammen, men de bør bruke båndbredden til å snakke om felles overordnede mål og hvordan de kan nås, fremfor implementasjonsdetaljer.

Lean og smidig produktutvikling

Har smidig utvikling positiv innvirkning på organisasjonens prestasjon, målt i produktivitet, markedsandel og profitt? Ja.

Smidig er jevnt over den foretrukne utviklingsmetoden, men blir ofte mangelfullt implementert. Organisasjonskultur og mer overordnede samarbeidsprosesser blir ikke tatt tak i. Det er fortsatt vanlig at bedrifter bruker lang tid på budsjettering, analyser og innhenting av krav før utviklingsarbeidet starter, for så å release i store bolker og ved ujevne mellomrom. Tilbakemeldinger fra kunder er uten innvirkning på sluttresultatet, og blir bare til ettertanke.

Lean / smidig produktutvikling står for det motsatte; Eksperimentell tilnærming med hyppig brukertesting av både design og forretningsmodell, fra starten av produktets livssyklus. Arbeidet deles opp i mindre bolker som leveres fortløpende.

Effektivisering av leveranseprosessen gjør det enklere å jobbe med mindre bolker om gangen, samt innhente bruker-feedback underveis. Å levere i mindre bolker gir raskere feedback loops.

Følgende er viktige egenskaper for en effektiv prosess:

Innhente og dra nytte av tilbakemelding fra brukere

Et poeng i smidig utvikling er å involvere brukerne tidlig i utviklingsløpet, for å få nyttige innspill og tilbakemeldinger. Disse tilbakemeldingene brukes så videre i neste steg av prosessen, før man jakter nye tilbakemeldinger igjen (feedback loop).

Forskningen viser at å aktivt søke tilbakemeldinger fra brukere, samt inkorporere lærdommen i produktet, er viktig for prestasjonen.

Visualisering av oppgaveflyt og verdikjede

Visualisering av prosess og gjennomstrømning av oppgaver, samt oversikt over og forståelse av verdikjeden (hele veien fra forretning til kunde), har betydning for leveranseevnen.

Visualisering (for eksempel Kanban) av arbeidsflyten og gjennomstrømning av oppgaver gjør det enkelt for alle å se hvem som jobber med hva, hva som er status på ulike oppgaver, hvor mange baller som er i lufta og hvorvidt noe er blokkert — som i at involvering av utenforstående og / eller eskalering er nødvendig. Det får igang viktig kommunikasjon.

Arbeide med små bolker om gangen

En bør dele opp arbeidet i små biter som kan ferdigstilles på en uke eller mindre. Det gir hurtigere og mer effektiv utvikling enn å jobbe med store og komplekse features på egne brancher over lang tid. Det gir kortere ledetid og raskere feedback loops.

Eksperimentering

Hvis teamet ikke får lov til å reagere på læringen fra tilbakemeldingene, uten godkjenning fra noen utenfor teamet, reduseres innovasjonsevnen drastisk. Organisasjonens prestasjon (profitt, produktivitet og markedsandel) reduseres også.

En forutsetning for effektiv eksperimentering er at det jobbes med små bolker om gangen, at arbeidsflyten gjennom leveranseprosessen er visualisert og at at bruker-feedback inkorporeres i produktets design. Det gir gjennomtenkte beslutninger. Det øker også sannsynligheten for fornøyde brukere og at det skapes verdi.

Lean management

Lean management bidrar til en bedre kultur, bedre leveranseevne og redusert utbrenthet.

Følgende er viktige egenskaper ved lean management:

Enkel prosess for godkjenning av endringer

Parprogrammering og pull requests internt i teamet, kombinert med deploy pipeline (push — bygg — test — deploy / release) for å blant annet oppdage og avslå endringer av lav kvalitet, er effektivt. Deploy / release bør være en heltautomatisert prosess, som trigges gjennom en deployment pipeline.

Team som må ha code review og godkjenning av noen utenfor teamet, presterer dårligere. Det gir heller ikke bedre stabilitet.

Ekstern godkjenning gir lengre ledetid, tregere leveransetakt og har ingenting å si for change/failure-rate. Det er verre enn å ikke ha en godkjenningsprosess i det hele tatt. I boka blir det blir beskrevet som risk management theater. Det er teamet som kjenner systemet og som best forstår effekten av endringene.

Overvåking av applikasjoner og infrastruktur

Data og lærdom fra overvåking av applikasjoner og infrastruktur kan brukes til å treffe bedre beslutninger. I tillegg til overvåking for varsling feil, bør man kjøre helsesjekker som kan varsle basert på terskelverdier og rate-of-change warnings, for eksempel om CPU har økt med 25% de siste 10 minuttene.

Synligheten og gjennomsiktigheten som oppnås ved effektiv overvåking er uvurderlig. Proaktiv monitorering er sterkt relatert til høy prestasjon og medarbeidertilfredshet, og er en viktig del av en teknisk rigg.

WIP-limits og visualisering av arbeid

Work in progress (WIP) limit definerer hvor mange oppgaver teamet kan håndtere samtidig. Meningen med WIP-limits er å optimalisere flyt ved å begrense antall samtidige oppgaver. Mindre tid kastes da bort på context switching. Det øker gjennomstrømningen av oppgaver og synliggjør flaskehalser.

Et interessant funn er at WIP-limits alene ikke har stor betydning for leveranseevne. Det er først når det kombineres med visuelle oversikter (tavler og skjermer som viser hva det jobbes med) og feedback loops fra produksjon, at WIP-limits gir stor verdi. Det hindrer at teamet har for mange oppgaver og dermed forlenget ledetid.

Kultur

En bedre kultur bygges gjennom kryssfunksjonelt samarbeid, gjennom å skape rom og tradisjon for læring, samt sørge for effektiv bruk av verktøy.

Følgende egenskaper er viktige egenskaper i en god kultur:

Generativ kultur

En generativ kultur kjennetegnes av god informasjonsflyt, høy grad av samarbeid og tillit, brobygging mellom team, felles ansvar, at nye ideer ønskes velkommen, at man oppfordres til å si fra om feil og mangler (messenger not shot) og man holder såkalte blameless postmortems hvor man lærer av feil fremfor å plassere skyld.

En slik kultur er prestasjonsfremmende for organisasjonen. Det gir bedre leveranseevne og reduserer utbrenthet.

Rom for læring og forbedring

Man kan stimulere til innovasjon og initiativer gjennom å investere i teamene:

• Ha et eget kompetansebudsjett, og oppfordre til å bruke det. La folk bestemme selv hvilke kurs, konferanser e.l de vil delta på, ut fra egne interesser og behov.
• Oppmuntre til deltagelse på minst en konferanse i året, og å i etterkant oppsummere hva man har lært for teamet / organisasjonen.
• Arranger hackathon / hack days, hvor tverrfaglige team kan skape og prøve ut nye ideer.
• Arranger yak days, hvor det jobbes med teknisk gjeld (ikke nødvendigvis bugs) og forbedringer som ellers ikke prioriteres.
• Hold jevnlige interne minikonferanser (foredrag, lyntaler, workshops, open space etc.)
• Sett av tid til å eksperimentere med nye verktøy og teknologier.
• Gjør det trygt å feile. Represalier gjør at folk ikke tør prøve nye ting. Feiling må ses på som en mulighet til å lære noe om hvordan prosesser og systemer kan forbedres. Det bidrar til innovasjon og kultur.

Samarbeid mellom team

En kan stimulere til kryssfunksjonelt samarbeid ved å

• Bygge tillit mellom teamene (åpen kommunikasjon, lovnader holdes, forutsigbar opptreden selv under stress).
• Tilrettelegge for flytting mellom avdelinger og team. Om noen bytter til en annen rolle et annet sted i organisasjonen, kan det være av verdi for begge team. Medarbeideren har med seg nyttig info om prosesser og utfordringer til det nye teamet, og det gamle får et naturlig kontaktpunkt for samarbeid.
• Aktivt søke, oppfordre til og belønne arbeid som krever kryssfunksjonelt samarbeid.

Gjør arbeidet meningsfylt

Drivere for medarbeidertilfredshet:

• La teamene velge verktøyene sine selv. Om de har verktøy til å gjøre jobben slik de vil, blir de mer engasjerte og effektive, og de gjør en bedre jobb.
• Kultur for eksperimentering og læring gjennom utnytting av teknologi (automatisering) kombinert med prinsipper fra lean management.
• Ansatte har innflytelse på egen hverdag

Bedre medarbeidertilfredshet gir bedre prestasjon, som gir konkurransefortrinn. Høy prestasjon og leveransetakt har dessuten en selvforsterkende effekt; Teamene får validert ideene sine oftere, som gir høyere tilfredshet, som gir høyere prestasjon.

Det motsatte er fortsatt ofte tilfelle. Teamene får overlevert kravspesifikasjoner, og må levere arbeid i store bolker om gangen. Det fører til liten kontroll over produktet som lages og hvilken effekt det har for kunder. Det er demotiverende, og de ansatte distanserer seg dermed mer fra organisasjonen, fremfor å identifisere seg med den. Det gir dårligere organisasjonskultur og dårligere prestasjon.

Transformasjonsledelse

En god leder forsterker teamets evne til å levere høy kvalitet i høyt tempo. Høytpresterende organisasjoner har engasjerte ledere som er gode på teknologi- og transformasjonsledelse, noe som er essensielt for en vellykket omstilling (til smidig / lean, DevOps eller lignende).

Transformasjonsledelse driver frem og forsterker effekten av de tekniske og organisatoriske praksisene som korrelerer med høy prestasjon (kontinuerlig leveranse, lean management etc.). Det går ut på å jobbe sammen med teamene for å identifisere nødvendig endring, samt skape og presentere en visjon for hvordan komme i havn.

For å lykkes med omstilling, bør en leder

• Være visjonær. Ha klare meninger om hvilken retning organisasjonen skal bevege seg, og hvor den skal være fem år frem i tid.
• Inspirere og motivere til engasjement for organisasjonens mål og visjoner.
• Gi intellektuell stimulans. Utfordre positivt. Oppfordre til nytenkning og å utfordre status quo.
• Være støttende. Bry seg om personlige behov og følelser.
• Gi personlig anerkjennelse. Legge merke til hva som oppnås og presteres, og gi personlig skryt når noen gjør noe bra.

Mer overordnet må man

• Utvikle riktig mindset gjennom å skape et miljø for læring.
• Utvikle egne coacher.
• Gjøre transformasjonen på sin egen måte.

Man kan la seg inspirere og lære av andre, men man bør ikke kopiere det andre gjør. Eksperimentering og tilpassing etter hva som funker for sin organisasjon, er det riktige å gjøre.

Videre bør en ikke sette ut transformasjonen til en ekstern partner. Teamene vil da føle at det blir gjort mot dem. Evne til forbedring, tilpasning og utvikling av prosesser og metoder osv. nås gjennom å ha eierskap til transformasjonen.

Bærekraftig arbeidsliv

Grad av utbrenthet og deployment pain ble målt for å forsikre at høy rapportert leveranseprestasjon ikke ble oppnådd gjennom tvang og på bekostning av teamets mentale helse.

Deployment pain

Deployment pain: Frykten man føler når kode dras ut i produksjon eller når en release skal installeres.

Der hvor deployment pain er verst, finner man også den dårligste leveranseevnen, dårligst kultur og dårligst presterende organisasjon.

Før Bing-teamet (hos Microsoft) implementerte kontinuerlig leveranse, scoret de 38% på life/work balance. Etterpå spratt det opp til 75%.

De fleste deployment-problemer skjer på grunn av en krøkkete deployment-prosess med avhengigheter til en bestemt konfigurasjon. Sannsynligheten for feil i deploy / release øker betraktelig når prosessen krever manuelle endringer.

Alt det som øker evnen til å levere kjapt og stabilt (kontinuerlig leveranse), reduserer stress og angst forbundet med deploy / release.

Vi bør derfor

• Sørge for enkel deploy til ulike miljøer.
• Bygge robuste systemer som kan detektere og tolerere feil i miljøer.
• Sørge for at komponenter kan oppdateres uavhengig av hverandre.
• Sørge for at alt, bortsett fra data, kan gjenopprettes fra versjonskontroll.

Utbrenthet

Disse fem faktorene er sterkt forbundet med utbrenthet:

• Dårlig organisasjonskultur (maktorientert, frykt, tilbakeholding av informasjon, plassering av skyld).
• Deployment pain.
• Lite effektivt lederskap (teamet har for mange samtidige oppgaver, hindere fjernes ikke osv.).
• Lite investering i og utvikling av ansatte.
• Dårlig kollektiv prestasjon (organizational performance).

Del to av boken handler om vitenskapen bak undersøkelsene, mens tredje del handler om transformasjon. Accelerate er ei veldig bra bok, som jeg vil anbefale på det sterkeste.