El lunes pasado tuvimos el primer Sprint Planning de la reimplementación de Scrum. Estuvo bastante bueno, como siempre, una de las principales ventajas de Scrum es que se comience una nueva etapa en la comunicación y colaboración del equipo. Ese cambio de cabeza, de perder el rol de «jefe», y pasar a que el trabajo de cada uno sea responsabilidad del equipo hace a un cambio general en el ambiente, no tanto en el plano personal del trato entre los miembros del equipo, sino la forma de encarar el trabajo en sí. Se hace mucho más dinámico y efectivo, además de organizado. Estoy hablando de un equipo donde anteriormente no se usaba una metodología específica de desarrollo, sino que se iba sacando el trabajo.

Va costando un poco, uno de los temas complicados es que un equipo pase de no tener horarios a cumplir con el timeboxing. Si bien los horarios de las reuniones se eligen en equipo, a algunos les sigue costando, por lo que a veces caemos en el error de esperar 5 minutos a que llegue un miembro u otro al Daily Meeting.

Algo que me dió la impresión durante esta primera planificación, es que el Product Owner cayó en la idea que su trabajo no es para nada trivial, sino que acarrea una responsabilidad bastante grande. Si bien demuestra que se nutrió bastante con la metodología, leyendo varias documentaciones y recursos, dió la impresión de que en ese momento realmente asimiló la cantidad de trabajo. Recordemos que el rol del Product Owner conlleva muchas funciones. Debe actuar como filtro y representante de los stakeholders, así como negociar y priorizar elementos del backlog. En fín, al igual que el resto de los integrantes, irá aprendiendo en el camino.

Y es que Scrum es una metodología ideal para ir aprendiendo sobre la marcha. Hemos estado pasando enlaces con documentos y demás y transmitiendo la idea, pero es un proceso evolutivo. Somos dos los que venimos oficiando de Scrum Master, retroalimentándonos en el rol, y tratando que los demás asimilen la esencia de Scrum para aplicarlo en armonía con el ideal que lo hace tan efectivo y productivo.

Todavía falta transmitir algunos conceptos fundamentales, y el equipo se va a ir amoldando. Algunos puntos importantes que quedaron en el tintero para ir mechando durante las reuniones fue la visión del equipo y el working agreement. Si bien no son imprescindibles para implementar la metodología, creo que sirven para afianzar la confianza y el respeto entre los miembros del equipo, y permite concretar un primer proyecto en común.

Pero ya estamos usando la gestión visual del proyecto con un task board. Usamos un pizarrón con 4 columnas:

• Backlog: En esta columna pegamos post-its amarillos grandes, con varias tareas (a alto nivel) que se fueron determinando en el primer planning. Obviamente está abierto a más post-its en el futuro, ya que es el backlog general del producto.
• Sprint Backlog: Es el «TO DO», lo que hay por hacer, las tareas comprometidas para este Sprint.
• En proceso: Las tareas en las que se está trabajando.
• Terminado: Tareas prontas.

Como referencia, ya que no estimamos esfuerzo por cada tarea, vamos marcando un punto rojo por día transcurrido de la tarea en la columna «En proceso». Al no haber estimado, no tenemos todavía un Burndown chart, pero los puntos rojos van a ayudar a empezar a estimar más adelante.

Este primer Sprint, como experiencia, lo hicimos de corta duración. Empezamos el lunes y terminamos el viernes. El lunes siguiente haríamos una retrospectiva y review del sprint, y un nuevo planning. Dependiendo de cómo nos vaya, lo haremos de una o dos semanas de duración. Iré comentando nuevas experiencias y observaciones a medida que vayan surgiendo.