De ‘waarom vraag’ is voor iedereen die met mensen werkt misschien wel de belangrijkste vraag van allemaal. Het helpt ons het diepere onderliggende probleem naar boven te halen, daarmee zorgt het ervoor dat we niet aan symptoombestrijding doen. Iets dat we helaas maar al te vaak doen. We bespreken hoe we aan de hand van een root cause analyse deze waarom kunnen achterhalen.

We bespreken de root cause analyse aan de hand van een interessante casus. Namelijk over een situatie die ik ooit als coach met een Agile team heb meegemaakt, waarbij ik oplossingen voor situaties implementeerde die om wat voor redenen dan ook niet het gewenste resultaat hadden. Redenen waar ik pas de vinger op kon leggen toen ik mij realiseerde dat mijn oplossingen veelal de pleister op de wond was, en niet de werkelijk oplossing voor het dissfunctioneren van het team.

Symptoombestrijding

Wanneer ik aan symptoombestrijding denk, dan denk ik bijvoorbeeld aan projecten waarvan de deadline niet gehaald wordt. Op het moment dat je in zo’n situatie terechtkomt, zul je twee dingen moeten doen om het juiste antwoord hierop te genereren: schakelen en een root cause analyse

Ten eerste zul je snel moeten schakelen. Concreet houdt dit vaak in dat je extra middelen en resources moet alloceren, om zo het project te kunnen verlengen en het juiste resultaat alsnog te behalen. Probleem opgelost, toch?

Toch niet… Want waarom is de deadline niet behaald? Niet genoeg resources? Onrealistische deadline gesteld? De juiste kennis niet aanwezig in het team/de organisatie? De opdracht was complexer dan gedacht?

En zo kan ik nog wel even doorgaan met mogelijke oorzaken die ten grondslag liggen aan het niet halen van een deadline. En deze tweede stap van verdieping ontbreekt vaak.

Een root cause analyse gebruiken om onderliggende redenen naar boven te halen

Er zijn verschillende technieken om een root cause analyse te doen, elk met als doel door te dringen tot de kern van het probleem. Want laten we eerlijk zijn, zolang je de kern van het probleem niet identificeert , los je in feite het probleem niet op.

Een van de manieren waarop je dit kunt bereiken is door middel van de 5 why’s, een techniek waarbij je 5x waarom vraagt om steeds dieper tot het kernprobleem te komen.

Casus time: een root cause analyse in de praktijk!

Ik werkte ooit als Scrum Master van een tweetal teams. Eén van deze teams was zelf-organiserend en presteerde op hoog niveau, maar bij het andere team kwam de gewenste en verwachtte resultaten er maar niet uit. En waarom? Ik kon mijn vinger er niet op leggen…

We besloten als team om een ochtend aan een root cause analyse te besteden en als startpunt had ik de volgende stelling bedacht:

‘Waarom benutten we niet de maximale potentie van het team?’

Iedereen mag op individueel niveau over deze vraag nadenken, en hier mag je best even de tijd voor nemen. Vervolgens krijgt ieder individu de kans om zijn/haar standpunt uit te dragen. De reden dat je deze eerste twee stappen in het proces individueel wilt doen is om iedereen onbevooroordeeld een mening te laten vormen enerzijds, en anderzijds om jouw mening te kunnen spiegelen aan die van anderen. Op deze manier denkt iedereen op een dieper niveau na over de gekozen stelling.

Vervolgens ontstaan er discussies en gesprekken binnen het team over hetgeen iedereen heeft ingebracht met de ‘waarom vraag’ als rode draad.

In dit geval was het antwoord op de stelling:

‘Er ontbreekt benodigde kennis in het team’

Nu zijn we er wel toch? Even ophalen welke kennis ontbreekt en dan stappen zetten. Vaak laten we het hierbij en doen we de aanname dat we het probleem hebben geïdentificeerd. En weet je, soms is dat ook zo, maar vaak zul je merken dat wanneer je dieper gaat graven er onderliggend een heel ander probleem speelt.

In dit geval gingen we op dezelfde manier met deze laatste stelling aan de haal en kwam gaandeweg de discussie langzaam maar zeker naar boven dat de kennis wel degelijk in het team aanwezig was en transformeerde naar:

‘We delen geen kennis met elkaar’

Het opvallende voor mij als coach was dat we hier een switch maakten van een faciliterend probleem (we hebben kennis nodig), naar een intermenselijk probleem (we delen de aanwezige kennis niet). Waren we na de eerste conclusie gestopt dan hadden we als oplossing extra kennis aangedragen, welke zeer waarschijnlijk dus niet gedeeld zou worden binnen het team.

Na wederom verdieping over deze stelling kwam er als conclusie uit:

‘We werken niet genoeg samen’

Op zo’n moment als dit voel je dat je dicht bij de kern zit. We zijn van faciliterend naar kennisdeling gegaan, en van daaruit naar samenwerking.

Een interessante ontwikkeling, en de uiteindelijke conclusie misschien nog wel interessanter.

Het probleem dat we na een laatste discussie hier uithaalden was:

‘We vertrouwen elkaar niet’

Lessons learned..

Wat je uit een casus als deze haalt is hoe zeer we met zijn allen geneigd zijn aan symptoombestrijding te doen. Immers, hadden we niet verder gekeken dan onze neus lang is. Als we niet een paar lagen dieper waren gegaan, dan hadden we de ondermatige prestaties van dit team opgelost door ze met veel extra kennis te faciliteren.

Kennis die (binnen dit team) vervolgens niet (voldoende) gedeeld zou worden met elkaar. De samenwerking zou niet verbeteren en al helemaal het gebrek aan vertrouwen was gebleven.

Eigenlijk kun je symptoombestrijding zien als een doekje voor het bloeden, als de dweil die we gebruiken wanneer de kraan nog open staat. En soms hebben we daar acuut ook behoefte aan. Als eerste reactie op een ontstane situatie wel te verstaan, niet als permanente oplossing. Daarvoor zul je toch echt een root cause analyse moeten uitvoeren om de wond te hechten en de kraan te sluiten.

Naar aanleiding van dit artikel nieuwsgierig hoe de Agile Scrum Group jouw organisatie kan helpen beter samen te werken? Stel al je vragen via info@agilescrumgroup.nl of 020 2614 195 en we helpen je graag verder.

Ook interessant:

• Hoe gebruik je Model Baarda om van klassiek functiehuis naar flexibele rollen te gaan voor HR
• Hoe gebruik je Classes of Service in Kanban om te prioriteren?
• Wat is een Solution Train Engineer? (+verantwoordelijkheden)