Sistema

Quali tecnologie, software o strumenti potrebbero influenzare le prestazioni o i risultati del nostro team?

La nostra pipeline di distribuzione spesso fallisce nelle ore di punta
L'ambiente di test non corrisponde alle impostazioni di produzione
L'integrazione tra i nostri strumenti di tracciamento delle attività e git è inaffidabile
Processo

Quali flussi di lavoro o sequenze di attività causano ritardi o inefficienze nel nostro lavoro?

Il processo di revisione del codice richiede troppo tempo con numerosi cicli di andirivieni
Nessuna definizione chiara di completato per le user story
Le riunioni di pianificazione dello sprint superano regolarmente il tempo previsto
Moduli

Quali problemi con i nostri template o la nostra documentazione potrebbero incidere sulla chiarezza o sull'accuratezza?

Il template delle user story manca della sezione dei criteri di accettazione
Il modulo di segnalazione degli incidenti non cattura efficacemente la causa profonda
La documentazione è sparsa su più piattaforme
Persone

Quali fattori legati alle competenze, alla comunicazione o ai ruoli individuali o del team influenzano il nostro successo?

Il team non ha competenze nel nuovo stack tecnologico
Lacune di comunicazione tra i membri del team remoti e quelli in ufficio
Ruoli e responsabilità poco chiari nei progetti interfunzionali
Politiche

Quali linee guida o regole potrebbero essere disallineate con le nostre pratiche reali o creare difficoltà?

Le politiche di sicurezza rendono difficile lo sviluppo in locale
Il processo di gestione delle modifiche è troppo rigido per le correzioni rapide
La politica delle ferie crea vincoli di risorse
Luogo

Quali aspetti del nostro spazio di lavoro fisico o virtuale potrebbero incidere sulla nostra collaborazione o produttività?

Scarsa connettività internet nelle sedi di lavoro remoto
Mancanza di spazi tranquilli per il lavoro concentrato
Gli strumenti di collaborazione virtuale non supportano bene le nostre esigenze

Che cos'è la Retrospettiva Fishbone (Ishikawa)?

La Retrospettiva Fishbone (Ishikawa) è un approccio strutturato alla risoluzione dei problemi che aiuta i team a identificare e comprendere le cause profonde delle sfide o dei problemi. Sviluppata da Kaoru Ishikawa negli anni '60, questa tecnica visualizza le relazioni di causa-effetto in un formato che ricorda uno scheletro di pesce. Durante la retrospettiva, i team esplorano sei dimensioni chiave che potrebbero contribuire alle loro sfide: Sistemi, Processi, Moduli, Persone, Politiche e Luogo. Questa analisi completa garantisce che nessun fattore potenziale venga trascurato, portando a soluzioni più efficaci. Questo metodo è particolarmente utile per i team che affrontano problemi complessi in cui possono entrare in gioco molteplici fattori. Organizzando le possibili cause in categorie distinte, i team possono comprendere meglio le relazioni tra i diversi problemi e sviluppare miglioramenti mirati. Un diagramma fishbone (chiamato anche diagramma di Ishikawa o diagramma causa-effetto — i tre nomi si riferiscono allo stesso strumento) funziona scrivendo il problema nella "testa" del pesce e disegnando le principali categorie di cause come lische che si diramano dalla spina dorsale. Nella sua forma originale, legata alla produzione e alla gestione della qualità, tali categorie sono le classiche "6 M": Manodopera (persone), Metodo (processo), Macchina (attrezzatura), Materiale (input), Misurazione (dati e metriche) e Madre Natura (l'ambiente circostante). I team fanno brainstorming sulle possibili cause di ogni lisca, poi continuano a chiedersi "perché?" per risalire lungo ogni ramo fino alla causa profonda anziché fermarsi al sintomo visibile. Le categorie in questo template di TeamRetro — Sistema, Processo, Moduli, Persone, Politiche e Luogo — sono un adattamento dello stesso metodo delle 6 M al processo di team, riadattato per i team di software e di lavoro basato sulla conoscenza anziché per una fabbrica. La tecnica è identica; cambiano solo le etichette delle categorie per adattarsi al tipo di lavoro che svolgi. Ad esempio, se il problema nella testa del pesce è "le release continuano a slittare", una causa nelle Persone potrebbe essere "un revisore chiave è un collo di bottiglia", una causa nel Processo potrebbe essere "nessuna definizione di completato" e una causa nel Sistema potrebbe essere "pipeline CI instabile". Mappare le cause in questo modo impedisce a un team di correggere i sintomi tralasciando la causa sottostante.

Formato della Retrospettiva Fishbone

Sistema

Quali tecnologie, software o strumenti potrebbero influenzare le prestazioni o i risultati del nostro team?

Guida il team nell'esame dell'infrastruttura tecnica, degli strumenti software e dei punti di integrazione dei sistemi. Incoraggia i partecipanti a riflettere sia sui problemi tecnici evidenti sia sulle interazioni di sistema più sottili che potrebbero influire sul loro lavoro.

Processo

Quali flussi di lavoro o sequenze di attività causano ritardi o inefficienze nel nostro lavoro?

