El Product Owner (PO) es ciertamente el más olvidado de los tres papeles del Scrum. Exactamente por esa razón, muchas organizaciones acaban por adoptar un camino aparentemente más fácil que el formar o contratar a un buen PO: le dan ese papel al propio cliente.
En función de esto, hemos escuchado mucho por ahí la propagación de la idea de que el mejor Product Owner es el cliente. Las principales justificaciones para esa afirmación incluyen el interés del cliente en el éxito del proyecto y su conocimiento sobre el negocio y sus propias necesidades.
¿Pero, será esta realmente una buena idea? Por el contrario. En muchas de las empresas que visitamos en nuestro día a día como asesores, encontramos proyectos en serios apuros, como consecuencia de una profunda falta de armonía entre el PO y el Equipo de Desarrollo. Estas empresas tienen justamente esa característica en común: el PO es el cliente. ¿Pero entonces, por qué tener un PO.-cliente es un problema?
1) El PO-cliente piensa en funcionalidades y no en problemas
El cliente raramente sabe lo que quiere: los clientes generalmente tienen dificultad para entender los propios problemas que hay que resolver y, como consecuencia de eso, no es nada raro que haya clientes que traigan soluciones «hechas» para problemas que ellos aún no han entendido. Un PO-cliente causa la siguiente disfunción en este caso: en vez de llevar problemas de negocio para resolverlos con el equipo, él lleva propuestas de soluciones hechas y que a final de cuentas no aportan mucho valor. El equipo puede hacer exactamente lo que el cliente pidió, pero como los problemas reales no se resuelven, ese cliente no queda satisfecho. ¿Quién no ha visto que esto suceda?
2) ¿Relación de equipo o de cliente-proveedor?
La relación del PO-cliente con el equipo es tensa: en el Scrum, PO, Scrum Master y Equipo de Desarrollo forman parte del Equipo de Scrum, que debe unirse para el proyecto. Solo que cuando el PO es el cliente, la relación deja de ser de equipo y pasa a ser de reclamar. En vez de colaborar con el equipo, el PO pasa a asumir la postura de gestor de proyectos, dado que él mismo es quien está «pagando» por el producto que se está construyendo.
Es bastante común en ese caso ver al PO usando la Daily Scrum como status report, la Retrospectiva para presionar al equipo y el Sprint Planning para empujar «solo una historia más». Además de eso, el PO-cliente, sufre una presión directa y constante de sus stakeholders por resultados. Así pues, en vez de proteger y colaborar con el equipo para organizar el trabajo, el PO-cliente quiere sacar el máximo rendimiento de su «proveedor». Un efecto directo de esto es que para ese PO-cliente todo es prioridad, comprometiendo una de las prácticas esenciales del Scrum: la priorización.
3) Ausencia frecuente
El PO-cliente raramente tiene disponibilidad para estar con el equipo, para resolver dudas y para colaborar para perfilar los ítems de trabajo. De hecho, cuando el PO es cliente, él probablemente está en otro lugar físico, lo que dificulta la comunicación, causando diversas disfunciones en el proyecto. Aliando esta cuestión al problema número 2, la vida del equipo se ve realmente complicada. Incluso cuando el proyecto es interno, el PO-cliente acaba teniendo otras actividades y prioridades, dejando el equipo muchas veces perdido.
Si tu equipo tiene un PO-cliente y tú estáis seguros de que no se enfrentan a esos tres problemas... excelente, pero que sepas que sois una excepción. En el caso general, en Knowledge21 defendemos que el mejor Product Owner NO es el cliente.
Es fundamental que la elección del Product Owner se haga con buen criterio, de manera que se trabaje con alguien que entienda de gestión ágil de productos, que tenga disponibilidad para el papel, que se sepa comunicar con el cliente y las partes de forma eficiente y que trabaje con el Equipo de Desarrollo en un régimen de colaboración continua. Solo así será posible formar un verdadero «Equipo de Scrum», según lo definen Jeff Sutherland y Ken Schwaber, los creadores del Scrum.
Si desea explorar este universo y profundizar en scrum le sugerimos que eche un vistazo a nuestros cursos:
● Certified ScrumMaster (CSM)
● Certified Scrum Product Owner (CSPO)
