Wat is de Visgraat (Ishikawa) retrospective?
Met de Visgraat (Ishikawa) retrospective vindt je team de grondoorzaken van een probleem, in plaats van alleen de symptomen te bestrijden. De retrospective is gebaseerd op het oorzaak-gevolgdiagram dat Kaoru Ishikawa in de jaren zestig populair maakte. Daarin worden mogelijke oorzaken uitgezet in een vorm die op een visgraat lijkt. In deze template werkt je team zes oorzaakcategorieën door: Systeem, Proces, Formulieren, Mensen, Beleid en Werkplek. Door categorie voor categorie te werken, kijken mensen verder dan de eerste verklaring die in hen opkomt. Zo komen ook oorzaken buiten ieders eigen vakgebied op tafel. De retrospective is het nuttigst bij problemen met meerdere oorzaken, waarbij één voor de hand liggende oplossing niet heeft gewerkt. Als je de oorzaken in categorieën indeelt, zie je hoe ze samenhangen. Dat wijst je de weg naar de verandering die het meeste verschil maakt. Een visgraatdiagram (ook wel Ishikawa-diagram of oorzaak-gevolgdiagram genoemd; alle drie de namen staan voor hetzelfde hulpmiddel) zet het probleem bij de "kop" van de vis en tekent de belangrijkste oorzaakcategorieën als graten die aftakken van de ruggengraat. In de oorspronkelijke vorm uit de productie en het kwaliteitsmanagement zijn dat de "6 M's": Mens (Manpower), Methode (Method, het proces), Machine (apparatuur), Materiaal (Material, de input), Meting (Measurement, data en metrics) en Milieu (Mother Nature, de omgeving). Het team brainstormt over mogelijke oorzaken bij elke graat en blijft vervolgens "waarom?" vragen om elke tak te volgen tot aan de grondoorzaak. De categorieën in deze template zijn een bewerking van de 6 M's voor softwareteams en teams die kenniswerk doen. De techniek blijft hetzelfde; alleen de labels zijn aangepast aan het werk dat je doet. Als het probleem bij de kop van de vis "releases lopen steeds vertraging op" is, kan een oorzaak bij Mensen zijn "een belangrijke reviewer is een bottleneck", een oorzaak bij Proces "geen definition of done" en een oorzaak bij Systeem "een onbetrouwbare CI-pipeline". Door oorzaken zo in kaart te brengen, voorkom je dat je team een symptoom oplost en mist wat het probleem echt veroorzaakt.
Visgraat retrospective-format
Systeem
Welke technologie, software of tools beïnvloeden de prestaties of resultaten van ons team?
Kijk naar je technische infrastructuur, softwaretools en de punten waar systemen op elkaar aansluiten. Vraag naar duidelijke technische storingen, maar ook naar de minder opvallende manieren waarop systemen samenwerken en het werk vertragen.
Proces
Welke workflows of werkvolgordes veroorzaken vertraging of inefficiëntie in ons werk?
Zoek naar bottlenecks, dubbele stappen en gaten in je workflows. Door te vragen naar specifieke stappen in hoe het werk gedaan wordt, kan het team procesproblemen onderscheiden van andere oorzaken.
Formulieren
Welke problemen met onze templates of documentatie gaan ten koste van duidelijkheid of nauwkeurigheid?
Kijk naar je templates en documentatie. Kunnen mensen vinden wat ze nodig hebben, is het compleet en doet het waarvoor het bedoeld is? Neem informele documenten net zo goed mee als formele.
Mensen
Welke factoren rond vaardigheden, communicatie of rollen beïnvloeden ons succes?
Bespreek vaardigheden, communicatie en rollen, maar houd het gesprek vrij van schuld. Richt je op de omstandigheden rond mensen, zoals onduidelijke rollen of kennissilo's, en niet op kritiek op individuen.
Beleid
Welke richtlijnen of regels sluiten niet aan op onze praktijk of zorgen voor problemen?
Kijk naar de geschreven en ongeschreven regels die het werk beïnvloeden. Vraag bij elk beleid of het de huidige manier van werken van het team nog ondersteunt of juist in de weg zit.
Werkplek
Welke aspecten van onze fysieke of virtuele werkplek beïnvloeden samenwerking of productiviteit?
Sta stil bij de fysieke en virtuele werkplek, inclusief je tools, de indeling van het kantoor en hoe goed samenwerken op afstand werkt.
Wanneer dient u deze retrospective te gebruiken?
- Als een probleem waarschijnlijk meer dan één oorzaak heeft
- Na een groot probleem dat eerst gestructureerd onderzocht moet worden voordat iemand een oplossing voorstelt
- Als het team steeds symptomen oplost en het probleem telkens terugkomt
- Bij project-post-mortems of incidentreviews, om te voorkomen dat dezelfde fout opnieuw gebeurt
Voorstellen voor ijsbrekers
- Als ons team een machine was, welk onderdeel zou dan nu het meeste onderhoud nodig hebben?
- Wat is de meest verrassende oplossing die je ooit hebt gevonden voor een terugkerend probleem?
Wilt u een opwarmoefening waarbij uw team daadwerkelijk meedoet, en niet alleen hardop antwoorden geeft? Bekijk gratis ijsbrekers →
Ideeën en tips voor uw retrospectievevergadering
- Schrijf een duidelijke probleemstelling bij de kop van de vis voordat iemand een oorzaak toevoegt
- Zorg dat iedereen oorzaken toevoegt in elke categorie, ook in categorieën buiten de eigen rol
- Wacht met oplossingen tot alle oorzaken in kaart zijn gebracht
- Gebruik binnen elke categorie de 5 x waarom-methode om verder te kijken dan het eerste antwoord
- Leg elke oorzaak vast, ook als die in eerste instantie klein lijkt
- Trek 90–120 minuten uit, zodat je alle zes categorieën goed kunt behandelen
Veelgestelde vragen
Wat zijn de 6 M's van een visgraatdiagram?
Wat is het verschil tussen een visgraatdiagram en een Ishikawa-diagram?
Hoe doe je een root cause analyse met een visgraatdiagram?
Wie heeft het Ishikawa-diagram bedacht?
Gerelateerde sjablonen
Zet je doelstellingen om in doelen en mijlpalen
Zeilboot retrospective
Breng in kaart wat je team vooruit helpt en wat het tegenhoudt
Start Stop Continue retrospective
Bepaal waarmee je team begint, stopt en doorgaat.
Must Should Could Won't-retrospective
Spreek als team af wat moet gebeuren en wat kan wachten.