¿Debe un Scrum Master también desempeñar un rol de gerente funcional?

Un gerente que realiza las contrataciones, los despidos, las revisiones de desempeño y tiene capacidad técnica aún puede socavar al equipo y obligarlo a hacer las cosas a su manera, ya sea que esta persona sea el Scrum Master o no. Para esta persona, asumir el rol de Scrum Master es solo una carga adicional para ellos.

Es de esperar que los tomadores de decisiones que eligieron seguir el camino de Scrum sepan cómo debería funcionar y el gerente del gerente debería hacer una evaluación para asegurarse de que esta persona esté facilitando las necesidades del equipo y les permita hacer el trabajo para el que fueron contratados. Si el gerente va a "subir de rango" constantemente, se trata de un problema personal y posiblemente de un malentendido de cómo se gestiona un Equipo Scrum.

Puede ser útil traer a un consultor externo para ayudar con este proceso. A veces, es más fácil para la gerencia comprender el concepto de "dejar que el equipo se gestione solo" de una persona externa que directamente de un equipo que temen que lo haga por interés propio.

Parece que la empresa ha decidido seguir este camino a pesar de que entiendes que esto socava algunos de los principios básicos de Agile . Así que me ceñiré a algunas de las advertencias que deben tenerse en cuenta:

• Los plazos/objetivos incumplidos por el equipo no deben atribuirse a sus decisiones de contratación/despido. El proceso de contratación puede cambiarse para tener una sesión de entrevista entre pares con todo el equipo
• Los miembros del equipo no deben comenzar a ocultar el progreso/impedimentos/estimaciones dependiendo de su disgusto/placer
• Scrum master debe continuar brindando retroalimentación frecuente sobre el desempeño y entrenar al equipo
• El equipo debe continuar administrando las reuniones diarias (el maestro de scrum solo se asegura de que se realicen las reuniones diarias).
• El equipo no debe comenzar a informar al scrum master
• Las revisiones de desempeño deben basarse en la evaluación realizada por todos los miembros del equipo, incluido el Scrum Master.

TL;DR

Estamos tratando de planificar una transformación ágil pronto, y uno de los principales puntos conflictivos en esto es la estructura organizativa. La expectativa de la gerencia es que un Scrum Master realice todas las funciones normales, pero agregando revisiones de contratación, despido y desempeño para las personas bajo su dirección.

Su empresa no planea transformar nada. Están planeando cambiar el nombre de un rol, que esperan dote mágicamente al proyecto con los beneficios de los procesos ágiles sin pasar por el arduo trabajo real de rediseñar el proceso de gestión de proyectos, la cultura corporativa o la estructura organizacional. Es muy probable que esto resulte en un fracaso épico para el proyecto, la culpa del equipo y una mancha en el currículum del supuesto Scrum Master.

Un Scrum Master no es un gerente de línea

El trabajo del Scrum Master es arbitrar el proceso Scrum, educar al equipo y a la organización sobre Scrum e irradiar información sobre el proyecto al Product Owner y a la organización en general. Si bien no es imposible otorgar autoridad gerencial a un Scrum Master, funciona activamente en contra de los principios de autoorganización que Scrum pretende fomentar.

El rol principal de un Scrum Master a menudo se ve comprometido cuando se le pide que administre individuos en lugar de actuar como un líder de servicio para todo el equipo. Un Scrum Master ideal es un portavoz del equipo, que trabaja con el propietario del producto y las partes interesadas para eliminar los obstáculos; hacer restallar el látigo no es parte de la descripción de ese trabajo.

El cambio organizacional es difícil

Muchas organizaciones intentan etiquetarse a sí mismas como ágiles o dicen que han adoptado Scrum, pero en realidad nunca cambian los procesos comerciales fundamentales que subyacen a sus proyectos. Scrum es un marco basado en la capacidad que utiliza cuadros de tiempo para estimar y medir el progreso; no es una varita mágica que pueda sustituir a un liderazgo inspirado.

La adopción de prácticas y marcos ágiles es sin duda un objetivo loable. Sin embargo, se necesita más que un cambio de título y una nueva tarjeta de presentación para reestructurar el rol de Project Manager a Scrum Master. También requiere cambios generalizados en la organización (especialmente entre las partes interesadas) para adoptar el modelo de desarrollo iterativo. También requiere cambios de comportamiento en los niveles de las partes interesadas y de gestión para respaldar el modelo de un proyecto, un propietario del producto necesario para una planificación de Sprint efectiva.

