Agile Scrum – introduktion til metoden

Op igennem 90’erne oplevede industrien en stigende tendens, hvor mange udviklingsprojekter blev påvirket af ændringer i krav og uforudsigelig kompleksitet. Tendensen betød, at der opstod et behov for at skabe en balance mellem fleksibilitet og disciplin i udviklingen. Det blev grundlaget for den agile udviklingsmetode også kaldet Scrum.

Introduktion til Scrum
Agile Scrum blev beskrevet for første gang i en udviklingssammenhæng i 1986, hvor de to professorer Hirotaka Takeuchi og Ikujiro Nonaka, i en berømt artikel fra Harvard Business Review, beskrev de mest succesfulde produktudviklings-projekter i Japan på det tidspunkt. Projekterne byggede på 4 principper, som står i skærende kontrast til den 'klassiske' lineære udvikling:

• Individer og samarbejde frem for processer og værktøjer
• Velfungerende produkter fremfor omfattende dokumentation
• Samarbejde med kunden frem for kontraktforhandlinger
• Håndtering af forandringer frem for fastholdelse af en plan

Omdrejningspunktet i udviklingsmetoden er kortere 'time to market' og tættere samarbejde. Scrum er således en mere lærende eller eksperimentel tilgang, hvor man typisk opdeler udviklingen i mindre forløb med hver sin delleverance, som i højere grad tillader ændringer, samt sikrer hurtigere fremdrift. Forløbene indeholder de almindelige udviklingsaktiviteter: Analyse, design, konstruktion og test.

Beskrivelse af modellen
Agile Scrum strukturerer udvikling i små arbejdscyklusser, som strækker sig over en periode på 1-4 uger. Cyklusserne kalder man for Sprints, og de gentages efter hinanden uden pause. Hver Sprint har en fast slutdato, som aldrig kan udsættes, uanset om arbejdet er færdiggjort eller ej. Før en sprint kan påbegyndes, skal et hold af udviklere nedbryde et projekt til tidsestimerede aktiviteter, og fordele dem på udviklingsteamets medlemmer. Teamet får projekterne fra en Product Backlog, som er en prioriteret liste af indkommende udviklingsprojekter.

En product backlog skal prioriteres ud fra en kombination af tre kriterier:

1. Strategi: Det kan være af strategisk værdi at prioritere et udviklingsprojekt, der er målrettet mod en civilisation, hvortil virksomheden planlægger at ekspandere.
2. Værdi: Den forventede værdi er vigtig for prioriteringen. Værdi er som regel et spørgsmål om kroner og øre, men en prioritering på baggrund af værdi kunne også være ud fra ønsket om at skabe en endnu grønnere profil.
3. Balance: Det er vigtigt, at der er en balance i udviklingsprojekternes risiko, lige såvel som det er vigtigt, at der er balance i medarbejdernes arbejdsbyrde på projekterne.

Når Teamet sætter cyklussen i gang, forpligter de sig til at fuldføre alle elementerne i det udvalgte projekt. Derfor afholder man hver dag et stående møde, hvor man informerer hinanden om fremskridt og koordinerer indsatsen på de resterende opgaver. Mødet må ikke tage mere end 15 minutter. Under mødet skal hvert teammedlem besvare tre spørgsmål:

1. Hvad han/hun har gennemført siden sidste møde
2. Hvad han/hun vil gennemføre inden næste møde
3. Hvilke hindringer der evt. er i vejen for, at han/hun kan gennemføre sit arbejde

Når en sprint er afsluttet, præsenterer teamet resultatet og får konstruktiv feedback, som derefter kan inkorporeres i næste Sprint.

Introduktion til Scrum
Et Scrum team udgøres af tre roller: Product Owner, Team og Scrum Master.

Product owner
I Scrum er der kun én person, der har rollen som Produkt Ejer. Denne person skal være tilgængelig i hele udviklingsforløbet og skal sikre, at teamet arbejder fornuftigt, ud fra et forretningsmæssigt synspunkt.

En Product owner har et maksimalt vidensniveau om opgaven og er projektets interne kunde. Han repræsenterer kundens interesser ved at administrere en Product Backlog; en to-do liste, hvor alle indkommende krav og produkt specifikationer er opført i henhold til, hvor vigtige/profitable de anses for at være. Backlog’en er synlig for hele organisationen, så alle er klar over, hvad de kan forvente i fremtidige versioner af produktet.

