Como final de la serie dedicada a los multiroles, quiero hablaros de la’ Tríada de responsabilidades Scrum’. De forma gráfica trataré de explicar, desde el punto de vista de las responsabilidades del trabajo, los problemas a los que se enfrenta una persona cuando quiere asumir más de un rol, y concretamente me centraré, de nuevo, en el binomio conflictivo… ScrumMaster + Product Owner.

Como final de la serie dedicada a los multiroles, quiero hablaros de la’ Tríada de responsabilidades Scrum’. De forma gráfica trataré de explicar, desde el punto de vista de las responsabilidades del trabajo, los problemas a los que se enfrenta una persona cuando quiere asumir más de un rol, y concretamente me centraré, de nuevo, en el binomio conflictivo… ScrumMaster + Product Owner.

Te aconsejo la lectura previa de las entradas anteriores:

¿Qué es la ‘Triada de responsabilidades Scrum’?. Los tres roles del método asumen las responsabilidades de un área que, en su conjunto, equilibra el método y el proyecto que desarrollan. El Product Owner es responsable del producto. El Equipo de desarrollo es responsable de cómo construirlo. El ScrumMaster es responsable del método empleado para gestionar el proyecto.Cada uno de los componentes de la triada trabaja en un área que ninguno de ellos debería sobrepasar. Vamos a ver en un gráfico cómo se comporta esta triada. En él se representan las responsabilidades de cada uno de los roles: ScrumMaster, P. Owner y Equipo de Desarrollo.  En cada uno de los vértices del gráfico se sitúan los roles.

El espacio que hay entre un eje y otro forma un triángulo en el que tiene cabida el trabajo que desempeña un rol y cómo afecta a su vecino. En la medida en que la responsabilidad de un trabajo es compartida con el rol vecino, dicho trabajo se situará cerca de un eje o centrado en el área del triángulo.Cada rol refleja su trabajo en dos medios triángulos, cada uno de ellos en dirección a cada uno de los otros dos roles vecinos. Así, por ejemplo, el ScrumMaster trabaja en dos medios triángulos: uno que avanza en el triángulo de responsabilidades hacia el equipo de desarrollo y otro que avanza en el triángulo hacia el Product Owner.Los trabajos son responsabilidad de alguien, cuanto más cerca están del eje de un rol, más únicamente suyas son esas responsabilidades; y cuanto más se acercan hacia otro eje, son responsabilidades que afectan a sus relacciones con el rol al que se acercan, es decir responsabilidades compartidas. Y por último, cuanto más se acercan al centro del diagrama, más afectan a las relacciones entre todos ellos.Así, por ejemplo, cuando el propietario está definiendo el Product backlog, este trabajo se debe situar en el punto señalado. Como veis está ligeramente cercano al ScrumMaster ya que es una responsabilidad compartida. A su vez, el trabajo (círculo verde) está en la zona exterior del triángulo ya que el equipo de desarrollo no interviene en este trabajo.En cambio, si queremos reflejar la Reunión de refinamiento del backlog, deberíamos situar este trabajo muy cerca del centro del triángulo formado entre el propietario y el equipo de desarrollo, ya que éste es responsable en gran medida del refinamiento. Además, el trabajo se sitúa cercano al centro de los tres vértices ya que el ScrumMaster tiene cierta responsabilidad en el correcto refinamiento.En una situación ideal, las responsabilidades bien repartidas y resueltas, equilibran el conjunto del proyecto. Así podríamos continuar con todas las actividades que realizan los roles scrum. Incluso, dada la flexibilidad de Scrum, cada proyecto puede situar los trabajos en un área ligeramente distinta que otro. Veamos ahora qué ocurre cuando una persona asume dos roles, en concreto el de ScrumMaster y Product Owner.Lo primero que vemos es que tiene que responsabilizarse de dos tercios del trabajo, eso ya supone una carga difícil de realizar puesto nadie puede duplicar su trabajo. Esta persona tendrá que adoptar una posición situada en algún punto entre ambos vértices de los roles. ¿Qué posición elegirá? ¿Qué pesará más, el producto, el método? ¿Cuál es la zona de confort, de efectividad?Por otro lado vemos que la frontera entre esos dos roles se ha roto. Ya no hay responsabilidades compartidas entre estos dos roles, dependerá del reparto y equilibrio que sea capaz de realizar dicha persona entre los dos roles que asume.Si  esta persona se sitúa en en centro de los dos ejes de los roles que asume, vemos que el trabajo, responsabilidades y tiempo dedicado a cada uno de ellos se reduce a la mitad. Como puedes ver, los trabajos y responsabilidades se condensan hacia el centro del gráfico. esto se traduce en que en este caso se reparten más las responsabilidades entre los tres roles.Y aún más grave, podemos ver qué ocurre cuando esta persona se posiciona hacia un extremo. ¿Qué ocurre con las responsabilidades en su conjunto?Si se posiciona ligeramente hacia el Product Owner (área marrón), baja el tiempo dedicado a las responsabilidades del ScrumMaster y vemos en el diagrama que de nuevo se rompe el equilibrio. El trabajo del ScrumMaster está en mínimos,  cobra más peso el rol del PO y su trabajo y responsabilidades se centran en su relación con el Equipo de desarrollo. Además, esta persona dedica menos tiempo a su trabajo como SC y eso impacta de forma peligrosa en el equilibrio de trabajo y responsabilidades entre el SM y el ED, esto empieza a parecerse a un modelo predictivo.Ahora imaginemos que esta persona se sitúa muy cerca del eje del SrumMaster (área verde). Ocurre lo mismo que en el caso anterior, el trabajo del Product Owner se encuentra en mínimos lo cual acabará en pérdida de visión del producto. Y lo que es peor, el área de trabajo reservado para el propietario y el equipo de desarrollo es casi nula.Aún nos queda analizar qué ocurre en los casos totalmente extremos.   Suprimir al ScrumMaster. Asumir los dos roles  posicionándose en ambos extremos en un balanceo constante.

Vamos con el primero, suprimir el ScrumMaster. El gráfico tendría este aspecto: Desaparición completa de las responsabilidades del ScrumMaster que son asumidas por el Product Owner y el Equipo de Desarrollo. Han desaparecido dos áreas de de trabajo completas.  Las responsabilidades del proyecto se concentran en un solo área,  el equilibrio está completamente roto.Me vais a permitir que dude de la validez de la solución. No creo que los miembros del equipo de desarrollo tengan la misma impresión de una aportación del ScrumMaster que de la misma aportación por parte del Propietario, y viceversa. Utilizando una analogía ¿creéis que los jugadores de un equipo esperan lo mismo de su entrenador que del presidente del club? Y el presidente ¿puede sustituir al entrenador repartiendo sus responsabilidades entre los jugadores y él mismo?¿Por qué los seguidores de esta tendencia creen que es más asumible eliminar al ScrumMaster que al Product Owner o mejor, al equipo de desarrollo? Es obvio que sin equipo de desarrollo no hay producto, y sin propietario no  hay producto, pero sin el ScrumMaster no pasa nada..., podemos seguir como antes…  ¿¿COMO ANTES?? Y ahora vamos con los segundos, los que asumen los dos roles y están en constante movimiento de un vértice a otro para asumir completamente ambos roles. Cuando se sitúe sobre el eje del SM, se perderá la perspectiva del Propietario y viceversa, de modo que las responsabilidades compartidas quedan en terreno vacío. Y esto no es lo peor, situaros en la posición del equipo de desarrollo. ¿Qué visión tiene de esta persona fluctuante? ¿Con qué careta le tiene que ver? ¿Qué espera de sus actuaciones? ¿Qué le solicita? No sabe cómo tratar a una persona así puesto que no tiene rol definido. De pronto les trata como un entrenador, como un mentor, como un trainer, y de pronto les trata como un cliente, un propietario, el que tiene el poder del producto. ¿Ante una pregunta o necesidad como qué les responderá? Como puedes ver, cualquier situación distinta de la propuesta por el framework, es altamente desaconsejable. Y recuerda una cosa, la misma solución no encaja en todos los proyectos, de modo que: tengamos sentido común.  Gracias por leer el blog, no olvides puntuar la entrada y dejar comentarios. Óscar R. Onrubia @OscaRonrubia

Nos vemos pronto con más temas interesantes.

Óscar R. Onrubia

@OscaRonrubia

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s