La administración también debe cambiar

Scrum no es algo que solo hacen los equipos de desarrollo. La adopción de Scrum también requiere que los ejecutivos, las partes interesadas y los gerentes cambien. El cambio psicológico de la utilización del 100 % de los miembros individuales del equipo a la planificación de la capacidad basada en el equipo puede, en última instancia, derrotar a una organización que se niega a cambiar sus métricas o su estilo de gestión.

Para que Scrum tenga éxito, la alta dirección también debe realizar cambios fundamentales. Si la "transformación ágil" se detiene en los límites organizacionales del equipo de desarrollo, la implementación de Scrum no tendrá éxito.

Soy gerente de desarrollo de aplicaciones en este puesto y funciona excelentemente para mi equipo. Lo principal es la diferencia de mentalidad con respecto a la gestión tradicional. Tengo la ventaja de construir el equipo desde cero, así que dejé muy claro desde el principio que estoy aquí para ayudarlos y que toman decisiones más que yo. Al principio, el equipo tardó un tiempo en creer realmente que tomaba las decisiones y que tenía el control total, pero después de algunas retrospectivas, escuchando genuinamente y haciendo cambios, ELLOS deciden, ahora están dispuestos a plantear cualquier cosa para discutir.

Esto funcionó con tanto éxito que incluso tuvimos un pequeño período en el que el equipo decidió que me mantuviera en silencio en los stand-ups, para evitar que hablaran conmigo en lugar de entre ellos. Solo duró unas pocas reuniones, pero los ayudó a concentrarse en discutir los problemas en lugar de informarme.

Si le das la propiedad al equipo, ellos asumirán la responsabilidad.

Hay una excelente publicación publicada http://www.sitepoint.com/managers-make-terrible-scrum-masters/ . Animo a leerlo todo. Aquí hay algunas citas de allí para traer el punto:

Existe un conflicto de intereses básico entre los deberes de un gerente y un scrum master.

Un gerente se sienta en la parte superior de la pirámide en la jerarquía de un equipo, mientras que un enfoque ágil tiene que ver con fomentar un entorno en red de comunicación abierta, en el que los miembros del equipo confían unos en otros en lugar de las reglas de arriba hacia abajo de la organización.

...

La naturaleza jerárquica de la gestión ayuda a posicionar un equipo dentro de una organización más grande, pero funciona mejor si se mantiene separado del proceso ágil en red.

...

Construir y curar el equipo es el deber principal del gerente.

Tuvimos esta situación; también tuvimos una situación como PO siendo también SM. No ayudaron a los equipos en absoluto y no trajeron ninguna mejora. No pasó nada.

El problema es que el gerente funcional tiene una agenda. El PO tiene una agenda.

-La agenda de SM es diferente y tiene un enfoque diferente. Muchas veces el SM tiene que discutir con el gerente funcional para obtener beneficios para el equipo o traer cambios que sean beneficiosos para el equipo (pero tal vez no tanto para el gerente). Es prácticamente imposible que el gerente funcional se vuelva lo suficientemente objetivo como para "liderar el servicio" del equipo. Especialmente cuando tienen objetivos de rendimiento que cumplir.

• El SM está muchas veces en conflicto con el PO. El PO presionará para obtener estimaciones, más trabajo hecho y, a veces, querrá asignar tareas a los desarrolladores que saben que pueden funcionar mejor. El SM se interpone en el camino de todo eso y, a veces, protege al equipo en caso de que el PO sea abusivo. Por lo tanto, no hay absolutamente ninguna forma de que un PO pueda ser lo suficientemente objetivo como para ser un SM.

Idealmente, el Scrum Master es solo un Scrum Master. También puede ser entrenador, pero eso es todo. Pueden estar en el liderazgo/junta ejecutiva para influir en la toma de decisiones de la empresa, pero siempre manteniendo el sombrero de líder servidor. En el momento en que le das una función de gestión, rompes todo el concepto de Scrum Master, la forma en que el equipo se relaciona. a la persona, la forma en que la persona influye en el equipo, la confianza que el equipo tiene en la persona.

TL; DR: no, un gerente funcional tiene una agenda diferente y no es objetivo para cumplir el rol de Scrum Master, mientras que el equipo no confía ni se relaciona con un SM que también es el jefe.