Ken Schwaber & Jeff Sutherland opfandt Scrum tilbage i 1990’erme. I 2010 kom så den første officielle Scrum Guide som de i alt beskedenhed, kalder ”Den ultimative guide til Scrum: spillets regler”.
I dette indlæg gennemgår jeg de væsentligste ændringer fra 2017 til 2020 udgaven med udgangspunkt i forfatternes egne beskrivelser. Sidst i indlægget kommer jeg med min egen vurdering af, om den nye version er bedre end den forrige. Hvis du er mere til lyd, kan jeg anbefale vores to podcastafsnit om henholdsvis 2017 og 2020 guiden:
- Podcast om 2017-versionen (optakt til den nye guide): lyt med her
- Podcast om 2020-versionen (umiddelbare reaktioner): lyt med her
Scrum er stadig Scrum
Lad det være sagt med det samme – Scrum er stadig Scrum. Ændringerne til den nye version af guiden kan synes markante, men ånden i Scrum er stadig den samme. Nystartede teams vil måske mangle den guidance, 2017-versionen gav, men modne teams vil formentlig ikke opleve den store forskel. Dog skal de være opmærksomme på, at 2020 udgaven bl.a. introducerer Product Goal som et nyt artefakt.
Mindre præskriptiv
I årenes løb var Scrum Guiden blevet en smule mere præskriptive for her ny opdatering. 2020-versionen har til formål at bringe Scrum tilbage til at være et minimalistisk, men tilstrækkelig, rammeværk for løsning af komplekse problemer. Det ser man bl.a., ved at præskriptive elementer, som f.eks. de tre spørgsmål, man stiller til Daily Scrum, er blevet fjernet. Det er nu op til teamet selv at definere, hvilke spørgsmål der skaber størst værdi for dem. Desuden er sproget generet blevet blødere og dermed mindre præskriptivt.
Ét team med fokus på ét produkt
Et af målene med den nye guide har været at fjerne den team-i-teamet konstruktion, som Udviklingsteamet kunne opfattes som. Jeg skriver ”kunne», fordi “os og dem” adfærd mellem PO og udviklingsteamet, aldrig har været ånden i Scrums. Fra og med 2020 er der nu kun ét team, Scrumteamet, der fokuserer på det samme mål med tre ansvarsområder inden for teamet: Product Owner, Scrum Master og udviklere.
Introduktion af produktmål
Hvor ét team tankegangen blot er en eksplicitering af ånden i Scrum, så er introduktionen af et produktmål en reel nyhed. Formålet er ifølge Ken og Jeff at give teamet en mekanisme til at fokusere på ét, større, værdifuldt mål. Hver Sprint, og dermed sprintmål skal bringe produktet tættere på det overordnede produktmål. Scrum understøtter dermed muligheden for at have både det korte (sprintmål) og det lange (produktmål) lys på. Det er noget, jeg har oplevet specielt mange interessenter omkring agile teams efterlyse.
Et hjem for sprintmål, Definition of Done og produktmål
Tidligere Scrum Guides beskrev sprintmål og Definition of Done uden egentlig at give dem en identitet. De var beskrevet i anførselstegn og var således ikke rigtige artefakter. Med tilføjelsen af produktmål bliver deres berettigelse i 2020 tydeligere. Hver af de tre artefakter i Scrum har nu commitment knyttet til sig. For Product Backlog er det produktmålet for Sprint Backlog er det sprintmålet, og Produktinkrementet har Definition of Done. De er dermed med til at øge transparensen og fokus på udviklingen af hvert artefakt.
Selvstyring over selv-organiserende tidligere
2017-versionen omtalte udviklingsteamet som selv-organiserende, hvilket betød, at teamet selv valgte, hvem og hvordan de skulle arbejde. 2020-versionen fremhæver det selvledende team, der selv vælger, hvem, hvordan og hvad man skal arbejde på. Dette er en naturlig konsekvens af det øget fokus på ét team frem for en Produkt Owner med/mod et udviklingsteam. Fremover skal teamet i forbindelse med sprintplanlægning også forholde sig til, «Hvorfor”, udover ”Hvad” og ”Hvordan”.
Hvem trykker på releaseknappen?
En anden konsekvens af ét team tankegangen og den øgede selv-ledelse er, at Product Owner ikke længere har det afgørende ord i forhold til om, og hvornår et produkt skal idriftsættes. Hvor den tidligere guide nævnte ”release” 8 gange, så figurer ”release” kun en gang i den 2020-versionen. I forbindelse med introduktionen af Definition of Done (DoD) som commitment beskriver guiden, at et Product Backlog Item ikke kan idriftsættes eller vises til Sprint Review, hvis ikke det lever op til DoD. Dermed er der lagt op til øget fokus, som team på hvilke kvalitetskriterier, både fra et forretningsmæssigt og teknisk perspektiv, der skal være opfyldt, for at en produktversion er klar til release.
Scrum for et bredere publikum
2020-versionen er 4 sider kortere end 2017-versionen. Forenklingen er primært opnået ved at eliminere overflødige og komplekse vendinger. Samtidig har man fjernet IT-specifikke termer, som f.eks. test, system, design, krav osv. Forfatterne understreger dermed, at Scrum er et framework til at hjælpe en gruppe mennesker arbejde sammen om at løse komplekse problemstillinger, uanset om det er inden for IT, markedsføring, produktudvikling, eller et helt andet fagområde.
En bedre Scrum Guide?
Ovenstående beskrivelser af den nye guide i høj grad baseret på forfatternes udmeldinger, og dermed i mindre grad udtryk for mine egne holdninger. Det vil jeg råde bod på her.
Personligt hilser jeg den nye version af guiden velkommen. Det er tydeligt, at forfatterne har analyseret, hvordan Scrum er blevet anvendt, og har forsøgt at tage et opgør med mange af de uhensigtsmæssige. den tidligere version har ført med sig. Et godt eksempel er understregning af, at Product Owner og udviklingsteamet er på samme hold og skal have fælles mål.
Jeg er også stor fan af, at forfatterne ikke er faldet for fristelsen til at gøre Scrum unødigt kompleks. Hvor andre frameworks for hver version eksploderer i kompleksitet og nye konfigurationer for at omfavne alverdens best practices, trends og døgnfluer, så er Scrum stadig uhyre enkelt. Det er som forfatterne skriver; et bevidst, ufuldstændigt rammeværk, der kun lige definerer de dele, der er nødvendige for at implementere Scrum teorien.
Den nye guide er dog ikke uden faldgruber. Man kan argumentere for, at en simplere guide med færre præskriptive elementer ikke kun er en mulighed, men også åbner en ladeport for misbrug og misforståelser. Her spiller lederen en særlig rolle. De kan være med til at skabe de helt rigtige betingelser/forudsætninger, for at organisationen får det optimale udbytte af Scrum rammeværket. På fredag udkommer jeg derfor som tidligere nævnt med et indlæg om, hvad ledere skal være særligt opmærksomme på i den nye guide. Det er desuden et emne, vi ivrigt debatterer på Professional Agile Leadership (PAL-E) kurset. Du kan se, hvornår jeg næste gang holder kurset på ugilic.dk/kurser under For ledere.
Har du læst den nye guide? På hvilke punkter synes du, at den er bedre eller dårligere end 2017-versionen? Eller har du spørgsmål til guiden? Så tøv ikke med at anvende kommentarfeltet herunder, eller kontakt mig direkte på martin@ugilic.dk
Du finder den nye Scrumguide på: https://www.scrumguides.org/
Image credit: unsplash.com
