SCRUM - ¿Como aumentamos la velocidad de equipo?

A continuación comparto los burn down chart de un proyecto SCRUM en el que definimos Sprints de 1 semana y en el que evidentemente tuvimos muchos problemas para arrancar. Solo hasta finalizar el quinto sprint logramos cumplir a cabalidad el compromiso con el product owner. Esta es la historia:

 

Burn down chart Sprint 1

El sprint 1 fue el mas caótico. No teníamos los ambientes de desarollo configurados, no existían permisos sobre la infraestructura (SVN, Bases de datos, Servidores de documentación etc) y los miembros del equipo jamás habían trabajado juntos. Adicionalmente no se tenía conocimiento sobre las aplicaciones de software que debían ser modificadas y lo peor era que no existía documentación de la gran mayoría.

Pese a todo lo anterior, como equipo reconocíamos que se trataba de un sprint de prueba en el que obtendríamos cierto conocimiento y para el que probablemente no lográramos todas las metas propuestas. Incluso el product owner era consciente de ello. 

Burn down chart Sprint 2

Para el segundo sprint existía mucha mas expectativa. El product owner esperaba que al menos termináramos las historias de usuario que teníamos comprometidas en el sprint inicial. 

Con el fin de satisfacer esta expectativa mas no por convicción propia el equipo comprometió en el siguiente sprint las mismas historias que había comprometido en el anterior. El resultado fue que logramos terminar una ellas (La mas sencilla), pero de igual manera no se logró cumplir con el compromiso.

La sensación aún así era bastante positiva. En 15 Días habíamos generado valor al negocio lo cual era bastante bueno.

 

Burn down chart Sprint 3

En el tercer sprint el equipo se sentía mucho mas confiado. Comprometió esta vez las historias pendientes del sprint 2, más una historia adicional. pero al final el resultado fue bastante desalentador. No se logró completar ni una sola historia de usuario.

En la retrospectiva discutimos la razón por la que esto había sucedido. Una de las principales causas que creemos generó este resultado fue el cambio de uno de los miembros del equipo. Una de las personas salió a vacaciones y fue reemplazada por alguien nuevo quien tuvo que recorrer nuevamente el camino ganado en 2 sprints previos.

 

Burn down chart Sprint 4

En el Sprint 4 el resultado fue igual de desalentador. ¿Pero por que si ya la persona nueva había aprendido algo del sprint previo, aún así no logramos completar nada?.

En el Sprint anterior el equipo había avanzado varias tareas que conllevaban a que el esfuerzo restante para completar las historias fuera mucho menor. Al menos esta era la percepción que tenían los miembros del equipo.

La realidad era que desde el tercer sprint una historia de usuario no había sido estimada con consciencia. Realmente nadie sabía como completarla y simplemente asignaron una cantidad de puntos alta con lo cual pretendían evidenciar su complejidad. ¿Por como habríamos de completar algo que no conocíamos?. 

Burn down chart Sprint 5

Para este momento el producto owner estaba furioso, había pasado 1 mes y solo habíamos entregado un pequeño valor. Empezaban a aflorar los temores por la inversión financiera tan alta que se estaba realizando sobre el equipo sin recibir retorno en la inversión y surgieron propuestas como "Trabajar horas extra". Lo único que se le ocurre a los directores. 

Era entonces el momento de tomar medidas extremas y le dijimos al dueño del producto que no podríamos estimar la historia que no conocíamos hasta completar una prueba de concepto. Esta fue aceptada y con el fin de generar algo de valor comprometimos una historia de baja prioridad y baja complejidad. 

También hicimos varios acuerdos de equipo. Llegamos a la conclusión que estábamos muy desenfocados y decidimos partir la daily meeting en 4 reuniones de 2 Horas durante todo el día que nos permitieran ponernos metas mas concretas. Al final logramos entregar la historia de baja complejidad y no alcanzamos a completar la prueba de concepto. ¡Pero ya teníamos mucha información que nos permitiría estimar el siguiente sprint!

Burn down chart Sprint 4

¡Y se hizo la luz!. Estimamos el siguiente sprint.

Comprometimos la historia de la prueba de concepto mas otras tres historias. Continuamos con los Hour meetings cada 2 Horas y exigimos al producto owner mayor presencia. Adicionalmente desde el sprint anterior se venía trabajando en conseguir información que nos permitiera estimar acertadamente las historias de usuario que venían en orden de prioridad (Defenition of ready). Con toda esta información, mas el foco de las reuniones de 2 Horas, y la compenetración que ahora tenía el equipo se logró este resultado.