jueves, septiembre 28, 2017

¿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


  • 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):

  • 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):

  • 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.

  • 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

jueves, septiembre 14, 2017

Es inútil, no trates de uniformizar tus equipos Scrum

Hola a todos

Algunos de nosotros hemos tenido la experiencia de empezar en un equipo Scrum desde cero, ya sea como Product Owner, Scrum Master o Team Member, y hemos intentado traer prácticas que hemos aprendido (y que nos han funcionado muy bien) en otros equipos pero en este:
  • no son acogidas, 
  • las usas pero no tienen el mismo impacto.
  • las usan y pronto las desechan

Lo cierto, es que cada equipo es un universo único de relaciones únicas entre sus integrantes y aunque empezaramos dos equipos con el mismo scrum master el mismo día y para el mismo producto, es muy probable que pronto (al segundo sprint - tal vez-) comiencen a existir diferencias entre las prácticas adoptadas, pues cada equipo (de acuerdo a su inteligencia colectiva) en las retrospectivas o en el avanzar de los sprints encuentra:
  • accionables
  • acuerdos
  • experimentos y 
  • prácticas
Que le son útiles en su contexto único, para esos integrantes en ese momento del tiempo y para nadie más.

Por lo tanto, y cerrando rápido esta corta reflexión
  • lo que le sirve a un equipo, no tiene necesariamente por que servirle a otro
  • (igual en las organizaciones) lo que le sirve a una organización no tiene necesariamente por que servirle a otra
  • cada equipo es un mundo diferente
  • los equipos van encontrando su propia forma particular de responder al contexto y es deber del Scrum Master guiarlos en este reto.
  • es necesario hacer inspección y adaptación para ir respondiendo al entorno complejo
y la obvia
  • es inútil tratar de uniformizar tus equipos scrum.

Hasta acá esta corta reflexión, bienvenido el feedback y tus experiencias en la zona de comentarios.

Saludos ágiles
Jorge Abad


Notas


  • Me he encontrado con equipos a los cuales les funciona bien el burdown y otros no, se contentan con el kanban.
  • Este post no va en contra de las prácticas definidas por la organización, en ese caso los equipos trabajan con los artefactos, y herramientas asignadas por la organización, es más dirigido a nuestro es fuerzo de copiar y pegar indiscriminadamente sin ningún contexto.