 |
| Imagen de Gerd Altmann en Pixabay |
Hablaba con mi amiga Claudia Toscano sobre el por qué la
duración de los Sprints debería ser siempre lo mismo, el por qué no era buena
idea estar cambiando de duración a las iteraciones en Scrum y lo primero que se
me ocurrió es que una de las razones principales es el ritmo, precisamente ese
ritmo sostenido del que hablamos ya desde el manifiesto ágil, que nos permite
conocer con más precisión (o menos imprecisión) la capacidad real del equipo.
Me refería a ese principio del Manifiesto que dice:
“Los
procesos Ágiles promueven el desarrollo sostenible. Los promotores,
desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de
forma indefinida”.
Decíamos que ese ritmo constante tiene otros beneficios
también, entre ellos mayor productividad, elimina el estar pensando
precisamente eso de "este sprint de cuánto tiempo será". Esas
conversaciones que son desperdicio y restan productividad desde el sprint
anterior en donde las personas están sugiriendo que "el próximo sprint sea
de 10 días o de 5", "qué tal si lo hacemos de 15", evita esos diálogos
que generan estrés, agregan confusión a un contexto que quizás ya tiene mucha
incertidumbre. En general, se reduce la complejidad, esa complejidad inherente
a tener que tomar ese tipo de decisiones cada vez que va a empezar un nuevo
sprint, aun desde el anterior.
Hay menos inseguridad. Hay menos gasto de energía y se
genera menos estrés. Además, con el tiempo, los eventos internos del Sprint son
más efectivos porque la gente ya conoce su ritmo y eso es muy importante en la Planificación,
porque el equipo ya tiene una proyección de lo que puede hacer en un Sprint. Hemos
notado que al mantener un ritmo y vigilarlo continuamente ayuda a mejorar la
eficiencia de las personas en el trabajo, reduce los riesgos inherentes al
trabajo del conocimiento y al producto o servicio, disminuye el desperdicio que
se pueda generar, sobre todo si mantenemos los elementos del backlog (historias
de usuario) pequeños, y contribuye significativamente a la mejora continua.
Algo que nos pasaba con nuestra forma de trabajar anterior,
en Cascada, era que lenta y casi imperceptiblemente empezábamos a caer en lo
que podríamos llamar "vórtice de procrastinación". Uno en el que
rápidamente estábamos perdiendo contacto con los clientes o consumidores, con
los interesados, pero incluso más grave aún, con los propios compañeros del
equipo. No sabíamos cuando íbamos a terminar algo, a pesar de los planes “detallados”
a que éramos sometidos de manera dictatorial y el fin de una actividad pasaba
de horas o días a semanas y rápidamente a meses… ¡un día a la vez!
¡Eso definitivamente no tenía nada de divertido!
¿Por qué? Porque somos seres rítmicos por naturaleza. Seguimos
ciclos de manera casi ritual, por ejemplo, estamos despiertos y dormimos más o
menos a las mismas horas, siempre. El ritmo nos ayuda a relajarnos, a calmar el
estrés, nos permite determinar bloques de tiempos para actividades específicas
y todo ello nos posibilita adaptarnos mejor a las circunstancias, porque
podemos predecir o proyectar lo que podemos hacer y cómo hacerlo sin estrés, de
manera más o menos divertida.
El Sprint en Scrum y
el ciclo lunar
 |
| Imagen de Syaibatul Hamdi en Pixabay |
El Sprint es el corazón de Scrum y en Scrum todo ocurre en
el marco de un Sprint. El objetivo en el Sprint es crear un incremento de producto “Terminado”, utilizable y
potencialmente desplegable en un ambiente donde al menos un grupo de usuarios o
consumidores pueda “jugar” con él. De la guía también aprendimos que “es más
conveniente si la duración de los
Sprints es consistente a lo largo del esfuerzo de desarrollo”. Ya hemos
establecido ampliamente el porqué es necesaria es invariabilidad.
Una de las
duraciones más ampliamente usadas por los equipos en todo el mundo es 2 semanas
para sus Sprints, según indica The
2015 State of Scrum Report de la Scrum Alliance. Más sobre este
reporte en:
Pero también es
importante definir Sprints cuyo inicio y fin concuerden con los ciclos lunares.
Esto se les hace más natural a las personas porque nos adaptamos mejor a esas
cadencias que son habituales para nosotros. Por eso siempre estamos buscando
iniciar Sprints un lunes y terminarlos un viernes. Sin embargo, en países como
Colombia donde las festividades fueron modificadas de manera artificiosa hace
ya varias décadas, hay que adaptar esos ciclos para acomodar tales eventos y
otras pausas habituales en las culturas locales. Por ejemplo, dado que en
Colombia hay muchos lunes festivos, podría ser interesante experimentar
iniciando los Sprints un martes y hacerlos de nueve días en vez de diez. En el
caso de que durante ese ciclo de dos semanas no haya días festivos, el décimo
día se puede usar para trabajar en la mejora del equipo o en apoyo a otros
equipos y áreas de la organización, o simplemente en socialización al interior
de la empresa. También son útiles estos días para realizar hackatones u otras actividades que fomenten la innovación.
De esta manera, los equipos establecen una cadencia acostumbrada
y fijan expectativas con base en las fechas de finalización de los Sprints. El
equipo puede sincronizarse con otros equipos para entregar incrementos de
producto en el que estén trabajando en conjunto o para tener un mejor manejo de
las dependencias entre ellos. Esto reduce los conflictos entre esos equipos y
las personas nos sentimos más a gusto y cómodas trabajando con el horizonte de
los ciclos naturales a los nos que hemos habituado desde niños. Esto mejora la
motivación del equipo y afianza los valores y la visión establecidos.
Conclusión
Tener este tipo de hábitos, como Sprints de duración fija,
reuniones diarias a la misma hora y en el mismo lugar, y conocer con
anticipación las fechas de otros eventos como la Planificación, la Revisión o
la Retrospectiva, permite que los miembros del equipo se enfoquen en sus tareas
principales y hagan lo que mejor saben hacer, que es manejar la incertidumbre, los
cambios y la ambigüedad inherente al tipo de tareas que hacemos diariamente, es
decir, esa otra cara variable del trabajo.
Referencias
Para saber más sobre patrones Scrum puedes consultar el
libro:
A Scrum
Book: The Spirit of the Game, de Sutherland , Coplien , den Hollander y otros.
