Acht opvallende veranderingen in de nieuwe update van de Scrum Guide - TMC (nl) Shape caret-double-left caret-double-right caret-down caret-left caret-right-circle caret-right Shape close dropdown expand more facebook Logo linkedin logo-footer logo-mark logo-mobile mail play search twitter youtube instagram
Menu Sluiten
article

Acht opvallende veranderingen in de nieuwe update van de Scrum Guide

De Scrum Guide heeft een behoorlijke update gekregen in november 2020. Wat is er veranderd, wat zit daar achter? En wat betekent dat voor jouw Scrum team vandaag?

Het Agile Manifesto begint met de woorden: “We are uncovering better ways of developing software by doing it and helping others do it.” Een van de kernwaarden van Agile is het ‘reageren op verandering’. Die verandering geldt niet alleen voor het werk dat je doet of het product dat je maakt, maar het geldt ook voor je werkwijze met Scrum.

Op woensdag 18 november 2020 werd in een livestream de 25e verjaardag van Scrum gevierd. Hier werd door de makers van Scrum, Jeff Sutherland en Ken Schwaber, een nieuwe update van de Scrum Guide gepresenteerd. Want ook de ontwikkeling van Scrum ‘reageert op verandering’.

“Scrum at its core is empirical; so all of your insights and experiences are pulled in to making Scrum better.” – Jeff Sutherland.

Wat vooral opvalt is dat de Scrum guide korter is geworden. De Scrum Guide is van 19 pagina’s naar een magere 13 pagina’s gegaan. Minder woorden, betere formulering. Meer wat je moet doen, minder hoe je het moet doen. Waar zijn bijvoorbeeld de drie bekende vragen van de Daily Scrum gebleven? Het wat staat in de Scrum Guide en wordt onder toeziend oog van de Scrum Master uitgevoerd. Het hoe wordt overgelaten aan het Scrum Team. Zij kunnen immers de beste oplossing bepalen voor hun specifieke situatie.

Afbeelding: het bijgewerkte Scrum Framework. Illustratie door Linda van Sinten, Creatieve Elephant

