Continue Verbetering met Agile Retrospectives

Zijn retrospectieves moeilijk, zijn ze lastig om te doen? Nee! Zijn ze waardevol voor teams en organisaties? Jazeker! Het helpt om te weten waarom je retrospectives doet en hoe je ze kunt doen om effectief en continu te verbeteren.

Teams die volgens agile gaan ontwikkelen doen meestal ook agile retrospectives. Vaak beginnen zij met retrospectives na één of meer sprints. Sommige teams blijven ze doen, maar ik zie ook teams die ze niet zo vaak doen of zelfs helemaal niet meer doen na een tijdje. Reden die meestal genoemd wordt is dat ze er niet genoeg voordelen uit halen. Maar als dat betekent dat het team hun manier van werken niet verbetert, niet aanpast aan veranderingen in hun omgeving; kan een team zich dat veroorloven? Ik denk van niet. Mijn suggestie: Doe retrospectives, maar zorg ervoor dat je weet waarom je ze doet en hoe je ze kunt soen!

Waarom Agile Retrospectives?

Het Agile Manifest geeft een paar goede redenen waarom je retrospectives zou doen. Het begint met eerste zin van het manifest:

Wij laten zien dat er betere manieren zijn om software te ontwikkelen door in de praktijk aan te tonen dat dit werkt en door anderen ermee te helpen.

Manifest voor Agile Software Ontwikkeling

Deze zin vertelt ons dat er niet 1 oplossing of 1 beste manier is van het ontwikkelen van software. Om te verbeteren kunnen we dingen proberen om daarna te reflecteren om te zien of het werkt. Dit is waar de retrospectives helpen, als een manier om te reflecteren aan het einde van de sprint of na een bepaalde tijd om te zien hoe het team zijn werk heeft gedaan en te ontdekken wat werkt en wat niet.

Een agile mindset hebben betekent dat je wilt reflecteren en leren en dit ook wilt blijven doen. Je bent nooit klaar!

En dan zijn er ook de principes achter het agile manifest. Het 12e principe zegt:

Op vaste tijden, onderzoekt het team hoe het effectiever kan worden en past vervolgens zijn gedrag daarop aan.

Manifest voor Agile Software Ontwikkeling

Agile noemt het “inspecteren en aanpassen”. Het begint bij het doen van dingen, daarna leren tijdens het doen, en onderweg verbeteren.

Het is vergelijkbaar met het maken van een product waarbij je niet vooraf alle specificaties kunt weten voordat je begint met het ontwikkelen van een product. Je begint met het realiseren van specificaties die duidelijk zijn en voor de klant waarde leveren en past vervolgens de planning aan gebaseerd op de feedback. Retrospectives zijn een manier om “verandering te omarmen”, om feedback op de manier waarop je als team werkt te benutten.

Agile retrospectives zij niet iets wat agile of Scrum bedacht heeft. Het vragen van feedback om jezelf te verbeteren is veel ouder. Zelfs project management methodes als Prince-2 en de PMBoK kennen reflectie op de manier waarop het project wordt gemanaged. Scrum heeft een ritueel gedefiniëerd om te reflecteren. En Scrum geeft het reflecteren een duidelijke en zinvolle plek in de cyclus van de software ontwikkeling.

Hoe doe je Agile Retrospectives

Nu we begrijpen waarom we retrospectives willen doen, laten we een bekijken hoe we ze kunnen doen.

Mijn ervaring is dat de heersende cultuur binnen het team en bedrijf een belangrijke rol speelt bij het doen van effectieve retrospectives. Mensen moeten zich veilig voelen, open staan voor elkaars ideeën en meningen, en willen veranderen.

Ik gebruik de Prime Directive aan het begin van de retrospective om de behoefte aan een veilige en open cultuur te benadrukken:

Ongeacht wat we ontdekken, we begrijpen en geloven dat iedereen zijn best heeft gedaan, gegeven wat zij wisten op dat moment, hun vaardigheden en mogelijkheden, de beschikbare middelen, en de situatie aan hand.

