¿Debo cancelar el scrum diario si el equipo solo tiene problemas menores para discutir?

Si no están planificando juntos, no están trabajando juntos

El Daily Scrum no es para abordar "problemas", menores o no. Es una reunión de planificación justo a tiempo para que los desarrolladores colaboren en el trabajo del día actual . Si se identifican problemas o bloqueadores que no encajarán fácilmente en el cuadro de tiempo del Daily Scrum, entonces este es el momento de coordinar quién se reunirá para discutirlo y cuándo tendrá lugar esa discusión; en otras palabras, coordinar y planificar. alrededor del tema!

El Daily Scrum es un evento marco obligatorio . De hecho, la Guía Scrum 2020 dice (énfasis mío):

Para reducir la complejidad... [el Daily Scrum] se lleva a cabo a la misma hora y en el mismo lugar todos los días hábiles del Sprint .

Si el equipo habitualmente no tiene nada que discutir durante el Daily Scrum, entonces eso es un olor a proyecto que indica que el equipo no está colaborando activamente en torno a una coherencia central para el Incremento, o que el equipo puede no estar realmente haciendo Scrum .

El Daily Scrum se puede acortar, cuando sea apropiado

Sin duda, puede recortar la duración del Daily Scrum en los días en que la planificación y la coordinación justo a tiempo toman menos del máximo de 15 minutos. Si se reúnen durante cinco minutos y ninguno de los desarrolladores tiene nada más de qué hablar, todos recuperan diez minutos en su día. Si el propósito de la reunión se ha cumplido, no es necesario que continúe hasta agotar la casilla de tiempo. Sin embargo, para implementar Scrum correctamente, debe proporcionar los eventos del marco como Daily Scrum a intervalos predecibles con una cadencia confiable. Esto garantiza que todo el Equipo Scrum pueda confiar en la cadencia del evento para coordinar cosas en las que quizás no haya pensado antes, y que las inquietudes de planificación de última hora tengan un lugar claro para abordarse cada día.

Hacer cualquier otra cosa trabaja activamente en contra del proceso de control empírico y el marco subyacente. No hagas eso.

Si hay problemas menores, según mi experiencia, es mejor mantenerlo . Los problemas pueden investigarse incorrectamente, por lo tanto, el plan de reparación puede ser incorrecto y, por lo tanto, las estimaciones del tiempo de reparación pueden ser incorrectas. Si los problemas son realmente menores, es más fácil explicárselos al equipo (a la gente le gusta dar buenas noticias) y con más alegría ahorrar el tiempo restante de la reunión programada (los que ya respondieron, pueden abandonar la reunión).

Una vez que te saltas una reunión, la gente se relaja y deja de considerar importante la ceremonia. Cuando se guarda algo de tiempo de la reunión, simplemente ahorran más tiempo para ellos mismos o para las tareas pendientes.

Consulte más información sobre la importancia de las ceremonias para el espíritu de equipo: saltarse la reunión desorganiza al equipo, no es una opción para saltársela.

Puedo ofrecer otra razón para no cancelar el scrum diario, incluso si no cree que haya nada importante que discutir.

Las personalidades de los desarrolladores varían enormemente. Algunos anunciarán gustosamente todos los obstáculos a los que se enfrentan actualmente o destacarán todos los posibles problemas que puedan ver venir. Otros son más reticentes y, si no se les pide o no se les da la oportunidad adecuada de ventilar sus problemas, felizmente "eliminarán" un problema en silencio.

Uno de los beneficios de una reunión diaria regular de scrum, con una atmósfera de " mencione cualquier problema (real, relevante) ", es que puede alentar a los desarrolladores "más tranquilos" a decir " Oh, por cierto, estoy un poco pegado a... ". Sin un scrum diario, pueden pasar varios días antes de que piensen que su problema es "lo suficientemente importante" como para enviar un correo electrónico pidiendo ayuda.

Por supuesto, como han dicho otros, si, después de haber presentado la oportunidad para que todos planteen los problemas que enfrentan, no hay ninguno, entonces la reunión puede terminar temprano.

Cuando me pregunta si debería hacerlo , eso me hace preguntarme si a los desarrolladores se les permite operar como un equipo verdaderamente autoorganizado. El scrum diario es propiedad del equipo y es para su beneficio, por lo que solo el equipo debe decidir cancelarlo. Si no eres parte del equipo, entonces tu intervención sería una interferencia externa y el SM debería sentirse justificado para resistirse como tal. Si usted es una persona en un equipo autoorganizado, entonces no es su decisión y, en su lugar, debe pedir la opinión de los demás.

No puedo pensar en una buena razón para cancelar el Daily Scrum.

Primero, está la razón por la cual el Daily Scrum se lleva a cabo todos los días hábiles del Sprint, e idealmente a la misma hora y en el mismo lugar: reduce la complejidad. Al eliminar la decisión sobre si el equipo debe reunirse (sin mencionar cuándo y dónde), elimina una decisión. Eliminar tantas decisiones como sea posible reduce la fatiga de las decisiones y permite que el equipo se concentre en tomar decisiones sobre las cosas que importan.

