¿Dónde está el problema?¿Por qué mi equipo Scrum falla continuamente sprint tras sprint?

Hola a todos

Muchas veces al visitar equipos de trabajo me encuentro con Scrum Masters en los que su equipo lleva continuamente fallando con los puntos comprometidos sprint tras sprint, y por lo general corresponden a ciertas sintomatologías.

A continuación voy a presentar algunas de las posibles causas raíz y posibles formas de solución, espero esta lista te sea útil al momento de diagnosticar a tu equipo si está atravesando por la misma situación:

Posibles razones Consecuencia y Posible Soluciones Equipos Inestables Cambio frecuente de team members Continua renuncia de team members Consecuencia: Pérdida constante de conocimiento y reinicio de la dinámica del equipo. Posible(s) Solución(es): Hablar con los líderes de la organización buscando remover la causa del constante cambio de personas, esto muy probablemente se debe a creer que el equipo esta compuesto por recursos que pueden remover e ingresar sin ningún problema e impacto. Solicitarle al equipo confíe ante la crisis que se está presentando, que se va a remover la causa raíz que esta generando la renuncia continua de los miembros del equipo, y cumplir lo prometido al equipo. Team members a tiempo parcial Consecuencia: Pérdida de foco de los team members generando desgaste en tiempo para volver a entender el contexto del proyecto.(Esto sucede cuando las organizaciones creen que hacer muchas cosas al tiempo es mejor que hacer una cosa bien hecha a la vez. Es mejor llevar proyectos a los equipos que armar equipos para los proyectos) Posible(s) Solución(es): Hablar con la organización y solicitar la estabilización de los miembros del equipo donde al menos el 80% este a dedicación a tiempo completo.  La tecnología es desconocida o nueva para el equipo Consecuencia: Por más buena intención que tenga el equipo no se cumplen los compromisos pues no sabe como solucionar los diferentes tipos de retos que implica la tecnología. Posible(s) Solución(es): Entrenar correctamente al equipo en la tecnología y darles el suficiente tiempo para que la dominen y maduren. Traer team member expertos para que hagan programación por pares con ellos y haga transferencia de conocimiento. cambiar de tecnología por una que domine el equipo Estamos en un entorno de completa incertidumbre con la tecnología, aunque la dominamos estamos haciendo cosas completamente innovadoras. (Común en equipos de investigación) Consecuencia: Las estimaciones no se cumplen pues no se sabe con certeza si se logrará el resultado esperado. Posible(s) Solución(es): No presionar al equipo, proveerles un entorno de aprendizaje, olvidándose si se logra o no los puntos comprometidos y tener metas pequeñas alcanzables (al menos en teoría), y permitirles fallar. Hay presión por parte del cliente, product owner o el scrum master (en el peor de los casos) en el planning y el equipo debido a esta presión  se sobrecompromete Consecuencia: El equipo se sobrecompromete por temor a los "jefes" Posible(s) Solución(es): Es muy probable que ni el cliente, ni el Product Owner, y con mayor razón el Scrum Master, no entiendan que Scrum es: "Tiempo fijo - Alcance Variable" y que la presión sobre lo entregado solo va a generar una continua fatiga de todos por tener expectativas irreales. Recomiendo este post: [Scrum] Ritmo Sostenible sobre Ritmo Insostenible (clic aquí) El equipo está constituido por novatos o son demasiado optimistas al hacer las estimaciones Consecuencia: El equipo se sobrecompromete ignorando muchos elementos técnicos debido a su baja experiencia en el producto o en la(s) tecnología(s) involucrada(s). Posible(s) Solución(es): Sugiero que los equipos estén constituidos al menos con la mitad de las personas con experiencia, de manera que les enseñen (haya transferencia de conocimiento) y ellos permitan ver aspectos ignorados por los novatos o aprendices. Infraestructura inestable Consecuencia: Los compromisos hechos se vienen al suelo por los impedimentos de la infraestructura. Posible(s) Solución(es): Estabilizar cuanto antes la infraestructura, si es posible destinar tiempo del equipo a hacerlo. El tamaño del sprint es demasiado pequeño para generar valor. Consecuencia: Las historias de usuario continuamente no alcanzan la Definition of Done (DoD). Posible(s) Solución(es): Muchas veces cuando la tecnología tiene muchas capas es costoso alcanzar la DoD en un Sprint, para esto sugiero, las siguientes soluciones Cambiar el Sprint a no más de tres semanas (4 semanas no lo recomiendo de verdad), y tener ese tamaño como estándar de ahora en adelante Reducir el tamaño de las historias de usuario, aplicando patrones de división y haciéndolas menos complejas. (Sugiero la lectura de este post: Esfuerzos Sugeridos de Historias de Usuario según la Duración del Sprint - cilc aquí-) Impedimentos y/o desenfoques excesivos en el sprint Consecuencia: Los frecuentes problemas frecuentes no permiten lograr el foco en el sprint. Posible(s) Solución(es): Dividir el equipo, o tener otro adicional enfocado en los "desenfoques" Estabilizar el entorno  Detener el proyecto hasta que el entorno esté estabilizado Un producto con mucha deuda técnica Consecuencia: Cualquier estimación es dañada por la mala calidad del producto en la que se está trabajando. (Recomiendo este post : Hablemos de Deuda Técnica - clic aquí-) Posible(s) Solución(es): Identificar y remover la deuda técnica y constituir este esfuerzo como trabajo a realizar durante el sprint. Liberar al equipo de las estimaciones de forma que pueda construir producto y a la par remueve la deuda mínima necesaria que les permita trabajar. Las historias de usuario son demasiado grandes Consecuencia: El equipo falla constantemente sus estimaciones, impidiendo encontrar la Definition of Done (DoD) al final del Sprint Posible(s) Solución(es): Reducir el tamaño de las historias de usuario, aplicando patrones de división y haciéndolas menos complejas. (Sugiero la lectura de este post: Esfuerzos Sugeridos de Historias de Usuario según la Duración del Sprint - cilc aquí-) Las historias de usuario no están cumpliendo la Definition of Ready (DoR), es decir son aceptadas por el equipo aun sin tener sus definiciones y dependencias resueltas Consecuencia: Las historias de usuario tiene demasiadas sorpresas y trabas en el camino, implicando que no se cumpla el compromiso. Posible(s) Solución(es): No aceptar las historias de usuario que no cumplen la Definition of Ready (DoR). Suigiero leer este post de Johnny Ordoñez - La Definición de “Ready” es tan importante como la Definición de “Done” - Clic aquí - El equipo acepta historias de usuario que no tienen sus dependencias construidas.  Consecuencia: Las historias de usuario tiene demasiadas sorpresas y trabas en el camino, implicando que no se cumpla el compromiso. Posible(s) Solución(es): Esto sucede cuando existen otros equipos que proporcionarán insumos y estos no son entregados a tiempo al equipo. No aceptar las historias de usuario que no cumplen la Definition of Ready (DoR) y no tienen sus dependencias resueltas o construidas previamente. Suigiero leer este post de Johnny Ordoñez - La Definición de “Ready” es tan importante como la Definición de “Done” - Clic aquí - Tener muy buena arquitectura de componentes y crear contratos, APIs, interfaces de componentes entre el trabajo de los diferentes equipos, de forma que se puedan generar resultados. Crear Mocks basados en contratos que emulen el trabajo de los otros equipos. El Product Owner cambia las historias de usuario durante el sprint aumentándoles el tamaño asociado a las mismas Consecuencia: Las historias de usuario tiene demasiadas sorpresas  implicando que no se cumpla el compromiso. Posible(s) Solución(es): Educar al Product Owner y no aceptar estos cambios en las historias, postergándolos para el siguiente sprint. El Product Owner esta cambiando las prioridades durante el Sprint Consecuencia: No es posible cumplir un compromiso si las prioridades cambian constantemente. Posible(s) Solución(es): Educar al Product Owner y no aceptar estos cambios en las historias, postergándolos para el siguiente sprint. No usar Scrum como forma de trabajo, tal vez sea mejor Kanban.

"Cualquier parecido con la coincidencia es pura realidad"☺

Ahora para ser sincero, la no identificación oportuna de estas causas es responsabilidad del Scrum Master.(les recomiendo este post: El Paciente se Enferma de lo que el Médico Sabe. Una Invitación a no Detenerse en el Proceso de Aprendizaje -clic aquí-)


Si tienen más razones y posibles soluciones, bienvenidas sean en la zona de comentarios.

Comos siempre, bienvenido el feedack.

Saludos Ágiles

Jorge Abad