Wat is de 5 Whys-techniek?
De 5 Whys is een techniek voor root cause analyse. Je beschrijft een probleem, vraagt waarom het gebeurde en vraagt bij elk antwoord opnieuw waarom, tot je bij een oorzaak komt die het team kan oplossen. De techniek komt uit het Toyota Production System. In het 5 whys-voorbeeld van Taiichi Ohno zelf volg je een stilgevallen machine via een doorgeslagen zekering, een droog gelopen lager en een versleten pompas naar de grondoorzaak: er zat geen filter op de pomp. Met deze 5 Whys-template doorloop je de hele keten in één TeamRetro-retrospective. Schrijf de probleemstelling in de eerste kolom en de feiten die je al hebt in de tweede. Daarna beantwoordt iedereen de eerste waarom, "Waarom gebeurde het?", in de derde kolom. Het team groepeert de antwoorden en stemt op de meest waarschijnlijke oorzaak. In Bespreken open je die kaart en stel je de volgende vier waaroms in een opmerkingenthread op die kaart, waarbij elk antwoord een reactie is op het vorige. De laatste reactie is je grondoorzaak, en die kopieer je naar een actie met een eigenaar en een deadline. De 5 Whys werkt het best wanneer een probleem één hoofdlijn van oorzaak en gevolg volgt: een late release, een terugkerend incident, een bug die door de tests glipte. Door één keten tot het einde te volgen, neemt het team geen genoegen met het eerste antwoord, en verschuift de discussie van wie een fout maakte naar wat in het proces die fout mogelijk maakte. Heeft een probleem veel bijdragende oorzaken, breng die dan eerst in kaart en pas daarna de 5 Whys toe op de meest waarschijnlijke.
Format van de 5 Whys retrospective
Probleemstelling
Wat is er precies gebeurd, waar en wanneer?
Spreek één probleemstelling af voordat iemand een oorzaak toevoegt, en houd het bij één kaart. Maak die concreet: wat er gebeurde, waar, wanneer en hoe groot, zonder te gissen naar de oorzaak. "Release 4.2 ging twee dagen te laat live" geeft het team iets om waarom over te vragen. "Releases zijn een chaos" doet dat niet.
Wat we weten
Welke feiten en data beschrijven het probleem?
Verzamel eerst feiten en pas daarna oorzaken, zoals tijdlijnen, metrics, logs, meldingen van klanten en wat er recent is veranderd. Elk antwoord in de keten van waaroms moet steunen op iets wat hier staat of iets wat het team kan controleren. Ontbreekt er een feit, noteer dat dan en maak het achterhalen ervan een actie.
Waarom gebeurde het?
Wat heeft het probleem direct veroorzaakt?
Elke kaart hier is een eerste waarom, een directe oorzaak van de probleemstelling. Houd de antwoorden bij wat er gebeurde, niet bij wie. Stem na het groeperen op de oorzaak die het probleem het meest waarschijnlijk verklaart. Open in Bespreken de bovenste kaart en stel de volgende vier waaroms in een opmerkingenthread, waarbij elk antwoord een reactie is op het vorige. Kloppen op één niveau twee antwoorden allebei, reageer dan twee keer op dezelfde opmerking en volg elke tak.
Wanneer gebruik je deze retrospective?
- Een probleem blijft terugkomen nadat het is opgelost, en je wilt de oorzaak vinden die de vorige oplossing over het hoofd zag.
- Na een incident, een ontsnapte bug of een gemiste deadline, wanneer het team moet weten waarom voordat het afspreekt wat er verandert.
- Eén item in een retrospective kreeg de meeste stemmen en verdient een grondige analyse in een eigen sessie.
- Het probleem lijkt één hoofdlijn van oorzaak en gevolg te hebben. Heeft het veel bijdragende oorzaken, breng die dan eerst in kaart met een fishbone-diagram.
Voorstellen voor ijsbrekers
- Welke kleine aanpassing heeft bij jou ooit een veel groter probleem opgelost?
- Wat begreep je pas nadat je meer dan één keer waarom had gevraagd?
Wil je een opwarmoefening waarbij je team daadwerkelijk meedoet, en niet alleen hardop antwoorden geeft? Bekijk gratis ijsbrekers →
Ideeën en tips voor je retrospective
- Spreek de probleemstelling hardop af voor de brainstorm en voeg die toe als enige kaart in Probleemstelling. De template zet de brainstorm op Ideeën direct tonen, zodat iedereen elke kaart ziet zodra die wordt toegevoegd. Je kunt dit wijzigen in de vergaderinstellingen.
- De template zet de fase Bespreken op Alles bespreken, zodat de probleemstelling en de feiten in beeld blijven naast de oorzaak met de meeste stemmen. Je kunt dit wijzigen in de vergaderinstellingen.
- Doorloop de keten als opmerkingenthread op de oorzaak met de meeste stemmen. Die kaart is de eerste waarom. Voeg een opmerking toe die antwoord geeft op "Waarom gebeurde dat?", reageer erop met het volgende antwoord en blijf reageren. Reacties worden tot drie niveaus diep genest, dus de kaart, één opmerking en drie reacties geven je vijf waaroms.
- Stop wanneer je bij een oorzaak komt die het team kan veranderen, of dat nu drie of zeven waaroms kost. Heb je een zesde nodig, voeg dan een nieuwe opmerking toe op de kaart die verdergaat waar de laatste reactie ophield.
- Vraag naar het proces, niet naar de persoon. Komt een antwoord uit op "iemand heeft een fout gemaakt", vraag dan waarom het proces die fout heeft doorgelaten.
- Zet de grondoorzaak om in een tegenmaatregel. Open het menu bij de laatste reactie, kies Kopiëren naar actie en geef de actie een eigenaar en een deadline. Bekijk de actie in de fase Open acties van een latere retrospective om te controleren of de oplossing heeft gewerkt.
Veelgestelde vragen
Wat is de 5 Whys-techniek van Taiichi Ohno?
Hoe kun je de 5 Whys gebruiken?
Wat zijn de technieken van root cause analyse?
Hoe schrijf je een root cause analyse?
Wat is de beste template voor root cause analyse?
Gerelateerde sjablonen
Blik terug op wat je team Liked, Learned, Lacked en Longed for
Agile retrospective
Vier vragen om je sprint te evalueren en veranderingen te plannen.
Ankers & Motoren Retrospective
Zie wat je team vooruitstuwt en wat het tegenhoudt
Retrospective voor cross-team samenwerking
Neem de wrijving weg tussen teams die van elkaar afhankelijk zijn