Wat gaat er goed in het team en in het project? En wat niet? Welke maatregelen kunnen hieruit worden afgeleid? Retrospectieven zijn een perfecte manier om motivatie en enthousiasme in je bedrijf of bureau te brengen. Wij laten je zien hoe je een retro kunt opzetten en wat de do's en don'ts zijn.

Een retrospective (kort: retro) is een soort evaluatie om samen in een groep, een team of voor een hele organisatie te bepalen welke successen in een bepaalde periode behaald werden. Je kunt het gebruiken om je projectmanagement of agile softwareontwikkeling op de proef te stellen, maar ook elk ander onderdeel in je bedrijf. Tegelijkertijd verduidelijken retro-vergaderingen de vraag of de samenwerking in de teams echt zo vlot verloopt - en hoe tevreden je werknemers zijn.

De basisregels

Retro's zijn bijzonder efficiënt. Want elke retro biedt voldoende ruimte voor suggesties van verbetering, die onmiddellijk in concrete projecten worden omgezet. Dit is precies wat retrospectives zo waardevol en blijvend maakt. Retro's vinden - mits op de juiste manier uitgevoerd - op een manier plaats die:

1. Iedereen in de groep of het team aan het woord laat
2. Ruimte biedt voor verschillende vormen van feedback, zonder deze onmiddellijk te beoordelen
3. Constructief, vooruitziend, respectvol en transparant is.

Retrospectieven zijn zeker niet alleen geschikt voor bedrijven of bureaus, maar ook voor NGO's, verenigingen, vrijwilligersgroepen, open source initiatieven of sociale en politieke projecten. Juist de omgeving van open source of WordPress waardeert feedback loops die op retrospectieven gebaseerd zijn. Dit brengt immers het hele ontwikkelingsteam samen en maakt besluitvormingsprocessen openbaar.

Retro's zijn net zo nuttig voor technische projecten als voor het verbeteren van de bedrijfscultuur. Hier volgt een kort overzicht van de twee varianten:

Scrum retrospective

Retrospectives zijn klassiek bekend van de Scrum projectmanagementmethode. Vooral teams van softwareontwikkeling of webdesign vertrouwen op Scrum, omdat het een tegenstelling biedt tot klassiek hiërarchisch georganiseerde projecten van het type "ik vertel je wat je moet doen en wanneer". Tot op zekere hoogte organiseren de ontwikkelaars zich in Scrum. Toch zijn er vaste structuren (zoals de Scrum Board) en vaste tijdsperioden ("sprint"). Subtaken maken het hele proces bijzonder flexibel en dus wendbaar. De retro zelf verloopt in vijf fasen:

1. Intro: Hier stel je het team in op de retro, bepaal je de doelstellingen van de vergadering, leg je zo nodig het organisatieproces nogmaals uit of introduceer je nieuwe deelnemers.
2. Verzamel gegevens: Deze stap is bedoeld om onderwerpen te verzamelen die in de retro moeten worden belicht. Met andere woorden, punten die goed gingen. Maar ook die geoptimaliseerd moeten worden of die conflicten veroorzaken. In eerste instantie is hier alle input toegestaan - de gezamenlijke prioritering vindt pas daarna plaats.
3. Inzicht krijgen: De opgenomen punten worden gezamenlijk besproken. Wat zijn de oorzaken van positieve ontwikkelingen, maar ook van ontwikkelingen die moeten worden geoptimaliseerd? Wat kan hieruit worden afgeleid voor verdere projecten of voor samenwerking in het team?
4. Maatregelen afleiden: De groep beslist samen welke verbetermaatregelen moeten gelden voor de volgende sprints. Deze maatregelen moeten zo concreet mogelijk worden geformuleerd ("wie doet wat wanneer") en schriftelijk worden vastgelegd.
5. Afsluiting van de terugblik: Hier kun je de resultaten nog eens samenvatten, laatste open vragen verduidelijken, alle deelnemers ophalen en als het ware een korte "retro van de retro" maken.

Voor sommige teams, bureaus en bedrijven is deze zeer open vorm van uitwisseling in het begin even wennen. Dan kan het gebeuren dat er aanvankelijk weinig feedback komt of dat er zelfs conflicten en wederzijdse verwijten ontstaan. Dit kan vermeden worden, dus hier zijn een paar tips.

Vroeg of laat moeten retrospectives echter leiden tot de volgende verbeteringen:

• Tijdlijnen in softwareontwikkeling of in het project kunnen beter worden gepland, belemmerende hindernissen worden uit de weg geruimd.
• De onderneming creëert de nodige middelen van technische, structurele of personele aard om goed te kunnen werken.
• De werknemers pakken conflicten opener aan en lossen ze samen op.
• Het team richt zich niet alleen op wat er niet goed gaat, maar ook op de positieve punten en op procesoptimalisatie.
• Niet alleen technische uitdagingen staan op de voorgrond, maar ook de samenwerking en de stemming in het team.

Indien een of meer van deze punten niet worden bereikt, kan het team samen werken aan het format, de tools, de besluitvormingsprocessen, de betrokkenheid van alle deelnemers of de presentatie. Of het team bepaalt dat eerst bepaalde randvoorwaarden moeten worden gecreëerd. Het kan bijvoorbeeld gaan om uniforme ontwikkelingsprocessen of betere communicatie of motivatie binnen het bedrijf.

Team Retro

En dat brengt ons bij de tweede functie die retrospectieven kunnen hebben. Afgezien van zuiver projectgerelateerde processen of als aanvulling op technische retrospectieven, kunnen ze worden gebruikt om de cohesie in het bureau of bedrijf te versterken. Geen enkel team kan zonder conflicten. Het is cruciaal om er op een open en oplossingsgerichte manier mee om te gaan, zodat de organisatie niet alleen met zichzelf bezig is of blijft hangen in "werken volgens het boekje".

Vrije Team Retro's die niet bij scrum betrokken zijn of een andere methode toepassen, gebruiken hoofdzakelijk de volgende drie vragen:

• Wat heeft goed gewerkt? In welke gevallen hebben we goed samengewerkt en waarom?
• Wat heeft niet goed gefunctioneerd? Waar kan iets in de samenwerking worden verbeterd?
• Wat hopen we te verbeteren en gaan we uitproberen? Wie zorgt voor de uitvoering en tot wanneer?

In dit geval is een retrospective minder star georganiseerd dan in scrum. In principe staat het het team vrij om te bepalen in welke vorm de zojuist opgesomde vragen worden verduidelijkt. Een regelmatige vorm (zoals een retrospective om de twee maanden), een representatieve selectie van deelnemers, een gedetailleerde documentatie en schriftelijke resultaten zijn echter nuttig. Ook een persoon die de uitnodiging, de presentatie en de verwerking op zich neemt.

De onderwerpen voor de retro's moeten van de werknemers zelf komen, daarover zo meteen meer. Om dit proces op gang te brengen, is het zinvol om vooraf regelmatig feedback te verzamelen. En om zowel steun als motivatie te geven. Bijvoorbeeld in het kader van (eventueel anonieme) enquêtes of via een speciale rol in het bedrijf. Hoe dit eruit kan zien, kun je lezen in ons artikel over Mental Health bij bedrijven.

Vooral werknemers die vroeger in een zeer hiërarchisch gestructureerd bedrijf hebben gewerkt, zijn niet gewend om open en moedig bij te dragen aan de bedrijfscultuur. Er zal in je bedrijf alleen iets veranderen als er een kader is waarin iedereen vrij zijn mening kan geven.

Do's in een retro

Ongeacht de technische of meer culturele retro zijn er een aantal voorwaarden en ook hulpmiddelen die bijdragen tot het succes van de meeting:

