Che cos'è la Retrospettiva Fishbone (Ishikawa)?
La Retrospettiva Fishbone (Ishikawa) aiuta il tuo team a trovare le cause profonde di un problema invece di curarne i sintomi. Si basa sul diagramma causa-effetto reso popolare da Kaoru Ishikawa negli anni '60, che dispone le possibili cause in una forma simile a una lisca di pesce. In questo template il team analizza sei categorie di cause: Sistema, Processo, Moduli, Persone, Policy e Luogo. Procedere una categoria alla volta spinge le persone ad andare oltre la prima spiegazione che viene in mente, così emergono anche le cause che non rientrano nell'area di competenza di nessuno. È particolarmente utile per i problemi con più fattori concomitanti, quando la soluzione più ovvia non ha funzionato. Raggruppare le cause in categorie mostra come sono collegate tra loro e indica il cambiamento che avrà l'impatto maggiore. Un diagramma a lisca di pesce (chiamato anche diagramma di Ishikawa o diagramma causa-effetto; i tre nomi indicano lo stesso strumento) colloca il problema nella "testa" del pesce e disegna le principali categorie di cause come lische che si diramano dalla spina dorsale. Nella sua forma originale, nata nella produzione industriale e nella gestione della qualità, queste categorie sono le "6 M": Manodopera (le persone), Metodo (il processo), Macchine (le attrezzature), Materiali (gli input), Misurazioni (dati e metriche) e Madre Natura (l'ambiente circostante). Il team elenca le possibili cause sotto ogni lisca, poi continua a chiedersi "perché?" per seguire ogni ramo fino alla causa radice. Le categorie di questo template adattano le 6 M ai team di sviluppo software e ai knowledge worker. La tecnica è la stessa; cambiano solo le etichette, per adattarsi al tipo di lavoro che svolgete. Se il problema nella testa del pesce è "i rilasci continuano a slittare", una causa legata alle Persone potrebbe essere "il revisore principale è un collo di bottiglia", una causa di Processo potrebbe essere "manca una definizione di fatto" e una causa di Sistema potrebbe essere "la pipeline di CI è instabile". Mappare le cause in questo modo evita che il team si limiti a correggere un sintomo senza vedere cosa lo sta davvero provocando.
Formato della retrospettiva Fishbone
Sistema
Quali tecnologie, software o strumenti potrebbero influire sui risultati del team?
Esaminate l'infrastruttura tecnica, gli strumenti software e i punti in cui i sistemi si collegano tra loro. Chiedete sia dei guasti tecnici evidenti sia dei modi meno visibili in cui l'interazione tra i sistemi rallenta il lavoro.
Processo
Quali flussi di lavoro o sequenze di attività causano ritardi o inefficienze?
Cercate colli di bottiglia, passaggi duplicati e lacune nei flussi di lavoro. Chiedere di passaggi specifici nel modo in cui si svolge il lavoro aiuta il team a distinguere i problemi di processo dalle altre cause.
Moduli
Quali problemi di template o documentazione potrebbero compromettere chiarezza o accuratezza?
Esaminate i template e la documentazione. Le persone trovano ciò che serve? È completa? Svolge davvero la sua funzione? Considerate sia i documenti formali sia quelli informali.
Persone
Quali fattori legati a competenze, comunicazione o ruoli influiscono sul nostro successo?
Parlate di competenze, comunicazione e ruoli senza cercare colpevoli. Concentratevi sulle condizioni in cui le persone lavorano, come ruoli poco chiari o silos di conoscenza, e non sulle critiche ai singoli.
Policy
Quali regole o linee guida non corrispondono alle nostre pratiche reali o creano difficoltà?
Esaminate le regole scritte e non scritte che influiscono sul lavoro. Chiedetevi se ogni policy sostiene ancora il modo in cui il team lavora oggi o se è d'intralcio.
Luogo
Quali aspetti dello spazio di lavoro fisico o virtuale influiscono su collaborazione o produttività?
Considerate lo spazio di lavoro fisico e virtuale, compresi gli strumenti, la disposizione dell'ufficio e quanto funziona bene la collaborazione da remoto.
Quando utilizzare questa analisi retrospettiva
- Quando un problema ha probabilmente più di una causa
- Dopo un problema significativo che richiede un'analisi strutturata prima che qualcuno proponga una soluzione
- Quando il team continua a correggere i sintomi e il problema si ripresenta
- Nei post-mortem di progetto o nelle analisi degli incidenti, per evitare che lo stesso errore si ripeta
Domande suggerite per rompere il ghiaccio
- Se il nostro team fosse una macchina, quale pezzo avrebbe più bisogno di manutenzione in questo momento?
- Qual è la soluzione più sorprendente che hai trovato per un problema ricorrente?
Desiderate un esercizio di riscaldamento che la vostra squadra possa svolgere, anziché limitarsi a rispondere ad alta voce? Sfogliate gli esercizi per rompighiaccio gratuiti →
Idee e consigli per la vostra riunione di retrospettiva
- Scrivete una descrizione chiara del problema nella testa del pesce prima che qualcuno aggiunga una causa
- Fate in modo che tutti aggiungano cause in ogni categoria, anche in quelle estranee al proprio ruolo
- Rimandate le soluzioni finché le cause non sono state mappate
- Usate i 5 perché all'interno di ogni categoria per andare oltre la prima risposta
- Annotate ogni causa, anche quelle che all'inizio sembrano secondarie
- Prevedete 90–120 minuti per affrontare bene tutte e sei le categorie
Domande frequenti
Quali sono le 6 M del diagramma a lisca di pesce?
Qual è la differenza tra diagramma a lisca di pesce e diagramma di Ishikawa?
Come si fa un'analisi delle cause radice con il diagramma a lisca di pesce?
Chi ha inventato il diagramma di Ishikawa?
Modelli correlati
Decidete insieme cosa va fatto e cosa può aspettare.
Pianificazione strategica della roadmap
Trasforma i tuoi obiettivi in traguardi e milestone
Retrospettiva di collaborazione tra team
Elimina gli attriti tra team che dipendono l'uno dall'altro
Analisi SWOT per team
Un template di analisi SWOT per team. Mappate insieme Punti di forza, Punti di debolezza, Opportunità e Minacce, votate ciò che conta e uscite con azioni concrete.