Velen zeggen dat de retrospective de belangrijkste ceremonie is in de agile gereedschapskist. Woody Zuill zegt het zo: 

Als je maar één #agile praktijk introduceert, zou dat retrospectives moeten zijn. Al het andere zal volgen.

Woody Zuill

Waarom is het dan toch mogelijk dat een ontwikkelteam de sprint retrospective als overbodig beschouwt? In mijn ervaring als Scrum Master en psycholoog heeft dit meestal te maken met het volwassenheidsniveau van het team.

Dus wat kun je doen om de volwassenheid van je team – deze context en in het algemeen te verbeteren? Hier zijn 7 gedachten, 7 tips die je zullen helpen met deze uitdaging.

Het team vindt de retrospectieve overbodig: wat te doen?

Overigens is het officiële antwoord volgens het Scrum certificeringsexamen dit: De Scrum Master moet aan het team werken om het efficiënter te maken. Mh, dat helpt niet echt. Wat zou daarmee bedoeld kunnen worden?

De Scrum Master moet aan het team werken om het efficiënter te maken

De officiële rol van een Scrum Master is als volgt, als je kijkt naar de Scrum Handleiding kijkt naar: "De Scrum Master moedigt het Scrum Team aan om hun ontwikkelproces en werkwijzen binnen het Scrum proces te verbeteren om het effectiever en leuker te maken voor de volgende Sprint."

In theorie betekent dit dat de retrospective een centraal evenement zou moeten zijn voor de Scrum Master, omdat het belangrijkste doel van de retrospective is om het team te helpen continu te verbeteren. In de praktijk is het echter mogelijk dat het team niet het volwassenheidsniveau heeft om een retrospective echt te gebruiken en daarom de waarde ervan niet inziet. Daarom interpreteer ik persoonlijk de uitspraak "het team efficiënter maken" op een abstract niveau als "het volwassenheidsniveau van het team verhogen". Hoe kun je dat in deze context doen? Voordat we beginnen met de tips hierover, nog één uitleg

Retro wordt als waardevol beschouwd als men daadwerkelijk voortdurend verbetert. Dan is het gevoel van autonomie, zelforganisatie en self-efficacy hoog. Wat leidt tot de hypothese: De ervaren kwaliteit van retrospectives is een van de beste indicatoren voor het (agile) volwassenheidsniveau van een team. 

Als je het agile volwassenheidsniveau – wilt meten, moet je de kwaliteit van retrospectives als indicator gebruiken. Dit is de typische correlatie in de tijd tussen de "waargenomen kwaliteit van de retrospectieve" en de "agile volwassenheid" van een team.

Deze progressie wordt als volgt bereikt: 

1. De eerste retrospectieven worden uitgevoerd, maatregelen worden opgeschreven. Het gevoel ontstaat: er gebeurt eindelijk iets! 
2. De maatregelen worden niet echt uitgevoerd. Er wordt veel gepraat, maar weinig gedaan. 
3. Na verloop van tijd ontstaat frustratie of gewoon de zogenaamde "retro-moeheid". Nu doet zich het fenomeen van dit artikel voor: De retrospective wordt als overbodig gezien. Het team zelf ziet zichzelf als relatief volwassen en ziet geen problemen.
4. Dit punt wordt slechts door enkele teams bereikt. Namelijk wanneer de kwaliteit van de retros weer toeneemt en dit uiteindelijk leidt tot merkbare verbeteringen en het gevoel van self-efficacy dus langzaam volwassen wordt. 

Hopelijk helpen de tips in deze tekst je om een paar stappen in deze richting te zetten. Ik kan echter ook onze tekst over "7 tips voor goede actie-items", die een andere rol spelen in deze kwestie.

1. begrijpen waarom het team denkt dat een retrospectief onnodig is

Als Scrum Master heb je misschien een hypothese waarom het team de sprint retrospective onnodig vindt. Maar toets deze hypothese. Vraag het team expliciet naar de achtergrond.

Vaak is er een "opinieleider" in het team die een grote invloed heeft op het team. Probeer deze persoon eruit te pikken, zijn standpunt te begrijpen en in het beste geval samen met hem tegenmaatregelen te bedenken (zie hieronder).

Hoe beter je het team begrijpt, hoe beter je een plan kunt ontwikkelen om de volwassenheid van het team te vergroten en de meest geschikte uit de volgende tips kunt kiezen.

2. de retrospectieve uitvoeren

In principe zou je de retrospective moeten doen. Stel dat het team gewoon meer tijd nodig heeft om het sprintdoel – te halen en dat een uurtje coderen in plaats van de retrospective cruciaal zou kunnen zijn. In dat geval is het goed om de retrospective een paar dagen uit te stellen.

Je kunt ook de aard van de retrospectieve veranderen, hem korter maken, enzovoort. Maar de beste manier om het team de waarde van een retrospectief te laten zien is door een echt goede retrospectief te houden. Dus mijn oproep is: reserveer een plekje in je teamagenda voor de retrospectieve.

3. meet de ROTI-waarde

Je kunt niet veranderen wat je niet meet. Een eenvoudige en snelle gewoonte die je helpt om voortdurend te beoordelen hoe het team de retrospectieve ervaart, is het meten van de ROTI-score: de "return on time invested" waarde. Stel gewoon de volgende vraag na elke retrospectieve, misschien als check-out: "Op een schaal van 0 tot 10, hoe goed was de geïnvesteerde tijd voor deze retrospectieve?". Meet het gemiddelde over de tijd – hopelijk zie je snel een positieve trend!

De gemiddelde "return-on-time-invest" score op een schaal van 0 tot 10 per maand in de Echometer tool – zijn de retros de moeite waard? Het lijkt er wel op!

