Op 18 november is er een nieuwe versie van de Scrum Guide gepresenteerd. Daar waar er in 2017 een kleine update is geweest, is er dit jaar een grote aanpassing aangekondigd. Als opleider willen we je natuurlijk meenemen in de veranderingen.

In de vorige blogs beschreef ik de meest opvallende veranderingen en de veranderingen die de Product Owner moet weten. In dit blog gaan we het hebben over de veranderingen voor de Scrum Master en in de volgende blog – voor de Developers.

Eindverantwoordelijk* voor het opzetten van Scrum zoals staat beschreven in de Scrum Guide

En dat ben je als Scrum Master niet alleen voor het Scrum Team, maar voor de hele organisatie. Scrum Masters doen dit door iedereen te helpen om Scrum theorie en praktijk te begrijpen en te laten werken, bijvoorbeeld door het trainen, coachen en adviseren van de organisatie in haar Scrum adoptie. Dat is wel even wat anders dan ‘verantwoordelijk zijn voor het promoten en ondersteunen van Scrum’, zoals dat stond beschreven in de 2017 versie van de Scrum Guide.

Daarnaast ben je als Scrum Master ook eindverantwoordelijk voor de effectiviteit van het Scrum Team. Scrum Masters zijn in de nieuwe Scrum Guide echte leiders geworden, die het Scrum Team en de grotere organisatie dienen.

In de inleiding van de Scrum Guide staat de volgende zin, een vergelijkbare stond overigens ook in de oude Scrum Guide: ‘Het basisontwerp of ideeën van Scrum aanpassen, het weglaten van elementen of de regels van Scrum niet volgen, verbergt problemen en beperkt de voordelen van Scrum en maakt het potentieel zelfs nutteloos.’

Werkt jullie Scrum Team (minimaal) zoals staat beschreven in de Scrum Guide?

Schalen naar meerdere Scrum teams

Hier heb ik in het eerste deel van deze blogreeks ook over geschreven. In de Scrum Guide staat nu:

‘Als Scrum Teams te groot worden, kunnen ze overwegen om zich te reorganiseren naar meerdere samenhangende Scrum Teams, elk gericht op hetzelfde product. Om deze reden zouden deze Scrum Teams zowel het Product Doel, de Product Backlog en de Product Owner moeten delen.’

Het is best wel een ingrijpende verandering om van één Scrum Team naar meerdere samenhangende Scrum Teams te gaan. Zowel voor het Scrum Team als voor de organisatie. Gelukkig zijn er raamwerken zoals bijvoorbeeld Nexus, Scrum@Scale en LeSS die je kunt gebruiken. Onder het vorige kopje hebben we gezien dat de je als Scrum Master de adviseur van de organisatie bent in haar Scrum adoptie. Maak je borst maar nat dus.

Mochten jullie met meerdere Scrum Teams aan één product werken, hebben deze teams een gedeelde Product Backlog en Product Owner?

Diverse kleine veranderingen met soms aanzienlijke impact

Er is een hele rits kleine veranderingen waarvan ik denk dat je ze als Scrum Master moet kennen. Een aantal is uitgebreider behandeld in andere blogs van deze reeks, daar verwijs ik dan naar. Ik behandel ze hier kort:

  • Er bestaat geen Development Team meer, enkel Developers. Voorheen stond expliciet beschreven hoe groot dit Development team minimaal en maximaal was. In de huidige versie van de Scrum Guide staat dat het hele Scrum Team klein genoeg is om wendbaar te blijven en groot genoeg om werk van betekenis te voltooien binnen een Sprint. Een typisch Scrum Team bestaat uit 10 of minder personen. Het zou dus ook groter kunnen zijn. Dit wordt echter niet aangeraden aangezien kleine teams over het algemeen beter communiceren en productiever zijn.
  • Introductie van de commitment Product Doel. De Product Owner is eindverantwoordelijk* voor het ontwikkelen en duidelijk overbrengen van het Product Doel, en jij dient als Scrum Master de Product Owner bij het vinden van technieken voor effectieve Product Doel definitie. Dit Product Doel komt in diverse Scrum Events terug. In mijn vorige blog lees je hier meer over.
  • Er is een onderwerp toegevoegd aan de Scrum Planning: Waarom is deze Sprint waardevol. Ook hier lees je in mijn vorige blog  meer over.
  • De drie optionele vragen van de Daily Scrum zijn geschrapt, ze zorgden er te veel voor dat de Daily Scrum een status update werd. Lijkt jullie Daily Scrum meer op een status update dan een moment waarop de voortgang richting het Sprint Doel wordt geïnspecteerd, de Sprint Backlog waar nodig wordt aangepast en aankomend gepland werk wordt bijgesteld? Dan is de Daily Scrum niet zoals die bedoeld is, en zeer waarschijnlijk niet productief. Het is jouw taak als Scrum Master ervoor te zorgen dat alle Scrum gebeurtenissen plaatsvinden en dat deze positief, productief en binnen de timebox zijn. Werk aan de winkel dus!
  • Het Product Doel komt ook weer terug in de Sprint Review. In mijn vorige blog lees je hier meer over, maar wat ik hier nog even wil melden is dat de Sprint Review nadrukkelijk een werksessie is. Het Scrum Team zou moeten vermijden dat het bij een presentatie blijft. Meer dan eens heb ik bij mijn klanten gezien dat het niet meer is dan een presentatie. Soms heb ik ervaren dat er een demo werd gegeven met behulp van een mock-up tool. Regelmatig zag ik een demo op een test- of acceptatieomgeving. Maar een echte werksessie, waar belanghebbenden het Increment in de handen kregen om ermee te ‘spelen’ heb ik maar heel zelden gezien. De time-box is 4 uur, ook bij een Sprint van 2 weken. Maak daar gebruik van! Na feedback van gebruikers is dit misschien wel hét moment waarop je de waardevolste feedback kunt krijgen. De kans dat je waardevolle feedback krijgt bij een gelikte presentatie of een goed voorbereide demo met perfecte data, is niet zo groot.
  • Tijdens mijn trainingen zeg ik vaak dat de Sprint Retrospective misschien wel het belangrijkste Event is voor de Scrum Master. Sinds de update van de Scrum Guide durf ik wel te beweren dat dit ook echt zo is. Het doel van de Sprint Retrospective is nu namelijk ‘om manieren te bedenken om kwaliteit en effectiviteit te verhogen en in te plannen.’ En jij bent als Scrum Master eindverantwoordelijk* voor de effectiviteit van het gehele Scrum Team. In dit Event krijg je daarbij hulp van het hele Scrum Team. Maak daar gebruik van!
  • Er is behoorlijk gesnoeid in het stuk over de Product Backlog om Scrum beter leesbaar en breder toepasbaar te maken. Zo zijn de verplichte ‘inschattingen’ verdwenen en vervangen door een optionele grootte van een Product Backlog item. Daar waar het de Product Owner helpt met de prioritering, de voorspelbaarheid van het Scrum Team verhoogt of de Developers helpt bij het plannen van de Sprint, zou ik zeker doorgaan met het inschatten van de grootte van Product Backlog Items.
  • De Definition of Done is gepositioneerd als commitment van het Increment, en wordt gezien als poort (‘gate’ in het Engels) naar het vrijgeven van waarde. De Sprint Review is nadrukkelijk niet zo’n poort. Een Gebruikers Acceptatie Test (GAT) die plaatsvindt na de Sprint Review is dit natuurlijk ook niet. Als de organisatie een GAT wenst, eist of nodig heeft, dan heb jij als adviseur van de organisatie nog wat werk te verrichten.
  • … en nog veel meer. Als Scrum Master ben je aansprakelijk voor het leiden, trainen en coachen van de organisatie in haar Scrum adoptie. Lees de nieuwe Scrum Guide dus nog even goed door, als je dat niet al gedaan hebt.

Heb jij de nieuwe Scrum Guide gelezen en ben je op de hoogte van alle veranderingen die voor jullie relevant zijn?

Wat zijn Next steps voor mij als Scrum Master?

Mijn conclusie is dat het bij elkaar een behoorlijke verzwaring van het werk van de Scrum Master is. Ik kan me dan ook goed voorstellen dat je ‘Nee’ hebt geantwoord op één of meer van de vragen onderaan de alinea’s. Onze consultants kunnen helpen in de opleiding, bijscholing, ondersteuning en coaching van Scrum Masters of bij vraagstukken die betrekking hebben tot het opschalen naar meerdere samenhangende Scrum Teams. Ook kun je je natuurlijk altijd inschrijven voor onze training Advanced Scrum Master. Ben je onlangs begonnen als Scrum Master, of ga je binnenkort beginnen? Kijk dan eens of onze Scrum Master of Virtuele Scrum Master training iets voor je is.

*In de vorige blog heb ik ‘accountable’ vertaald met ‘aansprakelijk’. Na een discussie met collega’s en met peers op LinkedIn heb ik dit aangepast naar ‘eindverantwoordelijk’. Dit is net als ‘aansprakelijk’ zwaarder dan ‘verantwoordelijk’ uit de Nederlandse vertaling, maar heeft niet de negatieve toon van ‘aansprakelijk’. Daarnaast is het in lijn met het RACI-model.

Ook interessant

Meer weten?

Wilt u hier meer over weten, dan kunt u bij inspearit en/of cibit academy daarvoor terecht. Bel daarvoor 030-2308900 of stuur een mail naar info.nl@inspearit.com.

Stefan Kennedie Stefan is een enthousiaste Scrum en Agile consultant en trainer die veel ervaring heeft in het trainen en coachen van professionals voor wie Agile en Scrum nieuw zijn. Hij heeft uitgebreide ervaring in het toepassen van Scrum bij organisaties buiten het IT-domein.

Heeft u een vraag?

Neem contact op