Es frecuente ver algunas disfunciones que llevan los Equipos de Scrum a tener Dailys más largas, pesadas y sin objetivos. El año pasado, Marcos Garrido escribió un post sobre Mitos y Hechos de la Daily Scrum y me inspiré en dicho texto para escribir consejos de cómo conseguir unas reuniones diarias más productivas.
En el post de Marcos él abordó tres disfunciones que encontramos frecuentemente al realizar coaching de equipos. En base a esto, presentamos consejos simples que creemos que pueden ayudar.
1) Daily Scrum como status report
En primer lugar, la Daily suele convertirse en un informe de situación. Esto sucede cuando el equipo habla siempre directamente con el Product Owner, el Scrum Master o con alguien que desempeñe la función de líder técnico. En vez de hablar al equipo como un todo, cada persona se dirige a quien se encuentre en uno de estos papeles. Para resolver este problema, podemos probar algunas acciones, tales como:
- personas que se encontraban en estos papeles quedan en segundo plano durante la Daily, dejando, consecuentemente, que el equipo sea el centro de atención;
- no se debe empezar la reunión con el P.O., el S.M. o el líder preguntando cosas como: ¿qué tal? ¿Qué estáis haciendo?
- Se debe recordar el objetivo de la Sprint al principio de la Daily, reforzando el concepto de que el equipo debe hablar sobre el trabajo y los impedimentos relacionados con el objetivo;
- se debe dejar que los miembros del equipo de desarrollo actualicen el tablero, en vez de que una única persona lo actualice siempre.
2) Daily Scrum como una reunión para resolver problemas
Muchas veces esto ocurre porque el equipo solo se comunica en la Daily o porque el Scrum Master no está disponible fuera de la Daily. Para crear una rutina en la que los impedimentos no surjan solo en la Daily:
- se debe reflexionar sobre si un impedimento o problema que no ha surgido hasta la Daily, ha acabado de suceder de hecho. Si no es el caso, entonces no debería ser una novedad;
- se debe reforzar el concepto de que la comunicación sobre impedimentos y problemas debe ser siempre lo más cercana posible al momento en el que ocurren, para tratarlos cuanto antes;
- el Scrum Master debe estar disponible siempre que el equipo lo necesite y no solo en las ceremonias del Scrum. Para ello puede ser que tenga que dejar de lado otras responsabilidades externas al equipo;
- se debe respetar el tiempo establecido y dejar las cuestiones más extensas para otro momento.
3) La Daily Scrum es el único momento para actualizar el tablero del equipo
Esto sucede con bastante frecuencia cuando el equipo se resiste a utilizar el tablero, cuando el Scrum Master o el P.O. toma para sí mismo la responsabilidad de mantener el tablero actualizado o cuando el nivel de detalle de elementos del tablero no es suficiente para dar la visibilidad necesaria al trabajo. En este caso puede probar a aplicar estos consejos:
- asegúrese de que el equipo entiende el motivo de que exista un tablero y le da un valor;
- promover el ownership del equipo sobre el tablero, dejando que actualicen y reformateen el tablero como les parezca mejor. ¿Qué tal promover una retrospectiva sobre el tablero y la forma de utilizarlo mejor?
- Pruebe a comprimir los elementos del tablero aplicando otro nivel de granularidad. Por ejemplo, las tareas que duran menos de un día, suelen fomentar la visión de progreso y el sentimiento de conquista que hacen que se desee divulgar la evolución de cada elemento;
- es importante recordar que no existen ni fórmulas ni balas de plata que sirvan de solución a todos los casos. En Knowledge21, creemos que siempre se trata de un trabajo a cuatro manos, y que experimentar y mejorar continuamente es lo que marca la diferencia.
Ebook Retrospectivas Ágiles
¡Descárgalo Gratis Aquí!
¡Esperamos que estos consejos les ayuden en el día a día para dailys cada vez más productivos! ¡Prueben y cuéntennos en los comentarios cómo les ha ido!
Si quiere convertirse en un Scrum Master o Product Owner, le invito a participar en los cursos de formación de Certified Scrum Master (CSM) y Certified Scrum Product Owner (CSPO).
