Hurra, det går af helvede til – en scrum success historie

Efter netop af have været igennem et sprint på arbejde hvor INTET fungerede, og hvor vi derfor kun nåede en tredjedel af hvad vi havde forpligtet (committed) os til har vi netop følt en af scrums vigtigste virkninger på egen krop nemlig transparens – noget der er lækkert når det går godt, og endnu bedre når det går dårligt!

Transparens når det går dårligt kan umiddelbart virke som en negativ konsekvens ved scrum. Men at alle alle tydeligt kan se at det går skidt er GULD værd – fordi synligheden helt naturligt provokere en reaktion. Helt konkret muliggjorde synligheden at vi som scrum team blev tvunget til at gennemgå en lang række uhensigtsmæssigheder i vores måde at arbejde på (både organisatorisk og personligt). Og denne italesættelse af uhensigtsmæssighederne gør det muligt at bearbejde, og ideelt set fjerne dem helt. Under andre udviklingsformer ville vi som team have ”lukket af” over for omverdenen og derved have skjult – men ikke løst problemerne.

Helt konkret fik vi som følge at vores synligt dårlige performance diskuteret forskellige scenarier på hvordan vi skal håndtere tasks der ”vokser” jo mere der arbejdes på dem, og derfor sætter teamets hastighed i stå. Det kan være tasks der bygger videre på kode der i løbet af sprintet viser sig at være af for dårlig kvalitet, og derfor skal refaktoreres ud over det forventede. Eller tasks hvor de tekniske usikkerheder viser sig at være anderledes end antaget i sprintplanlægningen.

Vi fik vendt nogle af de organisatoriske fordele ved ”fail fast”, og at det kan være bedre at afbryde et sprint tidligt, end at fortsætte imod et urealistisk mål – hvis det viser sig at forudsætningerne for et sprint ikke er tilstede. Og vi fik snakket en række konkrete indgreb igennem som vi i fremtiden vil benytte hvis fremgangen en task går i stå.

De indgreb vi snakkede igennem var blandt andre at splitte et kode-par op og blande nye personer ind på en opgave der går fast, og at tasks der viser sig større end først antaget bør splittes op af hele teamet, og ikke kun de personer der aktuelt sidder med den pågældende task – også for at få delt designbeslutninger ud som en team-beslutning.

Scrum er godt – specielt når det går skidt :-)

Leave a Reply

Bødkers.net bliver stolt drevet af WordPress
Indlæg (RSS) og Kommentare (RSS).