• Presentatie: In de Sprint Retrospective wordt deze rol vervuld door de Scrum Master. In een niet-formele retro kan deze taak vrij worden bepaald, misschien zelfs roterend.
• Platte hiërarchieën: Het is belangrijk dat de begeleiders de bijeenkomst leiden als gelijkwaardige deelnemers, niet "van bovenaf". Hetzelfde geldt voor het management of ander hoger personeel.
• Definieer een reeks regels: Als er tijdens de retros misverstanden of ruzies ontstaan, helpt het om de mensen te herinneren aan de gemeenschappelijke waarden van het agentschap of het bedrijf. Niet als een verbodslijst, maar in de vorm van voorbeelden die staan voor positieve communicatie. Zie bijvoorbeeld de Code of Conduct van Raidboxes.
• Bindende overeenkomsten: Dit houdt ook in dat de resultaten in een protocol worden vastgelegd. Maar ook om niet over de hoofden van afwezigen te beslissen. In geval van twijfel moet de groep deelnemers worden uitgebreid. Of - afhankelijk van de verwachte onderwerpen - kunnen gasten uit andere afdelingen en teams worden uitgenodigd.
• Succes meten: Leiden de tot dusver genomen maatregelen tot verbeteringen? Zo niet, hoe kan een meer concrete afsluiting van de retro eruit zien? Kunnen de successen worden bewezen of gemeten? Wordt de werklast duurzaam verminderd of verbetert de stemming in het team?

Vooral het laatste punt is belangrijk: alleen door positieve resultaten wordt de retro blijvend verankerd en door iedereen geaccepteerd. Niet iedereen in je team zal vanaf het begin de betekenis van retrospectives begrijpen. Het voorwendsel "Het is toch zinloos" kan alleen weerlegd worden als er successen zichtbaar worden. En als je regelmatig alle rollen in het bedrijf oppakt.

Don'ts van een Retro

De don'ts vloeien gedeeltelijk voort uit de bovenstaande punten. Maar ook daarbuiten liggen risico's op de loer, als de retrospectieven niet goed zijn doordacht of op een slordige manier worden geleid:

Onproductieve kring van deelnemers

Hier is openheid en soms ook tact nodig. Het is nadelig als individuen uit het team zich niet betrokken voelen. Te grote rondes daarentegen of met te veel thematische vermenging worden snel onproductief. Als afzonderlijke onderwerpen niet in de grote ronde kunnen worden opgelost, kunnen zij zo nodig worden doorgeschoven naar de kleinere teamretro's.

Te weinig transparantie

Als andere afdelingen het gevoel hebben dat zij geen inzicht hebben in de resultaten van een retro ontstaat er snel onrust of frustratie. Hier helpen openlijk zichtbare protocollen of de regelmatige presentatie van de resultaten voor iedereen. Dit geldt ook voor het meten van het succes van de goedgekeurde punten.

Veilige omgeving

Tegelijkertijd moet het retrospectief zelf een veilige plek zijn, zodat je geen reserves voelt om kritiek te uiten. Sommigen spreken alleen openlijk over wat er in zo'n setting verbeterd moet worden. Bijvoorbeeld binnen het eigen team of zonder het managementniveau. Indien nodig kunnen de retrospectieven worden opgesplitst om het juiste evenwicht te vinden tussen transparantie en de behoefte aan bescherming.

Te strikte richtlijnen

Zijn het altijd dezelfde deelnemers die bij een retrospectief hun mond opendoen? Worden suggesties snel afgeketst? Of zijn de individuele resultaten al op voorhand bekend? Dat kan niet werken. Retro's zijn alleen geschikt voor bureaus en bedrijven waar een open cultuur heerst.

Taken zijn onnauwkeurig omschreven of worden niet nageleefd

De vraag "wie doet wat tegen wanneer" is uiterst belangrijk. Retrospectives vereisen dat de cirkel verantwoordelijkheden en deadlines vaststelt voor elk uit te voeren idee.

Wat de duurzaamheid van de maatregelen betreft: is het de moeite waard om een beroep te doen op een projectmanagement-tool waarin de afzonderlijke taken worden ingevoerd. Dan kun je altijd in één oogopslag zien op welke gebieden een retro goed verloopt en waar het moet worden verbeterd. Heb je verschillende retrospectieven in je bedrijf? Dan kun je ze tegen elkaar afmeten of samen ideeën uitwisselen.

Alleen technologie, geen cultuur

