En este post te voy a intentar explicar lo mejor posible cómo se trabaja y qué son las ceremonias de SCRUM. Seguro que lo has escuchado o pronunciado tal como suena: “escrum” en lugar de “scram”, no pasa nada, por lo menos estás en la onda y sabes de que va esta nueva metodología.
Dejar de llamarlas reuniones o lo que es lo mismo: La resistencia al cambio
¿Sigues todavía trabajando con metodologías Waterfall? ¿Tu organización duda de que Agile vaya a funcionar? En mi pasado más reciente empezamos con la semilla de Agile allá por el año 2013 en el área de Middleware en la que trabajé, cuando prácticamente nadie trabajaba en modo Agile.
Tuvimos la oportunidad de asistir a la CAS 2014 (Conferencias Agile Spain) en Barcelona donde aprendimos a mejorar en nuestro día a día. Te puedes imaginar que en este punto empezamos siendo autodidactas en varios proyectos en los que trabajamos.
Esta es una foto de nuestros inicios, donde teníamos nuestros proyectos representados en una pizarra física con nuestros post-its. Decidimos dejar de contribuir a la deforestación del Amazonas y nos pasamos a tableros virtuales con TargetProcess.
Antes de decidirnos por TargetProcess habíamos probado multitud de herramientas. Al final se decidió de forma consensuada con los equipos de desarrollo que era lo que mejor les parecía para implementar la nueva metodología de trabajo. Por el camino probamos JIRA, Rally, Mendix, etc.
Y así fue como los que éramos Jefes de proyecto pasamos a ser o Team Leaders de los equipos de desarrollo o bien Scrum masters encargados de seguir las distintas ceremonias que forman parte del concepto Agile.
(Qué son) y Cómo trabajamos en las ceremonias SCRUM:
Los Sprint Planning
Esta era la reunión (ups, ceremonia) más divertida. En el Sprint Planning se decide qué será desarrollado según la prioridad que ponga el Product Owner y la estimación de tiempo/esfuerzo que haga el Scrum Team.
Aquí probamos con varias técnicas para planificar las tareas que iba a ser capaz de desarrollar el equipo en lo que durase el sprint definido (2 a 4 semanas). Empezamos usando las medidas de puntos de historia o Story Points (1, 2, 4, 8 , 16, 32, 40 , 80) para determinar el coste de cada una de las historias de usuario.
Luego probamos con tallas de camisetas: XS, S, M, L, XL, XXL y finalmente acabamos probando también el Poker Planning, donde cada uno saca su carta de póker para estimar lo que estimaba que costaba hacer esa historia de usuario y llegar a un consenso entre todos.
Al final nos quedamos con los puntos de historia y tomábamos como referente 1 punto, que era lo que nos costaba modificar un fichero .properties con la modificación de un literal que luego se usaría en nuestro framework de Java.
? Si quieres profundizar en alguno de estos conceptos, aquí tienes un Glosario completo de la terminología Agile. Aquí puedes consultar todas las palabras de las que estoy hablando en este post.
En el Sprint Planning lo importante era llegar a un consenso entre lo que quería el Product Owner (PO) y lo que realmente iban a poder desarrollar el equipo. La figura del Scrum Master desempeña un papel de pisar el freno al PO, ya que había que contar con bajas por Gripe (o a día de hoy Coronavirus) , vacaciones, etc. Lo que como lógicamente estarás pensando, resta un pequeño % a la capacidad real del equipo en la duración del sprint.
La Daily
En nuestro caso lo que más nos costó afinar fueron las dailies. La daily es una ceremonia que se hace diariamente, de pie y en menos de 15 minutos, donde cada uno cuenta lo que ha hecho el día anterior, lo que iba a hacer ese día y si había tenido algún impedimento que le hubiese bloqueado la tarea prevista.
En este tipo de reuniones era donde se veía quien era la persona más pícara que siempre estaba con la misma tarea daily tras daily. Quien iba a la velocidad de la luz o quien era quien realmente tenía algún problema para poder finalizar su tarea.
Aquí vuelve a jugar un papel imprescindible el Scrum Master para que la daily no excediese de los 15 minutos. Muchas veces se bajaba al plano técnico y acabábamos extendiendo la charla 45 minutos y mucha parte del equipo con otro tipo de rol (acuérdate que en Agile los equipos son multidisciplinares) desconectaba de la reunión.
El Refinement
Para poder planificar el Sprint, el equipo (Scrum Team) necesita que el Product Owner hubiera dejado priorizadas las User Stories en el backlog. Suena fácil pero créeme que parece más sencillo de lo que es.
El PO puede priorizar al principio de cualquier Sprint, de forma que la ceremonia del Sprint Planning se hace más amigable y rápida basada en el Backlog Refinement.
Sprint Review o Demo
Esta es la ceremonia que determina si vas por el buen camino o no. Es la única en la que tendrían que estar todos los stakeholders presentes ya que se muestra el resultado del Sprint y deben confirmar que el desarrollo era tal cual esperaban o si por el contrario, había que modificar algo para el siguiente Sprint. Y así hacerlo lo antes posible.
Sprint Retrospective o Retro
Esta también era una reunión chula. En la Sprint Retrospective usábamos post-it’s para hacer un análisis post-mortem de que era lo que habíamos hecho mejor y debíamos seguir potenciando y que habíamos hecho peor y debíamos modificar de cara a los siguientes sprints para no cometer los mismos errores.
Todavía conservo los post-its que me dedicaron tres compañeros: Alberto, Ana y Alfredo en una de esas reuniones, tras un periodo muy tenso de nuestro proyecto en el que agradecían mi figura de Scrum master como “el que para la mierda”.
Agile súper agile!!
No todo es siempre tan bonito como los cuentos de hadas y en aquella época podía llegar un momento en el que la alta dirección podía decir: hazme esto para ya, con lo que se iba a incumplir lo que hubieras planificado en el sprint. Recuerdo perfectamente la frase de nuestro manager diciéndonos: “Si quieres ve y le dices a la directora de tecnología que no vas a hacer esto porque tienes que cumplir con tu sprint”. Por suerte ya no es así ?
Así que en conclusión, de aquí aprendimos un gran concepto: el de RESILIENCIA. Aprendimos una lección y finalmente creamos un tablero mezcla Scrum y Kanban (Scrumban) en el que teníamos un carril de alta prioridad en el que si entraba alguna tarea tenía que ser atendida a la menor brevedad posible por parte de todo el equipo si fuera necesario.
Afortunadamente hoy el contexto es otro: tenemos herramientas, formación y lo más importante, una cultura con total apoyo por parte de la dirección en la que todos vamos de la mano del Agile.
¿Y tú sigues trabajando en modelo Waterfall o te animas a pasarte al modelo Agile?
Joan Rodríguez
Santander Global T&O
Soy Ingeniero superior informático y he tenido la gran oportunidad de trabajar en todos los perfiles de desarrollo Waterfall o Agile: Desarrollador, Arquitecto SW, Evangelista del SW, Scrum master, Jefe de proyecto, Team leader, QA tester y Product owner. Me considero una persona inquieta, resiliente, friki y sobre todo muy volcado con mi familia. Ahora estoy haciendo desarrollos de ciberseguridad para el Grupo Santander.
