He llegado a creer que, al igual que el scrum diario, las 3 preguntas son una señal de inmadurez en la capacidad del equipo.
Estoy a punto de decretar a todos mis equipos que eliminaremos el formato de scrum diario de tres preguntas, es decir
Esto es simple y fácil de seguir, pero en realidad no es el equipo el que habla con una sola voz. También puede degradarse rápidamente a una sesión de estado y no brinda una claridad real al progreso de la acumulación de sprint.
A partir de ahora, pediré a los SM que caminen por el tablero y que el grupo discuta el WIP y qué historias están por venir. Esto también está relacionado con el hecho de que, a partir de ahora, el equipo, en la medida de lo posible, solo trabajará en una historia a la vez.
¿Tiene algún valor mantener las tres preguntas una vez que los equipos se hayan asentado y trabajen para lograr una capacidad XP?
Voy a darle una respuesta ligeramente diferente a Sergey porque no creo que esta sea una pregunta simple con una respuesta correcta, pero también me gustaría señalar que voté a favor de su respuesta porque también estoy de acuerdo con él.
El objetivo del scrum diario es que el equipo se reinicie entre sí sobre dónde están las cosas actualmente y cuál es el plan inmediato para el día siguiente. Si están logrando esto, deberían poder decirle qué se completó ayer, cuál es el enfoque para completar hoy y si alguien tiene algún impedimento.
Si tomas un nuevo equipo y les dices "tienes 15 minutos para sincronizar", muchos equipos no lo lograrán. Ahí es donde entran las tres preguntas: brindan orientación. Hay muchas variaciones sobre estas preguntas que la gente ha sugerido. De hecho, la Guía Scrum más reciente en realidad los modifica para enfocarse más en conducir hacia la meta del sprint. Sin embargo, si su equipo está tratando el scrum diario como una reunión de estado, simplemente eliminar las preguntas no resolverá su problema.
Brevemente:
Verbosamente:
En realidad, no entiendo por qué Scrum diario con tres preguntas debería ser un signo de inmadurez del equipo.
Estas son tres preguntas como Scrum Guide las describió:
- ¿Qué hice ayer que ayudó al equipo de desarrollo a alcanzar el Sprint Goal?
- ¿Qué haré hoy para ayudar al Equipo de Desarrollo a alcanzar el Sprint Goal?
- ¿Veo algún impedimento que me impida a mí o al Equipo de Desarrollo alcanzar el Sprint Goal?
Como sabes, Scrum se sustenta en tres pilares: transparencia, inspección y adaptación.
En primer lugar, las dos primeras preguntas brindan transparencia al equipo. Todo el mundo sabe lo que hacen todos los demás miembros del equipo.
Además, Daily Scrum brinda la capacidad de inspeccionar Sprint Progress y adaptar Sprint Backlog con el plan diario (el plan diario no es el término Scrum, pero Scrum Team siempre lo tiene, no importa explícita o implícitamente).
Por lo general, las respuestas de las dos primeras preguntas son más que suficientes para el seguimiento del progreso del Sprint. Si tiene un problema con esto, las razones por las que no están en el formato Daily Scrum. Tal vez su equipo no descompone las historias de usuario en suficientes tareas pequeñas y es difícil decir cuánto trabajo realmente se ha hecho. O, tal vez existe otra razón. Su Scrum Master debería detectarlo y eliminarlo.
Y, por supuesto, Daily Scrum no es una reunión diaria de informes de estado. Es para la sincronización del equipo, no para los informes de los miembros del equipo a los gerentes. Si su Daily Scrum tiende a "degradarse rápidamente a una sesión de estado", no es un problema de Daily Scrum, sino un problema de su Scrum Master.
Finalmente, Mike Cohn habló sobre otro propósito de la primera y la segunda pregunta : es el compromiso de los miembros del equipo entre sí.
Al centrarse en lo que cada persona logró ayer y logrará hoy, el equipo obtiene una excelente comprensión de qué trabajo se ha realizado y qué trabajo queda. La reunión diaria de scrum no es una reunión de actualización de estado en la que un jefe recopila información sobre quién está retrasado. Más bien, es una reunión en la que los miembros del equipo se comprometen entre sí.
Si un programador se levanta y dice: "Hoy terminaré el módulo de almacenamiento de datos", todos saben que en la reunión de mañana dirá si terminó o no. Esto tiene el maravilloso efecto de ayudar a un equipo a darse cuenta de la importancia de estos compromisos y de que sus compromisos son entre sí, no con un cliente o vendedor lejano.
Alguien (como el autor de este artículo ) puede decir que "un enfoque en el compromiso personal" no es muy bueno, pero no veo ninguna razón para esta afirmación.
Y la última (la tercera) pregunta. Anima a los miembros del equipo a colaborar y no quedarse solos con sus problemas.
Resumiendo:
Daily Scrum como se describe en Scrum Guide (con tres preguntas):
Por supuesto, existen otros formatos de Reuniones Diarias (como Tablero de Mejora ), pero la Guía Scrum prescribe el formato de Tres Preguntas. De lo contrario, no es Scrum.
Por las razones que describí anteriormente, no veo ninguna desventaja (incluida la que escribió en su pregunta) en el formato de tres preguntas.
Scrum y XP no se oponen entre sí en este tema. Más aún, Kent Back en su libro "Extreme Programming Explained" [1999] había propuesto este formato antes que Ken Schwaber y Jeff Sutherland en su libro "Agile Software Development with Scrum" [2001].
Cita sobre la reunión diaria de pie (sin una explicación profunda) de "Explicación de la programación extrema":
"Puede tener una reunión diaria de pie para que todos sepan en qué están trabajando los demás".
Y más detalles de ExtremeProgramming.org :
Durante una reunión de pie, los desarrolladores informan al menos tres cosas; qué se logró ayer, qué se intentará hoy y qué problemas están causando retrasos. La reunión diaria de pie no es otra reunión para hacer perder el tiempo a la gente. Reemplazará muchas otras reuniones dando un ahorro neto varias veces su propia duración.
Los equipos multifuncionales que he supervisado siempre han tenido problemas con el tradicional "¿Qué hice ayer, qué haré hoy, algún bloqueador?" método. Principalmente porque en un equipo interfuncional, si las personas hablan sobre sus tareas diarias, nadie entiende lo que están haciendo.
En su lugar, tomé el método descrito en la Sección 3.2 de este gran documento (una gran lectura): http://www.scruminc.com/wp-content/uploads/2014/05/Hyper-Productive-Metircs.pdf
La propuesta hace que el equipo se concentre en el burndown y el sprint backlog como un todo.
"Cambiamos el enfoque de la reunión de los individuos al Sprint Backlog. Comenzando con el Sprint Backlog Item (SBI) de mayor prioridad que aún no se ha completado en cada Daily Stand-Up, todo el equipo analiza su contribución colectiva para completar ese SBI ."
Las preguntas propuestas a la respuesta del equipo son:
Seré franco, apenas estamos comenzando en este camino. Esperamos ver a los equipos trabajar juntos para completar sus compromisos de sprint.
Si el equipo comenzó con 3Q en Daily Standup y continúa esta práctica sin cambios durante meses desde entonces, me calificaría para verificar cómo el equipo inspecciona y adapta su proceso. Podría ser un síntoma de inmadurez (también conocida como etapa de formación).
Sería una simplificación excesiva crear una correlación de "3 Q sin cambios => el equipo es inmaduro", pero eso es algo que vale la pena verificar. Lo siguiente que verificaría en tal caso sería la tasa de éxito para la entrega de sprints. Si responden las 3 preguntas y aún cumplen, podría haber cosas más importantes para mejorar :-)
Bravo a Sergey y Daniel por sus excelentes respuestas. Creo que dan muy buen alcance sobre el valor de las tres preguntas y que nada está escrito en piedra.
Me gustaría abordar su pregunta de una manera ligeramente diferente. Quiero resaltar un terreno potencialmente peligroso.
Estoy por decretar a todos mis equipos
Estoy seguro de que sus intenciones son las mejores y esto puede ser una mala elección de palabras. Como otros que lean esto pueden no saberlo, creo que es importante señalar los peligros de esta declaración.
Según tu publicación, parece que eres un líder de ingeniería de algún tipo. El liderazgo no debe decirle a un equipo cómo llevar a cabo sus reuniones internas. Agile se trata de crear equipos empoderados y confiar en ellos para hacer el trabajo.
Si el equipo no está haciendo el trabajo, entonces puede hacer preguntas poderosas para tratar de alentarlos hacia el desempeño. Preguntas como.
Dictar a un equipo ágil es un camino de regreso a la gestión de comando y control y eliminar el empoderamiento del equipo. A menos que el equipo esté completamente roto, no se entrometa directamente, trabaje con sus maestros de scrum y establezca objetivos para que los equipos los cumplan. Dales la confianza para hacerlo o para reportar sus problemas.
No me queda claro a qué te refieres cuando hablas de:
el equipo hablando con una sola voz.
y porque el formato:
no aporta una claridad real al progreso de la acumulación de sprint.
Pero he visto la regresión a una reunión de estado como un antipatrón recurrente, especialmente durante las primeras fases de una transición a la agilidad, o en entornos donde las viejas prácticas de gestión aún son difíciles de eliminar.
Dicho esto, si ve que los equipos son lo suficientemente maduros, puede salirse con la suya con el formato, siempre que el enfoque y la meta se mantengan. La Guía Scrum dice que:
Durante la reunión, los miembros del Equipo de Desarrollo explican :
- ¿Qué hice ayer que ayudó al equipo de desarrollo a alcanzar el Sprint Goal?
- ¿Qué haré hoy para ayudar al Equipo de Desarrollo a alcanzar el Sprint Goal?
- ¿Veo algún impedimento que me impida a mí o al Equipo de Desarrollo alcanzar el Sprint Goal?
Eso no significa necesariamente que tengan que seguir exactamente el mismo formato sin importar qué o responder mecánicamente las tres preguntas en el pedido.
Tener un formato es una buena manera de comenzar y poner al equipo en la misma página y mantener el enfoque, especialmente cuando son nuevos en Scrum, pero puede retroceder rápidamente a una "reunión de estado" si el equipo no pone algo de inteligencia en el ejercicio. Los equipos más maduros (al menos en mi experiencia) no necesitan que les recuerden el objetivo, ni las preguntas y el scrum diario simplemente "fluye".
hombres
El Toro Bauldo
Todd A. Jacobs
nathan cooper
El Toro Bauldo
CBRF23