En segundo lugar, no es una reunión larga. El Daily Scrum no debe tomar más de 15 minutos. Reunir al equipo, asegurarse de que todos estén al tanto de los problemas (incluso si son menores) y determinar cómo se resolverán esos problemas o reservar tiempo adicional con el subconjunto adecuado del equipo para resolver los problemas parece valer la pena. no más de 15 minutos fuera de la jornada laboral.

Teniendo en cuenta estos dos factores, no estoy seguro de por qué alguien querría cancelar el Daily Scrum. El costo es relativamente bajo, y el valor de planificar los próximos pasos inmediatos o levantar una bandera si las metas del equipo están en peligro parece valer la pena.

La idea de una reunión diaria no es solo para discutir problemas, sino para que el equipo que incluye al scrum master, el propietario del producto y el resto del equipo (desarrolladores, BA, etc.) confirme lo que han trabajado. en, se van a centrar en durante el día y cualquier problema. A veces, el sentimiento entre el equipo es 'bueno, ya sabemos las respuestas', pero la práctica y la rutina de hacer esto revelan las incógnitas y también abren oportunidades para decir algo que normalmente las personas no siempre hacen (y a tiempo) hasta que están cara a cara o se les pregunta al respecto.

No existe una forma de libro de texto para ejecutarlos, y debe ejecutarse de una manera que genere el mejor resultado del equipo y del proyecto en el que se está trabajando. A veces, el equipo no siempre estará de acuerdo con el enfoque del maestro de scrum y eso está bien, pero el maestro de scrum siempre debe asegurarse de que todos tengan claro cuál es el terreno para el día.

Algunas veces hay un caso en el que no puede o no necesita uno por cualquier motivo. Aún así, puede invitar al equipo a reunirse y concentrarse en cualquier cosa urgente y luego interrumpir.

Siempre alentaría la comunicación por correo electrónico, pero solo después de la reunión física (o virtual). Después de que el equipo pueda hacer ping a cualquier cosa que crea que los otros miembros del equipo deberían saber si existe la necesidad (o a través de cualquier otro método de colaboración, por ejemplo, mensajería instantánea a través de Microsoft Teams , Skype , etc.).

La idea de reuniones diarias es muy anterior a Scrum, y el formato de libro de texto (sí, hay uno) deja en claro que la función no es principalmente discutir problemas. No es una reunión de estado ; es una reunión de compromiso . Si tomamos las tres preguntas estándar y las reordenamos teniendo en cuenta la psicología de la motivación, esto es lo que sucede:

1. Un día, entras y dices lo que vas a hacer por el cliente y el equipo durante el próximo día hábil.
2. Al día siguiente, tienes que decirle a tu equipo si lo hiciste o no.
3. De lo contrario, comparte si algún obstáculo (técnico, organizativo, personal, etc.) lo bloqueó y puede pedir ayuda con esos bloqueadores.

Entonces, por razones de motivación, transparencia, colaboración y comunicación, los equipos que eligen usar Scrum se reúnen todos los días, ya sea que el Scrum Master esté disponible o no. Si no hay problemas, he visto reuniones de 12 personas que duran tan solo cinco minutos, por lo que no hay inconveniente. A menos que haya una crisis en la que todo el equipo debe involucrarse de inmediato, deje que todos se vayan en ese momento.

Los temas de la agenda pueden parecer triviales, sin embargo, deje que la discusión se lleve a cabo, ya que a veces lo que inicialmente parece trivial puede convertirse en un desafío. Es mejor atrapar a los menores, ya que a veces pueden convertirse en grandes desafíos.

Aquí hay una respuesta de un desarrollador en las trincheras durante décadas: una reunión diaria de cualquier duración es una interrupción en mi proceso de pensamiento. Si en el medio de tratar de averiguar alguna lógica intrincada, siempre me imagino que cualquier reunión impone una penalización invisible de 15 minutos antes de la reunión mientras intenta ajustar lo que está haciendo para estar listo para la reunión, y otros 15 minutos después para trabajar de nuevo en el marco mental de antes de la reunión. Por lo tanto, su scrum de 15 minutos equivale a una parte del día de 45 minutos (a veces peor si se encuentra en medio de un problema realmente difícil).

También experimenté pasar un día completo depurando un problema solo para encontrar una declaración de cambio sin lógica: ya había ingresado la lógica para el caso A y el caso B, estaba llegando al caso C cuando tenía que ir al scrum, mientras que el sistema reiniciado, por lo que tuve que reiniciar todo, olvidando lo que estaba en proceso antes del scrum, por lo que el caso C continuó sin lógica.

Pregúntese, si usted fuera un paciente que se sometió a una cirugía a corazón abierto, ¿le gustaría que su cirujano saliera corriendo para una reunión rápida en el medio? Lo siento, no una reunión, una ceremonia. Y solo el hecho de que tengas que cambiarle el nombre debería ser una pista.

Sí, deberías cancelar el scrum. Para empezar, las ideas de los scrums son exageradas. La mayoría de las respuestas parecen provenir de personas que no son desarrolladores. Desde la perspectiva de un desarrollador, los scrums son principalmente una interrupción del día. Cualquier colaboración útil ocurre durante sesiones ad hoc más pequeñas con desarrolladores que están estrechamente alineados en las tareas diarias o semanales.