En una empresa, el gerente de desarrollo proviene de un entorno técnico y de PM. También actúa como líder técnico, aunque sin realizar ningún trabajo de desarrollo. Se enfoca en el lado gerencial del rol.
En la reunión de scrum de la mañana, los desarrolladores comienzan a hablar sobre ayer, hoy y si hay algún impedimento. El gerente de desarrollo comienza a hacer preguntas a los miembros del equipo como "¿dónde estamos en esto?", "¿por qué ocurrió esto?" etc. Los miembros del equipo responden, por lo tanto, muchas veces comienzan a entrar en detalles. El Scrum Master ha tratado de mencionar que esta no es una reunión técnica, pero el gerente responde que quiere saber qué está pasando "con esta cosa específica" o "necesitamos entender esto mejor". A veces le responde al SM "espera, tenemos que discutir esto", por lo que el SM ha renunciado a tratar de reenfocar la discusión. Otras veces, el SM tratará de coordinar la discusión sobre un tema, y el gerente dirá "vamos, esto puede esperar".
El SM tuvo discusiones separadas con el gerente sobre esto, y el gerente responde con argumentos como "el scrum de la mañana es un gran lugar para ponerse al día con lo que está pasando, sin distraer a la gente durante el día" y "algunas personas necesitan coordinación". , por lo tanto, necesitamos sostener sus manos por un momento".
En esta empresa el gerente es el responsable de la entrega del producto y ha estado trabajando muy de cerca con el equipo desde el primer día. Ha contribuido mucho y todavía lo hace, pero parece que quiere controlar todos los aspectos de la reunión y el desarrollo (esto se propaga hasta la planificación, donde el gerente pedirá que se hagan las cosas y, por lo tanto, priorizará el trabajo pendiente junto con el CORREOS).
En esta empresa, hay una fecha límite fija para el proyecto, y parece mucho más importante cumplir con la fecha límite "pase lo que pase", en lugar de cultivar un entorno scrum. SM y PO se sienten desesperanzados y no sienten que las cosas puedan cambiar. ¿Cuáles serían sus sugerencias para SM y el gerente de desarrollo, para facilitar mejor el scrum?
El Scrum Master tiene que exigir a cualquier persona que no forme parte del equipo de desarrollo que permanezca 100 % en silencio durante el Daily Scrum. Esta es la regla según la guía Scrum :
El Scrum Master hace cumplir la regla de que solo los miembros del Equipo de Desarrollo participan en el Daily Scrum.
Después del Daily Scrum, está bien discutir un poco sobre los detalles si es necesario.
Le sugiero que también deje que su gerente lea las páginas MENOS sobre administración . Esto para hacerle entender lo que se espera de los gerentes en entornos Agile.
Ahora es posible que no quiera cambiar su comportamiento y no le importa si su equipo está haciendo Scrum real o algo que se parece a Scrum. Intentaría que todo el equipo dijera (en voz alta) que quieren seguir e implementar Scrum al pie de la letra, ya que genera el mayor valor. Luego, también debe aprender a su gerente Shu-Ha-Ri y, si quiere jugar a Ri, primero debe aprender y jugar el juego por un tiempo, como unos años antes de modificarlo.
Para terminar me gustaría citar a Martin Fowler como sugerencia final:
Si no puede cambiar su organización, ¡cambie su organización!
He hecho ambos lados en el pasado y realmente es genial de cualquier manera. Si cree que puede cambiar la organización, no se dé por vencido después de algunos retrocesos. Sigue repitiendo y repitiendo con respeto, eventualmente se darán la vuelta. El cambio de cultura puede ser un proceso de años, por lo que necesitas tener un largo respiro.
Aquí hay varios problemas.
Por un lado, una persona dirige el scrum diario. Esto por sí mismo es un problema. El propósito del scrum diario no es un cambio de estado; su propósito es mejorar la coordinación del equipo . Es una reunión del Equipo de Desarrollo, para el Equipo de Desarrollo.
El hecho de que esté dirigido por alguien que ni siquiera está en el equipo es aún más preocupante. Si su líder técnico no es el propietario del producto, no es el Scrum Master y no está haciendo ningún desarrollo, entonces parece que no debería ser parte del Equipo Scrum en absoluto (aunque todavía puede ser considerado parte del equipo de desarrollo incluso si no hace ningún desarrollo. Depende de lo que implica exactamente 'el lado de gestión del rol'). Si no es parte del Equipo Scrum, entonces no solo no debería liderar el scrum diario, sino que probablemente ni siquiera debería estar allí .
También asumo que la reunión no está limitada en el tiempo. El scrum diario debe tomar como máximo 15 minutos (hay una razón por la que a menudo lo escucho llamar 'reunión diaria'). Si el equipo se va constantemente por la tangente, entonces es muy poco probable que se respete el tiempo establecido mientras se permite que todos hablen de su parte.
Sin embargo, el mayor problema con diferencia parece ser la falta de aceptación. Si es "más importante cumplir con la fecha límite 'sin importar qué', en lugar de cultivar un entorno scrum", entonces, mientras eso sea cierto, tendrá dificultades para lograr cualquier mejora. Antes que nada, debe encontrar una manera de mejorar la aceptación. La forma más sencilla de hacer esto es mostrar qué tipo de problemas está causando el proceso actual.
Esto es, por supuesto, asumiendo que el proceso actual realmente está causando problemas . Usted mencionó que el Scrum Master y el Product Owner se sienten impotentes. ¿Habló esto también con el equipo de desarrollo? ¿Ha sido mencionado en una retrospectiva? ¿Tiene métricas reales que describen los costos incurridos? El primer paso es discutir y examinar los temas actuales. El siguiente paso es hacerlos visibles.
Un enfoque que podría probar es el siguiente:
Hable con el gerente de desarrollo y pídale que permanezca en silencio durante el scrum diario, mientras el equipo responde sus 3 preguntas y se autoorganiza.
Una vez que todos los miembros del equipo han hablado, el Scrum Master declara que el scrum diario ha terminado y pregunta si hay algo más que cubrir. En este punto, el gerente de desarrollo puede hacer sus preguntas.
Tal vez no necesiten que todo el equipo esté presente para sus preguntas, ya que pueden ser específicas para ciertas personas. Luego, los otros miembros del equipo pueden volver a su trabajo. Este es un uso más eficiente de su tiempo que hacer que todo el equipo escuche conversaciones que pueden no ser relevantes para ellos.
¿Hay apoyo de otros niveles de gestión que puedan ayudar a resolver este problema? El mejor de los casos podría ser que otros puedan ayudar a iluminar al Dev Mgr sobre cómo sus interacciones pueden ser inútiles e incluso perjudiciales para la eficiencia y, en última instancia, el éxito. También es importante reforzar las interacciones positivas. "El Scrum Master ayuda a los que están fuera del Equipo Scrum a comprender cuáles de sus interacciones con el Equipo Scrum son útiles y cuáles no. El Scrum Master ayuda a todos a cambiar estas interacciones para maximizar el valor creado por el Equipo Scrum".
Aparte: ¿El "plazo fijo del proyecto" incluye un alcance fijo? Si es así, aún se pueden lograr muchos beneficios de Scrum; sin embargo, seguramente habrá problemas de tipo cascada.
Al igual que Barnaby, creo que debe hacer que el desarrollador esté en silencio durante la primera parte de la reunión, pero sugiero dos enfoques específicos para ese fin:
Trabaje con su comentario de que "algunas personas necesitan coordinación, por lo tanto, debemos sostenerlos un poco de la mano", especialmente si hay un gerente de línea que no es el gerente de desarrollo al que puede solicitar apoyo.
Alternativamente, o si eso no funciona, renuncie a defender el scrum puro (por ahora, hasta que pueda obtener ayuda/aliados/etc). Cree y distribuya una agenda estándar para esta reunión diaria:
¡Buena suerte!
MCW
Ewan
nathan cooper