Én af de største udfordringer ved at indføre et inkrementelt og iterativt tankesæt er ofte at det er to simple ord der er svære at forholde sig til. I værste fald har jeg erfaret at ordene bliver tolket så teamet reelt arbejder efter vandfaldsmodellen og i stedet for inkrementer, arbejder sig fremad i faser.

Teorien siger

Den officielle beskrivelse af Scrum skriver følgende:

Scrum implementerer en iterativ, inkrementel tilgang til at optimere forudsigeligheden og at kontrollere risici.

Dejlig nemt og lige til at implementere i sit team. Bare følg Scrum og så kommer du til at arbejde iterativt og inkrementelt – eller hvad?

Water-scrum-fall

Tager man de mekaniske elementer fra Scrum og anvender principperne i et vandfaldsmiljø, så får man water-scrum-fall. Der er i min optik intet galt med dette. Det forudsætter dog at man har taget en oplyst beslutning – altså at man ikke vil arbejde i inkrementer, men i stedet i faser.

Der findes to hurtige måder at spotte denne afart af Scrum:

1. Opgaver på product backlog har faser tilknyttet, f.eks:
   • Analyse af PDF ændringer
   • Design af PDF løsning
   • Programmering af PDF løsning
   • Osv.
2. Opgaver afsluttes ikke i et sprint, men overføres til næste sprint, f.eks.:
   • Sprint 1: Opdatering af PDF løsning
   • Sprint 2: Opdatering af PDF løsning (forsat)
   • Sprint 3: Opdatering af PDF løsning (forsat)
   • Osv.

Udfordringen ved water-scrum-fall er at man står tilbage med samme udfordring som ved alle andre vandfaldsprojekter; man rammesætter opgaven i detaljer up-front og laver løsningen til slut. Det gør det svært men ikke umuligt at lave risikostyring og forholde sig til ændringer i omverdenen.

Mere teori

For at undgå ovenstående er man nødt til at sætte sig ind i hvad ordene inkrementel og iterativ rent faktisk betyder – og særligt hvilke effekter det kan have på arbejdet i teamet.

• Inkrementel betyder “gradvist voksende”
• Iterativ betyder “gentagende”

Med andre ord, så er Scrum en process der gentagende og gradvist “vokser” et produkt. Hvis vi prøver at se på water-scrum-fall backlogsne beskrevet ovenfor; hvad synes du så? “Vokser” det produktet eller “vokser” det noget andet? I scenarie 1 mener jeg at man “vokser” viden og i scenarie 2) er der ingen der ved hvad der “vokses”.

Kronborg Slot

Uden at være historiker gengives her historien for Kronborg Slot i træskolængder:

• 1420: Erik af Pommeren anlægger en fæstning hvis formål var at opkræve told af forbipasserende skibe.
• 1570: Frederik 2. ombygger fæstningen til et slot i renæssancestil med fire fløje
• 1630: Christian 4. ombygger slottet indvendigt efter en brand
• 1780: Kronborg ombygges til militærtbrug
• 1850: Told af forbipasserende skibe stoppes og funktionen nedlægges
• 1915: Dele af slottet indrettes som museum for søfart
• 1938: Slottet restaureres og åbnes for offentligheden

Grunden til at jeg inddrager denne historiske anekdote er at det elegant beskriver hvordan man arbejder iterativt og inkrementelt, omend med årelange perioder. Det skaber rum for forståelse og over tid har det været muligt for den siddende konge at skifte formål for anvendelse af slottet.

Omskrevet på en software-nær form kunne en versionsoversigt for området se ud som følger:

• Kronborg version 1.0: Fæstning til opkrævning af told af forbipasserende skibe
• Kronborg version 1.1: Slot i renæssancestil med fire fløje
• Kronborg version 1.2: Indvendig ombygning efter brand
• Kronborg version 2.0: Anvendelse til militærtbrug
• Kronborg version 2.1: Nedlæggelse af toldfunktion
• Kronborg version 2.2: Indretning af museum for søfart
• Kronborg version 3.0: Restauration af slottet og åbning for offentligheden

Opsummering

Jeg har erfaret at hos os der arbejder med software giver det mening at drage versionsperspektivet i spil når der tales om iterativ og inkrementel udvikling. Det kan derfor varmt anbefales at arbejde med versioner på sprints, så man kontinuert arbejder mod færdigt software som slutprodukt fra et sprint frem for at falde i water-scrum-fall fælden.