El Product Owner debe ser uno por producto, no un comité o conjunto de personas. La Guía Scrum lo dice muy claramente y, a pesar de los pesares, nos empeñamos en hacer experimentos raros. Otra cosa es que el Product Owner represente los intereses de distintos stakeholders (clientes, el CEO, el Consejo de Administración, ventas, marketing, etc.), o que pueda delegar ciertas tareas (de gestión del Product Backlog, por ejemplo). Pero el Product Owner debe ser una única persona y es quien tiene la última palabra sobre las decisiones de producto y asume tal responsabilidad.

Contar con varios PO es darnos “un tiro en el pie” y asumir la indefinición por bandera en nuestro proceso de creación de software. Ya tenemos suficiente con las incertidumbres de mercado y tecnológicas que afectan a cualquier producto como para permitirnos este lujo. ¡Con la que está cayendo!

Veamos en qué se traduce esta indefinición cuando varios Product Owner gestionan un mismo producto:

Confusión para el Equipo de Desarrollo. ¿A quién han de acudir los miembros del Equipo de Desarrollo cuando tengan preguntas sobre las funcionalidades en las que están trabajando? Si el alcance del Sprint necesita ser renegociado, ¿a quien nos dirigimos? Se genera una situación de ambigüedad innecesaria, por no mencionar el riesgo de que, si no nos gusta lo que dice “mamá”, vayamos a “papá” -o a la inversa-. Es inevitable, pasa en las mejores familias.

Fragmentación de la visión de producto. Al igual que el CEO hace lo propio al determinar el rumbo de la empresa, el Product Owner marca la visión del producto. Si tenemos a varios Product Owner, cada uno con su propia visión sobre el producto, es probable que terminemos yendo a la deriva, sin saber hacia dónde vamos ni por qué. No olvidemos que tener una visión de producto potente y bien comunicada aumentará el grado de autoorganización del Equipo de Desarrollo; lo contrario lo hace dependiente -de los varios PO- y dubitativo.

Lentitud en la toma de decisiones relativas a producto. Imaginemos que tenemos a un comité, oficina o equipo de producto, cuyos miembros se tienen que poner de acuerdo antes de decidir. Podrían pasar días o semanas hasta que desojen la margarita. Tanto el contenido como el orden del Product Backlog podrían reflejar aspectos que están por acordarse y, por tanto, dejar de ser transparentes.

Compartimentación del Producto en áreas (funcionales o no), sobre las que deciden cada uno de los Product Owner, que son propietarios de su respectiva parcela. El conflicto entre vecinos está servido, en especial a la hora de priorizar y resolver dependencias.

Confusión para el Scrum Master. El Scrum Master da servicio al Product Owner, al Equipo de Desarrollo y a la Organización. Pero, si tenemos a varios Product Owner, ¿a cuál de ellos asiste? El Scrum Master terminará facilitando espacios en los que el comité de producto se pueda poner de acuerdo, o mediando entre sus miembros, o entre estos y los desarrolladores, alimentando el despilfarro en el proceso de toma de decisiones.

…

La multiplicidad en el rol de Product Owner puede ser un impedimento claro a la productividad del Equipo Scrum que requerirá de la mano izquierda del buen Scrum Master. Algunas situaciones que explican la existencia de diversos Product Owner y posibles estrategias para abordarlas, son:

Nadie en la organización se atreve a designar a un único Product Owner, para no ofender a los demás involucrados en el producto. En este escenario convendría explicar al grupo las desventajas de carecer de un único Product Owner e, incluso, facilitar que sea este quien proponga o elija al “nuevo” y único Product Owner, que será representante de sus inquietudes.  

Nadie en el Equipo quiere asumir la responsabilidad, puesto que, si las cosas salen mal y las funcionalidades desarrolladas no tienen el retorno esperado, es más fácil que las “culpas” se diluyan entre los múltiples Product Owner. Comprendo este miedo, ya se lo decía el Tío Ben a Peter: “un gran poder conlleva una gran responsabilidad”. En esta situación habría que buscar a algún candidato que diera un paso al frente, procurando el apoyo y ayuda de los demás, singularmente del Scrum Master, en su desarrollo profesional como Propietario de Producto.

Hay un único Product Owner sobre el papel, si bien no tiene poder decisorio respecto al presupuesto y otros aspectos importantes sobre la estrategia de producto, de manera que al final management u otros directivos son los que se reservan el visto bueno sobre aquellos, siendo los verdaderos Product Owner de facto. Aquí solo cabe “evangilizar” e intentar que el Product Owner sea empoderado de verdad por el resto de la organización.

¿Qué piensas? ¿Tenéis a varios PO para el mismo producto? ¿Cómo habéis clarificado el rol del Propietario de Producto?

Imagen de portada: Foto de Hombre creado por kues1 – www.freepik.es