¿Cuáles son algunos ejemplos de mal comportamiento de los scrum masters y los entrenadores ágiles?

Answer 1

Como entrenador ágil, he visto tantos errores cometidos por Scrum Masters sin experiencia, que entristecen mi corazón.

¡Muchas malas conductas se repiten una y otra vez! Entiendo que es fácil de encontrar para un entrenador ágil como yo, que ha visto cientos de equipos y proyectos; ¡Pero es mucho más difícil de detectar para el equipo que usa Scrum por primera o segunda vez! Es por eso que comencé a crear materiales para los equipos de Scrum Masters y Scrum para ver las trampas comunes que pueden o pueden conducir a un mal comportamiento. Uno de estos materiales es el curso de Udemy, The Daily Scrum – ¡Problemas comunes y cómo evitarlos!

Algunos de los errores de la descripción del curso son:

• Falta de caja de tiempo → siempre debe permanecer por debajo de 15 minutos
• No Scrum Master, no show → ¡Scrum Master no lleva esto, el equipo sí! O bien algo está muy mal en tu equipo.
• Comenzando discusiones → ¡no es un lugar para hablar sobre problemas o soluciones!
• Sin rastrear impedimentos → ¡si aparecen bloqueadores, anótelos y péguelos en la pared de impedimentos!
• Tiempo diferente, lugar diferente → ¡el ritmo es importante y lo mantiene eficiente! ¡No cambies la hora y el lugar del Daily Scrum!
• …y más

Siéntase libre de revisar el curso para ver una gran cantidad de malos comportamientos solo durante el evento de Daily Scrum. Solo la lectura de la descripción del curso y los títulos de las conferencias puede ser suficiente para que pueda tener una idea de los problemas comunes.

Answer 2

Estas son dos categorías muy amplias de personas … con ejemplos muy diferentes de mal comportamiento. Dicho esto, esto es lo que he visto comúnmente:

Entrenadores ágiles

• Sin tomarse el tiempo para evaluar realmente la cultura de la organización, no todas las culturas están listas para saltar de cabeza con las prácticas ágiles. A veces tienes que tomarte un tiempo para entender qué es la cultura y cambiarla gradualmente.
• No escuchas a las personas que están entrenando, hay un dicho común que se aplica a todas las formas de entrenamiento: “Tienes dos orejas y una boca, así que escucha el doble de lo que hablas”. Las personas a las que entrenas son Diciéndote lo que necesitan, solo necesitas escuchar.
• No aplicar sus propias prácticas: a veces soy víctima de esto, cortando esquinas en las historias de los usuarios porque es necesario en el momento. Pero cuando alguien más venga y vea que el entrenador está cortando esquinas, creerán que también está bien que lo hagan. Como entrenador, debes ser más diligente en tus prácticas que aquellos a los que entrenas.
• Pensando que lo sabes todo, lo más probable es que, si eres un entrenador Agile, lo hayas hecho a través de canales en su mayoría informales, con un poco de entrenamiento agregado aquí y allá. Eso es bueno, pero no significa que los demás no tengan pensamientos e ideas valiosos sobre lo que haces. El coaching debe ser una vía de doble sentido para que sea efectivo; ignora las entradas de otros a tu riesgo.

Scrum Masters

• Micromanaging: su función como Scrum Master es un facilitador para todo el equipo, no el gerente de ese equipo. Debes trabajar para asegurarte de que el equipo sea tan efectivo como sea posible, no gastes tiempo en administrar las tareas e historias para completarlas.
• Falta de enfoque: como Scrum Master, debe ser el segundo en saber tanto sobre el proyecto y el producto como el Propietario del producto, y anticipar lo que vendrá a continuación. No puedes hacer eso si te permites a ti y a tu equipo ser aleatorizados en múltiples esfuerzos en el mismo sprint o en sprints.
• Incapacidad para hacer retroceder: eres el protector de tu equipo; cuando la OP o una parte interesada llega a su equipo con algo con lo que no se han comprometido, algo que no cumple con su definición de listo, o algo que de otra manera pone en peligro la capacidad de su equipo para cumplir, debe rechazar eso.
• Desinterés por la Mejora Continua: si todos los equipos que hacen en sus retros se quejan y desean que las cosas sean mejores, o si es diligente en la revisión del pasado pero no hace planes para el futuro, realmente no es ágil. La parte más importante de Agile es seguir mejorando , sprint over sprint, mes tras mes, año tras año. Su función como Scrum Master es averiguar qué está frenando a su equipo y corregir esos objetivos tan rápido y eficazmente como sea posible.

Eso es solo un puñado justo en la parte superior de mi cabeza – ¡Estoy seguro de que hay más!

Answer 3

No todos los entrenadores ágiles son buenos. Y hay tantos escollos.

Un mal comportamiento común, por ejemplo, es la microgestión. (Mal) El entrenador se comporta como un tipo de administrador y usa herramientas y rituales ágiles contra el equipo. En lugar de empoderar al equipo (pseudo), las prácticas ágiles pueden ayudar a presionarlo. Esto suele ser fácil de detectar, ya que los entrenadores se centran en las fechas de entrega y utilizan la velocidad como una herramienta para predecirlos. También he visto a los mismos entrenadores que influyen en el equipo para arreglar puntos de historia. Y lo que es peor: usar los puntos de la historia como algún tipo de medida de rendimiento individual.

También puede ocurrir lo contrario y el entrenador puede tener dificultades para abordar las malas conductas de algunos miembros del equipo (por ejemplo, falta de compromiso). Sorprendentemente, he visto ambos tipos de problemas al mismo tiempo.

Realmente, ese comportamiento es algo así como Sabotagile (¿mira Agile o Sabotagile? ¿Cuál es la diferencia?) Está ocurriendo con bastante frecuencia y le da una reputación muy mala a Agility como una herramienta de microgestión.

Tengo muchas dudas sobre el uso de rituales de gestión ágil (iteración, historias de usuarios, reuniones diarias, gráficos BurnDown, definición de hecho, retrospectiva, etc.) sin prácticas técnicas (pruebas automatizadas, TDD, refactorización continua, olores de código, propiedad colectiva del código , Programación de pares, entregas de sodtware reales y demostración del cliente, etc). He visto muchas fallas relacionadas con eso. Probablemente porque los entrenadores que no son programadores consideran que los eventos de sus reuniones son más importantes que los problemas técnicos (que no lo son: ambos son importantes).

Otro problema común con los entrenadores ágiles es ser un fanático ágil. Esos se apegan a los rituales ágiles y se olvidan del propósito (ya saben, entregan software en funcionamiento). Si no te cuidas, los rituales pueden consumir mucho tiempo. Puede empeorar aún más (debido a las buenas intenciones) que ha definido una Definición de Hecho muy ambiciosa. Trabajé en un equipo en el que entre rituales y (uno mismo) requería etapas de finalización antes de que se consintiera la función (hecho después de la programación real) … estábamos consumiendo alrededor del 70% del tiempo disponible. La eficiencia del equipo se dividió por 3 entre antes y después de poner a trabajar a Agility. El entrenador fue instrumental en estas evoluciones.

Ese entrenador también fue un adicto al cambio. Estábamos cambiando continuamente las prácticas a un ritmo acelerado, sin tener tiempo para digerir y adaptarnos a las nuevas prácticas. Hay una diferencia entre aceptar el cambio y una tasa de cambio excesiva que mantiene al equipo fuera de balance.

Muchos escollos están relacionados con las dificultades para cambiar un equipo existente (aún peor: un equipo no dispuesto) o cambiar las prácticas y roles establecidos a nuevas formas ágiles. Puedes llevar un caballo al agua pero no puedes hacer que beba. Y Agile probablemente no sea para todos los programadores de todos modos, funciona mejor con generalistas experimentados, otros pueden ser desequilibrados o ineficientes. He visto a muy buenos programadores abandonar equipos debido a su incapacidad para adaptarse al método Agile (especialmente el hecho de no aceptar el cambio y la constante evolución de los requisitos).

Estos son simplemente una serie de posibles fallos que he visto directamente en una lista interminable. Los entrenadores ágiles son humanos como cualquier otra persona y se espera mucho de ellos. Lo que significa muchas posibilidades de fallar.

Answer 4

El # 1 para mí es cuando los equipos se ven obligados a adherirse 100% a un marco Agile en particular.

Lograr que los equipos se desempeñen de la mejor manera requiere tiempo y contexto.