Todo el mundo sabe, o cree saber, lo que es un Daily. Al menos te debe de sonar, sino este no es tu post (mejor lee Que no te confundan, lo que realmente son Daily meetings, o Reuniones Diarias, efectivos).
Pero fíjate que siendo, a priori, algo, aparentemente simple… la de problemas y malas aplicaciones que trae consigo.
Esto no es algo que aplique sólo a los Dailys, es algo muy típico en un montón de prácticas ágiles, aparentemente simples, pocas reglas, mucha profundidad de entendimiento y mala aplicación.
En el post que te referecié al principio tienes un montón de consejos sobre los Dailys y en este post me voy a centrar en uno sólo, uno que siempre se pasa por alto, uno fundamental… Swarming. Swarming, Swarming y Swarming.
Ya lo deberías conocer, el Swarming es una buena práctica muy fundamental en esto del Scrum, en el importante y desconocido Swarming, “flujo continuo de una sola pieza” o One-Piece Continuous Flow le dediqué un post que deberías leer y del que te resumo que la idea del Swarming es dedicar todos los esfuerzos a la historia (o item) de mayor prioridad, hacer todo lo necesario para completarla y todo el mundo debe ayudar, si pueden, a que se termine esa historia de mayor prioridad.
El Swarming en Scrum vendría a ser una especie de WIP en Kanban. Y no voy a entrar en por qué me pongo tan pesado con el Swarming porque ya lo conté en el post de antes, y te conté lo de cómo trabaja la entrega de valor, cómo ayuda en evitar el cambio de contexto, etc.
¿Y qué tiene esto que ver con los Dailys? Pues que los Dailys son una de las reuniones principales para potenciar el Swarming. Pero muchas veces, muchas, los Dailys pasan por alto el Swarming y ocurre lo de que cada uno va por su lado.
Tanto es así, y es de importante el tema, que hace unos años hubo una propuesta de un tal Downey y Sutherland (uno de los dos padres de Scrum, te recuerdo la entrevista a Jeff Sutherland) para modificar el clásico y popular guión de los Daylis en pro del Swarming.
Como sabrás, el clásico guión es:
1 – ¿Qué hice/hicimos ayer?
2 – ¿Qué vamos a hacer hoy?
3 – ¿Qué nos está bloqueando?
Bueno, pues la propuesta, y consejo, recomendación, que te cuento se basa en modificar el anterior guión por el siguiente:
1 – ¿Qué hicimos (NOSOTROS, PLURAL) ayer por terminar el item de prioridad número 1?
2 – ¿Cuál fue NUESTRA (plural) principal contribución al item de prioridad 1 en número de puntos historia?
3 – ¿Qué tenemos previsto hacer hoy para terminar el item de prioridad número 1?
4 – ¿Qué puede bloquearnos HOY?
Cómo ves, el cambio de guión cambia sustancialmente la estructura de un Daily. Y cambia que puedas incluso plantearte aquello de que cada uno cuente su rollo, mientras el resto está pensando en sus cosas, sin tener mucha relación unos temas con otros.
Pruébalo, y luego me cuentas cómo te ha ido, ya verás como cambia la cosa.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Más allá del Management 3.0: 12 prácticas (de muchas) que no están en M 3.0 - 25 enero, 2024
- Más allá del Management 3.0: Otros muchos patrones para equipos Ágiles - 18 enero, 2024
- Años 30, Ohio (EE.UU.) y el Agile Product Management - 11 enero, 2024
Suena interesante y vale la pena probarla. Pero a qué se refiere la pregunta: «¿Cuál fue NUESTRA (plural) principal contribución al item de prioridad 1 en número de puntos historia?» la veo muy similar al punto anterior.
Hola, que añade… en número de puntos historia, solo eso
Bajo mi humilde opinión, yo creo que si hay que darle importancia al item de prioridad 1, pero no haciendo que todo el equipo se vuelque a hacerlo. Para mi lo ideal es que se hable en el daily siempre al principio y que se pongan varias personas con él (no todo el equipo) ya que sino pierdes velocidad, porque normalmente las tareas reales no son tan fáciles de dividir entre varias personas.
Hola! gracias por compartir, aunque no me termina de convencer a primera vista 🙂 . Me tomaré un poco más de tiempo en tratar de entender qué valor da el hacerla así. Como contribución, en el equipo donde estoy vemos más de valor no revisar qué hizo cada uno sino en revisar los items de cada historia, obviamente en orden de prioridad, y ver cómo va su avance ya que, entendemos, lo importante es saber lo que falta para cerrar la historia por encima de lo que hicieron los miembros del equipo, en realidad eso último sale de la misma conversación de la revisión de la historia. Al final de la sesión cerramos preguntando si alguien tiene algo más que agregar. Esto también ayuda cuando tienes equipos un poco más grandes de lo que te dice la guía. En mi caso somos 10 personas, por lo que ir 1 por 1 se nos hacía muy pesado y ciertamente al final quedábamos con la sensación de tener una daily no muy productiva. Ya esta, cierro aquí XD. Saludos y gracias nuevamente, el blog me ha ayudado varias veces!
Hola Diego,
si de verdad piensas que es una mala idea trabajar todo el equipo en un PBI, entonces no intentes hacer Mob Programming, te dejo varios enlaces:
-https://www.agilealliance.org/resources/experience-reports/mob-programming-agile2014/
– http://mobprogramming.org/
¡Yo lo probé en varios equipos y el resultado es espectacular!
Hola gracias por compartir, sinceramente no le veo mucho aporte pero lo tendré presente.
Me parece que es una vuelta de rosca interesante el orientar el dialogo de la Daily hacia la tarea de mayor prioridad que tenemos en el sprint, y además creo que saca al «sujeto o individuo» de la pregunta y pone al Equipo como ejecutor de las tareas, de hecho el Equipo trabaja en pos de lograr el objetivo que se planteó.
En cuanto a «¿Cuál fue NUESTRA (plural) principal contribución al item de prioridad 1 en número de puntos historia?» creo que eso ayuda a ver cuánto queda y también que es lo que se hizo (esto a veces no se tiene en cuenta y considero que motiva al Team ver los puntos ya logrados).
Saludos.