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.

Arquitectura - Mi experiencia como arquitecto de un proyecto SCRUM

Hace algún tiempo (y continuo haciéndolo), tuve la fortuna de participar como arquitecto de software en  un proyecto SCRUM. Previamente había leído algunos libros y asistido a ciertas capacitaciones. La teoría la tenía absolutamente clara, pero continuaba con un gran interrogante. ¿Cuál es el papel de un arquitecto de software en un proyecto ágil? Cada uno de los trainers con los que discutía me daba respuestas diferentes. Uno me dijo que simplemente en Scrum no existe tal cargo, que los diseños son absolutamente emergentes y parten de la decisión de cada uno de los miembros del equipo, otro me dijo que la labor del rol dentro del equipo era de apoyo y consultoría, otro simplemente me dijo que la arquitectura en ágil se presta como un servicio y no como una imposición.

Hoy después de un par de meses como practicante he llegado a una conclusión. La respuesta a esta pregunta no es importante y todos tienen razón.

Los proyectos de software realizados bajo metodología RUP tienen roles claramente identificados, con responsabilidades muy claras, delimitadas en el sentido más estricto. Esta es la forma como había trabajado hasta el momento y era la zona de confort en la que mejor de desenvolvía. Ahora que conozco Scrum pienso que esta estructura imposibilita el trabajo en equipo y orienta a las personas a la realización de tareas y no al logro de metas. Piensen en lo siguiente. El analista de requerimientos es el encargado de levantar los requisitos con el cliente y hacer casos de uso, el arquitecto es el encargado de realizar un diseño de alto nivel que satisfagas los drivers arquitectónicos, los desarrolladores son los encargados de implementar lo que definen el analista de requerimientos y el arquitecto, el de calidad simplemente prueba, reporta errores y le daña la vida a los desarrolladores. ¿Y dónde queda el objetivo de construir un software de calidad que satisfaga las necesidades del cliente?

Alguien me dijo alguna vez. Lo importante no son los roles, ni los cargos. Lo importante es el logro de la meta, algo similar a lo que pasa en un EQUIPO de futbol. Hasta el arquero cobra tiros libres en caso de ser necesario. 

Cuando inició el proyecto en cuestión el equipo pasó varios días tratando de organizarse. Al inicio como arquitecto me encargaba de hacer pair programming de ciertas historias de usuario muy complejas, acompañar los diseños y visionar lo que venía en conjunto con el producto owner. Luego por la premura del tiempo terminé haciendo parte del equipo de desarrollo, implementando y sacando a producción varias funcionalidades. 

La velocidad del equipo era muy baja tendiente a 0. La motivación de las personas decaía y el producto owner estaba molesto, no teníamos un Scrum master asignado de modo que como equipo debíamos tratar de resolver los impedimentos y avanzar en el logro de las metas de cada sprint.

Solo hasta que todo estuvo muy mal, empezamos a mejorar. El producto owner estaba desesperado e insistió en que el equipo debía recuperarse del atraso que se tenía respecto a las historias de usuarios que se habían comprometido e incumplido en sprints anteriores. Incluso sugirió trabajar tiempo extra (Lo que por supuesto el equipo rechazó).

En una de las retrospectivas descubrimos (Entre otras cosas) que el equipo no podía avanzar en la construcción de las historias comprometidas porque en el planning no se consideraban muchas cosas que finalmente se realizaban en la implementación, esto incrementaba el esfuerzo requerido y hacía que se perdiera el foco.

Después de discutir algunas alternativas decidimos que en el sprint planning se revisaran algunas de las historias que podrían hacer parte del siguiente sprint y hacer una definición de listo (Definition of ready). Se trata de revisar que necesitamos que se encuentre completo antes de incluir una historia de usuario en un sprint. 

Como arquitecto mi labor ahora era completar todas aquellas cosas que el equipo requería para poder estimar y completar una historia de usuario. De esta manera se tenía menor incertidumbre en el planning y no se perdía tiempo en labores de configuración de ambiente, o gestiones con otras áreas de tecnología durante el sprint. También debía conversar constantemente con el owner para aclarar mucho más las historias que venían en orden de prioridad y dejar claros los criterios de aceptación de las mismas. Esto se tradujo en mayor foco y por supuesto en mayor velocidad. Ahora el owner y el sponsor se sienten un poco más tranquilos y como equipo estamos avanzando en el logro de la meta.

Como conclusión puedo decir que el nombre del cargo realmente no importa, simplemente es una persona más dentro del equipo que se preocupa al igual que todos por lograr el objetivo y durante el proceso apoya al equipo en todo lo que sea necesario para llegar a la meta (Esto incluye lo que tradicionalmente se hace en arquitectura de software, solo que con un enfoque mas servil y no como imposición que es la forma como tradicionalmente se ve).