Sytten erfarne it-udviklere mødtes i februar 2001 i Wasatchbjergene i Utah. De var bestemt ikke årsunger længere: Deres hårvækst var lige så tilstrækkelig som Bank Trelleborgs likviditet. Og hvis deres maver engang havde lignet vaskebrædder, så lignede de nu mere tørretumblere. Alligevel var de alle optændt af en ungdommelig lyst til at lave store ændringer.

De var trætte af de pinefuldt forsinkede it-projekter, der alt for ofte gav dårlige resultater. På trods af, at deltagere i it-projekter tit knokler mere – og længere – end sundt er. Efter et par dages intensiv diskussion udformede de et højtideligt manifest, som de alle underskrev. Det forpligtede dem til at finde bedre måder at udvikle it-programmer på. Dette ved at fokusere på:

• Individer og interaktion frem for processer og værktøjer
• Fungerende programmer over omfattende dokumentation
• Samarbejde med kunden i stedet for kontraktforhandlinger
• Reaktion på ændringer over at følge en plan

Resultatet blev en flodbølge af nye måder at udvikle it-programmer på.

Den mest udbredte af disse metoder kaldes scrum. Modsat de fleste andre ord i it-verdenen, er det ikke en forkortelse. Ordet ”scrum” kommer fra rugby, og betyder at holdet står tæt sammen og aftaler strategi og fremgangsmåde for det næste sprint.

I udviklingsmetoden er der meget fokus på udviklerne, og hvordan de hele tiden mest effektivt kan løse opgaverne. Den minder en del om selvstyrende teams i fabrikshaller: De overordnede mål er kendt, men hvordan arbejdet bedst tilrettelægges, det beslutter gruppen selv.

Alle udviklingsforløb i scrum har en afgrænset periode, der kaldes et sprint. Denne kan eksempelvis vare 30 dage. I den periode løser de så mange af de ønskede opgaver, som de kan. Opgaverne er ret kortfattet beskrevet af en produktejer fra forretningen. Det er også ham, der løbende styrer, hvordan opgaverne skal prioriteres i forhold til hinanden. Er der tvivl om hvordan opgaven skal forstås, så er han hele tiden til rådighed for udviklerne. Teamet mødes hver morgen for at drøfte hvilke opgaver, der er afsluttet, og hvilke der ikke er. Herunder især: Hvorfor ikke? Derefter aftales hvem der laver hvilke opgaver til næste dag. Mødet styres af en scrum-master, hvis vigtigste formål er at fjerne alle forhindringer for udviklernes fremdrift.

Ved afslutningen af sprintet beslutter produktejeren, om resultatet skal lanceres som det er. Hvis ikke, så køres et nyt sprint.

Jeg har både gode og dårlige erfaringer med metoden. Mest overraskende er produktivitetsforøgelsen. Der bliver virkelig leveret meget, meget mere programkode – i høj kvalitet. Den nuværende kort- og ruteplan på krak.dk blev eksempelvis udviklet vha scrum-metoden. På under fire måneder. Men metoden kræver en del is i maven: Ved starten af et sprint ved man ikke, hvad der kommer ud af det. Kun at der er afsat et vist antal ressourcer, og at de arbejder på en lang liste af emner. Alligevel kommer der oftest flere og bedre resultater ud af processen, end når man anvender traditionelle metoder. Selvom disse – i teorien – burde give et mere forudsigeligt resultat.

Blandt mine dårlige erfaringer er, at teamet bliver meget indadvendt. Og let kommer til at overse afhængigheder til andre projekter. Eller forudsætninger, der skal være på plads for at systemet kan komme i produktion.

Hvordan dette kan undgås? Det er temaet i næste uge.

Bragt som kommentar i Jyllands-Posten 13. maj 2008 og på epn.dk 17. maj 2008