Los malos hábitos de su Scrum Master

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

El gran mal hábito que tenía nuestro Scrum Master 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 que hemos tratado es el Scrum Master pensando que estaban a cargo de montar las espaldas de los desarrolladores hasta que se hayan solucionado 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 bastante éxito con él. También hay Administración ágil de proyectos con Scrum, que es más para los roles Scrum Master y Product Owner específicamente.

Answer 2

Cuando estaba 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 3

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

Answer 4

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

Answer 5

Constantemente intercambiando nuevos errores dentro y fuera del Sprint.

Answer 6

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

Answer 7

1. No ser capaz de ranura tareas dentro de ciclo de manera apropiada (demasiados por lo general)
2. No se ocupan bien con los clientes externos (si una determinada tarea es demasiado grande para un solo ciclo, el lloriqueo al equipo en lugar de empujar hacia atrás en el cliente)
3. Hacer los scrums diarios demasiado grandes de un proceso, sin respetar un límite de tiempo determinado (preferimos un máximo de 15 minutos).

Answer 8

Intentando constantemente relacionar las horas reales trabajadas con las estimaciones de puntos de la historia.

Answer 9

1. Micromanaging
2. ejercer el mando y el control de estilo antiguo en lugar de facilitar un equipo autodirigido
3. Centrándose más en los números/Burn-ups/atraso que en los personas que componen el equipo
4. No proteger el equipo de la interferencia externa

Answer 10

Hay dos tipos de maestros 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.

Además,

1. Se espera que un scrum master estar presente con el equipo de velocidad todo el tiempo (no literalmente). Si un gerente de proyecto hace eso, él/ella sería microadministrador.
2. La función de Scrum Masters no es administrar los presupuestos, sino predecir el equipo de Sprint, en términos de 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 de mejores prácticas entre scrums.

Por lo tanto, mi punto es que si estos roles se confunden, puede que el equipo no lo haga muy bien.

Answer 11

1. Micromanaging al equipo con hiperactividad
2. desarrolladores de alto nivel sobre Anulación de las decisiones técnicas, porque "Scrum dice" y "el equipo tiene que 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 se disectan los puntos, se analizan 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 amuleto 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 responsabilidad, o no-PM.

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