El pasado lunes 30 tuvo lugar la siguiente reunión de Scrum Masters de Kaleidos, tras el parón veraniego. En el orden del día, el repaso de conclusiones de la reunión anterior, y un punto importante, referido a las estimaciones de los trabajos de maquetación.
Repaso reunión anterior
Primera vez con menos asistentes
En la reunión anterior se decidió que asistiera sólo un Scrum Master por equipo, con la idea de agilizar el trabajo y reducir la carga de horas, sin perder demasiado en calidad y difusión de la información. La sensación ahora es que fue una decisión correcta.
Todos somos maquetadores
No entramos a valorar específicamente esta consigna surgida de la última vez, pero se percibe que es una cuestión que está progresando correctamente por ahora.
Scrum en equipos “grandes”
En el equipo que generó este debate, profundizando en la raíz de las causas, se ha visto que el problema no es tanto el tamaño del equipo, que parece que se va pudiendo gestionar bien con los mecanismos que se han ido implantando. Lo que está generando mayor estrés es el tener un cliente que, aparte de las tareas estables, requiere constantemente tareas urgentes, con prisa para salir a producción y que trastocan el ciclo de sprints y entregas planificadas.
Para afrontar la situación, el equipo ha decidido implantar lo que han llamado “Scrumban”. Es decir, se añade al backlog normal de Scrum un “canal Kanban”, una historia especial dentro de cada sprint donde puedan entrar estas tareas urgentes. Y se establecen varias restricciones para conciliar las expectativas del cliente con mantener la salud mental del equipo y la calidad del trabajo:
- Las tareas Kanban no se estiman, se ejecutarán ASAP teniendo en cuenta el tiempo de pruebas, Pirata Roberts y despliegue.
- Hay un límite en la cantidad de tareas que puede haber simultáneamente en el canal Kanban.
- Se acepta que el canal Kanban reduce la capacidad del equipo para historias normales, podrá haber historias del sprint que no se completen.
- Se han implantado varias técnicas para agilizar la gestión de ramas y los despliegues.
Esta estructura se acaba de implantar, en próximas reuniones iremos viendo si funciona.
Nuevos temas
Estimación de trabajos de maquetación
Hace pocos días se ha detectado un problema: desde que contamos con maquetadores propios de Kaleidos, integrados en los equipos, no estamos gestionando bien su trabajo. Parece que no tenemos claro cómo estimarlo, visibilizarlo, coordinarlo y calcular sus costes e incluirlos en los presupuestos. En cada equipo se está haciendo de forma distinta, lo cual desconcierta a los maquetadores, que están repartidos en más de un proyecto.
Tras un largo debate, llegamos a una propuesta que ofrecemos a todos los equipos para hacerlo así desde ahora:
Los maquetadores se van a gestionar como cualquier otro miembro del equipo, a todos los efectos, siendo su trabajo estimado en puntos, presupuestado y visibilizado con los mismos mecanismos que el de programación.
Esto implica que las historias tendrán puntos de maquetación y puntos de programación, sumados en un total. Se debe poder ver el desglose de ambos en algún sitio.
Según el proyecto, la estimación de maquetación se puede hacer como un % sobre la programación, o bien hacer una estimación más fina con la involucración del maquetador.
En historias en las que la maquetación y la programación caben enteras en un sprint, esto parece óptimo. La complejidad surge cuando no es así, teniendo en cuenta nuestra estructura de paralelismo, en los que los programadores pueden ir avanzando historias mientras se van maquetando las que entrarán en el sprint siguiente.
Se plantean dos posibles formas de hacerlo, según el tipo de proyecto:
a) Al llegar a la cima del backlog, la historia se parte en dos, una tiene la parte de maquetación y otra la de programación (para eso es necesario ver el desglose en puntos). En el sprint se mete la subhistoria de maquetación y la otra se deja en el backlog para el sprint siguiente. Esto vale en proyectos en los que las maquetas son percibidas por el cliente como algo con valor suficiente como entregable, para enseñar en la demo.
b) Las historias no se parten, y los maquetadores pueden trabajar en historias que están aún en el backlog. Cuando éstas entran en el sprint, se asume que los puntos correspondientes a maquetación ya están consumidos, y en el sprint se van a completar los de programación. Para esto, hay que congelar de alguna forma un fragmento superior del backlog, en un pseudo-próximo sprint o “sprint cocina”.
Se piensa en un futuro poder extender estas técnicas también a UX y diseño.
Profundizando en la involucración del Agile Coach
Dado el interés que tiene la figura y los buenos resultados que se van percibiendo, el Agile Coach sigue incrementando poco a poco su dedicación de tiempo. Aumenta también su presencia en reuniones de los equipos y su asistencia a congresos y actos relacionados con el agilismo. En algunos proyectos pequeños puede incluso ser él el Scrum Master aunque no participe en el desarrollo.
Se va tambien a plantear hacer más mediciones de parámetros de los equipos, para conocer mejor cómo están funcionando.
Felicidad del equipo
Se comentó también la situación de otro equipo en el que, a pesar de tener la sensación de estar realizando un buen producto al final, el proceso está siendo difícil. Esto provoca que la velocidad del equipo sea bastante menor de lo deseable, y genera cierta cantidad de estrés y frustración. Se informó de que ha habido una reunión en la que se han analizado las causas, tanto del lado de cliente y partners como internas del equipo, y se han establecido algunas medidas que se colocarán en un panel.
Open Space
Se decidió dar por fin el impulso definitivo al Open Space interno de Kaleidos, al que llevamos tiempo buscando hueco, y que se ha celebrado finalmente el día 4 de octubre, con interesantes resultados de los que esperamos hablar también pronto en este blog.