Scrum simulatie escaleert schitterend

Scrum uitleggen door middel van een simulatie. Dat leek een goede aanpak, alleen liep dat helaas niet zo soepel. Het escaleerde zelfs zo erg, dat een deelnemer vertrok. Soms gaat iets weleens minder goed dan vooraf bedacht. Toch hebben we dit weten om te buigen naar iets positiefs. In dit geval levert dat waardevolle learnings op. Daarbij kwam juist de kracht van Scrum naar voren! De inzichten die deze sessie opleverde, wil ik graag transparant met jullie delen. Lees hoe een vastgelopen sessie met ongelukkige deelnemers werd omgebogen dankzij Scrum.

Scrum simulatie sessie

Vooraf hadden we twee doelen met deze sessie:

1. Voor drie producten een Product Backlog creëren
2. De Scrum events leren door ze te ervaren

Deze blog verscheen eerder op scrum.nl.

Scrum rollen verdeeld

Tijdens de sessie werden de Scrum rollen verdeeld:

• De organisatoren van de sessie namen de rol van Product Owner op zich. De teams konden tijdens de verschillende Scrum events bij hen terecht voor inhoudelijke vragen.
• Samen met een collega vulde ik de rol van Scrum Master in. We faciliteerden de sessie, zorgen ervoor dat iedereen materialen (flipovers, stiften en post-its) had en hielden de timeboxes van de Scrum events in de gaten met een timer.
• De grote groep werd verdeeld in drie Development Teams die alle drie een product vertegenwoordigden. Tijdens de Sprint gingen zij aan de slag met de producten.

Scrum events met doelen en timebox

De sessie begon met de visie (en vragen) van de Product Owner, zoals een Sprint Planning start. Hierdoor werd duidelijk waarvan deze Sprints in het teken staan. Vervolgens deden we drie Sprints van 30 minuten. Hieronder het overzicht van de Scrum events, met bijbehorende doelen en timeboxes:

• Sprint Planning (2,5 minuut)
  Maak een plan, bepaal wat we deze Sprint kunnen opleveren en hoe we dat gaan doen. Formuleer een Sprint Goal.
• Sprint (10 minuten)
  Voer het plan uit (beantwoord de vragen van de Product Owner) en maak hiervan Product Backlog Items. Benoem taken.
• Review (3x 5 minuten)
  Toon aan de stakeholders wat je hebt opgeleverd in de Sprint, vraag feedback en bepaal gezamenlijk de vervolgstappen.
• Retrospective (2,5 minuut)
  Bespreek hoe de Sprint is verlopen, wat we kunnen verbeteren aan het proces of de samenwerking en benoem actiepunten voor de volgende Sprint.

Feedback op de eerste Sprint

Tot zover alles prima, zou je denken. Alleen vertrok een deelnemer na de eerste Sprint. Diegene ervaarde de timeboxes als een bepaalde (tijds)druk waarbinnen het werk opgeleverd moest worden. Daar voelde deze persoon zich dusdanig onprettig bij, dat hij de sessie verliet. Jammer dat dit niet voorkomen kon worden, maar goed dat daarmee de anderen werden getriggerd. Hierdoor kwamen namelijk ook andere deelnemers met feedback tijdens de Retrospective. Twee gehoorde klachten:

1. De timeboxes geven mij een bepaalde tijdsdruk.
2. De feedback die ik als stakeholder geef, is niet echt relevant.

Agile door inspelen op verandering

De feedback tijdens de Retrospective hebben we natuurlijk van harte aangenomen. Scrum was namelijk niet het hoofddoel, maar het middel om met de producten aan de slag te gaan. Hier wilden we juist flexibel mee omgaan en daarom hebben we het programma omgegooid. Geheel volgens het Agile Manifesto verkozen we “inspelen op verandering” boven “het volgen van een plan”. Daarnaast besloten we om nog één in plaats van twee Sprints te doen. De Scrum Events hebben we omgegooid én timeboxes aangepast:

• Sprint Planning: Een nieuwe planning was niet echt meer nodig want het Sprint Goal vanuit de eerste Sprint konden we verder uitbreiden in de tweede Sprint. Dit klinkt heel fout als je dit met een Scrumteam zomaar zou doen, maar voor deze sessie was dat prima.
• Sprint: In plaats van tien minuten, hebben we de timebox verdubbeld. Enerzijds om die tijdsdruk te verminderen en anderzijds om nog een flinke slag met de Product Backlog te maken. Ook dit (de timebox verlengen) is niet aan te raden voor een Scrumteam, maar voor deze sessie wederom een goede oplossing.
• Review: Voor deze simulatie was de feedback vanuit de andere groepen minder relevant, omdat zij minder van de (andere) producten afweten. Vandaar dat we ervoor gekozen hebben om alleen een demo te doen. Alle groepen presenteerden dus even kort aan de rest wat er na de tweede Sprint was opgeleverd. Zoals gezegd wil een Scrumteam bij een echte Sprint Review juist graag feedback van stakeholders. Voor deze sessie hebben we dat bewust anders ingestoken.
• Retrospective: Als Scrum Master zou ik nooit adviseren om de Retrospective over te slaan. Dit is namelijk bij uitstek hét Scrum event om als Scrumteam te verbeteren. Voor deze sessie hebben we de Retrospective voor deze Sprint wel overgeslagen, omdat we na afloop van deze Sprint nog een overall Retrospective voor de hele sessie gingen doen.

Learnings uit deze Scrum simulatie

Waar het programma eerst verstikkend werkte, hebben we dat dankzij een aantal aanpassingen positief omgedraaid. Hierdoor gaven de deelnemers na afloop aan zich nu veel beter te voelen en zelfs blij te zijn met het resultaat. Drie take-aways van deze sessie en blog:

1. Inspelen op verandering! Aanpassen op wat de situatie vraagt levert meer op dan het volgen van een plan.
2. Een Retrospective is zeer waardevol! Dat heeft eraan bijgedragen dat de deelnemers toch blij waren en de sessie een goed resultaat (namelijk drie Product Backlogs) heeft opgeleverd.
3. Scrum is geen doel op zich, maar een middel. Schitterend dat (de escalatie van) deze sessie dat heeft opgeleverd, toch?