Få realiseret værdi hurtigere med Continuous Deployment

For mig har et team ikke leveret et værdifuldt inkrement til deres produkt, før det er kommet i hænderne på slutbrugeren. Fra udviklingen af en feature begynder og frem til det bliver taget i brug, er det lidt groft sagt værdiløst.

‍Scrum handler i bund og grund om at levere værdifuldt software kontinuerligt i god kvalitet til brugerne. Jeg oplever, at mange teams - og ikke mindst organisationer - tror, at hvis man bare arbejder inden for Scrum frameworkets rammer, så kommer resten af sig selv. Det gør det sjældent. Med det udgangspunkt er teamet halvvejs på vej mod “Scrum virker ikke for vores team og organisation” — inden de overhovedet er kommet igang.

Scrum er et framework, der skaber rammerne for, at teamet kan arbejde agilt. Der er fokus på kontinuerlig feedback og forbedring, og alle events eksisterer for at give teamet feedback. Alle events er mulighed for inspect & adapt.
Hvad er det, der inspiceres og tilpasses for hvert event? Det er et spørgsmål værd at overveje i et hvert Scrum Team. Mange Scrum Teams har glæde af Scrums indbyggede feedback-loops med det samme, men hvordan ser det ud med det produkt, som teamet arbejder på at levere til brugerne?

I sine tidligere udformninger beskrev Scrum Guiden, hvordan release typisk sker efter sprint review, og altså kun en enkelt gang per sprint. Selvom der nu i Scrum Guiden bliver opfordret til at release oftere, er der stadig mange teams, der releaser en gang per sprint (og mange endda sjældnere).

Men behøver det være sådan?

Med Continuous Deployment bliver kadencen sat op, og et team kan i princippet release til produktion flere gange dagligt. Det bør for de fleste teams være et scenario, de stræber efter. Det sætter feedback-kadencen op og giver mulighed for, at man ikke skal vente til efter afslutningen af et sprint på at få feedback fra slutbrugere, og måle værdien af en funktionalitet.

For mig har et team ikke leveret et værdifuldt inkrement til deres produkt, før det er kommet i hænderne på slutbrugeren. Fra udviklingen af en feature begynder og frem til det bliver taget i brug, er det lidt groft sagt værdiløst.

Start i det små

Men hvad skal der så til for at nå dertil?

Det handler meget om arkitektur! Det er svært at release ofte og i god kvalitet, når du har et stort og komplekst system med hårde afhængigheder og grænseflader til en masse andre systemer.

Virker det uoverskueligt at slippe ud af den suppedas?

‍Start i det små. Microservices og asynkron beskedudveksling services imellem er et sted, du kan starte. Find en del af systemet med tydeligt og afgrænset ansvar, og separer det til en selvstændig service, der kan kommunikere med resten af systemet asynkront — eksempelvis via en message-bus. Dermed kan du arbejde i mod løsere koblede systemer, der kan releases ofte, individuelt og automatisk! Kig eventuelt på Domain Driven Design og Microservice arkitektur for inspiration. Begynd der, og når erfaringerne og aha-oplevelserne er høstet, tag en bid mere. Elefanten skal spises en bid af gangen.

Teamet kan udnytte en af de mest brugte (og samtidig mest oversete/glemte) artefakter i Scrum til at motivere og skabe fokus omkring hyppige releases — Definition of Done (DoD).

Definition of Done er teamets aftale for, hvornår et Product Backlog Item (PBI) er færdig og kan betragtes som “Done”.

Definition of Done består af målbare punkter, og for mange Scrum Teams stopper det desværre ved kriterier, der omhandler et ønsket niveau af automatisteret test-coverage, at acceptkriterier er opfyldt, at der er lavet kode-review, manuel test osv.

Der skal ikke meget til for, at Definition of Done effektivt kan bruges til også at motivere imod daglige/hyppige releases til produktion.

Jeg har med flere teams været med til at føje til teamets Definition of Done, at en PBI ikke er “Done”, før den er verificeret i produktion. Det skaber et incitament til at skrive små PBI’er, der kan implementeres parallelt, og der opnås et mere effektivt flow med mindre “work in progress”.

Med den hurtigere feedback fra brugerne, bevæger teamet sig med hjælp fra Definition of Done mod at blive mere outcome-baseret fremfor aktivitets- og output-baseret.

Så hvad indeholder jeres DoD?

‍