Wat is er veranderd?

  1. Scrum is korter en duidelijker beschreven voor een breder publiek.
    “Scrum hasn’t changed, we just found a better way to describe it” – Jeff Sutherland & Ken Schwaber
    De uitleg is duidelijker geworden met minder woorden en zonder IT specifieke woorden als bijvoorbeeld ‘requirement’ en ‘testen’. Het enige woord dat nog een connectie met IT lijkt te hebben is het woord ‘developer’ (ontwikkelaar). Een ontwikkelaar is niet alleen iemand die code schrijft. Een team kan ook een opleidingscurriculum ontwikkelen of een mediacampagne. Scrum wordt al een tijd niet meer alleen maar in software gebruikt en nu is de Scrum Guide daar ook klaar voor.

  2. Scrum is minder voorschrijvend.
    In een eerdere versie van de Scrum Guide wilden de makers van Scrum de Scrum Teams op weg helpen door handvatten te geven. Een voorbeeld daarvan zijn de drie bekende vragen van de Daily Scrum. Dit leidde echter in (te) veel gevallen tot de verkeerde situatie. Het doel van de Daily Scrum is om de voortgang tot de Sprint Goal te inspecteren en om met het team een plan te maken voor de komende dag. In de realiteit werd de Daily Scrum door antwoord te geven op de drie vragen vaak een simpele, saaie update. De ontwikkelaars binnen het Scrum Team kunnen nu volgens de Scrum Guide zelf kiezen hoe ze de Daily Scrum invullen, zolang de Daily zich focust op de voortgang tot de sprint goal en een plan voor de dag oplevert. Dit was altijd al mogelijk, maar nu beschrijft Scrum meer wat er moet gebeuren en minder hoe je het moet doen.

  3. Er is één Scrum Team dat aan één product werkt.
    Scrum had het concept van een ontwikkelteam binnen het Scrum Team. Dat leidde mogelijk tot een barrière tussen de Product Owner en het ontwikkelteam. In de nieuwe versie is er nog maar één team: het Scrum Team. Bestaande uit: één Product Owner, één Scrum Master en ontwikkelaars. Het Scrum Team als geheel is verantwoordelijk voor het creëren van een bruikbaar en waardevol increment, elke sprint. Er is geen apart ontwikkelteam binnen het Scrum Team meer. Het doel is om geen ‘wij-zij’ mentaliteit te creëren tussen de ontwikkelaars en de Product Owner, maar om als één team samen te werken naar een gezamenlijk doel. “We’re all in this together.” – Ken Schwaber.

    Binnen het team wordt niet meer gesproken over rollen. Wat de rollen Scrum Master, Product Owner en Developer waren zijn nu verantwoordelijkheden (accountabilities) geworden. Het is nu ook duidelijker beschreven wat de verantwoordelijkheden zijn. Bijvoorbeeld wordt expliciet beschreven dat de Scrum Master verantwoordelijk is voor de effectiviteit van het team door het team te helpen zichzelf te verbeteren.

  4. Introductie van de Product Goal.
    Met de introductie van een Product Goal wordt een doel voor het product beschreven op langere termijn. De Product Goal is de som van alle items in de product backlog. Het geeft antwoord op de vraag ‘Waar werken we met alle sprints naartoe?’ Als kip zonder kop aftikken van items die de Product Owner in de backlog plakt, werkt niet bijzonder motiverend. De Product Goal geeft focus. Als Scrum Team wil je weten waar je naartoe werkt, wat het doel is van de organisatie. Zodra het team weet naar welk doel ze toe werken, dan helpt de Product Goal met het geven van richting bij het nemen van beslissingen tijdens het ontwikkelwerk.

  5. Meer nadruk op de Sprint goal, Definition of Done en de Product Goal.
    De drie artefacten van Scrum (Product Backlog, Sprint Backlog en het Product Increment) worden sinds de nieuwe update van de Scrum Guide ondersteund door drie commitments. De Sprint goal en de Definition of Done zijn niet nieuw in Scrum, maar met deze verandering is de positie duidelijker geworden. Ze geven transparantie en focus aan de drie artefacten.
    a. De Product backlog heeft als commitment de Product Goal.
    b. De Sprint Backlog heeft als commitment de Sprint goal.
    c. Het increment heeft als commitment de Definition of Done.

    Bij de Definition of Done is er een verandering gekomen in de bewoordingen van het increment. “The moment a Product Backlog item meets the Definition of Done, an Increment is born. In de vorige versie van de Scrum Guide werd het increment beschreven als iets dat aan het einde van de sprint wordt opgeleverd. Met deze verandering suggereert Scrum dat zodra een backlog item voldoet aan de Definition of Done, het gelijk gereleased kan worden door de Product Owner, nog voor het einde van de sprint. Volgens Jeff Sutherland zorgt dit ervoor dat teams met z’n allen op Backlog Items kunnen ‘Swarmen’. Dat betekent dat het hele team zich richt op het zo snel mogelijk afmaken van de meest waardevolle items, voordat het aan het volgende item begint. Dit voorkomt het ‘watervallen van een Sprint’, waarbij de teamleden aan verschillende items tegelijk werken en ze aan het einde van een Sprint allemaal afmaken. Tijd om je DevOps skills te verbeteren!

  6. Nieuw onderdeel van de Sprint planning: De Waarom?
    Afbeelding: Sprint Planning. Illustratie door Linda van Sinten, Creatieve Elephant.

    Naast de vragen “Wat gaan we maken?” en “Hoe gaan we het maken?” heeft de Sprint planning nu een derde vraag gekregen: “Waarom gaan we dit maken?” De “waarom” vraag van een sprint geeft meer duidelijkheid waarom we een sprint doen. Dit hangt nauw samen met de nieuwe Product Goal. Waarom geeft deze sprint waarde aan het product of de stakeholders?

    Met deze toevoeging willen de makers van Scrum voorkomen dat Scrum Teams zogenaamde ‘feature factories’ worden die sprint na sprint alle features aftikken die van tevoren in een sprint planning zijn gekozen. Bij het werken aan complexe problemen kan door het opdoen van nieuwe inzichten de scope van het werk dagelijks veranderen. Door de sprint goal in te vullen met de nieuwe waaromvraag, wordt richting gegeven aan de beslissingen die je moet nemen over het werk tijdens de sprint. Misschien is de meest gebruikte sprint goal: “Maak alle items in de sprint backlog af”. Hier kom je in Scrum 2020 niet meer mee weg. En dat is maar goed ook!

  7. Andere bewoordingen: self-managing en geen servant-leader meer?
    Wij zeggen friet, jij zegt patat. Daar lijkt het een beetje op met de verandering van bewoordingen. Maar er zit meer achter. Het Scrum Team is niet meer ‘self-organizing’ maar is nu ‘self-managing’. Met de nieuwe focus op het Scrum Team als geheel wilden de schrijvers duidelijker maken dat het team zelf verantwoordelijk is om te bepalen wie, hoe en wat gemaakt wordt.

    De definitie ‘servant-leader’ voor de Scrum Master is ook niet buiten schot gebleven. De verantwoordelijkheid van Scrum Master wordt nu omschreven als ‘true leader who serves the Scrum Team and the larger organization.’ De term ‘servant-leader’ werd vaak verkeerd uitgelegd. Door die term kon de Scrum Master gezien worden als iemand die niet verantwoordelijk is voor de vooruitgang van een team maar meer als een soort secretaris. Door het woord ‘leader’ voorop te plaatsen wilden ze de focus terugplaatsen naar het belangrijkste: het leiderschap.

  8. Backlog items niet meer inschatten?
    Waar is het woordje ‘estimate’ naartoe? Drie alinea’s over het inschatten en verduidelijken van de product backlog items zijn teruggebracht naar één alinea met twee keer het woordje ‘size’. Hoe (en óf) je backlog items op grootte/tijd/waarde inschat en hoeveel tijd je daarvoor neemt, wordt niet voorgeschreven door Scrum. Of je punten, T-shirt sizes of #noestimates gebruikt mag het team zelf bepalen. Bij de Product Backlog wordt alleen nog gesproken over ‘sizing’ van items. De discussie over het wel of niet inschatten van backlog items is een stevige. En Scrum houdt hierbij alle opties open.