4. houd je sprint retrospective heel kort

Dus het ontwikkelteam vindt de sprint retrospective overbodig – wat moet je nu doen als Scrum Master?

Zoals ik in het begin al zei, vindt het team een sprint retrospective waarschijnlijk niet nodig omdat ze denken dat het tijdverspilling is.

Met andere woorden: In de laatste retrospectives hebben ze blijkbaar "geleerd" dat de ROTI van een retrospective – d.w.z. de kwaliteit van de geïnvesteerde tijd, zie hierboven – nogal slecht is. Er is een vrij eenvoudige aanpak om dit te veranderen: investeer gewoon minder tijd voor dezelfde output.

Dit is misschien wel de beste tip als het team de sprint retrospective onnodig vindt. Vertel je team: OK, we houden het zo kort mogelijk (lees meer in onze blogpost "Korte terugblik – beter snel dan helemaal niet"). 

Belangrijk: Je wilt niet aangeven dat het voor altijd zo blijft. Je boodschap blijft hetzelfde: Retrospectives zijn echt belangrijk. Vroeg of laat zullen retrospectives niet meer zo kort zijn.

Maar je verkort de retrospectieve (bijvoorbeeld van 60 minuten naar 30 minuten) omdat het team zo leert hoe belangrijk het kan zijn om de tijd te investeren. En je laat de lengte van de retrospectieve als het ware "organisch" groeien door een "pull" of "wens" van het team, omdat ze op een gegeven moment meer tijd voor de retrospectieve willen. Hoe doe je dat? 

Je stelt gewoon de belangrijkste vraag:

"Waarom zijn we er niet in geslaagd om alle user stories af te ronden die voor de laatste iteratie waren vastgesteld?"

Dit zal in korte tijd leiden tot heftige discussies en waarschijnlijk ideeën voor actie. Het kan zelfs leiden tot langere discussies. En het team heeft al aangegeven dat ze meer tijd nodig hebben voor een retrospectief (natuurlijk is het jouw taak om de discussie constructief te houden).

Je moet altijd de vraag stellen waarvan je denkt dat hij goede gedachten of discussies in het team losmaakt. En je moet altijd het doel hebben om een experiment vast te leggen dat je in de volgende sprint gaat uitproberen (ook bekend als een actie-item).

5. voorstellen om ook andere routines weg te laten

Dus het team denkt dat een retrospectieve tijdverspilling is. Oké. Als Scrum Master zou je hoofddoel nooit moeten zijn om de persoon te zijn die Scrum implementeert. Nee, het gaat niet om "Scrum". 

Het gaat erom dat het team succesvol is en waarde levert aan de klant en belanghebbenden. Scrum wordt verondersteld het team daarbij te helpen. Maar het is slechts een raamwerk, een gereedschapskist (een behoorlijk goede) van vele mogelijke benaderingen om snel, duurzaam en met hoge kwaliteit waarde te leveren.

Dus als het team ontevreden is over retrospectives, kun je benadrukken dat je Scrum bekijkt vanuit het zojuist beschreven perspectief. En dan voeg je eraan toe dat je denkt dat sommige van de andere routines die je hebt eigenlijk minder belangrijk zijn dan de retrospective. 

De retrospectieve is de motor voor voortdurende verbetering. Het is bedoeld om teamleden te helpen erachter te komen wat goed werkte en wat niet. Als je dit deel van de continue lus weglaat, loop je het risico dat de continue verbeteringslus stokt.

 

Wat zou er bijvoorbeeld gebeuren als je een paar dailies weglaat? Weet je wat er zou gebeuren? Misschien heeft het geen invloed – perfect, dan kun je het hetzelfde houden en tijd besparen. 

Aan de andere kant kan dit ook leiden tot slechtere communicatie in het team. Het team maakt daardoor fouten. Uiteindelijk zal er een organische behoefte zijn aan meer communicatie, die je vsl. in retrospective zou merken. Deze keer wordt een agile ceremonie echter niet op jouw aandringen ingevoerd, maar vanwege de "pijn" van het team. Als gevolg daarvan zal er veel meer acceptatie voor deze ceremonie zijn in het team.

6. naar retrospectives uit het verleden kijken en hun waarde laten zien

Een benadering die de andere benaderingen kan aanvullen is om te kijken naar de "retrospectieve geschiedenis" van het team over een langere periode. De voorwaarde hiervoor is dat sommige van de laatste retrospectives succesvol waren.

Je kijkt bijvoorbeeld naar de terugblik van een jaar geleden en realiseert je hoe moeilijk die uitdagingen vorig jaar waren. En dan realiseer je je dat het zoveel makkelijker zou zijn om diezelfde uitdagingen vandaag op te lossen als je alle kennis en ervaring had die je hebt opgedaan.

Met andere woorden: Je realiseert je hoeveel je in de tussentijd verbeterd bent. Misschien kan deze "continu verbeteren" aanpak toch werken! En de retrospectives kunnen hier inderdaad een grote rol in hebben gespeeld. Op de juiste manier gebruikt, kan het zeker leiden tot een "aha" moment in het team.

Daarnaast kun je ook kijken naar de ROTI-waarde (return on time investment) van je laatste retrospectief (zie hierboven): Als je kunt aantonen dat de retrospectieve een ROTI van 8 tot 10 heeft, is de tijd duidelijk goed geïnvesteerd. Onze retrospectieve tool Echometer, bijvoorbeeld, vraagt de ROTI op na elke retrospectieve en geeft je zo een regelmatige indicator van de relevante prestaties. Prestaties van jou als Scrum Master.