Waardevolle Agile Retrospectives

 
Het uitspreken van de prime directive (wat ik niet letterlijk doe maar in mijn eigen woorden) helpt om van de retrospective een positief en een vruchtbaar event te maken. Met de prime directive wordt een retrospective een effectieve teambijeenkomst waar wordt geleerd en oplossing worden gevonden om de manier van werken te verbeteren.

In een retrospective reflecteert een team op hun manier van werken. Er zijn veel verschillende technieken die gebruikt kunnen worden om een retrospective te doen, variërend van het stellen van vragen en met post-its antwoorden verzamelen, het maken van een tijdlijn, root cause analyse, games, etc.

Waardevolle Agile Retrospectives is het 1e Nederlandstalige Agile boek voor het faciliteren van retrospectives. Met vele oefeningen, het “wat” en “waarom” van retrospectives, de business value en de voordelen die retrospectives brengen. Tevens practische tips en adviezen voor het introduceren en verbeteren van retrospectives.

Verkrijgbaar in mijn webshop als paperback en ebook, op Amazon.nl (Kindle), Amazon.de (Paperback), Bol.com (ebook) en Bol.com (paperback), Managementboek (ebook) en Managementboek (paperback).

Afhankelijk van de situatie en waar het team naar op zoek is, kies ik een geschikte techniek uit mijn gereedschapskist.

Een techniek die ik vaak gebruik is het vragen van de vier kernvragen, gebaseerd op het boek Project Retrospectives door Norm Kerth:

  • Wat hebben we goed gedaan, die als we ze niet bespreken we wellicht vergeten?
  • Wat hebben we geleerd?
  • Wat zouden we de volgende keer anders doen?
  • Waar hebben we nog vragen over?

Voor mij zijn deze vragen erg effectief gebleken. Ik hou van de vraag “Wat hebben we goed gedaan”, het is een oplossing gebaseerde benadering om sterke kanten te vinden die vervolgens ingezet te kunnen worden voor verbetering. De toevoeging “die als we ze niet bespreken we wellicht vergeten” maakt de vraag zelf nog sterker. Als iets per ongeluk goed gaat, dat is fantastisch, maar wat kunnen we doen om er zeker van te zijn dat we dit blijven doen?

Ook de vraag “Waar hebben we nog vragen over” geeft in mijn retrospectives met teams vaak nuttige inzichten. Het onthult dingen waarover nog niet gesproken werd voordat ik deze vraag had gesteld.

 Acties na de retrospective

Ik stimuleer teams om gebruik te maken van dingen die ze al hebben om hun retrospectives acties zichtbaar te maken. Plak ze op de muur bij de werkplek, zet ze op je planning bord, gebruik ze als input bij de planning, enz.

Voor grotere verbeteringen helpt het vaak om een User Story (beschrijven van het wie, wat en waarom) te definiëren en ook daarvoor tijd te plannen. De nieuwste editie van de Scrum guide noemt deze concrete aanpak ook (eindelijk).

Door het op deze manier met acties om te gaan, help ik teams om hun continue verbetering skills te ontwikkelen. Daarmee zijn ze in staat te om efficiënt hun eigen vooruitgang te managen en meer waarde te leveren aan hun klanten.

In een retrospective, check ik ook of het team in staat is geweest om de acties te voltooien van de vorige retrospective. Zo niet, dan is het goed om te bespreken welke belemmering het team ziet waardoor ze niet in staat waren deze acties te doen. Misschien is er een dieper probleem dat het team blokkeert? Of hadden ze acties bedacht waarvan bleek dat die onhaalbaar of onbruikbaar waren? Het is goed om te reflecteren op de acties om er zeker van te zijn dat retrospectives waardevol zijn en blijven voor het team.

Conclusie

Agile retrospectives zijn een goede manier voor teams om hun manier van werken te verbeteren. Het definiëren van acties in een retrospective die haalbaar zijn en ervoor zorgen dat de acties ook gedaan worden, helpt teams om voortdurend te leren en zorgt voor continue verbeteringen.

Ben Linders

I help organizations with effective software development and management practices. Active member of several networks on Agile, Lean and Quality, and a frequent speaker and writer.

Geef een reactie

Deze website gebruikt Akismet om spam te verminderen. Bekijk hoe je reactie-gegevens worden verwerkt.

×
×

Winkelmand