Miembros del equipo dominante en un equipo Scrum

¿Qué harías en una situación en la que un miembro del equipo trata de asumir responsabilidades no se le asignó inicialmente a él sino al Scrum Master?

El equipo Scrum está autoorganizado, por lo que hay espacio para alguien que es un poco más dominante. Otros deberían pedirle sus ideas sobre las tareas en las que están trabajando, pero su dominio debe mantenerse bajo control.

Lo que puedes hacer:

• Motive a otros a ser independientes pero colaborativos: esto se puede lograr mejor si coopera con su gerente y RR.HH., quienes les establecerán algunas expectativas, que se evaluarán periódicamente.
• Durante stand-ups, planificación y retrospectivas; deje que otros miembros del equipo hablen primero. Durante las revisiones, permita que otros miembros del equipo presenten historias de usuarios que implementaron.
• Deje que otros elijan las tareas primero para que el desarrollador dominante no solo pueda elegir las tareas que quiere hacer.
• Involucre la programación de pares para algunas tareas para que el miembro del equipo dominante esté colaborando con otros desarrolladores.
• Sea demócrata: la opinión de un miembro del equipo no es suficiente para realizar cambios en el proceso: Scrum solo funcionará si el equipo se comunica con claridad, o simplemente se estarán bloqueando mutuamente.
• Si nada de esto te ayuda, debes hablar con el miembro dominante del equipo y explicarle la situación, pero ten cuidado porque no hay un líder de equipo en Scrum por una razón. Si tiene el apoyo de la gerencia, también podría amenazar su estabilidad laboral, pero esta debería ser la última opción.

Si el miembro dominante del equipo no quiere perder su dominio y los miembros pasivos del equipo no quieren ser más activos, necesitará el apoyo de su gerente y recursos humanos. Esto podría ser un problema si la gerencia no alienta el proceso Scrum.

Presumiblemente, la razón de esta pregunta es porque siente que el equipo está de alguna manera con un rendimiento inferior debido a esta persona dominante. Quizás porque el resto del equipo no está contribuyendo al 100% porque, bueno, ¿cuál es el punto?

Como gerente, si lo es, es su responsabilidad asegurarse de que todos sus empleados comprendan cuáles son sus roles. Específicamente, qué se espera de ellos y cómo serán evaluados. Como miembro del equipo en un equipo Scrum, cada persona es personalmente responsable del éxito del equipo. Por lo tanto, este miembro dominante del equipo necesita saber que está fallando en esa responsabilidad y será evaluado en consecuencia.

La retroalimentación es un punto clave. Si hay una reunión de equipo y esta persona domina la discusión, obliga sus diseños y enfoque al resto del equipo y empuja al resto a roles pasivos, entonces se le debe decir, sin rodeos y en privado, que no cumple con los requisitos del papel Si lo ves resaltando furtivamente solo sus propios logros personales, entonces debe ser llamado y comprender que los logros personales se valoran mucho, mucho menos que ayudar al equipo a tener un logro grupal.

Todo lo cual es difícil, pero para eso están los gerentes y los Scrum Masters.

Hay otra forma posible de hacerlo. Que sea un problema de equipo. Llámalos juntos y diles que tienen un bajo rendimiento y he aquí por qué. Pídales que encuentren una solución. Te sorprenderías.

¿Por qué no preguntarle al desarrollador alfa su opinión? Es completamente posible que no tenga idea del efecto que está teniendo. Llévalo a un lado y dile lo que piensas. Incluso podría expresar la discusión de "oye, eres nuestro desarrollador principal, pero necesitamos llevar a estas personas a tu nivel, necesito tu ayuda para resolver cómo podemos hacerlo". Convierta su dominio en un activo. Vea si él puede ver formas de hacerlo.

Si se mide qué tan bien apoya a su equipo y los eleva a su nivel, entonces tendrá más motivación para hacerlo.

Usted implica que en realidad no está trabajando en interés del equipo (supongo), es decir, es malvado de alguna manera, entonces sí, elimínelo. Pero un hombre sabio me dijo una vez: No asumas mala voluntad, cuando la incompetencia o la simple ignorancia son más probables.

Parece que intenta ser el Scrum Master.

Aclare sus posiciones y actúe en consecuencia.

El papel del Scrum Master es habilitar el espíritu de equipo. Si no puede hacer que esta única persona sea un jugador de equipo, retírela del equipo .

Nota rápida: su desarrollador dominante no es más problemático que su desarrollador pasivo.

Actualmente, la planificación del sprint es un rol que rota en todo el equipo

La planificación de Sprint debe involucrar a todo el equipo, no ser entregada a una persona a la vez. A menos que haya una buena razón para esto, veo esto como un problema grave.

Si lo que está diciendo es verdadero y objetivo, entonces tiene un gran problema en sus manos: las personas que no participan y el "Dominador" que impide un proceso verdaderamente ágil. Como maestro de srum, depende de usted tomar medidas. Tal vez le gustaría tener a su gerente de proyecto en confianza sobre esta situación.

Muchos equipos se alejan del núcleo de ágil, y es su trabajo traerlos de vuelta. Debe enseñar y volver a incorporar valores ágiles en el equipo. De hecho, constantemente debes enseñar valores ágiles. Mantén tu visión ágil, hazla clara y poderosa. Muéstrales tu compromiso con "ágil bien hecho".

Para hacer esto, guíelos a través del manifiesto ágil y los valores de Scrum. Pregúnteles qué significa la colaboración para ellos y por qué es importante. Pregúnteles sobre el papel de la confianza en ágil. Este es un buen momento para hablar sobre por qué no hay un rol de líder de equipo y un rol de gerente de proyecto en Scrum y que es responsabilidad de todo el equipo hacer un excelente software, no el individuo.

Planifique una sesión retrospectiva completa en torno a esto. Haga que se comprometan con algunos valores y hagan un seguimiento durante la próxima retrospectiva. No apunte con los dedos, use métodos neutros.

Introducir métodos que obliguen a los otros miembros a expresar sus opiniones de manera segura. Algo simple como puño de cinco es genial para escuchar las voces silenciosas del equipo. Hace dolorosamente obvio que el equipo no está de acuerdo con el tipo dominante. Planning Poker funciona bien, pero la clave es no permitir discusiones antes de que se muestren las cartas. Cualquier cosa que ayude a que los demás sean escuchados sin iniciar conflictos es útil.

Si eso va bien, ya está todo listo. De lo contrario, hable con él sobre el problema. Use el entrenamiento y haga preguntas poderosas que puedan ayudarlo a darse cuenta del problema con claridad. Trate de llegar a la raíz porque ha tomado el papel dominante. Tal vez carece de confianza en el equipo (¿por qué?) Y tal vez siente que es responsable del éxito (¿por qué?). Sospecho que este rol no es algo que él quiere y es muy posible que le gustaría que cambie. Él puede venir alrededor y darse cuenta de ello.

¿Quizás el desarrollador "dominante" es recompensado por su desempeño individual en lugar de los logros del equipo?

En el pasado, me he asegurado de que las personas que son muy vocales y tengan ideas claras también sean recompensadas (a través de sus objetivos) fomentando otras contribuciones.

En general, creo que es una mala idea recompensar a los miembros de scrum sólidamente por su contribución individual y no por los logros del equipo.

También puede intentar hacer una ronda de comentarios 360 en su equipo para todos los miembros del equipo, solo si cree que los otros miembros del equipo serán sinceros en sus comentarios.

Proponer que se convierte en el Scrum Master para el siguiente sprint.

Las personas dispuestas a asumir responsabilidades no son un problema (siempre y cuando no quieran el monopolio sobre ellas), es precisamente lo que buscamos lograr con la autoorganización.

Los equipos con un rol rotativo de scrum master no son infrecuentes, por cierto.

La única tarea del maestro Scrum es asegurarse de que todos jueguen según las reglas del libro Scrum. Si los maestros que no son scrum lo hicieran por sí mismos sin la interferencia del maestro Scrum, ¡eso solo demostraría que estás en excelente forma (Scrum)! Cuanto menos tenga que hacer el maestro Scrum, más malo y delgado será su equipo desde la perspectiva de Scrum. Eventualmente, el papel del maestro Scrum podría / debería ser eliminado, él está allí para ayudarlo a comenzar y enseñarle Scrum.

Nuevamente, el Scrum master no participa en el proceso de desarrollo. Debe asegurarse de que todas las partes interesadas se comuniquen a tiempo sobre las cosas correctas, conoce a Scrum y brinda orientación para hacerlo, no es propietario de un producto o líder de proyecto. Si experimentas algo diferente, es posible que no estés haciendo Scrum con el espíritu ágil. Por supuesto, en entornos más pequeños, Scrum master podría ser un papel que desempeñe uno de los miembros del equipo o los interesados ​​en el juego. Entonces es solo un límite que uno se pone cuando es hora de formalidades. No lo confunda con un rol de liderazgo, es un rol de orientación.

Abrace el individualismo y el desempeño individual, pero también intente empoderar a las personas pasivas para que sean más participativas.

Mi experiencia dice que aunque parezcan similares a primera vista, comunismo y agilidad no son lo mismo. Agile no apunta a una sociedad (equipo) sin clases, sino a un software que funcione.

Trate de hacer que su desarrollador alfa comprenda que él podría ayudarlo a desarrollar las habilidades de otros al preguntar y asesorar, en lugar de responder siempre primero, y lograr logros individuales. Seguramente su desarrollador alfa es uno que se preocupa por un buen software, y eso es algo que no puede permitirse perder.