¿Puede scrum master asignar tareas?

Estamos siguiendo scrum en nuestro proyecto. Veo la mayoría de las veces que el scrum master nos asigna las tareas. Sin embargo, leí de muchos libros de scrum que scrum funciona al revés (el enfoque 'pull') y los miembros del equipo toman tareas o características. ¿El scrum master asignando tareas es el enfoque correcto o va en contra de la ideología ágil?

De acuerdo con el artículo de Wikipedia sobre Scrum , las tareas de Sprint no son asignadas por ScrumMaster:

Las tareas en el backlog de sprint nunca se asignan; más bien, los miembros del equipo registran las tareas según sea necesario, de acuerdo con la prioridad establecida y las habilidades de los miembros del equipo. Esto promueve la autoorganización del equipo y la aceptación del desarrollador.

Además, la definición de un ScrumMaster es que él / ella es la persona responsable de asegurarse de que las personas sigan las reglas del proceso Scrum.

ScrumMaster La persona responsable del proceso Scrum, asegurándose de que se usa correctamente y maximizando sus beneficios.

ScrumMaster no asigna tareas, simple y llanamente. El equipo se autoorganiza y decide quién trabaja en lo que decide el equipo.

Esto es cierto Scrum. Sin embargo, muchas organizaciones pueden usar variaciones de esto.

Esa es la forma en que se supone que funciona, pero como con todas las cosas que funcionan muy bien en teoría ... en realidad no siempre funciona.

Hay dependencias, deseos del cliente y controladores desde el exterior. Algunas cosas solo deben hacerse antes de poder trabajar en ese widget sofisticado en el que todos quieren trabajar.

Hay habilidades básicas de desarrollador que se manejan desde adentro. Algunas cosas son difíciles y algunas personas son mejores. Claro, cuando trabajo dentro de una línea de tiempo infinita, puedo dejar que lo descubras; pero cuando hay que hacer algo, entonces asignar a la persona mejor ubicada para hacerlo más rápido y mejor es el que está haciendo el trabajo.

Y luego están los problemas de personalidad como el control excesivo de Scrum Master y / o los desarrolladores que no pueden atarse sus propios zapatos sin que se lo indiquen. Mi equipo, por ejemplo, tiene ambos. Simplemente funciona mejor para que todos ignoren este pequeño hecho sobre Scrum en tales casos.

En otras palabras, no solo lo hagas porque el proceso lo dice. Haz lo que funciona. A la mierda el resto.

Por supuesto, también está el otro hecho básico de la existencia humana ... tal vez ni siquiera sabes quién es realmente el Scrum Master. Quizás no sea la persona con ese título. Quizás ni siquiera tienes uno.

Nunca.

Scrum es totalmente claro en esto. El equipo de desarrollo, como grupo, es responsable de completar los elementos en la cartera de pedidos de Sprint. También tienen el control total de cómo realizan el desarrollo y nadie tiene permitido decirles cómo hacerlo.

Como entrenador, el Scrum Master tiene un papel en señalarlo cuando ve que el Equipo está en peligro de perder los objetivos de Sprint por cualquier razón. Pero luego necesita pedirles que descubran cómo van a lidiar con eso, y luego apartarse de su camino.

Otro enfoque podría ser dejar que el Equipo complete el Sprint, responsabilizarlos por la falta de resultados y luego dejar que se discuta en la Retrospectiva de Sprint.

Al igual que cualquier ideología, hay momentos en los que el libro de reglas debe desecharse o ignorarse cuidadosamente.

Use un juicio sobre lo que parece apropiado. Solo tenga cuidado de que alguien se convierta en un gerente de proyecto de facto, o peor aún, intimide a las personas para que hagan ciertas cosas.

Hay una gran diferencia entre la asignación de tareas por dictado (DEBE hacer X) y la asignación por discusión y acuerdo. A veces el acuerdo puede ser tibio.

Por otra parte, tal vez el equipo necesita dirección ... es difícil de saber.

Sin embargo, me preocuparía cualquier proceso que insista en que debe seguir el proceso al pie de la letra sin margen de maniobra o juicio. Tal proceso es un sustituto del pensamiento.

En mi opinión, el maestro escoria no debería hacer eso, los miembros del equipo deberían recoger las tareas. Si el scrummaster solo está haciendo la administración, como es el caso en nuestro equipo, no vemos ningún problema. Nuestro scrum master se asegura de que el tablero de scrum de papel permanezca sincronizado con el archivo de Excel. El papel de scrum master debe ser facilitador, estamos seguros de que puede hacer su trabajo sin obstáculos. Así trabajamos nosotros. ¿Sabes por qué tu scrummaster hace esto? ¿Es un gerente de proyecto que teme volverse obsoleto? ¿Teme que el equipo no tome tareas por sí mismo? Podría ser una buena idea discutir esto durante una retrospectiva.

He sido un maestro scrum en ambos tipos de entornos (donde empujé tareas a individuos y donde los individuos extraen tareas).

O el equipo de Push, los recursos de desarrollo no eran intercambiables. El trabajo del cliente de Windows tenía que ir al desarrollador de Windows y el trabajo web al desarrollador web. Así que pude llevar las tareas a los recursos durante las sesiones de planificación. También pude planificar la capacidad individual para saber cuándo dejar de presionar.

El método de extracción funcionó bien en un equipo donde cualquier tarea podría ser recogida por cualquier recurso. Pero no pude planificar la capacidad individual durante la sesión de planificación, sino que tuve que depender de la velocidad promedio para saber cuándo era suficiente. (Tomó ~ 3-4 sprints antes de tener una buena idea sobre la velocidad).

Me encontré con un artículo interesante que describe los pros y los contras de Push vs. Pull.