Ved du at man kan være agil uden at køre Scrum – og at det også er muligt at køre Scrum uden at være agil? Jeg deltog fornylig i en diskussion omkring forskellen mellem de to koncepter: Agil og Scrum. Mange tror, fejlagtigt, at de er agile blot fordi de kører Scrum. Det er en basal antagelse, som kan have store konsekvenser for succes. Definition:
Agil: Det agile manifest er grundstenen i at være agil. Én af de væsentligste faktorer i manifestet er at forstå at det er et værdisæt der bl.a. omfatter en vægtning mellem individer over process, fungerende applikationer over omfattende dokumentation, m.v.
Scrum: En metode der introducerer en række roller, artefakter samt mødetyper.
Kan du se forskellen? Indfører man den mekaniske del af Scrum, altså fordeler roller, starter op på artefakter samt indkalder til møder, uden at adoptere det agile værdisæt – så er man ikke mere agil end før indførslen. Mange virksomheder udmærker sig ved at have indført Scrum og følge metoden “by the book”. Det har en række fordele, så som opdeling i inkrementer (sprints), fokus på forbedringer (retrospective) samt fokus på fremdrift (standups). Scrum er, som nævnt, en metode. Denne metode er skabt med afsæt i det agile manifest, med det agile værdisæt som kerne. Nedbryder vi det agile manifest kan vi se at Scrum forholder sig således:
- Individ over process: Et Scrum Team er selvorganiserende og arbejder i et vis omfang autonomt med en Scrum Master som pedel. I princippet beskriver Scrum ikke hvordan et Scrum Team kommer fra et krav (user story) udarbejdet af Product Owner og frem til det stykke software som Product Owner senere skal verificere og godkende.
- Fungerende applikationer over omfattende dokumentation: Én af omdrejningspunkterne i Scrum er at hvert inkrement (sprint) afleverer Scrum Teamet en mængde applikationer der er færdig udviklet. Product Owner verificerer og godkender om det leverede lever op til forventningerne. Dokumentation af det leverede er vigtigt, men ikke vigtigere end at have fungerende applikationer.
- Samarbejde med kunde over kontraktforhandling: En Product Owner er intrduceret for at bygge bro mellem de traditionelle kontraktuelle kravsspecifikationer og det arbejdende Scrum Team. Via hyppig kontakt, gennem Grooming sessioner og Sprint Reviews, bliver Scrum Teams arbejde verificeret med kunden og dens ønsker.
- Håndtering af ændringer over planlægning: En Product Owner ejer en Product og evt. Release Backlog, som kontinuert bliver vedligeholdt med øje for aktuel prioritering af opgaver. Via hyppig kontakt mellem Scrum Team og Product Owner opnåes en mere fleksibel (agil) tilgang til kravshåndtering og implementeringsplaner.
Problemstillingen mellem de koncepter bliver for tiden diskuteret flittigt i den agile verden:
Leave a Reply