Esta vez vamos a comentar sobre las «famosas» reuniones diarias dentro de un sprint, este post está dentro de la serie de posts relacionados con las reuniones dentro de un modelo agile de desarrollo.

Esta reunión ante todo debería ser un buen punto de inflexión para ayudar a compartir y poner encima de la mesa los problemas, comunicar a todos los miembros del equipo «que pasa» actualmente y en qué estado está el sprint.

Además se puede usar para «reforzar» ciertos skills, pero no es una reunión de control del equipo para otros roles, es una reunión cuyos «propietarios» son el equipo, a nivel grupal, pero el equipo como entidad.

Contenido

Según scrum, las daily deberían hacerse de pie, no durar más de cinco minutos y solo se pueden tratar tres preguntas a responder por cada uno de los miembros del equipo:

– Que se hizo desde ayer

– Que se hará hoy

– Qué impedimentos tengo

Bueno, los que nos conocéis ya sabéis que somos un poco particulares y que lo de los libros y las normas a rajatabla no es nuestro fuerte 😉

Por tanto, desde TecnoEstrategia proponemos un modelo un poco diferente (en realidad no tanto) al del «scrum de libro» pero hay diferencias, y son importantes. en primer lugar:

Pensamos que no es necesario tener un reloj ni tampoco estar de pie

Eso sí, una reunión daily no puede ser bajo ningún concepto algo donde se consuma tiempo y recursos, debería ser corta y con el foco en el sprint y las tareas del mismo.

Es decir, nosotros apostamos por que en las dailys se traten los problemas y la marcha general del equipo respecto a las tareas del sprint y por tanto ver de una manera muy rápida si la planificación del mismo sigue o no, pero no somos partidarios de tratar esos problemas en la misma daily.

Esta propuesta (que ahora centraremos y desglosáremos) está basada en nuestra experiencia, generalmente si nos dedicamos a preguntar las 3 cuestiones típicas y ceñirnos a un guión preestablecido nos sucederán principalmente (entre otras) dos cosas:

a) O bien el equipo usa las dailys como «gestión de riesgos» y se eternizan pasando con mucho de los 5 minutos porque se discuten problemas, responsables y posibles soluciones a los mismos por todo el equipo.

b) O se acaban convirtiendo en algo repetitivo, cada uno dice “lo de siempre” y por tanto el equipo no percibe el valor de hacer dichas reuniones.

No tenemos fórmulas mágicas, y cada equipo es un mundo, pero para nosotros es básico que en una daily se comuniquen y se pongan encima de la mesa los siguientes puntos (para tratar a fondo lo que surja de una daily es otro asunto, lo principal de la daily es comunicar):

– Si hay algún problema con el sprint, a nivel de ítems y reflejado y centrado en cumplir con los compromisos del mismo.

– Si alguien cree que no va a ser capaz de cumplir con el compromiso adquirido.

– Si alguien no tiene trabajo o no puede realizarlo, está bloqueado o va retrasado.

Esto debería ser clave, de esta manera el equipo por un lado tiene un canal muy efectivo de dar feedback (diario) sobre el estado del sprint, por otro se pueden y deben actualizar ciertas métricas como los bloqueos, problemas, relaciones de ítems con esto y sus clasificaciones [aquello de la importancia al negocio, urgencia, frecuencia, etc.]

Pero, sobre todo, una daily debe ser el escaparate donde todo el equipo muestre sus problemas, logros e impedimentos que dependan de otros miembros del equipo.

 

Desarrollo

Nuestra apuesta pasa por que el scrum master o el rol similar tenga clara esta visión e intente terminar lo antes posible con la daily una vez ya se han expuesto los posibles problemas y la marcha del equipo (tiempos, ítems a trabajar, logros terminados, etcétera) encima de la mesa.

Lo que recomendamos es, que si en una daily surgen aspectos contrarios a la marcha del proyecto (también deberías preguntarte si todo está bien a nivel interno si un equipo en todas las dailys dice que todo está ok y no hay problemas…) el rol encargado de gestionar a dicho equipo dedique su tiempo a solucionarlo abordando los problemas que puedan surgir y aparecer en la daily DESPUÉS de la misma y NUNCA en la propia daily.

Esas otras reuniones o acciones, que pueden ser en el mismo día o incluso justo después, pero al no tratar con esos problemas dentro de la reunión, esta no se “corrompe” y por tanto el espíritu y la utilidad de la daily permanecen y se perciben como algo útil.

De cualquier manera, esto último tiene sus peligros:

Por un lado que el equipo se piense que siempre se tratan los problemas por separado y en privado rompiendo así el espíritu de equipo y es de vital importancia saber que; una cosa es solucionar un problema de manera separada a las reuniones daily (básicamente porque no son el objetivo de dichas reuniones y además, lo más normal es que haya parte del equipo que no presta demasiado atención a este y tengamos un desperdicio «de libro») y otra, que la comunicación no fluya de manera adecuada.

Aprovechamos esto último para recalcar que las dailys son excelentes para demostrar que todo el equipo tiene un objetivo común y que todo el mundo hace cosas por los demás.

Algunas métricas

Por último y no por ello menos importante, en una daily se verán los logros del equipo, también los fracasos, pero es importante que una daily sea una oportunidad para:

– Mejorar y trabajar los skills importantes a nivel grupal sobre todo, pero también a nivel individual.

– Ver la progresión del sprint y ayudar a dar una visión de que se está haciendo a diario para que el sprint y los compromisos se cumplan.

– Averiguar si hay bloqueos, o no los hay, y las causas.

 

1 comentario en «Reuniones dentro del sprint en un modelo agile – IV de VI – dailys»

  1. Pingback: Reuniones dentro del sprint en un modelo agile – V de VI – Retrospectivas – TecnoEstrategia

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *