agile - metodologia - Los malos hábitos de su Scrum Master

scrum significado

Question

Scrum es un proceso de desarrollo bastante popular en estos días y, a menudo, Project Manager de repente obtiene un nuevo título (Scrum Master). Sin embargo, no debería ser solo un título nuevo, sino nuevos hábitos y un nuevo paradigma. ¿Cuáles son los malos hábitos de su maestro de Scrum?

Answer 1

1. No poder asignar las tareas dentro del ciclo de forma adecuada (demasiadas por lo general)
2. No se trata bien con clientes externos (si una tarea determinada es demasiado grande para un solo ciclo, lloriquear ante el equipo en lugar de presionar al cliente)
3. Hacer scrums diarios demasiado grandes de un proceso, sin respetar un límite de tiempo determinado (preferimos un máximo de 15 minutos).

Answer 2

Asignar trabajo y solicitar informes de estado diarios en lugar de dejar que el equipo aprenda cómo administrar su propio trabajo.

Answer 3

Constantemente intercambiando nuevos errores dentro y fuera del Sprint.

Answer 4

Constantemente tratando de atar las horas reales regresó a las estimaciones del punto de la historia.

Answer 5

Cuando estuve involucrado en un Scrum, el maestro de Scrum rápidamente desarrolló el hábito de dejarnos hacer lo nuestro, y el Scrum volvió a nuestra rutina normal de desarrollo.

Answer 6

El gran mal hábito que nuestro Scrum Master tuvo al principio fue pensar que nos haríamos cargo de nuestros propios impedimentos. Esa es una de las cosas que se supone que el Scrum Master debe hacer, pero ella nos lo dejó hasta que se volvió inmanejable.

La otra cosa con la que nos hemos enfrentado es que el Scrum Master pensó que estaban a cargo de montar las espaldas de los desarrolladores hasta que se resolvieran las tareas. Esto crea una mala atmósfera en el equipo ya que se supone que deben ser autogestionados.

Para mí y para nuestro equipo, el trabajo del Scrum Master es ser un escudo y asistente del equipo, bloqueando los impedimentos y haciendo todo lo posible para ayudar a agilizar las cosas. El desarrollo de software ágil de Ken Schwaber con Scrum es una excelente introducción a Scrum, es lo que nuestro equipo usó y hemos tenido mucho éxito. También hay Agile Project Management con Scrum , que es más para los roles Scrum Master y Product Owner específicamente.

Answer 7

No ayuda con la parte de rechazo del proceso, por ejemplo, ''estas son todas las tiendas que el cliente quiere en esta iteración, así que eso es lo que tenemos que hacer''.

Answer 8

No mantener los scrums en el buen camino, dejándolos descender a las discusiones técnicas y una reunión mucho más larga.

Answer 9

1. Micromanaje
2. Ejercer un comando y control al viejo estilo en lugar de facilitar un equipo autodirigido
3. Centrándose más en los números / burn-ups / backlog que en las personas que componen el equipo
4. No protege al equipo de interferencias externas

Answer 10

Hay dos tipos de maestros del scrum:

1. Un gerente de proyecto cuyo título ha cambiado debido a la adopción de Agile.
2. Un maestro de scrum exclusivo que solo facilita el scrum y reporta al gerente de proyecto (shusa).

El segundo punto se predica y se practica en organizaciones ''verdaderamente'' ágiles. Es caro pero tiene algunos méritos.

También,

1. Se espera que un maestro de scrum esté presente con el equipo de sprint todo el tiempo (no literalmente). Si un gerente de proyecto hace eso, él / ella sería microadministrador.
2. El rol de los maestros de Scrum no es administrar los presupuestos, sino predecir el equipo de sprint, en términos de la cantidad de trabajo que el equipo puede hacer.
3. Los maestros de Scrum deben conocer las fortalezas y debilidades de los miembros del equipo y facilitar el intercambio entre las mejores prácticas.

Entonces, mi punto es que si estos roles son confusos, el equipo puede no funcionar muy bien.

Answer 11

1. Micromanar al equipo con hiper actividad
2. Anulando a los desarrolladores sénior en decisiones técnicas porque "Scrum dice" y "el equipo debe votar". Totalmente des-empoderamiento de personas técnicas superiores.
3. Tratando de exprimir sangre de una piedra en retrospectivas sobre problemas que en realidad no son problemas.
4. Decirme que los puntos no importan, pero en cada revisión los puntos son disecados, analizados cada 2 semanas en la revisión. Además, basar nuestra bonificación anual en nuestro rendimiento de puntos.

Scrum es bueno, pero puede ignorar las buenas prácticas de ingeniería y los procesos técnicos que han funcionado como un hechizo durante siglos.

Answer 12

Realmente me disgusta que cuando los ex PMs se convirtieron en Scrum Master, consideran a Scrum una forma de recortar sus obligaciones originales (individuales) sin invertir ese tiempo en trabajo en equipo, y reducción activa del estrés (planificación de contratiempos). Simplemente se reclinan y comienzan a elogiarse por los excelentes resultados, mientras que todos pueden ver que el equipo funcionaría incluso mejor sin su presencia, en absoluto.

En mi opinión, nuestros mejores maestros de Scrum han sido desarrolladores con un gran sentido de la responsabilidad, o no-PM.

Por otra parte, he trabajado (antes de que el mundo supiera de Scrum) para los PM que se tambalearon seriamente. Harían grandes maestros de Scrum hoy, estoy seguro.