"Retro is overbodig": 7 tips om te reageren
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.
Wat kun je dus doen om de volwassenheid van je team te verbeteren - in deze context en ook in het algemeen? Hier zijn 7 gedachten, 7 tips die je zullen helpen bij 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 bekijkt: “De Scrum Master moedigt het Scrum Team aan om zijn ontwikkelingsproces en praktijken te verbeteren in het kader van het Scrum proces, om het effectiever en aangenamer te maken voor de volgende Sprint.”
In theorie betekent dit dat de retrospectief een centrale gebeurtenis van de Scrum Master zou moeten zijn, aangezien het belangrijkste doel van de retrospectief is om het team te helpen zichzelf voortdurend te verbeteren. In de praktijk heeft het team echter misschien niet de volwassenheid om een retrospectief echt te gebruiken en ziet het daarom de waarde ervan niet. Om die reden interpreteer ik zelf de uitspraak “het team efficiënter maken” op een abstract niveau als “de volwassenheid van het team verhogen”. Hoe kun je dat in deze context doen? Voordat we met de tips beginnen, nog een 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 de agile volwassenheid wilt meten, dan moet je de kwaliteit van retrospectieven als een indicator gebruiken. Dit is het typische verband in de tijd tussen “waargenomen kwaliteit van de retrospectief” en “Agile volwassenheid” van een team.
Deze progressie wordt als volgt bereikt:
- De eerste retrospectieven worden uitgevoerd, maatregelen worden opgeschreven. Het gevoel ontstaat: er gebeurt eindelijk iets!
- De maatregelen worden niet echt uitgevoerd. Er wordt veel gepraat, maar weinig gedaan.
- 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.
- 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 %E2%80%9D, die een andere rol spelen bij dit onderwerp.
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 op het team heeft. Probeer deze persoon eruit te pikken, zijn visie te begrijpen en in het beste geval samen met hem de tegenmaatregelen vorm te geven (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
Je zou de retrospectief in principe moeten uitvoeren. Laten we aannemen dat het team gewoon meer tijd nodig heeft om zijn sprintdoel te bereiken - en een uur coderen in plaats van de retro zou cruciaal kunnen zijn. In dat geval is het oké om de retrospectief 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
Wat je niet meet, kun je niet veranderen. Een eenvoudige en snelle gewoonte die je helpt om continu te beoordelen hoe het team de retro’s ervaart, is het meten van de ROTI-score: De “Return on time invest”-waarde. Stel gewoon de volgende vraag na elke retrospectief, misschien als check-out: “Op een schaal van 0 tot 10, hoe goed was de tijd voor deze retrospectief geïnvesteerd?”. Meet het gemiddelde over de tijd - hopelijk kun je al snel een positieve trend herkennen!
De gemiddelde “Return-on-time-invest” score op een schaal van 0 tot 10 per maand in de Echometer Tool - zijn de retro’s de moeite waard? Het lijkt erop!
4. houd je sprint retrospective heel kort
Het development team vindt de sprint retrospectief dus overbodig - wat moet je als Scrum Master nu doen?
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 retrospectieven hebben ze blijkbaar “geleerd” dat de ROTI van een retrospectief - dus de kwaliteit van de geïnvesteerde tijd, zie hierboven - eerder slecht is. Er is een vrij eenvoudige aanpak om dit te veranderen: bij gelijke output gewoon minder tijd investeren 🙂
Dit is misschien wel de beste tip als het team de Sprint Retrospective overbodig vindt. Zeg tegen je team: Oké, we gaan hem zo kort mogelijk houden (meer hierover 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 retrospectief (bijv. van 60 minuten naar 30 minuten) omdat het team op deze manier leert hoe belangrijk het kan zijn om de tijd te investeren. En je laat de lengte van de retrospectief quasi “organisch” groeien, door een “Pull” bzw. “Wunsch” van het team, want op een gegeven moment zal het meer tijd voor de retrospectief willen. Hoe doe je dat?
Je stelt gewoon de belangrijkste vraag:
“Waarom is het ons niet gelukt 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 jullie een paar Dailies weglaten? Weet je wat er zou gebeuren? Eventueel zal het misschien geen invloed hebben - perfect, dan kunnen jullie het gelijk zo 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 kijken naar de \“retrospectieve geschiedenis\” van het team over een langere periode. De voorwaarde hiervoor is dat een aantal van de laatste retrospectieven succesvol zijn geweest.
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: jullie zien in hoe erg jullie je in de tussentijd hebben verbeterd. Misschien zou deze aanpak van \“continue verbetering\” toch kunnen werken?! En de retrospectieven zouden daarbij in feite een grote rol kunnen hebben gespeeld. Correct gebruikt kan dat zeker tot een aha-moment in het team leiden.
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 .
"Veel teamleden durven zich niet uit te spreken!"
Los deze uitdaging op"We ontdekken te veel onverwachte problemen en bugs in een laat stadium!"
Los deze uitdaging op"Waarom kost het me soms uren om een eenvoudige terugblik voor te bereiden?"
Los deze uitdaging op7. Breng meer variatie in je retrospectief
Een van de typische antwoorden op de vraag \“Het ontwikkelingsteam vindt de sprintretrospectief overbodig - wat moet de Scrum Master doen?\” is om de retrospectief productiever en spannender te maken door meer afwisseling in je methoden te brengen en ze leuker te maken. Ik benadruk altijd dat \“plezier\” niet zo belangrijk is, de focus moet altijd nog liggen op het productief maken ervan. Toch kan plezier natuurlijk een zekere creativiteit en motivatie losmaken.
Dat betekent enerzijds dat je creatieve retrospectieve methoden kunt gebruiken - zie bv. onze bijdrage over 32 Retrospectieve methoden voor beginners en professionals -, d.w.z. metaforen in de vorm van open vragen die nieuwe gedachten en ideeën op gang brengen.
Aan de andere kant kun je ook methoden gebruiken die verder gaan dan de typische retrospectieve, maar nog steeds gericht zijn op het verbeteren van het team. Je zou bijvoorbeeld een retrospective/teamworkshop kunnen houden die zich richt op de psychologische veiligheid in het team verbeterd - een van de belangrijkste voorwaarden voor succesvolle teams.
Of je gebruikt onze Retro Tool Echometer, dat je retrospectief continu aanvult met wetenschappelijk onderbouwde vragen. Ze helpen het team om na te denken over de mate waarin het voldoet aan de kernmerken van succesvolle teams. Hier een voorbeeld van een van de vragen uit onze tool, een andere voorwaarde voor succesvolle teams - een gezonde feedbackcultuur:
Ik krijg regelmatig nuttige feedback over hoe goed ik presteer en hoe ik me kan verbeteren.
Voorbeeld van een impuls van de Echometer tool besproken in retrospectives.
Er zijn veel andere benaderingen om afwisseling in je retro’s te brengen - wees gerust creatief.
Zoals gezegd, afhankelijk van \“waarom\” het team de sprintretrospectief overbodig vindt, zou meer afwisseling waarschijnlijk niet de enige maatregel moeten zijn om het probleem op te lossen.
Conclusie over \“overbodige retro’s\”
Zoals je hebt gezien, pakken de 7 tips en acties de uitdaging op verschillende niveaus aan. Als ik maar één tip zou moeten geven, dan zou het zijn om de retrospectieve op een intelligente manier in te korten, zoals ik hierboven heb geschetst. Als je al deze maatregelen combineert, zul je zeker snel resultaten zien.
Veel plezier met je #continue verbetering!