¿Puede una persona ser Scrum Master y Architect al mismo tiempo?

Los roles de Scrum Master y del equipo de desarrollo pueden entrar en conflicto

¿Está bien si Scrum Master y Architect son una sola persona?

Presumiblemente, el Arquitecto es considerado un miembro del Equipo de Desarrollo. El rol de Scrum Master es un rol distinto con la responsabilidad de ser un árbitro del proceso , mientras que el Equipo de Desarrollo está a cargo de la implementación .

Si bien es técnicamente factible que una persona cumpla con ambos roles, es mucho más común ver un conflicto entre el requisito de entregar y el requisito de facilitar un proceso formal.

Además, el tiempo requerido para desempeñar ambos roles también representa un conflicto de intereses. Por ejemplo, si tiene un día para implementar una historia arquitectónica de la que depende su equipo, así como tareas de Scrum Master, como impedimentos para eliminar o una larga sesión de Refinamiento de Backlog para asistir con el Product Owner, ¿cuál priorizaría? Si no puede hacer ambas cosas sin tomar atajos, entonces no cumple ninguna función correctamente.

Como con todas las cosas, su millaje puede variar. Sin embargo, no variará mucho si está implementando Scrum correctamente. También tenga en cuenta que si desea evitar presupuestar un recurso adicional para uno de los roles, aún pagará por ese recurso en la capacidad de equipo perdida porque TANSTAAFL .

Puedo hablar desde cierta experiencia, ya que actualmente soy Scrum Master y miembro del equipo de desarrollo (como un arquitecto, que es 'solo' un miembro del equipo de desarrollo en términos de Scrum) . Aunque a menudo está mal visto, esto es posible y no está explícitamente prohibido. Para mi esta parte de la guía de scrum es la más orientativa y nos da cierta libertad:

El Equipo Scrum está formado por un Product Owner, el Equipo de Desarrollo y un Scrum Master. Los Equipos Scrum son autoorganizados y multifuncionales. Los equipos autoorganizados eligen la mejor manera de realizar su trabajo, en lugar de ser dirigidos por otros fuera del equipo. Los equipos multifuncionales tienen todas las competencias necesarias para realizar el trabajo sin depender de otros que no forman parte del equipo. El modelo de equipo en Scrum está diseñado para optimizar la flexibilidad, la creatividad y la productividad.

Tenga en cuenta que se menciona todo el equipo Scrum, no solo el equipo de desarrollo. Dicho esto, pueden surgir una serie de conflictos:

• Tiempo : como menciona CodeGnome, hay días en los que el Scrum master y el rol de desarrollo necesitan toda su atención. Especialmente cerca del cierre del sprint, un desarrollador está en el calor de terminar las cosas para terminar las historias, mientras que el maestro Scrum probablemente necesite ayudar al propietario del producto en la gestión del trabajo pendiente.
• Metas : todo el equipo Scrum está comprometido con la meta del sprint. Sin embargo, un maestro Scrum adecuado también mantiene una agenda de entrenamiento. En algunas ocasiones, esto puede significar que el Scrum master necesita que el equipo experimente una forma de falla, por ejemplo, no terminar completamente una historia de usuario, para que aprendan, inspeccionen, adapten y mejoren. Como desarrollador, nunca quieres que esto suceda, quieres tener éxito de la mejor manera posible. Este conflicto puede convertir al scrum master en una 'scrum mom' que persigue todo para mantener el éxito del equipo. Esto termina pareciéndose mucho a un administrador de proyectos integrado o, como mínimo, a un microadministrador de servicio.
• Confusión : durante los eventos formales de inspección y adaptación, puede ser difícil para otros miembros del equipo saber quién está hablando. ¿El scrum master o el desarrollador? Como desarrollador, es posible que desee expresar una opinión sólida durante la retrospectiva, pero nadie puede decir de quién está hablando. Esto corre el riesgo de parecer un Scrum Master autoritario, que comienza a parecerse mucho a un líder de equipo. Por tonto que parezca, probablemente quieras comenzar todas tus oraciones con 'hablando como desarrollador / maestro scrum' .

Dicho todo esto, los equipos experimentados con un fuerte vínculo pueden manejar esta confusión en la mayoría de los casos. Por otra parte, nunca es la situación ideal.

El rol de Scrum Master proporciona dos cosas al Equipo Scrum:

• Ayuda al equipo a resolver impedimentos.
• Ayuda a garantizar que el equipo siga Scrum al proporcionar entrenamiento y facilitar las ceremonias de Scrum.

Si un individuo puede proporcionar esas dos cosas, entonces puede desempeñar el rol de Scrum Master.

No hay nada que decir cuánto tiempo tomarán estas actividades. En un equipo grande que es nuevo en Scrum y en un dominio comercial difícil, el Scrum Master bien puede estar muy ocupado. En un equipo más pequeño, o con un equipo que tiene mucha experiencia, el Scrum Master puede tener mucho menos que hacer.

La clave es ver al Scrum Master como un servicio al equipo. Si pueden brindar ese servicio y tienen suficiente tiempo para hacer otras cosas, entonces está bien.

A menudo he trabajado con equipos en los que el rol de Scrum Master lo realiza un miembro del equipo que no es especialista. He visto a desarrolladores, evaluadores y analistas de negocios desempeñar el rol de Scrum Master. No he trabajado con un arquitecto en el rol de Scrum Master, pero no veo ninguna razón por la que esto no funcione.

Es difícil ver algún conflicto de intereses entre el rol de Scrum Master y cualquier otro rol del equipo de desarrollo. Un Scrum Master no tiene autoridad sobre el equipo, por lo que no puede decirles que hagan cosas. El Scrum Master tampoco tiene la última palabra en asuntos técnicos. El equipo en su conjunto toma decisiones técnicas por consenso.

@Barnaby Golden dice que les resulta "difícil ver algún conflicto de intereses entre el rol de Scrum Master y cualquier otro rol del equipo de desarrollo". ¡Puedo ver (y he visto) mucho!

Considere un arquitecto que tiene un rol de desarrollador en dos equipos: ¿puede cada equipo, respectivamente, hacer que el arquitecto sea totalmente responsable ante su equipo? Puedo imaginar un escenario en el que surge un "trabajo urgente no planificado" en un equipo, el arquitecto salta sobre ese equipo y el otro equipo se queda en la nada, lo que resulta en un Sprint fallido para ellos.

Ahora considere un solo equipo donde el arquitecto tiene tanto un rol de desarrollador como el rol de SM: cuando surge algún "trabajo urgente no planificado" para el equipo, ¿cómo reacciona el arquitecto? ¿El arquitecto salta al modo SM completo para garantizar que se mantenga la seguridad psicológica, que el equipo de desarrollo no se comprometa en exceso, que lo proteja de la intromisión externa (horas extra obligatorias, etc.)? ¿O se sumergen en el modo Desarrollador completo y comienzan a 'facilitar' sesiones de pizarra, escribir y revisar código, ayudar a probar, eliminar impedimentos activamente, etc.?

He trabajado en varios Equipos Scrum que tenían una persona Desarrollador + SM y siempre volvían al modo Desarrollador y lo primero que desaparecía era la seguridad psicológica, es decir, justo cuando más necesitábamos un SM.

Por supuesto, en teoría , no hay ninguna razón por la que el arquitecto no pueda continuar desempeñando ambas funciones al máximo. Pero, ¿te imaginas que sucedan estas conversaciones?:

• ¿El arquitecto como SM hace que el Equipo de Desarrollo rinda cuentas por no hacer que el SM rinda cuentas por no ser un SM cuando lo necesitan?
• Arquitecto: "... así que pronosticamos que no terminaremos por poco al final de Sprint con la cantidad de trabajo y seis FTE". Gerente de proyecto: "¿Pero tiene 6.5 FTE?" Arquitecto: "No, en estas circunstancias he vuelto al modo SM completo. No contribuiré más al Incremento". Gerente de proyecto: "Ah, sí, por supuesto. Lo entiendo perfectamente".

OK, estoy siendo un poco bromista, pero entiendes mi punto. Puede haber conflictos de intereses reales y, por la razón que sea, es el rol de SM el que sufre.

@Barnaby Golden menciona servicios al Equipo pero no los otros dos: servicios al PO y a la organización respectivamente. En mi experiencia, no he visto a una persona Developer+SM que haya brindado estos servicios de manera efectiva, y por lo general no lo ha hecho en absoluto, porque están demasiado concentrados en su propio equipo. Por lo general, no hay suficientes horas en el día.

El resultado final para mí es este: aquellos de nosotros que hemos trabajado en un Equipo donde el SM es un SM/entrenador ágil de carrera, está a tiempo completo y totalmente dedicado al rol de SM, sabemos el valor que esa persona aporta al Equipo. y, dada la elección, optaría por este escenario cada vez. Siento que, si alguien piensa que un desarrollador + SM no compromete de alguna manera el rol de SM, entonces todavía tiene que trabajar con una persona de SM realmente buena.