Agile metoder tilpasser sig efter forandringer. Til forskel fra gamle metoder, der forsøgte at forudse det fremtidige behov, vil man her i stedet tilfredsstille det behov, der findes nu og her. Man taler om mottoet ”Embrace change”, hvor man kan ændre retningen i sit projekt, efterhånden som forudsætningerne ændrer sig. Det eneste faktum, der fortæller, om det er lykkedes eller ej, er et fungerende produkt eller en færdig løsning.
I februar 2001 fremsatte skaberne af de forskellige agile metoder et manifest, som jeg synes sammenfatter tankegangen meget godt:
”Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.”
Det kan jo godt lyde som selvfølgeligheder, men tanken er ikke, at det skal være en metode, som man kan følge slavisk. Det er nærmere en form for koncept og en måde til at stille spørgsmål på, der får en – eller snarere tvinger en – til selv at træffe beslutninger og til at vælge de veje, der passer en bedst. Jens Østergaard, som jeg og mange andre har haft som lærer i SCRUM, kalder det ”Agile Heart – self organization”, hvor det kritisk tænkende er en afgørende faktor i stedet for blindt at følge en gammel plan.
Godt, lad os se nærmere på detaljerne i SCRUM-metoden.
Der er tre forskellige roller i SCRUM:
- Scrum Team
- Product Owner
- Scrum Master
Et ”Scrum Team” omfatter alle aktive deltagere såsom udviklere, testere, designere osv. Alle deltagere skal være med på heltid, og gruppen skal organisere sig selv – helst uden titler.
”Product Owner” repræsenterer bestilleren og er oftest kunden. Han eller hun sammensætter, prioriterer og uddeler ansvar for de krav, som produktet skal tilfredsstille. Det gør han ved at oprette en ”product backlog”, som kan sammenlignes med en form for prioriteret kravspecifikation.
”Scrum Masterens rolle er at styre Scrum teamet ved at være gruppens forbindelse til ledelsen, se til at man praktiserer SCRUM på rette vis og at afhjælpe eventuelle forhindringer, gruppen har, så alle kan arbejde så effektivt som muligt. Tanken er endvidere, at han eller hun skal beskytte gruppen fra alle distraktionsmomenter, som f.eks. andre projekter, kunder der vil have hjælp med noget andet osv. Scrum Masteren holder også ”Daily standup” hver dag, hvor alle deltagere skal svare på tre spørgsmål:
- Hvad har du arbejdet med siden det sidste møde?
- Hvad skal du arbejde med i dag?
- Er der noget, som forhindrer dig i dit arbejde?
Tanken er ikke, at mødet skal føre til lange diskussioner. Det skal blot hurtigt, i løbet af ca. 15 min., give et overblik over, hvordan projektet skrider frem. Hvis deltagerne har problemer, der hindrer deres effektivitet, er det Scrum Masterens opgave at sørge for, at de bliver løst.
I SCRUM arbejder man iterativt i sprint, hvor et sprint er en ca. 30 dage lang periode, hvor man begynder med at planlægge, hvilket arbejde der skal udføres i sprinten. Det gør man ved at gennemgå en ”product backlog”, som jeg nævnte tidligere. Ud fra den skaber man en ”sprint backlog”, der indeholder de opgaver, der skal udføres under sprinten. Når først sprinten er sat i gang, må man ikke ændre på de opgaver, man begyndte med. Såfremt man bliver helt færdig, inden sprinten er slut, må man gerne inddrage noget nyt fra product backlogen, men man må ikke ændre på de krav, der allerede er valgt. Når sprinten er slut, skal man lave en præsentation af det, man har fået lavet, som helst skal være i kørbar form. Her kan der, ud over product owneren, også deltage f.eks. brugere og repræsentanter fra virksomhedsledelsen.
Hvert sprint skal desuden have en evaluering, en såkaldt ”Sprint retrospective”, hvor man gennemgår forløbet for at se, om noget kan forbedres til næste sprint.
Jens Østergaard fortalte en historie, hvor en af SCRUMs grundlæggere, Ken Schwaber, var Scrum master. Den vil jeg gerne genfortælle. Der var opstået en situation i det pågældende projekt, som gjorde, at projektet stod stille. Jeg kan ikke huske, om det var en server eller en database, der var gået ned. I hvert fald kunne teamet ikke arbejde, og på trods af at man havde drøftet problemet med ledelsen, så det ikke ud, som om der var nogen, der kunne løse det, eller var nogen der ville tage et ansvar.
Så bad Ken hele teamet om at gå ud i forhallen, lægge sig på ryggen og kigge op i loftet. Der gik ikke mange minutter, inden den øverste chef kom løbende og undrede sig over, hvorfor der lå en masse programmører på gulvet i forhallen. Om det løste problemet, eller om Ken blev fyret (hvilket han tydeligvis er blevet nogle gange) beretter historien ikke noget om.
Nu skal man jo ikke være så drastisk, men min erfaring er, at man i mange projekter har en tendens til at feje problemerne under gulvtæppet i stedet for at løse dem med det samme. SCRUM som metode medfører bl.a., at sådan noget bliver sværere, fordi problemerne konstant bliver synliggjort.
Et par links:
http://www.softhouse.se/Uploades/Scrum_broschyr.pdf – En udmærket sammenfatning af SCRUM
http://www.mountaingoatsoftware.com – Et godt site om SCRUM
http://scrum.dk – SCRUM-Certificering
