¿Qué es la Retrospectiva Fishbone (Ishikawa)?
La Retrospectiva Fishbone (Ishikawa) es un enfoque estructurado de resolución de problemas que ayuda a los equipos a identificar y comprender las causas raíz de los desafíos o problemas. Desarrollada por Kaoru Ishikawa en la década de 1960, esta técnica visualiza las relaciones de causa y efecto en un formato que se asemeja al esqueleto de un pez. Durante la retrospectiva, los equipos exploran seis dimensiones clave que podrían contribuir a sus desafíos: Sistemas, Procesos, Formularios, Personas, Políticas y Lugar. Este análisis integral garantiza que no se pase por alto ningún factor potencial, lo que conduce a soluciones más efectivas. Este método es particularmente valioso para equipos que enfrentan problemas complejos donde pueden intervenir múltiples factores. Al organizar las posibles causas en categorías distintas, los equipos pueden comprender mejor las relaciones entre los diferentes problemas y desarrollar mejoras específicas. Un diagrama de espina de pescado (también llamado diagrama de Ishikawa o diagrama de causa y efecto — los tres nombres se refieren a la misma herramienta) funciona escribiendo el problema en la "cabeza" del pez y dibujando las principales categorías de causas como espinas que se ramifican desde la columna vertebral. En su forma original de fabricación y gestión de calidad, esas categorías son las clásicas "6 Ms": Mano de obra (personas), Método (proceso), Maquinaria (equipo), Materiales (insumos), Medición (datos y métricas) y Medio ambiente (el entorno circundante). Los equipos hacen una lluvia de ideas sobre posibles causas bajo cada espina, y luego siguen preguntando "¿por qué?" para rastrear cada rama hasta su causa raíz en lugar de detenerse en el síntoma visible. Las categorías de esta plantilla de TeamRetro — Sistema, Proceso, Formularios, Personas, Políticas y Lugar — son una adaptación del mismo método de las 6 Ms para procesos de equipo, reajustadas para equipos de software y de trabajo del conocimiento en lugar de una fábrica. La técnica es idéntica; solo cambian las etiquetas de las categorías para adaptarse al tipo de trabajo que realizas. Por ejemplo, si el problema en la cabeza del pez es "los lanzamientos siguen retrasándose", una causa de Personas podría ser "el revisor clave es un cuello de botella", una causa de Proceso podría ser "no hay definición de terminado", y una causa de Sistema podría ser "un pipeline de CI inestable". Mapear las causas de esta manera evita que un equipo arregle síntomas y pase por alto el factor subyacente.
Formato de la Retrospectiva Fishbone
Sistema
¿Qué tecnología, software o herramientas podrían estar afectando el rendimiento o los resultados de nuestro equipo?
Guía al equipo en el examen de la infraestructura técnica, las herramientas de software y los puntos de integración de sistemas. Anima a los participantes a pensar tanto en problemas técnicos obvios como en interacciones sutiles del sistema que podrían afectar su trabajo.
Proceso
¿Qué flujos de trabajo o secuencias de actividades están causando retrasos o ineficiencias en nuestro trabajo?
Concéntrate en identificar cuellos de botella, redundancias o vacíos en los flujos de trabajo. Ayuda al equipo a distinguir entre problemas de proceso y otros factores preguntando sobre pasos específicos en sus procedimientos de trabajo.
Formularios
¿Qué problemas con nuestras plantillas o documentación podrían estar afectando la claridad o la precisión?
Examina la calidad, accesibilidad e integridad de la documentación. Considera tanto la documentación formal como la informal, y qué tan bien cumple su propósito previsto.
Personas
¿Qué factores relacionados con las habilidades, la comunicación o los roles individuales o del equipo están afectando nuestro éxito?
Aborda la dinámica del equipo y las contribuciones individuales manteniendo un entorno libre de culpas. Concéntrate en problemas sistémicos en lugar de críticas personales.
Políticas
¿Qué directrices o reglas podrían estar desalineadas con nuestras prácticas reales o crear desafíos?
Explora tanto las políticas formales como las informales que impactan el trabajo. Considera si las políticas apoyan u obstaculizan las necesidades y prácticas actuales del equipo.
Lugar
¿Qué aspectos de nuestro espacio de trabajo físico o virtual podrían estar afectando nuestra colaboración o productividad?
Considera tanto los entornos de trabajo físicos como los virtuales. Incluye factores como herramientas, distribución del espacio de trabajo y capacidades de colaboración remota.
Cuándo utilizar esta análisis retrospectivo
- Cuando se enfrentan problemas complejos que pueden tener múltiples causas raíz o factores contribuyentes
- Después de identificar un problema o desafío significativo que requiere un análisis sistemático
- Cuando el equipo necesita ir más allá de los síntomas para comprender las causas subyacentes
- Durante análisis post mortem de proyectos o revisiones de incidentes para prevenir problemas futuros
Preguntas sugeridas para romper el hielo
- Si nuestro equipo fuera una máquina, ¿qué parte necesitaría más mantenimiento en este momento?
- ¿Cuál es la solución más sorprendente que has descubierto para un problema recurrente?
Ideas y consejos para su reunión retrospectiva
- Comienza con el efecto o la declaración del problema claramente definido en la 'cabeza' del pez
- Fomenta la participación equitativa de todos los miembros del equipo en todas las categorías
- Concéntrate en identificar causas en lugar de saltar demasiado rápido a las soluciones
- Usa la técnica de los 'Cinco Porqués' dentro de cada categoría para profundizar en las causas raíz
- Documenta todos los hallazgos, incluso si inicialmente no parecen significativos
- Programa suficiente tiempo (90-120 minutos) para explorar todas las categorías a fondo
Preguntas frecuentes
¿Cuáles son las 6 Ms de un diagrama de espina de pescado?
¿Cuál es la diferencia entre un diagrama de espina de pescado y un diagrama de Ishikawa?
¿Cómo se hace un análisis de causa raíz con un diagrama de espina de pescado?
¿Quién inventó el diagrama de Ishikawa?
Plantillas relacionadas
Alinea a tu equipo sobre lo que realmente significa "terminado".
Retrospectiva Debe Debería Podría No Hará
Priorizar iniciativas usando criterios claros de decisión para mejores resultados de proyecto
Reunión Diaria
Mejora la alineación y productividad del equipo a través de breves reuniones diarias.
Café Lean
Una reunión estructurada pero sin agenda para discusión abierta.