Los Scrum Master no deberían ser Product Owner

Oye, Scrum Master: ¡Manos fuera de las tarjetas! Si ya eres Scrum Master, no deberías ser al mismo tiempo también el Product Owner de un equipo. Hay varias razones por las que estos dos roles no deberían ser asumidos por una misma persona.

Cada rol tiene un enfoque diferente

En primer lugar, el Product Owner y el Scrum Master tienen tareas muy diferentes en un proyecto Scrum. El Product Owner debe pensar en qué se debe desarrollar. Esto debería suceder independientemente de las capacidades del equipo. Para eso está el Scrum Master.

Mientras que el Product Owner establece qué se debe desarrollar, el Scrum Master ayuda al equipo a poder alcanzar este objetivo.

Del mismo modo, el programador de un equipo no debería ser también al mismo tiempo el tester. Ciertamente, un buen programador puede probar y un buen tester puede programar. Sin embargo, normalmente tiene sentido separar estos dos roles.

Cada uno ya tiene suficiente que hacer

En segundo lugar, el rol como Scrum Master o el rol como Product Owner requiere toda la atención de una persona. Si se le dieran ambos roles a una persona, con seguridad al menos uno de ellos sería descuidado.

Los dos roles requieren personalidades diferentes

Las habilidades y características que hacen buenos Scrum Masters y Product Owners se superponen en algunos puntos. Sin embargo, los roles son muy diferentes y es bastante improbable que alguien sea realmente bueno en ambos roles, especialmente al mismo tiempo.

¿Por qué son dos roles diferentes el Scrum Master y el Product Owner?

Por qué es así se puede explicar bien si se observan las tareas de un capitán pirata del siglo XVII. En la revista Harvard Business Review, el profesor Hayagreeva Rao escribió sobre cómo sus estudiantes se imaginaban el trabajo de un capitán pirata. Llegaron con una descripción del puesto que incluía dos áreas de responsabilidad:

1. Star Tasks – Trabajos estratégicos: por ejemplo, decidir qué barcos atacar, liderar a la tripulación en la batalla, negociar con otros capitanes, etc.
2. Guardian Tasks – Trabajos operativos: por ejemplo, dividir el botín, mediar conflictos, castigar a miembros de la tripulación y organizar el cuidado de los heridos
   El problema con esta descripción del puesto es que incluye ambos: Star Tasks y Guardian Tasks. Según el profesor Rao, hay pocas personas que puedan hacer ambas cosas igual de bien.

Scrum Master y Product Owner no son dos roles separados sin razón

Los Star Tasks requieren disposición al riesgo y espíritu empresarial. Los Guardian Tasks, por otro lado, requieren sentido del deber y constancia. Un capitán pirata que es bueno atacando barcos y liderando a su tripulación en la batalla probablemente se aburriría rápidamente con las tareas administrativas de los Guardian Tasks. El profesor Rao afirma que las personas rinden mejor en las tareas en las que son buenos (y que les gusta hacer). Solo puedo confirmar esto.

Los piratas evitaron este problema. Tenían un capitán que era responsable de los Star Tasks. Además, tenían un intendente general para los Guardian Tasks. ¿Qué tiene entonces el entorno poco comunitario y poco ágil de un barco pirata con la gestión de proyectos ágiles? Bueno, el Product Owner es principalmente responsable de los Star Tasks y el Scrum Master realiza en gran parte Guardian Tasks.

Y por exactamente la misma razón por la que los piratas tenían un capitán y un intendente general, debería haber un Scrum Master y un Product Owner independientes entre sí en los proyectos de desarrollo ágiles.

Hay una tensión natural entre los roles Scrum Master y Product Owner

Además, debería haber, como en el ejemplo, una tensión natural entre los dos roles. Aunque ambos están significativamente interesados en el éxito del producto o sistema (o barco), los Product Owner siempre quieren más, más, más.

Los Scrum Masters, por otro lado, tienen en cuenta los problemas que surgen cuando un equipo debe rendir más, más y más. Si hay un equilibrio entre los dos roles, el Product Owner puede seguir su inclinación natural de exigir más. El Scrum Master entonces se asegura de que no sea demasiado.

¿Hay excepciones?

Definitivamente.

He visto muchas veces que el Product Owner y el Scrum Master eran la misma persona, y estaba bien.

En algunos de estos casos, las organizaciones eran relativamente pequeñas. Simplemente no podían permitirse el lujo de tener una persona diferente para cada rol.
En otros casos, había equipos pequeños que habían comenzado con la implementación de una visión técnica del Product Owner. En equipos tan pequeños, cualquiera puede tener un gran efecto en el equipo, sin importar qué rol formal tenga.
Hay más excepciones con Scrum Masters que están involucrados en el desarrollo por contrato. En este caso, el Product Owner "verdadero" a menudo es el cliente del software a desarrollar. Desafortunadamente, estos Product Owner verdaderos a menudo no quieren estar particularmente involucrados en el proyecto, lo cual sería importante para el equipo. En tal situación, un buen Scrum Master a menudo asume el rol de Product Owner suplente.
Hay excepciones, como con cualquier regla. Sin embargo, ninguna de estas excepciones debería ser permanente. Y cualquiera que haya asumido ambos roles debería ser consciente de que este doble rol trae consigo muchos desafíos.