(Hipotético) Durante una Retrospectiva de Sprint, el equipo de Desarrollo propone mover el Scrum diario a dos veces al día

TL;DR

Ayudar al equipo a identificar la causa raíz de un problema (para evitar soluciones X/Y) y luego permitirles generar soluciones medibles que funcionen dentro del contexto único del equipo es una función esencial de facilitación de Scrum Master. El aprendizaje validado y la mejora continua de procesos dirigida por el equipo deben ser los objetivos reales aquí.

Análisis

Para que la implementación de su marco sea Scrum, debe realizar un Daily Scrum. Si no realiza todos los eventos requeridos, entonces el resultado no es Scrum .

Por otro lado, el marco Scrum no impide que los equipos realicen eventos adicionales o implementen sus propios procesos dentro del marco. Por lo tanto, si un equipo descubre que necesita más de una reunión de colaboración de equipo completo al día, no hay nada que les impida hacerlo.

En la tercera (!) mano, agregar una sobrecarga de proceso adicional puede o no agregar valor, y puede o no resolver cualquier problema subyacente que haya llevado al equipo a probar este enfoque. En abstracto, es difícil decir si esto sería útil o no, pero ciertamente está dentro del control del equipo autoorganizarse y administrar sus propios procesos internos si quieren intentarlo. Simplemente sugeriría que adopten un enfoque de prueba primero para definir cómo medirán el éxito o el fracaso del proceso.

La perspectiva de prueba

Es casi imposible adivinar qué piensan los diseñadores de la prueba que es la respuesta correcta, o cómo han elegido normalizarla. Por lo tanto, no puede haber una respuesta canónica al tipo de pregunta "¿cuál es la respuesta correcta de la prueba?".

Dicho esto, las únicas dos opciones presentadas que son congruentes con permitir que el equipo se organice y colabore sin un enfoque de comando y control utilizando la autoridad que Scrum Master no tiene son:

• Aprenda por qué el Equipo de Desarrollo quiere esto y trabaje con ellos para mejorar el resultado del Scrum diario
• Reconocer y apoyar la decisión del equipo autoorganizado

Ya sea que las respuestas sean o no lo que buscan los diseñadores de pruebas, son las dos mejores respuestas de la lista. Sin embargo, todavía se quedan cortos porque carecen del contexto completo y del sabor correcto. Reempaquetando esto como "¿Cuál es la mejor manera de apoyar y facilitar al equipo?" es un mejor enfoque que alentará al Scrum Master a entrenar al equipo en el análisis de la causa raíz y ayudarlos a explorar enfoques procesables y comprobables para el aprendizaje validado y la mejora continua.

La pregunta original era sobre un examen y mi respuesta (la aceptada) estaba orientada a cómo considerar las respuestas. Podrías considerar las mismas cosas. Sin embargo, vas a responderlas de manera diferente. Por ejemplo, el propósito del scrum diario se ve socavado por reuniones menos frecuentes, mientras que no se socava pero puede o no amplificar ese propósito. Entonces, no creo que la respuesta sea la misma, pero puedes hacer algunas de las mismas preguntas.

¡Gracias por la discusión, a todos! Aquí están mis respuestas-pensamientos sobre esto:

Lo único de este escenario que viola Scrum de alguna manera es el nombre de la segunda reunión. Así que simplemente cámbiele el nombre y continúe.

No hay nada en Scrum que diga que no se pueden tener reuniones o que prescribe lo que puede haber o no en esas reuniones. Llamar a la reunión de la tarde The After-Lunch Hullabaloo lo resuelve todo.

Estrictamente en términos de qué 2 de 5 respuestas son las mejores de la lista de opción múltiple, probablemente elegiría "Reconocer y apoyar la decisión del equipo autoorganizado" y "Considerar la solicitud y decidir cuándo debe ocurrir el Daily Scrum". " -- esta última es la decisión sobre qué reunión debe llamarse Daily Scrum, si por alguna razón el equipo no puede o no quiere tomar su propia decisión al respecto.

Gracias de nuevo a todos los que echaron un vistazo a esto.