En la sesión de Agile Talks que tuvimos la semana pasada sobre “El día a día del Scrum Master”, la pregunta más votada por los asistentes fue ¿Cómo hacer una Daily Scrum efectiva? y sobre ella se hablaron de los siguientes temas y sobre algunos profundizaré en este blog y agregaré algunos otros.

La Daily no es para monitorear

Este evento de Scrum no es para controlar al equipo o aplicar el “micro-management”, sino porque en un día pueden pasar muchas cosas y es importante tener claridad sobre lo que va sucediendo, sobre todo, sobre lo que se va descubriendo:

Dependencias nuevas.
Condiciones nuevas.
Complejidad, algo que parecía más fácil pero se complicó por alguna razón.
Necesidades de comunicar algo.
Nueva información o datos.

Y claro, las 3 preguntas propuestas para guiar este evento, la verdad, es que no ayudan mucho para entender esto porque al leerlas, si parece que es para monitorear: ¿Qué se hizo ayer? ¿Qué se va a hacer hoy? ¿Qué impedimentos hay?.

Pero no es para reportar, es para compartir los descubrimientos y sobre todo los impedimentos, todo aquello que nos esté haciendo avanzar más lento de lo que esperábamos o que ya nos haya detenido, porque algo puede estar en la columna de “en proceso” pero estar detenido.

Así que, recuerda que el objetivo de la Daily es: Inspeccionar el progreso hacia el Objetivo Sprint y adaptar el Sprint Backlog según sea necesario, ajustando el próximo trabajo planeado.

Por lo tanto, si la daily nos ayuda a ir ajustando nuestro plan de acuerdo a lo que se avanza y se descubre cada día para con ello ser más certeros en lo que nos vamos comprometiendo, indica que la estamos haciendo bien.

Visualizar el tablero mientras se está llevando a cabo la Daily.

Antes de empezar con la importancia de la visualización, considero que vale la pena aclarar que en la guía oficial de Scrum, en ningún lado se hace referencia a “ceremonias”, Scrum oficialmente no tiene ceremonias, se hacen EVENTOS. Esta convención de llamarle así fue más algo de las Comunidades de Agilistas y los Evangelistas de la Agilidad, pero para entender la importancia de visualizar el tablero mientras se lleva a cabo la daily, es importante entender que NO es una ceremonia.

Una ceremonia, por definición, es la acción que se lleva a cabo de acuerdo a una costumbre, un reglamento o una norma, con el objetivo de rendir tributo o manifestar respeto o adhesión a algo o alguien. Entonces, los objetivos son distintos, porque si se busca que sea una costumbre pero no estamos rindiendo tributo a algo o a alguien, buscamos ADAPTARNOS, por lo tanto, no pueden ser todas las Dailys iguales o incluso parecer aburridas, porque en ellas se mantiene el interés del equipo por avanzar y por colaborar.

Para adaptarnos, avanzar y colaborar, es necesario que todos veamos lo mismo, y es ahí donde entra el poder estar visualizando el tablero como apoyo a Scrum, porque el uso del tablero no es una práctica de Scrum ya que solo tiene Eventos, Artefactos y Responsabilidades, el uso del tablero lo adoptamos de Kanban. Si bien, Scrum no tiene prácticas, es un excelente contenedor de prácticas.

Si esto era importante antes de la pandemia, al llegar el trabajo virtual esto toma una mayor importancia ya que al no estar juntos presencialmente, necesitamos asegurar que estamos entendiendo y viendo lo mismo.

No perder el foco y respetar el tiempo

En la Daily no se resuelve nada, se prioriza lo que hay que resolver al terminar este evento Scrum y cuando se respeta esto, el tiempo establecido si alcanza.

Esto se refuerza en la guía de Scrum diciendo “El Daily Scrum no es la única vez que los desarrolladores pueden ajustar su plan. Frecuentemente se reúnen durante todo el día para debatir de forma más detalladas sobre la adaptación o replanificación del resto del trabajo del Sprint.”

Fomentar la colaboración

Incluir la pregunta ¿En qué nos podemos enfocar como equipo de lo que ya empezamos hacer, para avanzar lo más posible y moverlo a la columna de terminado”. Esta es una recomendación de Jeff Sutherland (aunque no viene en la guía de Scrum).

Cuando cada miembro del equipo simplemente está esperando su turno para hablar sin escuchar a los demás y hablando por hablar, no estamos cumpliendo el objetivo de la Daily Scrum.

Si hay multiproyectos la Daily se dificulta

El fenómeno de los multiproyectos y que cada persona tenga más de un proyecto a la vez no solo dificulta la Daily, sino que dificulta hacer Scrum y ¡dificulta la vida misma!

El cambio de contexto provoca pérdida de tiempo y no podemos evitarlo, porque así somos los humanos, pero no solo eso, dificulta coordinarnos para llevar a cabo la Daily a la misma hora con todos presentes cuando el equipo tiene otros 4 proyectos donde no están juntos y hay diferentes prioridades, y aparte, si son 4 proyectos ya no se invierten solo 15 minutos al día, con 4 proyectos ya se te fue una hora en dailys.

Tanto en el caso de la Daily como en el caso de otra característica de Scrum que no se pueda habilitar, por la cultura de la empresa, por los multiproyectos o por lo que sea, es importante levantar la mano y que todos estén conscientes de que algo que está estipulado en este momento no se va a hacer de la manera esperada, identificar las razones y con ello las acciones necesarias para cambiar realmente.

A lo anterior hay que agregarle una fecha para ya ver el cambio manifestado, si no, no sirve y más que no servir, podemos caer en disfrazar el cambio, es decir, decir que hacemos la daily cuando ni la hacemos diario ni la hacemos bien y de repente, eso queda normalizado. Y el problema de los disfraces es que implican dobles esfuerzos y ya considerando el tema de los multiproyectos, es claro, que no tenemos tiempo para perderlo disfrazando cambios inexistentes.

Conclusión:

La Daily Scrum efectiva no solo es posible, es necesaria. Porque si estamos en entorno de incertidumbre donde tenemos alta susceptibilidad a cambios y con ello el descubrimiento es constante y por ello hacemos planeación a corto plazo, necesitamos actualizar nuestras expectativas y avances diario para tener tiempo de reaccionar y poder ser más certeros en los compromisos que hacemos Sprint por Sprint.

Vanessa Amaya

Business Analyst y Agile Trainer. Cuenta con 18 años de experiencia implementando prácticas de mejora & productividad en equipos y empresas principalmente en equipos de Desarrollo de software y equipos comerciales aplicando: Agile Business Analysis, Ingeniería de requerimientos, Scrum, Kanban, Visual Thinking, Lean Change, Management 3.0, dinámicas de integración, facilitación de retrospectivas y Agile Coaching.

También cuenta con experiencia en equipos de: Recursos Humanos, Reclutamiento, Gestión de Siderúrgica, Marketing y Organización de eventos.

Representante del nodo México de la Comunidad Internacional Agile Women y participante activa en la Comunidad Coderos.

Docente en el Diplomado de Ingeniería de Software ágil de la Universidad Nacional Autónoma de México.

Ha participado en proyectos relacionados en marcos ágiles desde el 2012.

Es Docente del equipo Académico del Diplomado de Ingeniería de Software Ágil en la UNAM desde el 2019 en el módulo de Requerimientos.