¿Cuáles son los aspectos negativos de los Gerentes de Desarrollo como Scrum Masters?

Se acuerda comúnmente que los gerentes de equipo no deberían ser maestros de scrum, pero estoy luchando por ver por qué. Por contexto, soy un administrador de desarrollo de aplicaciones con 4 desarrolladores en un equipo Scrum. Vengo de un fondo Scrum Master, y he presentado scrum a la organización. Construí el equipo desde cero y dejé en claro que todo lo que hago es facilitar al equipo y que tomen las decisiones. Como equipo, somos muy abiertos, incluso me silenciaron en los stand-ups por un tiempo para eliminar la sensación de 'informar' que estábamos empezando a tener. La falta de apertura es generalmente el mayor argumento contra el gerente como scrum master, pero manejado bien, se supera fácilmente con la cultura correcta.

Los experimentados entrenadores de scrum me han advertido que esta es una situación peligrosa y que existen riesgos "si las cosas van mal". A mi modo de ver, las 2 posiciones no entran en conflicto, en ambos roles tengo el mismo objetivo para el equipo y los individuos. Scrum resuelve conflictos dentro del equipo, que tradicionalmente podría ser un rol de gerentes. La naturaleza autogestionada de los sprints elimina la asignación de trabajo que un gerente haría tradicionalmente.

Todo lo que realmente me queda por elegir como gerente de desarrollo es asegurarme de que se cumplan las necesidades individuales, los objetivos profesionales, el lugar de trabajo, etc. Tengo una actualización semanal con cada miembro del equipo para plantear cualquier problema y manejar cualquier tarea administrativa. Mucho de esto se relaciona directamente con el equipo, o mi papel como scrum master de todos modos.

Entiendo en organizaciones grandes cómo esto podría ser inmanejable y un papel separado, pero para una organización pequeña ciertamente no podríamos justificar a otro Scrum Master o Gerente de Desarrollo.

Por favor, ilumíneme sobre las trampas de los Gerentes de Desarrollo como Scrum Masters, excluyendo los puntos que planteé anteriormente y que ya he superado.

Esencialmente, tienes un conflicto de intereses. El trabajo de un gerente es cumplir con los plazos. El trabajo de un maestro scrum es garantizar que las estimaciones sean lo más precisas posible y trabajar a un ritmo sostenible. Un gerente tiende a querer más trabajo en un sprint, y un scrum master tiende a querer una cantidad que se pueda terminar de manera realista, independientemente de los plazos externos. Aunque un buen gerente puede equilibrar ese conflicto, es mucho más fácil cuando el trabajo se divide entre dos personas. Los gerentes suelen ser mucho más adecuados para el rol de propietario del producto.

No hay nada de malo en actuar como scrum master si nadie en su equipo está familiarizado con él, pero su equipo verá beneficios si entrega ese papel después de unos meses. Es importante que ese papel sea visto como un compañero. Incluso los maestros de scrum no administrativos a menudo tienen que retirarse después de un tiempo porque el equipo comienza a tratarlos demasiado como a un gerente.

Creo que el principal problema es que, como gerente, usted tiene la autoridad para decirle al equipo qué hacer. Un maestro scrum no tiene esta autoridad fuera de hacer cumplir los principios de Scrum.

¿Qué significa esto? La aportación del gerente implícitamente tendrá más peso. Es posible que no lo desee, o lo desee, pero al final del día, la carrera y el sueldo de los miembros de su equipo dependen de usted de alguna manera. Y ellos lo saben. Y esto contamina la relación.

¿Aún puedes hacerlo? Por supuesto. Solo necesita trabajar muy duro para reforzar que usted es un líder de servicio y que de arriba hacia abajo no volará.

De hecho, he visto lo que sucede cuando un "gerente técnico" se involucra demasiado en la mecánica diaria de un proyecto, y no es bonito. En nuestro caso, el gerente en cuestión no era el scrum master sino que estaba tratando de cooptar algunas de esas decisiones; si no hubiéramos hecho tenía un scrum master separado para jugar a la defensiva, entonces habría sido mucho más doloroso.

(Por cierto, este no era mi gerente, así que me siento bastante objetivo en este punto).

Revisaré lo que vi como los principales conflictos de intereses; Si no cree que ninguno de estos se aplique a su situación, tal vez pueda hacer ambas cosas. Pero asegúrese de volver a verificar estos supuestos regularmente para asegurarse de no caer en ninguna de estas trampas:

1. Los gerentes técnicos suelen ser responsables de un determinado rol dentro de múltiples equipos. Si es solo un equipo, entonces es más un "líder" que un "gerente". Esta distribución de responsabilidad significa menos tiempo con el equipo y menos tiempo con el proyecto / producto, y tiende a conducir a una gestión de estilo de "golpear y ejecutar".

2. Los gerentes técnicos tienen muchos otros deberes gerenciales para el negocio. Deben realizar coaching / capacitación, revisiones de desempeño, entrevistas / contratación, planificación de infraestructura / recursos a largo plazo y más. Esto puede convertirse fácilmente en un trabajo de tiempo completo por sí mismo y significa que queda muy poco para gastar en la facilitación.

3. Un horario ocupado también puede imponerse en el equipo; los gerentes técnicos pueden necesitar (o desear) atraer a los miembros del equipo a las reuniones en lo que el equipo considera un momento inoportuno. Normalmente es el trabajo del maestro scrum manejar e intentar eliminar las interrupciones, pero es imposible ser objetivo al respecto cuando tienes que preocuparte de tu propio horario. Los maestros de Scrum rara vez necesitan reunirse por separado con los miembros del equipo porque todas esas reuniones ya están programadas previamente (stand-ups, retrospectivas, etc.)

4. Los gerentes técnicos deben ocuparse de las preocupaciones de proyectos transversales y su impulso natural será tratar de estandarizar todo: bibliotecas, control de fuente, algoritmos, diseños, colores, lo que sea. Si bien esto puede ser algo bueno para la empresa, en última instancia, no deja que nadie vaya al palo por lo que el equipo quiere hacer, y pueden tener muy buenas razones para querer hacer algo diferente. Esto va en contra de los ideales de "mejora continua" subyacentes a Scrum y metodologías similares.

5. Los gerentes que provienen de una experiencia experta en el rol que manejan tendrán sus propias ideas bastante sólidas sobre cómo se debe hacer el trabajo y cuánto tiempo debe tomar. Esto no es malo como gerente , pero como maestro de scrum a menudo significará sesgar a los miembros del equipo en diseños o estimaciones que de otro modo no habrían acordado, y probablemente sepan más que usted sobre el problema en cuestión.

6. Los miembros del equipo siempre tendrán problemas para diferenciar entre una solicitud y un pedido. No te dirán esto y tal vez ni siquiera se den cuenta. Incluso si deja en claro que simplemente pregunta y no dice, en su opinión, sigue siendo su gerente y existen riesgos a nivel profesional al decir "no". Este es probablemente el más insidioso de todos los problemas porque no hay nada que puedas hacer al respecto ; lo que importa es su actitud y no la tuya .

Si está seguro de que nunca caerá en ninguna de estas trampas, hágalo ... pero repito, asegúrese de validar con frecuencia sus suposiciones con hablando con su equipo (¡y otros equipos / gerentes!) y asegúrese de que no sucedan de una manera sutil o inconsciente que tal vez no note.

En una nota positiva, agregaré que el hecho de que consideres el tema lo suficientemente importante como para hacer la pregunta significa que probablemente eres bastante bueno en ambos roles. La preocupación por el equipo y no solo por sus propias ambiciones profesionales probablemente representa más de la mitad de lo que es una buena administración, en mis libros de todos modos.

... pero ser bueno en ambos no necesariamente significa que puedes ser bueno en ambos al mismo tiempo, todo el tiempo . Ten cuidado con eso.

Esto no es religión y las reglas de Scrum no son dogmáticas. Si alguna vez ha habido un caso para una función combinada de Gerente de Recursos Humanos / Maestro Srum, has hecho una buena. Esté atento a los escollos que mencionó, pero nunca habrá un solo conjunto de reglas que se adapten perfectamente a cada situación.

Si su equipo se siente cómodo con usted desempeñando ambos roles, entonces no hay razón para cambiar las cosas solo para ajustarse a las reglas de un libro.

El mayor problema que veo es la situación en la que el equipo tiene un problema relacionado con usted, el gerente. Si son jóvenes, o carecen de confianza, pueden tener miedo de hablar durante las retrospectivas. Esto podría limitar la efectividad de las retrospectivas. Muchas personas tienen miedo de decir "Siento que el gerente no es realista" cuando el gerente está presente.

Entonces, tal vez te disculpes de las retrospectivas para resolver este problema. Ahora su equipo está haciendo retrospectivas sin un scrum master, lo que también limita potencialmente la efectividad de la retrospectiva.

En cualquier caso, estás teniendo un impacto negativo en el equipo.

El principal problema que veo es que está enviando mensajes contradictorios al equipo sobre la organización del equipo.

A continuación hay dos posibles organizaciones de equipo. Ambos pueden ser exitosos. Ellos son diferentes. (No son las únicas opciones posibles).

1. El equipo tiene un líder oficialmente designado. El líder del equipo es en última instancia responsable del desempeño general de los equipos. El líder del equipo puede no tomar todas las decisiones, pero el líder del equipo tiene la última palabra en todas las decisiones.
2. El equipo está autoorganizado y no tiene un líder designado oficialmente. Todos en el equipo son responsables de su propio desempeño y del desempeño general de los equipos. El Scrum Master facilita el proceso de Scrum, pero no está facultado para tomar decisiones unilaterales para el equipo.

Parece que la estructura real de su equipo es la n. ° 1, pero al usar la terminología y varios procesos de Scrum, está dando a entender que la estructura es la n. ° 2. Mi opinión es que # 1 no es Scrum.

A continuación hay dos sugerencias sobre cómo resolver el conflicto.

1. Sigue haciendo las cosas como estás, pero aclara que eres el líder del equipo y que no estás siguiendo a Scrum al 100%. Probablemente sería útil explicar que, si bien ve el valor de segregar los deberes de un gerente y un scrum master, eso no es factible para la empresa.
2. Entregue las responsabilidades de Scrum Master, tanto como pueda, a otra persona. Incluso si todavía tiene que retener algunas responsabilidades, como eliminar obstáculos y desviar las distracciones del resto de la organización, seguirá siendo útil que un compañero realice gran parte del trabajo de Scrum Master.

¿Cuáles son los aspectos negativos de los Gerentes de Desarrollo como Scrum Masters?

Los gerentes de desarrollo son contratados para:

• Resolver problemas de desarrollo .
• Monitorear y reducir la deuda técnica.
• Crecer el personal técnico.

Sus antecedentes y experiencia les predisponen a centrarse en cuestiones técnicas .

Por otro lado, los gerentes de proyecto / maestros de scrum son contratados;

• Garantizar el éxito del proyecto.
• Asigne errores / preguntas de trabajo y clasificación a los recursos de desarrollo apropiados.
• Colabore con el equipo de desarrollo para eliminar todos los obstáculos que puedan retrasar la finalización del proyecto.
• Transmitir el estado del proyecto a la alta dirección.

• Cuando un proyecto o una empresa crece hasta un cierto tamaño, es ineficiente y poco sabio pedirle a un gerente de desarrollo que realice ambas tareas.

• Un gerente de desarrollo debería estar inclinado a realizar "inmersiones profundas" en código y / o arquitectura, mientras que un gerente de proyecto / scrum master siempre debería preocuparse por la vista de "50,000 pies" de las cosas.

• La mayoría de los gerentes de desarrollo han pasado años desarrollando código. Los problemas de desarrollo les son muy familiares.

  • Por lo tanto, son más útiles cuando resuelven problemas técnicos.
• Los roles de gerente de proyecto / scrum master requieren personas muy organizadas y muy detalladas, pero no super-técnicas.
• Cuando puede permitirse el lujo de permitir que estas personas se especialicen en las cosas en las que son buenas, el negocio es más eficiente.
• Y cuando puede descargar las responsabilidades relacionadas con scrum de la placa de un gerente de desarrollo, él / ella puede pasar más tiempo en problemas técnicos y reducir la deuda técnica.

Escuchaba a entrenadores de scrum con experiencia. Es posible que trabaje bien el 99% del tiempo. Sin embargo, cuando ese temido 1% aparece y los roles entran en conflicto, tienes la oportunidad de arruinar no solo la relación de un individuo contigo sino el bienestar de todo el equipo. Y después de un error, su papel como scrum master y manager se vería debilitado.

Si yo fuera usted, identificaría a un individuo en el equipo que tiene el potencial de ser el maestro de scrum y lo acompañaría. Siempre vi a un maestro scrum como alguien en quien el equipo confía y que comprende el proceso, el negocio y las cosas técnicas aterradoras también. Si elige una persona capaz, un rol de maestro scrum no es (y ni siquiera está cerca de ser) un trabajo de tiempo completo.