En Product owner må ikke forveksles med en projektleder, da han i Scrum ikke er uddelegerende, men rollen kræver omfattende viden om teknik, markedsføring og forretningsudviklingsprocesser.

Team
Et team er de projektdeltagere, der udfører det egentlige arbejde af de projekter, der ligger øverst i Product Backlog’en. Teamet er selvorganiseret og består normalt af 5-9 personer - en størrelse, som erfaring har vist at være bedst for denne type arbejde.

I en Sprint Backlog nedbryder teamet projekter i aktiviteter, tidsestimerer dem og fordeler dem på teamets medlemmer. Time boxing indikerer et fastsat tidsrum, hvor teamet ikke må forstyrres i deres arbejde med tidsestimerede aktiviteter. Time boxing skal sikre, at teamet har optimale arbejdsbetingelser, således at aktiviteterne bliver udført til aftalt tid.

Det er vigtigt, at et Team har alle de nødvendige kompetencer for at fuldføre opgaven i løbet af en Sprint - og for at understøtte mest mulig fleksibilitet. Udover at bygge produktet, kommer teamet også med vigtige input og ideer til Product Owner om, hvordan man kan gøre produktet endnu bedre i forhold til kundens behov.

Scrum Master
En Scrum Masters vigtigste mission er at skabe de bedst mulige forudsætninger for, at Teamet realiserer de fastsatte mål. Dette sker bl.a. igennem en funktion som gatekeeper, hvor al information fra personer uden for projektet går gennem Scrum Masteren. Denne tager de vigtigste pointer med på det daglige møde, hvor informationen deles. Denne procedure sikrer, at Teamets deltagere forstyrres mindst muligt i deres arbejde. Skulle Teamet støde på problemer i deres arbejde, kan de henvende sig til Scrum Master, hvis opgave er at løse disse problemer og holde hjulene i gang. Formålet er at løfte holdets niveau af aktivitet og øge motivationen forud for næste Sprint.

Visualisering
I forbindelse med Scrum har man behov for et værktøj til at styre processen, og der er stor forskel på de værktøjer, der bruges til at understøtte Scrum udvikling. Værktøjerne spænder fra lavpraktiske lister og Post-it sedler, som udelukkende håndteres manuelt, til avancerede digitaliserede systemer. Et af de mest centrale værktøjer er en Scrum tavle, som synliggør status og eventuelle problemer.

Det er typisk omkring Scrum tavlen, at et projektteam samles i forbindelse med det daglige møde. Her kan tavlen bl.a. være med til at højne kvaliteten i diskussionerne og koordineringen af indsatser mod et fælles mål. Lavpraktiske tavler fungerer bedst i projekter, hvor hele Scrum teamet kan samles, hvorimod udviklingsafdelinger med fragmenterede og globaliserede teams stiller større krav, da kommunikation over distancer og tidszoner er meget vanskeligt.

Normalt håndteres Sprint backlog’en på tavlen ved, at den opsplittes i små sedler, som flyttes og skifter status i forbindelse med det daglige Scrum møde. Hver gang en opgave er færdig, flyttes den til en 'Færdig' kategori og registreres på en Burndown graf. Burndown grafen viser status på løste opgaver i forhold til de totalt planlagte opgaver.

Agile metoder sikrer visualisering og forbedret arbejdsflow
Scrum er en procesramme, hvori vi eksekverer opgaver. Opgaverne samles i en batch, hvis størrelse svarer til længden af en defineret sprint - og opgaverne afsluttes, før næste sprint kan påbegyndes. På den måde adskiller Scrum sig fra andre kendte Lean værktøjer, -metoder og -rutiner. På trods af dette synes lighederne alligevel at overskygge, hvad enten man helliger sig Kanban, Kaizen eller Toyota Kata. Uagtet metoden til at udføre arbejdet, handler det grundlæggende om at visualisere og forbedre arbejdsflowet.

En arbejdsmetode udviklet på agile principper giver en struktureret tilgang til komplekse opgaver. Arbejdet understøttes af en facilitator, men teammedlemmer oplever stort ejerskab. Visualiseringen giver overblik og synliggør teamets fremdrift og resultater. Det er en anerkendelse af teamets præstationer, hvori der er indlagt feedback loop til retrospektiv læring.

Agile principper kan tilpasses de processer og arbejdssystemer, dit team og/eller virksomhed allerede har på plads. Formålet er at hjælpe med at styre projekter, arbejdsgange og processer på en måde, der fungerer bedst for alle.