Concentrati sull'identificazione di colli di bottiglia, ridondanze o lacune nei flussi di lavoro. Aiuta il team a distinguere tra problemi di processo e altri fattori chiedendo informazioni su passaggi specifici delle loro procedure di lavoro.

Moduli

Quali problemi con i nostri template o la nostra documentazione potrebbero incidere sulla chiarezza o sull'accuratezza?

Esamina la qualità, l'accessibilità e la completezza della documentazione. Considera sia la documentazione formale sia quella informale e quanto bene serve allo scopo previsto.

Persone

Quali fattori legati alle competenze, alla comunicazione o ai ruoli individuali o del team influenzano il nostro successo?

Affronta le dinamiche del team e i contributi individuali mantenendo un ambiente privo di colpevolizzazioni. Concentrati su problemi sistemici piuttosto che su critiche personali.

Politiche

Quali linee guida o regole potrebbero essere disallineate con le nostre pratiche reali o creare difficoltà?

Esplora sia le politiche formali sia quelle informali che influiscono sul lavoro. Considera se le politiche supportano o ostacolano le attuali esigenze e pratiche del team.

Luogo

Quali aspetti del nostro spazio di lavoro fisico o virtuale potrebbero incidere sulla nostra collaborazione o produttività?

Considera sia gli ambienti di lavoro fisici sia quelli virtuali. Includi fattori come strumenti, disposizione dello spazio di lavoro e capacità di collaborazione da remoto.

Quando utilizzare questa analisi retrospettiva

  • Quando si affrontano problemi complessi che possono avere molteplici cause profonde o fattori contribuenti
  • Dopo aver identificato un problema o una sfida significativa che richiede un'analisi sistematica
  • Quando il team deve andare oltre i sintomi per comprendere le cause sottostanti
  • Durante i post-mortem di progetto o le revisioni degli incidenti per prevenire problemi futuri

Domande suggerite per rompere il ghiaccio

  • Se il nostro team fosse una macchina, quale parte avrebbe più bisogno di manutenzione in questo momento?
  • Qual è la soluzione più sorprendente che hai scoperto per un problema ricorrente?

Idee e consigli per la vostra riunione di retrospettiva

  • Inizia definendo chiaramente l'effetto o il problema nella 'testa' del pesce
  • Incoraggia una partecipazione equa di tutti i membri del team in tutte le categorie
  • Concentrati sull'identificazione delle cause piuttosto che saltare troppo rapidamente alle soluzioni
  • Usa la tecnica dei 'Cinque Perché' all'interno di ogni categoria per approfondire le cause profonde
  • Documenta tutte le intuizioni, anche se all'inizio non sembrano significative
  • Prevedi tempo sufficiente (90-120 minuti) per esplorare a fondo tutte le categorie

Domande frequenti

Quali sono le 6 M di un diagramma fishbone?
Le 6 M sono le classiche categorie di cause utilizzate in un diagramma fishbone (Ishikawa) nella gestione della qualità e nella produzione: Manodopera (le persone coinvolte), Metodo (il processo o il flusso di lavoro), Macchina (attrezzature e strumenti), Materiale (input e forniture), Misurazione (i dati e le metriche utilizzate) e Madre Natura (l'ambiente circostante). Ogni "M" diventa una lisca che si dirama dalla spina dorsale del pesce e il team fa brainstorming sulle possibili cause di ciascuna. Questo template di TeamRetro adatta la stessa idea delle sei categorie per i team di software e di lavoro basato sulla conoscenza usando le etichette Sistema, Processo, Moduli, Persone, Politiche e Luogo.
Qual è la differenza tra un diagramma fishbone e un diagramma di Ishikawa?
Non c'è differenza — sono due nomi per lo stesso strumento, insieme a un terzo nome, il "diagramma causa-effetto". Si chiama diagramma fishbone (a lisca di pesce) perché il disegno finito ricorda uno scheletro di pesce, e diagramma di Ishikawa in onore di Kaoru Ishikawa, l'esperto giapponese di controllo qualità che lo rese popolare negli anni '60.
Come si esegue l'analisi delle cause profonde con un diagramma fishbone?
Scrivi il problema nella testa del pesce, poi disegna le principali categorie di cause (come le 6 M, oppure Sistema, Processo, Moduli, Persone, Politiche e Luogo di questo template) come lische lungo la spina dorsale. Fai brainstorming sulle possibili cause di ogni categoria, poi per ciascuna continua a chiederti "perché?" finché non raggiungi una causa profonda anziché un sintomo. Infine, individua quali cause profonde sono più probabili e più impattanti e trasformale in azioni. Il valore del diagramma sta nel costringere il team a guardare ogni categoria invece di fissarsi sulla prima causa che viene in mente.
Chi ha inventato il diagramma di Ishikawa?
Il diagramma prende il nome da Kaoru Ishikawa, un teorico organizzativo giapponese e pioniere della gestione della qualità, che lo sviluppò e lo rese popolare negli anni '60 nell'ambito del movimento del controllo qualità. Rimane uno strumento standard nell'analisi delle cause profonde, nella produzione e nel lavoro di miglioramento continuo ancora oggi.