Sprint Retrospective is het evenement dat elke Sprint afsluit. En tegelijkertijd een van de moeilijkste Scrum Team vergaderingen. De meest voorkomende fouten tijdens een Sprint Retrospective hebben te maken met het vermijden van gesprekken over gevoelige onderwerpen, evenals het gebrek aan concrete verplichtingen die leiden tot de oplossing van al eerder gediagnosticeerde problemen.
Veelvoorkomende fouten tijdens een Sprint Retrospective – inhoudsopgave:
- Inleiding
- Onvoldoende transparantie
- Focus op eenmalige problemen of successen
- Oververtegenwoordiging van de Product Owner
- Zelfmanagementproblemen
- Te veel verplichtingen
- Veelvoorkomende fouten tijdens een Sprint Retrospective – Samenvatting
Inleiding
Fouten tijdens een Sprint Retrospective zijn helaas heel gebruikelijk. Dit komt omdat het een van de moeilijkste vergaderingen is om succesvol uit te voeren, aangezien het veel volwassenheid van het team vereist. Daarom is het de moeite waard om te kijken naar de problemen die het vaakst voorkomen in andere teams, zodat je hun symptomen gemakkelijker kunt herkennen bij het uitvoeren van de Sprint Retrospective in jouw Scrum Team.

Onvoldoende transparantie
Volgens de Scrum Guide is elk lid van het Scrum Team verplicht om eerlijk en moedig te zijn in het uiten van zorgen en om hun mening te geven tijdens de Sprint Retrospective. In de praktijk is de verplichting tot transparantie echter zeer veeleisend. Hierdoor proberen leden van het Scrum Team vaak om deze te omzeilen.
Een probleem dat moeilijk te herkennen en op te lossen is, is het vermijden van discussie over geobserveerde tekortkomingen in het werk van het Scrum Team. Dit kan op de lange termijn leiden tot veel ernstigere problemen.
De taak van de Scrum Master is daarom om de situatie in het team goed in de gaten te houden en alle teamleden aan te moedigen om vanaf het begin van de Sprint Retrospective proactief te zijn.
Focus op eenmalige problemen of successen
Een ander probleem dat kan optreden tijdens de Sprint Retrospective is onvoldoende aandacht besteden aan cyclische en repetitieve teamgedragingen, en hun impact op de effectiviteit van het team.
Het is altijd goed om leden van het Scrum Team te feliciteren als ze uitzonderlijk succes hebben behaald. Echter, de Sprint Review mag niet gewijd zijn aan het vieren daarvan. Hetzelfde geldt voor mislukkingen. Als iets is mislukt om toevallige redenen of door een al gediagnosticeerde fout, is het niet de moeite waard om het evenement tijdens de Sprint Review te overanalyseren.
Soms besteedt het team echter een groot deel van de Sprint Retrospective aan dergelijke gebeurtenissen. Houd er echter rekening mee dat het doel van de Sprint Retrospective is om manieren te zoeken om het dagelijkse werk van het team te verbeteren. Daarom zou de vergadering niet moeten draaien om eenmalige successen of problemen die zeer waarschijnlijk niet opnieuw zullen optreden.
Oververtegenwoordiging van de Product Owner
In veel organisaties wordt de functie van Product Owner gelijkgesteld aan die van Product Manager. De Product Owner wordt dan vaak beschouwd als de toezichthouder van het Scrum Team. Om deze reden komt het voor dat het Development Team niet over teamwerkproblemen wil praten in zijn aanwezigheid.
Daarom is het zo belangrijk om onderling vertrouwen op te bouwen tussen het Development Team en de Product Owner. Helaas is het proces van het opbouwen van vertrouwen moeilijk en tijdrovend. Daarom is het soms een goed idee voor de Product Owner om deelname aan alle of een deel van de Sprint Retrospective op te geven om ruimte te laten voor de rest van het team om vrij te discussiëren.
Zelfmanagementproblemen
Zelfmanagement betekent dat leden van het Scrum Team zelf beslissingen nemen over wie van hen bepaalde taken zal uitvoeren, wanneer en hoe. Tijdens de Sprint Retrospective bespreekt het team mensen, hun interacties en teampraktijken. Het besluit vervolgens welke problemen moeten worden opgelost in de komende Sprint, hoe dit samen kan worden gedaan en wie verantwoordelijk zal zijn voor het ondernemen van actie.
Als er ernstigere problemen ontstaan in een zelfsturend team, kan er een verleiding zijn in het Scrum Team om de verantwoordelijkheid af te schuiven.
Af en toe willen teamleden niet deelnemen aan de discussie en proberen ze de managementverantwoordelijkheid op iemand anders te schuiven. Om dit te voorkomen, is het uiterst belangrijk om zelfs kleine problemen regelmatig te bespreken om hun accumulatie te voorkomen.