Het maakt niet uit of het een Sprint Retro is of een andere variant: het gaat niet uitsluitend om het inventariseren en oplossen van louter technische uitdagingen. Ook de sociale en culturele interactie binnen het team moet worden belicht. Omdat het ene (efficiënt werken) niet werkt zonder het andere (teamgeest). Ontwikkelingsafdelingen vinden het soms moeilijk om de twee te combineren. In dat geval kunnen geschikte trainingen helpen, zie bijvoorbeeld onze blogpost over geweldloze communicatie.

Onduidelijke structuur

Retros moeten de ruimte scheppen om vrijuit te kunnen spreken over conflictueuze onderwerpen. Niettemin hebben zij een duidelijk kader en een vaste structuur nodig. Dit omvat hoekstenen zoals een regelmatige uitvoering, de rol van moderator, indien nodig een aparte rol voor de documentatie of de notulen, tijdbeheer en - indien gewenst - het gebruik van speciale retro-tools. Informatie hierover geef ik zo meteen. De vijf fasen van een retro (zie hierboven) helpen je om je aan de structuur te houden.

Voor alle bovengenoemde punten kun je hulp krijgen als er in jouw bureau of bedrijf niet voldoende kennis voorhanden is. Bijvoorbeeld door middel van opleidingscursussen of externe opleiders.

Retros @ Raidboxes

Bij Raidboxes gebruiken we verschillende vormen van retrospectives om onszelf te organiseren. Enerzijds de klassieke Scrum retrospectives van onze productontwikkeling, waardoor we nu veel sneller kunnen handelen. Bovendien maakt ons supportteam – en binnenkort ook wij in marketing – gebruik van team-interne retros om de kwaliteit voortdurend te verbeteren.

Bovendien zijn wij momenteel bezig een format op te zetten dat alle collega's bij Raidboxes omvat. We zijn nog bezig met het vinden van een oplossing. Door onze huidige groei is het niet meer makkelijk om iedereen rond de tafel te krijgen. Een idee waar we naar kijken: Elk team stuurt twee afgevaardigden naar de bedrijfsbrede retrospectieve, in een roterend proces. Zo krijgt iedereen de kans om bij te dragen.

Thema's voor de Retro

De positieve punten, maar ook de uitdagingen, die wij in dit bedrijfsbrede format inbrengen, komen deels uit onze personeelsenquête. We doen dit om de zes maanden. De prioritering van de onderwerpen is vrij eenvoudig: wij wegen de punten al naargelang hoe vaak of hoe dringend deze in de enquête werd beoordeeld.

Een andere aanpak kan zijn om van tevoren in het team onderwerpen voor de retro te verzamelen. Als er te veel punten zijn voor een retro, wordt er gestemd: welke daarvan willen we bespreken? Alle andere punten gaan dan automatisch in een backlog voor de volgende retro.

Retro Software: Echometer

Er zijn nu een aantal instrumenten beschikbaar voor het uitvoeren van een softwarematige retrospectieve. Wij werken zelf samen met Echometer, een bedrijf dat ook in Münster gevestigd is. Echometer is een tool dat helpt bij het systematisch uitvoeren van een team retrospective. Om daarbij het potentieel en de stemmingen van je werknemers vast te leggen.

Je kunt kiezen uit een pool van voorgedefinieerde vragen, geselecteerd volgens psychologische benaderingen, die de deelnemers beantwoorden. Je kunt ook je eigen vragen indienen. Vanuit deze pool van antwoorden leidt Echometer je team vervolgens stap voor stap door de retrospective. Een bijzonder voordeel: de resultaten worden automatisch gedocumenteerd en kunnen met elkaar worden vergeleken. Na een paar retrospectives kun je altijd zien waar verbeteringen zijn aangebracht of waar aanpassingen mogelijk zijn.

Bronnen en verdere links

Wil je Retro's of Scrum in je bureau of bedrijf invoeren? Hier zijn nog enkele aanvullende bronnen:

• Retrospectives: 10 voorbeelden en download formats
• Scrum.nl: Een retrospective is net een goed diner
• Wat is een Scrum Retrospective? 10 vormen, ideeën & voorbeelden
• Scrumguide.nl: Sprint Retrospective
• Echometer: 3 verschillende scrum retrospective methodes
• Echometer: 3 creatieve methodes voor online retrospectives