¿Qué es la retrospectiva Espina de pescado (Ishikawa)?
La retrospectiva Espina de pescado (Ishikawa) ayuda a tu equipo a encontrar las causas raíz de un problema en lugar de tratar solo sus síntomas. Se basa en el diagrama de causa y efecto que Kaoru Ishikawa popularizó en los años sesenta, que organiza las posibles causas en una figura parecida al esqueleto de un pez. En esta plantilla el equipo recorre seis categorías de causas: Sistema, Proceso, Formularios, Personas, Políticas y Lugar. Ir categoría por categoría obliga a mirar más allá de la primera explicación que viene a la cabeza, de modo que también salen a la luz las causas que quedan fuera del área de cada uno. Es especialmente útil para problemas con varios factores en juego, cuando una solución evidente no ha funcionado. Clasificar las causas por categorías muestra cómo se relacionan entre sí y señala el cambio que tendrá mayor impacto. 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) coloca el problema en la "cabeza" del pez y dibuja las principales categorías de causas como espinas que salen de la columna. En su forma original, propia de la fabricación y la gestión de la calidad, esas categorías son las "6 M": Mano de obra (personas), Método (proceso), Máquina (equipos), Material (insumos), Medición (datos y métricas) y Medio ambiente (el entorno). El equipo propone posibles causas en cada espina y luego sigue preguntando "¿por qué?" para recorrer cada rama hasta su causa raíz. Las categorías de esta plantilla adaptan las 6 M a equipos de software y de trabajo del conocimiento. La técnica es la misma; solo cambian las etiquetas para ajustarse a vuestro trabajo. Si el problema en la cabeza del pez es "las entregas se retrasan una y otra vez", una causa de Personas podría ser "el revisor clave es un cuello de botella", una de Proceso "no hay definición de terminado" y una de Sistema "el pipeline de CI falla de forma intermitente". Mapear las causas así evita que el equipo corrija un síntoma y pase por alto lo que realmente lo provoca.
Formato de retrospectiva Espina de pescado
Sistema
¿Qué tecnología, software o herramientas podrían estar afectando al rendimiento o los resultados del equipo?
Revisad la infraestructura técnica, las herramientas de software y los puntos donde se conectan los sistemas. Preguntad por los fallos técnicos evidentes y también por las formas más sutiles en que la interacción entre sistemas ralentiza el trabajo.
Proceso
¿Qué flujos de trabajo o secuencias de actividades están causando retrasos o ineficiencias?
Buscad cuellos de botella, pasos duplicados y huecos en los flujos de trabajo. Preguntar por pasos concretos de cómo se hace el trabajo ayuda al equipo a distinguir los problemas de proceso de otras causas.
Formularios
¿Qué problemas con plantillas o documentación podrían afectar a la claridad o la precisión?
Revisad las plantillas y la documentación. ¿Se encuentra lo que hace falta, está completo y cumple su función? Incluid tanto los documentos formales como los informales.
Personas
¿Qué factores de habilidades, comunicación o roles están afectando a nuestro éxito?
Hablad de habilidades, comunicación y roles sin buscar culpables. Centraos en las condiciones que rodean a las personas, como roles poco claros o silos de conocimiento, y no en criticar a nadie.
Políticas
¿Qué normas o directrices no encajan con nuestra práctica real o nos generan dificultades?
Revisad las normas escritas y no escritas que afectan al trabajo. Preguntad si cada política sigue apoyando la forma en que el equipo trabaja hoy o si se ha convertido en un obstáculo.
Lugar
¿Qué aspectos del espacio físico o virtual podrían afectar a la colaboración o productividad?
Tened en cuenta el espacio de trabajo físico y virtual, incluidas las herramientas, la distribución de la oficina y lo bien que funciona la colaboración en remoto.
Cuándo utilizar este estudio retrospectivo
- Cuando es probable que un problema tenga más de una causa
- Después de una incidencia importante que necesita un análisis estructurado antes de que nadie proponga una solución
- Cuando el equipo sigue corrigiendo síntomas y el problema vuelve a aparecer
- En post-mortems de proyectos o revisiones de incidencias, para evitar que el mismo fallo se repita
Preguntas sugeridas para romper el hielo
- Si nuestro equipo fuera una máquina, ¿qué pieza necesitaría más mantenimiento ahora mismo?
- ¿Cuál es la solución más sorprendente que has encontrado para un problema recurrente?
¿Le gustaría que su equipo realizara un ejercicio de calentamiento, en lugar de limitarse a responder en voz alta? Eche un vistazo a los rompehielos gratuitos →
Ideas y consejos para su reunión retrospectiva
- Escribid un enunciado claro del problema en la cabeza del pez antes de que nadie añada causas
- Aseguraos de que todo el mundo aporte causas en todas las categorías, también en las que quedan fuera de su rol
- No propongáis soluciones hasta haber mapeado las causas
- Usad los Cinco porqués dentro de cada categoría para ir más allá de la primera respuesta
- Anotad todas las causas, incluso las que al principio parecen menores
- Reservad entre 90 y 120 minutos para poder cubrir bien las seis categorías
Preguntas frecuentes
¿Qué son las 6 M de un diagrama de espina de pescado?
¿Qué diferencia hay 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
Acordad en equipo qué significa realmente terminado.
Retrospectiva Must Should Could Won't
Acordad en equipo qué tiene que hacerse y qué puede esperar.
Lean Coffee
Una reunión estructurada pero sin agenda para conversar abiertamente.
Retrospectiva Rosa, Brote, Espina
Identifica los logros, oportunidades incipientes y puntos de dolor de tu equipo en una sola sesión.