Te veel verplichtingen
Een actief Scrum Team dat werkt volgens de drie pijlers van empirisme: transparantie, inspectie en aanpassing, kan het probleem tegenkomen van het maken van te veel verplichtingen tegelijk.
Als de verplichtingen die door het Scrum Team tijdens een Sprint Retrospective worden gemaakt te veel zijn, is er een aanzienlijke kans dat:
- geen van de verplichtingen goed zal worden uitgevoerd
- enkele verplichtingen helemaal niet zullen worden uitgevoerd
- de aangebrachte veranderingen niet permanent zullen zijn
Daarom is het een goede praktijk om niet meer dan vier verbeteringen in elke Sprint aan te pakken. Dit maakt een geleidelijke maar effectieve verbetering van de prestaties van het team mogelijk.
Veelvoorkomende fouten tijdens een Sprint Retrospective – Samenvatting
Aangezien de Sprint Retrospective een uitdagend evenement is, ontstaan er vaak problemen tijdens de uitvoering ervan. Om ze gemakkelijker aan te pakken, is het de moeite waard om de meest voorkomende te noteren. Veelvoorkomende fouten tijdens een Sprint Retrospective zijn:
- onvoldoende transparantie – wanneer leden van het Scrum Team niet eerlijk omgaan met moeilijkere teamsituaties
- focus op eenmalige problemen of successen – wanneer leden van het Scrum Team zich richten op het bespreken van successen en mislukkingen, in plaats van de langetermijneffectiviteit van het werk van het team te bespreken
- oververtegenwoordiging van de Product Owner – wanneer leden van het Scrum Team de Product Owner met beperkte vertrouwen behandelen alsof hij of zij iemand van buiten het team of een toezichthouder is
- zelfmanagementproblemen – wanneer leden van het Scrum Team proberen de verantwoordelijkheid voor problemen en besluitvorming af te schuiven.
Als je onze inhoud leuk vindt, sluit je dan aan bij onze drukke bijengemeenschap op Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.
Caroline Becker
Als projectmanager is Caroline een expert in het vinden van nieuwe methoden om de beste workflows te ontwerpen en processen te optimaliseren. Haar organisatorische vaardigheden en haar vermogen om onder tijdsdruk te werken, maken haar de beste persoon om ingewikkelde projecten werkelijkheid te laten worden.
Scrum Guide:
- Glossarium van basisbegrippen, rollen en noties
- Wat is Scrum?
- Scrum waarden
- Hoe Scrum in uw bedrijf te implementeren?
- Scrum Team - wat is het en hoe werkt het?
- Wie is een Product Owner?
- De meest voorkomende fouten van de Product Owner
- Wie is de Scrum Master?
- De meest voorkomende fouten van de Scrum Master
- Welke statistieken en metrics moet de Scrum Master bijhouden?
- Ontwikkelteam in Scrum
- De meest voorkomende fouten van ontwikkelaars
- Scrum-artikelen
- Schaalbare Scrum
- Sprint Backlog
- Wat is de Product Backlog?
- Wat zijn User Stories?
- Het creëren van de beste User Story met INVEST
- De meest voorkomende fouten bij User Stories
- Gebruikersverhaal Acceptatiecriteria
- Schatting en Verhaalpunten in Scrum
- Planning Poker
- Team Schatting Spel
- Definiëren van Incremente
- Scrum evenementen
- Wat is een Burndown Chart?
- Voordelen en nadelen van de burndown-grafiek
- Kanban-borden in Scrum en Scrumban
- Snelheid in Scrum - Snelheid van het Ontwikkelteam
- Dagelijkse Scrum
- Sprint Planning
- Sprint Review
- Wat is een Sprint Retrospective?
- Veelvoorkomende fouten tijdens een Sprint Retrospective
- Product Backlog verzorging
- Hoe maak je een burndown-grafiek en hoe interpreteer je deze?
- Wat is een Sprint in Scrum?
- Samenwerking tussen Product Owner en Scrum Master
- Scrum Team Verbintenissen - Productdoel, Sprintdoel en Definitie van Voltooiing
- Kenmerken van een goede Scrum Master