De Scrum Guide bevat de definitie van Scrum. Deze definitie is geschreven voor het gebruik van Scrum in alle industrieën en domeinen. Scrum is niet alleen meer gericht op softwareontwikkeling. Met deze update aan de Scrum Guide is Scrum nog meer een minimaal en lichtgewicht framework geworden. Het is ook opzettelijk incompleet gehouden. Ken Schwaber, een van de schrijvers van de Scrum Guide, zegt: ‘just do it.’ De zin ‘Scrum is easy to understand, but difficult to master’ is uit de Scrum Guide gehaald. Maar in de praktijk blijkt dit nog altijd waar.

Nu Scrum nog lichtgewichter is beschreven en er nog minder is voorgeschreven, kan het lastig zijn voor nieuwe teams om met Scrum te beginnen. En bestaande teams kunnen zichzelf gemakkelijk verliezen in de waan van de dag. Daarom is het nu belangrijker dan ooit om een goede Scrum Master of Agile Coach te hebben die de teams begeleidt en de juiste balans kan faciliteren in een sprint. TMC Agile kan je daarbij helpen. Ben je van plan om te starten met Scrum voor je organisatie? Of ben je al een tijdje bezig maar mis je het vliegwiel? Huur een ervaren Scrum Master of Agile coach in en geef je team en je organisatie die Agile boost die je nodig hebt!

Meer weten? Neem dan contact op met Bart van Nieuwburg of Teun van Hoesel.

Wat is je volgende stap? We kunnen je daarbij helpen

Stel je vraag