Retro's voor agentschappen en bedrijven: meer efficiëntie en tevredenheid

9 Min.
Scrum Retro voor Agentschappen & Bedrijven

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

Retrospectieven zijn oorspronkelijk bekend van de projectmanagementmethode Scrum. Vooral teams uit de softwareontwikkeling of het webdesign vertrouwen op Scrum, omdat het een tegenpool biedt voor klassiek hiërarchisch georganiseerde projecten van het type "ik zeg je wat je moet doen en wanneer". Tot op zekere hoogte organiseren de ontwikkelaars zich in Scrum. Toch zijn er vaste structuren (bv. de Scrum Board) en vaste tijdsperiodes ("Sprint"). Subtaken maken het geheel bijzonder flexibel en dus agile. 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 maatregelen ter verbetering voor de volgende sprints moeten gelden. Deze maatregelen moeten zo concreet mogelijk worden geformuleerd ("wie doet wat tot wanneer") en schriftelijk worden vastgelegd.
  5. Afsluiting van de retrospectieve: Hier kun je de resultaten nogmaals samenvatten, de laatste open vragen verduidelijken, alle deelnemers erbij betrekken en een korte "retro van de retro" houden.

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.

echometer scrum retro
Een software-ondersteunde retro, hier met echometer

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 dit brengt ons bij de tweede functie die retrospectives kunnen hebben. Afgezien van puur projectgerelateerde processen of als aanvulling op technische retro's kunnen ze worden gebruikt om de samenwerking in het bureau of het bedrijf te versterken. Geen enkel team redt het zonder conflicten. Het is van cruciaal belang om op een open en oplossingsgerichte manier met hen om te gaan, zodat de organisatie niet alleen met zichzelf bezig is of blijft "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 presentatoren de vergadering als gelijkwaardige deelnemers leiden, niet "van bovenaf". Hetzelfde geldt voor mensen van het management of andere hogere leidinggevenden.
  • Bepaal een aantal regels: Als er misverstanden of meningsverschillen ontstaan tijdens retro's, helpt het om mensen te herinneren aan gemeenschappelijke waarden van het bureau of bedrijf. Niet als een verbodslijst, maar in de vorm van voorbeelden die voor positieve communicatie staan. 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 verankert de retro zich blijvend en wordt door iedereen geaccepteerd. Want niet iedereen in je team zal het belang van retrospectieven vanaf het begin begrijpen. De mentaliteit "Het heeft toch geen zin" kan alleen weerlegd worden als zich successen aandienen. En als je regelmatig alle rollen in het bedrijf erbij betrekt.

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 en tot wanneer" is uitermate belangrijk. Retrospectives vereisen dat de cirkel bij elk idee dat moet worden uitgevoerd verantwoordelijkheden en deadlines vastlegt.

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.

Stappen naar geweldloze communicatie
De vier stappen van geweldloze communicatie: waarnemen, gevoel, behoefte, verzoek

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.

Retro's @ RAIDBOXES

Bij RAIDBOXES gebruiken we verschillende vormen van retro's om ons 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 retro's om de kwaliteit voortdurend te verbeteren.

Bovendien zijn wij momenteel bezig een format op te zetten waarbij alle collega's van RAIDBOXES betrokken zijn. Wij bevinden ons nog in de ontdekkingsfase. Door onze huidige groei is het niet meer gemakkelijk om iedereen samen aan één tafel te krijgen. Een idee dat we onderzoeken: elk team stuurt bij om de beurt twee afgevaardigden naar de bedrijfsbrede retrospectieve. Dit geeft iedereen de kans om een steentje bij te dragen.

Retro's en holacratie

Dit alles past goed in de holacratische aanpak die RAIDBOXES heeft ingevoerd. Dit is een vorm van organisatie die zeer zelfbepaald werk mogelijk maakt. Meer informatie hierover vind je in onze blogpost New Leadership met Holacratie.

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:

Retro's en teamwork: jouw vragen

Welke vragen heb je over retrospectieven of dit artikel? Hoe verbeter je het teamwork in je team? We horen graag je reactie. Wil je meer tips over zakelijk en maatschappelijk verantwoord ondernemen? Volg ons dan op Twitter, Facebook of via onze nieuwsbrief.

Michael is bij RAIDBOXES verantwoordelijk voor Content en Mental Health. Hij is al vanaf 2007 actief in de blogging- en WordPress-community. Onder andere als mede-organisator van WordPress evenementen, auteur van boeken en Corporate Blog Trainer. Hij geniet ongelooflijk van bloggen, zowel professioneel als persoonlijk. Michael werkt en schrijft op afstand vanuit het zonnige Freiburg.

Reacties op dit artikel

Laat een opmerking achter

Jouw e-mailadres zal niet worden gepubliceerd. Verplichte velden zijn met een * gemarkeerd.