Het Agile Manifesto beschrijft dat 'a team reflects on how to become more effective'. Agile retrospectives kun je gebruiken om frequent te reflecteren en de manier van werken in Agile-teams aan te passen om continu te verbeteren. Dit artikel geeft een introductie in retrospectives en beschrijft hoe je ze effectief en efficiënt kunt uitvoeren.
Een Agile retrospective of Sprint retrospective, zoals Scrum hem noemt, is een practice die teams gebruiken om op hun manier van werken te reflecteren en om daarmee voortdurend beter te worden in wat ze doen. Het twaalfde Agile-principe stelt: ‘At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.’
Het hele team neemt deel aan de retrospective bijeenkomst, waarin ze ‘inspecteren’ hoe de iteratie (Sprint) is gegaan, en beslissen wat en hoe ze hun werkwijze willen ‘aanpassen’ en daarmee hun processen verbeteren. De acties die uit een retrospective komen worden gecommuniceerd en bij voorkeur in de volgende iteratie gedaan. Dit maakt retrospectives een effectieve manier om korte cyclische verbetering te doen en om good practices te implementeren volgens een just-in-time aanpak.
De retrospective facilitator (meestal de Scrum-master) heeft een gereedschapskist met retrospective oefeningen en is in staat om, gegeven de situatie, de meest effectieve oefeningen toe te passen in een retrospective. Voorbeelden van oefeningen zijn ‘vragen stellen‘, ‘één-woord retrospective‘, ‘vijf-keer-waarom‘ (root causes), ‘sterktegerichte retrospective‘ en ‘retrospectives van retrospectives‘ (in het boek Waardevolle Agile Retrospectives van Luis Gonçalves en Ben Linders worden deze oefeningen uitgebreid beschreven).
Om ervoor te zorgen dat de acties van een retrospective uitgevoerd worden, kun je ze in de planning-game inbrengen en ze zichtbaar ophangen op het planningsbord van de teams. Met behulp van user stories kunnen grotere verbeteracties gepland en opgevolgd worden.
Elke retrospective bijeenkomst begint door te kijken naar de acties van de vorige retrospective, om te zien of ze klaar zijn (en om actie te ondernemen als dat niet het geval is).
Veiligheid in Retrospectives
Het is van cruciaal belang om een open cultuur te hebben in een Agile retrospective, waarin de teamleden eerlijk hun mening kunnen geven en problemen naar voren durven brengen en bespreken. Norm Kerth heeft de Prime Directive gedefinieerd, een hulpmiddel wat je kunt gebruiken om retrospectives positief en effectief uit te voeren en ervoor te zorgen dat mensen zich veilig voelen: ‘Ongeacht wat we ontdekken, moeten we begrijpen en er op vertrouwen dat iedereen het uiterste heeft gedaan om zijn of haar werk te doen, binnen de grenzen van de kennis van het moment, zijn of haar vaardigheden en capaciteiten, de beschikbare middelen en de situatie zoals die was’.
Met de Prime Directive zorg je ervoor dat een retrospective een effectieve team-bijeenkomst is waar mensen van elkaar leren en oplossingen vinden om hun manier van werken te verbeteren.
Waarom doe je retrospectives?
‘Insanity is doing the same things and expecting different results.‘ Als je de problemen die je ondervindt op wilt lossen, en meer waarde wilt leveren aan je klanten, dan moet je de manier waarop je je werk doet veranderen. Dat is de reden waarom Agile het gebruik van retrospectives aanbeveelt: om teams te helpen om problemen zelf op te lossen en zich te verbeteren!
Wat maakt retrospectives anders, welke voordelen leveren ze op? Een voordeel is dat retrospectives de macht aan het team geven, ze empoweren het team. Aangezien de teamleden zelf de retrospective doen en samen beslissen welke verbeteracties ze gaan doen, zal er weinig weerstand zijn tegen de veranderingen die nodig zijn.
Een ander voordeel is dat de acties die in een retrospectieve zijn afgesproken worden uitgevoerd door de leden van het team: er is geen hand-over! Het team analyseert wat er gebeurd is, bepaalt de acties, en de teamleden doen ze. Dit is veel effectiever en ook sneller en goedkoper :-).
Deze voordelen maken van Agile retrospectives een betere manier om verbeteringen te doen. Retrospectives zijn een van de succesfactoren voor het effectief gebruiken van Scrum. Je kunt verschillende retrospectieve oefeningen gebruiken om waarde toe te voegen voor de business. En retrospectives zijn ook een geweldig hulpmiddel om stabiele teams te creëren en behouden en hen te helpen om flexibel en effectief te werken en daarmee werkelijk Agile en Lean te worden.
Hoe begin je met retrospectives?
Er bestaan verschillende manieren om retrospectives te introduceren in organisaties. Je kunt Scrum-masters en andere mensen die retrospectives zullen faciliteren trainen (bijvoorbeeld met een Waardevolle Agile Retrospectives-workshop) om ze te leren hoe ze retrospectives goed kunnen doen. In de training leren ze hoe ze retrospectives kunnen doen in de Agile-teams door de diverse oefeningen te gebruiken.
Ik ben zelf begonnen met Agile retrospectives in ‘stealth mode’ te doen in mijn projecten. Ik noemde ze geen retrospectives maar gebruikte de term ‘evaluaties’. In plaats van te wachten tot het einde van het project stelde ik voor aan de teams om ze iedere iteratie te doen (het project werkte volgens RUP met iteraties van vier tot zes weken). De acties die uit de evaluatie kwamen, namen we in de volgende iteratie meteen mee. Dit voelde voor de teams heel natuurlijk.
Welke manier je ook kiest, zorg ervoor dat je retrospectives frequent blijft doen en dat de acties die uit de retrospective komen ook uitgevoerd worden. Zelfs als alles goed lijkt te gaan zijn er altijd manieren te vinden om te verbeteren!
Deze blog is afgeleid van de post What’s an Agile Retrospective and why would you do it? die eerder is gepubliceerd op BenLinders.com.
Boek en tool
Wil je meer weten over retrospectives? Luis Gonçalves en ik hebben het mini boek Getting Waarde van Agile Retrospectives gepubliceerd. Dit boek is vertaald door een team van vrijwilligers naar het Nederlands: Waardevolle Agile Retrospectives. Het boek helpt je om voordelen te halen uit het doen van retrospectives. Er is ook een online Retrospective Oefeningen Toolbox die je kunt gebruiken om je eigen waardevolle Agile retrospectives ontwerpen.
Wanneer er meerdere agile teams samenwerken aan één product is er vaak ook sprake van een scrum of scrums om afstemming tussen de teams te coördineren.
Is zo’n aanpak ook aan te bevelen voor de retrospectives?
Achtergrond van mijn vraag: in praktijk heb ik gezien dat meerdere teams soms tegen dezelfde problemen aanlopen, en deze elk lokaal naar eigen inzicht oplossen, wat niet altijd even efficiënt is (zo is mijn ervaring)
Hier heb ik ooit eens wat over geschreven: https://www.computable.nl/artikel/opinie/softwarebeheer/4728437/4480179/de-verborgen-inefficiency-van-agile.html
@PaVeKe jazeker, net zoals de Scrum of Scrums bestaat er ook een Retrospective of Retrospectives. Zie http://www.benlinders.com/2013/improving-collaboration-in-agile-projects-with-the-retrospective-of-retrospectives/.
Retrospective of Retrospectives (RoR) helpen teams om van elkaar te leren en zijn een prima manier om de manier van werken binnen een project/organisatie te alignen:
“As an RoR improves collaboration within the project, it can be a great way to handle risks and improve product quality. And increase the chance that the project delivers valuable functionality, quickly.”
hoe kun je een Computable expert herkennen ?
– noemt zich independent
– publiceert hetzelfde verhaal via meerdere bronnen, soms zelfs hetzelfde verhaal in dezelfde bron, maandje later
– verwijst graag naar eigen eerdere publicaties
– schrijft eigenlijk zelden iets nieuws
– citeert graag Gartner, want die hebben altijd gelijk en het staat interessant
– geen, al-dan-niet erkende check op hun expertise
– creeert een probleem waarvoor zij een betaalde oplossing hebben
– bij voorkeur open deuren
Waarom agile en scrum weinig toevoegen aan IT?
Die vraag is eenvoudig te beantwoorden. als je namelijk heel eenvoudig kijkt naar de betreffende IT discipline, om het even welke, en je volgt mijn zijn allen de principes en wetmatigheden van IT, dan heb je weinig scrum of agile nodig om te stroomlijnen en te verbeteren.
In dat opzicht is een eenvoudige mindset iets menselijks te doen… voorkomen dat je op je plaat gaat, gemeenschappelijke ervaringen te D.o.c.u.m.e.n.t.e.r.e.n.!!! vrij voldoende om gezamenlijk verbeteringen te bewerkstelligen en door te voeren in bestaande processen. Toyoda in begin jaren vijftig van de vorige eeuw nam een oud chinees woord daarvoor, Kaizen, of wel, beter maken, en nam een zeer eenvoudig principe in gebruik. Verbeteren bij wederkerigheid.
Waarom dat met scrum, agile, humtidum telkens weer zo moeilijk blijkt???
Omdat dit commerciële producten zijn die over die reeds in gebruik zijnde processen worden gelegd waarbij al die IT medewerkers tegen heel veel geld een nieuw trucje moeten leren die…. eenvoudig beschouwd, met een simpele niets kostende mindset, meer en toegepast iets toevoegt.
Of je schrijft er weer eens een artikeltje over…. natuurlijk…
Duidelijk artikel met veel ondersteunende verwijzingen.
Verder:
Hoe herken je een zure commentator:
– staat in de toplijst van reageerders
– levert zelf geen constructieve bijdrage
– levert wel negatieve commentaren
– die vaak ook hetzelfde stramien hebben (lijkt of ze een voorbeeld klaar hebben staan)