Jump to content

Fishbone: Difference between revisions

From Scrum Manager BoK
No edit summary
No edit summary
 
(3 intermediate revisions by the same user not shown)
Line 1: Line 1:
'''''Fishbone''''' ("Espina de pez" en español) es una práctica ágil que se suele realizar durante la fase 3 de una [[retrospectiva]]. Dura entre 30 y 60 minutos.  
{{Meta-bok|min=4}}
==Descripción y objetivos==
El '''Fishbone''' ("espina de pez"), también conocido como '''diagrama de Ishikawa''' o '''diagrama causa-efecto''', es una técnica de [[Retrospectiva|retrospectiva]] que usa una representación visual con forma de esqueleto de pez para identificar las causas que contribuyen a un problema. Se realiza en la '''tercera fase''' de la retrospectiva. Dura entre 30 y 60 minutos.
Sirve para revisar síntomas que identifiquen un problema de raíz y buscar las razones tras él.  
[[File:19EspinaPez.jpg|300px|thumb|right]]
 
== Descripción y objetivos ==
El equipo identifica los factores que están causando o afectando una situación problemática y luego busca las causas más probables. Después se buscan formas de hacer cambios o influir en esos factores.  
Sirve para revisar síntomas que identifiquen un problema de raíz y explorar las causas más probables. El equipo identifica los factores que están causando o afectando una situación problemática, busca las causas más probables detrás de esos factores, y luego diseña acciones para influir sobre ellos.
==Cómo realizar la actividad==
== Cuándo usarlo ==
La actividad paso a paso transcurre así:
* Cuando el equipo ha identificado un problema recurrente y necesita entender sus causas de forma estructurada antes de proponer soluciones.
# Se dibuja un diagrama de espina de pez o ''fishbone diagram''. El problema a tratar será la cabeza del pez. Hay que incluir los cinco ''W's'': qué, quién, cuándo, dónde y por qué (''What, Who, When, Where, and Why''). Para ello, se escribe una categoría por cada espina del pez (el equipo puede crear sus propias categorías), por ejemplo:  
* Como complemento a [[Cinco veces porqué]]: el Fishbone organiza las causas por categorías; los cinco porqués profundizan en cada causa.
* Cuando el problema tiene múltiples dimensiones (técnica, organizativa, humana, de proceso) que conviene explorar de forma paralela.
== Cómo realizar la actividad ==
# Se dibuja un diagrama de espina de pez. El problema a tratar es la cabeza del pez. Se incluyen los cinco ''W's'': qué, quién, cuándo, dónde y por qué (''What, Who, When, Where, Why''). Se escribe una categoría por cada espina. El equipo puede crear sus propias categorías o usar marcos habituales como:
#* Métodos, Materiales, Maquinaria, Personal (o mano de obra).
#* Métodos, Materiales, Maquinaria, Personal (o mano de obra).
#* Lugar, Procedimiento, Personas, Políticas de la empresa
#* Lugar, Procedimiento, Personas, Políticas.
#* Entorno, Proveedores, Sistemas, Habilidades
#* Entorno, Proveedores, Sistemas, Habilidades.
# Se hace una lluvia de ideas sobre los factores que pueden encajar en cada categoría. Se puede preguntar "¿Cuáles son los problemas de [nombre de categoría] que pueden causar o afectar a [nombre del problema]? Esto puede repetirse para cada categoría.
# Se genera una lluvia de ideas sobre los factores que pueden encajar en cada categoría. La pregunta guía es: "¿Cuáles son los problemas de [categoría] que pueden causar o contribuir a [problema]?"
# Cada miembro del equipo puede escribir los factores en ''post-its'' para pegarlos en las espinas del pez o puede ser el/la líder de la retrospectiva quien los escriba directamente en el diagrama.
# Cada miembro puede escribir los factores en post-its para pegarlos en las espinas, o el facilitador los escribe directamente en el diagrama.
# Este proceso puede continuarse hasta que las causas estén fuera del control del equipo.
# Se buscan los factores que aparecen en más de una categoría: suelen ser las causas más probables.
# Se buscan los factores que aparecen en más de una categoría, pues pueden ser las causas más probables del problema.  
# Se identifican áreas donde el equipo puede actuar con mayor impacto.
# Se puede animar al grupo a buscar áreas en las que se pueden realizar cambios.
# Los resultados se usan como base para la siguiente fase de la retrospectiva.
# Los resultados se usan para la siguiente fase de la retrospectiva.
== Error frecuente ==
==Véase también==
<div class="bok-aviso">
*[[Retrospectiva]].
'''Quedarse en los primeros factores evidentes.''' La estructura del Fishbone invita a explorar causas en múltiples categorías, pero si el equipo solo aporta las causas más obvias ("falta de tiempo", "requisitos cambiantes") sin profundizar, el diagrama acaba siendo un mapa de síntomas, no de causas. Combinar el Fishbone con los [[Cinco veces porqué|cinco porqués]] en cada espina ayuda a llegar a causas más profundas y accionables.
*[https://www.scrummanager.com/blog/2023/06/primera-fase-de-una-retrospectiva-3-actividades/ Scrum Manager Blog: «Primera fase de una retrospectiva: reflexión en equipo (3 actividades)»].
</div>
*[https://www.scrummanager.com/blog/2023/08/segunda-fase-de-una-retrospectiva-en-busca-de-la-mejora-continua/ Scrum Manager Blog: «Segunda fase de una retrospectiva: en busca de la mejora continua»].
== Recursos ==
*[https://www.scrummanager.com/blog/2023/10/tercera-fase-de-una-retrospectiva-crear-conocimiento/ Scrum Manager Blog: «Tercera fase de una retrospectiva: crear conocimiento»].
<div class="bok-recurso">
*[https://www.scrummanager.com/blog/2022/10/sprint-retrospective-ejemplo-preparacion-y-puesta-en-practica/ Scrum Manager Blog: «Ejemplo: cómo diseñar una sprint retrospective»].
📄 [https://www.scrummanager.com/blog/2023/10/tercera-fase-de-una-retrospectiva-crear-conocimiento/ '''Tercera fase de una retrospectiva: crear conocimiento''']<span class="detalle">Scrum Manager Blog · oct 2023</span>
*[https://www.scrummanager.com/blog/2022/12/resolucion-de-conflictos-en-una-retrospectiva/ Scrum Manager Blog: «Liderar retrospectivas y resolución de conflictos»].
</div>
*[https://www.scrummanager.com/blog/2022/09/apuntes-agile-retrospectives/ Scrum Manager Blog:  «Apuntes: Agile Retrospectives»].
== Referencias ==
==Referencias==
Derby, Esther; Larsen, Diana. (2006). ''Agile Retrospectives: Making Good Teams Great''. Pragmatic Bookshelf.
*[https://www.amazon.com/Agile-Retrospectives-Making-Teams-Great/dp/0977616649 Derby, Esther; Larsen, Diana. (2006) ''Agile Retrospectives: Making Good Teams Great''].
== Véase también ==
[[Category: Glosario de términos]]
<div class="bok-tags">
[[Category: Prácticas ágiles]]
[[Retrospectiva]] [[Cinco veces porqué]] [[Brainstorming/Filtering]] [[Force field analysis]] [[Patterns and shifts]] [[Acuerdos de trabajo]]
</div>
<div class="bok-ecosistema">
<div class="texto">
<span class="titulo">'''¿Quieres avanzar en agilidad?'''</span>
<span class="sub">Puedes buscar convocatorias de cursos y exámenes o ir a tu ritmo haciéndote miembro del Club Agile. Esta membresía incluye recursos exclusivos, aulas e-learning y acceso a [https://scrummanager.com/skillarena/ '''Skill Arena''']: un espacio para practicar y medir tus habilidades ágiles a tu ritmo.</span>
</div>
<div class="botones">
<div class="bok-btn-outline">[https://www.scrummanager.com/website/c/calendar/show-courses.php Buscar convocatorias]</div>
<div class="bok-btn-filled">[https://scrummanager.com/club/ Club Agile]</div>
</div>
</div>
[[Category:Glosario de términos]]
[[Category:Retrospectivas]]
[[Category:Prácticas ágiles]]

Latest revision as of 15:48, 14 May 2026

⏱ 4 min de lectura  ·  📅 Actualizado en 2026

El Fishbone ("espina de pez"), también conocido como diagrama de Ishikawa o diagrama causa-efecto, es una técnica de retrospectiva que usa una representación visual con forma de esqueleto de pez para identificar las causas que contribuyen a un problema. Se realiza en la tercera fase de la retrospectiva. Dura entre 30 y 60 minutos.

Descripción y objetivos

Sirve para revisar síntomas que identifiquen un problema de raíz y explorar las causas más probables. El equipo identifica los factores que están causando o afectando una situación problemática, busca las causas más probables detrás de esos factores, y luego diseña acciones para influir sobre ellos.

Cuándo usarlo

  • Cuando el equipo ha identificado un problema recurrente y necesita entender sus causas de forma estructurada antes de proponer soluciones.
  • Como complemento a Cinco veces porqué: el Fishbone organiza las causas por categorías; los cinco porqués profundizan en cada causa.
  • Cuando el problema tiene múltiples dimensiones (técnica, organizativa, humana, de proceso) que conviene explorar de forma paralela.

Cómo realizar la actividad

  1. Se dibuja un diagrama de espina de pez. El problema a tratar es la cabeza del pez. Se incluyen los cinco W's: qué, quién, cuándo, dónde y por qué (What, Who, When, Where, Why). Se escribe una categoría por cada espina. El equipo puede crear sus propias categorías o usar marcos habituales como:
    • Métodos, Materiales, Maquinaria, Personal (o mano de obra).
    • Lugar, Procedimiento, Personas, Políticas.
    • Entorno, Proveedores, Sistemas, Habilidades.
  2. Se genera una lluvia de ideas sobre los factores que pueden encajar en cada categoría. La pregunta guía es: "¿Cuáles son los problemas de [categoría] que pueden causar o contribuir a [problema]?"
  3. Cada miembro puede escribir los factores en post-its para pegarlos en las espinas, o el facilitador los escribe directamente en el diagrama.
  4. Se buscan los factores que aparecen en más de una categoría: suelen ser las causas más probables.
  5. Se identifican áreas donde el equipo puede actuar con mayor impacto.
  6. Los resultados se usan como base para la siguiente fase de la retrospectiva.

Error frecuente

Quedarse en los primeros factores evidentes. La estructura del Fishbone invita a explorar causas en múltiples categorías, pero si el equipo solo aporta las causas más obvias ("falta de tiempo", "requisitos cambiantes") sin profundizar, el diagrama acaba siendo un mapa de síntomas, no de causas. Combinar el Fishbone con los cinco porqués en cada espina ayuda a llegar a causas más profundas y accionables.

Recursos

📄 Tercera fase de una retrospectiva: crear conocimientoScrum Manager Blog · oct 2023

Referencias

Derby, Esther; Larsen, Diana. (2006). Agile Retrospectives: Making Good Teams Great. Pragmatic Bookshelf.

Véase también

¿Quieres avanzar en agilidad? Puedes buscar convocatorias de cursos y exámenes o ir a tu ritmo haciéndote miembro del Club Agile. Esta membresía incluye recursos exclusivos, aulas e-learning y acceso a Skill Arena: un espacio para practicar y medir tus habilidades ágiles a tu ritmo.