Quando una Root Cause Analysis ha senso
Una mattina avevo una gomma a terra alla macchina. Per fortuna sono riuscito a cambiare la ruota velocemente. Tuttavia, mi piace anche trasferire nella vita quotidiana le cose che ho imparato al lavoro. Così ho deciso di fare una Root Cause Analysis – un'analisi delle cause profonde. Speravo di poter evitare gomme a terra in futuro. Dopotutto, avrei potuto impiegare meglio il tempo speso a cambiare la ruota.
Il metodo dei "Five Whys" della Root Cause Analysis
Il metodo dei "Five Whys" è adatto a questo tipo di analisi delle cause. Si chiede semplicemente cinque volte di seguito "Perché?" – i miei figli erano particolarmente bravi in questo all'età di circa quattro anni! La ricerca della causa è quindi iniziata:
Perché avevo una gomma a terra?
-Perché c'era un chiodo nella gomma.
Perché c'era un chiodo nella gomma?
-Perché evidentemente ci ero passato sopra il giorno prima.
Perché ero passato sopra il chiodo il giorno prima?
-Perché il parcheggio della mia palestra (l'unico posto dove ero andato quel giorno) era in fase di rifacimento.
Perché il parcheggio veniva rifatto?
-A causa delle molte buche.
Perché c'erano buche nel parcheggio?
-A causa della pioggia.
La causa della mia gomma a terra era quindi la pioggia. Quindi non deve più piovere.
Purtroppo questo non è in mio potere. Normalmente avrei potuto segnalare una cosa del genere al mio Scrum Master, ma persino uno Scrum Master non può cambiare il tempo.
Conclusione della Root Cause Analysis
Cosa voglio dire con questo? A volte una Root Cause Analysis semplicemente non vale la pena. Come ogni altro metodo o tecnica, non è sempre sensata. Molte cose nello sviluppo software sono completamente nuove, ovvero vengono fatte per la prima volta (almeno dalla persona o dal team). L'analisi delle cause profonde è più utile in situazioni ricorrenti – ad es. nella produzione. È meno utile per cose nuove e complesse, come quelle che si verificano nello sviluppo software (o nello sviluppo prodotto in generale).
Non sto dicendo che dovreste rinunciare completamente alla Root Cause Analysis e ai Five Whys. Ricordate solo che non esiste un metodo applicabile sempre.
Questo testo proviene dal blog di Mike Cohn ed è stato tradotto in italiano da noi.
Diventa Certified Scrum Master!
Per gli Scrum Master offriamo i seguenti training e opportunità di formazione gratuite:
