Disfunciones Ágiles: cuando el Product Owner es el jefe del Scrum Master

Cuando una organización pasa de un modelo de trabajo tradicional a intentar trabajar de forma Ágil (con Scrum) se tienen que reconvertir antiguas estructuras y roles a las nuevas maneras de trabajar. Hasta aquí todo claro y nada nuevo.

El problema, bastante típico, y de ahí que viene este post, puede venir cuando, y supongo que no te sorprendo, un cambio de roles no supone un cambio de atribuciones o un cambio de mentalidad o un cambio en la manera de trabajar de siempre. 

Es muy típico (o yo es que me los encuentro todos) que los antiguos jefes de proyecto, que, normalmente, estaban más cerca de los clientes, gestionaban las viejunas especificaciones de requisitos, etc., pasen a tomar el rol de Product Owner, como que parece que les pilla más cerca.  

Y que como el rol de Scrum Master no existía lo tome alguien del equipo técnico o se contrate a alguien de fuera.

Como te decía, el anterior esquema de «transformación» es bastante típico, en la teoría parece no tener problema pero en la práctica…

En la práctica la disfunción (bastante profunda) viene cuando el Product Owner sigue haciendo de Jefe de Proyecto, «control y mando», y el Scrum Master queda por debajo, bajo las «ordenes», de manera explícita o tácita, del Product Owner, más si fue su jefe anteriormente o, en cualquier caso, ejerce como tal. 

En Scrum ambos roles están al mismo nivel, no está uno jerárquicamente sobre el otro, lo que hay es un reparto claro de responsabilidades, ya sabes, el Product Owner se preocupa más del valor, de la eficacia, y el Scrum Master de la eficiencia del proceso. No me extiendo mucho aquí, que ya lo deberías tener claro, en cualquier caso, te dejo un antiguo vídeo donde cuento esto (y hay más post sobre los roles de Scrum).

Ver este vídeo en YouTube.

Pero cuando el Product Owner está por encima del Scrum Master te vas a encontrar con Scrum Master eclipsados, que se frustran, que muchas veces el Product Owner intenta que no sean más que su «secretari@» y organicen post-it o muevan el Jira… en vez de ser cazadores de desperdicios que aumenten la eficiencia del proceso. 

Y cuando aparece este tipo de disfunción, aparte de que queda mermada la auto-organización del equipo, lo que más fuerza va a tomar va a ser meter como sea Items de negocio o Items que el Product Owner cree él o ella que son necesarios para el negocio. Y uso explícitamente la palabra Item porque a la mayoría de ellos, raramente, se les podría llamar Historias de Usuario, con Scrum Masters sin peso para que así sea. 

El «working software» como medida del avance suele ser raro de ver, las prisas, por encima de mínimos de deuda técnica, se ven reflejadas en Sprints copados de resolución de bugs por malas implementaciones previas, reflexionar sobre cómo ser más eficientes Sprint a Sprint queda en mero postureo, cualquier reflexión sobre mejorar en lo anterior queda en un «eso son chorradas lo importante es el negocio», etc., y así podríamos seguir hasta enumerar muchos de los problemas típicos del modelo tradicional jerárquico de gestión de proyectos.

Lo más gracioso del tema, por llamarlo de alguna manera, es que en algún momento, cuando los problemas sean más que visibles, acabaras escuchando al «Product Owner jefe de proyecto» decir… «es que la culpa de todo lo que está pasando es del Agile».

3 comentarios en “Disfunciones Ágiles: cuando el Product Owner es el jefe del Scrum Master”

  1. Muy buen Post, muchas gracias. Seria interesante si puedes compartir algunos Tips de como evitar estas situaciones o como lograr el cambio de mentalidad de estos «Product Owner Jefes de Proyecto»

  2. Guillermo Lázaro

    Permite que te indique que este artículo es un fiel reflejo de lo que sucede en la mayoría de lugares que he pisado yo por ahora…

    ¡Bravo Javier!

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Share This
Ir arriba