Proxy Product Owner: ¿porque? ¿como alcanzar un autentico PO?

¿Qué es un Proxy PO?

Un Proxy Product Owner (Proxy en adelante) es un rol que actúa como intermediario entre las personas que toman las decisiones sobre el producto y el equipo de desarrollo. Adopta parte de las responsabilidades que habitualmente desempeña un Product Owner (PO en adelante) como:

• Recoger las necesidades de los clientes
• Estructurar y priorizar el Backlog de Producto
• Negociar con el equipo la realización del Backlog
• Validar cuando el producto está listo para ser entregado a los clientes

Aún así, el Proxy es una versión incompleta de un PO auténtico, hecho que le resta mucha efectividad y dificulta la misión del PO, maximizar el valor sobre el producto. Las principales carencias de un Proxy suelen ser:

• No es el dueño del producto, por lo que no toma las decisiones fundamentales ni suele ser responsable de su resultado.
• No controla el presupuesto.
• A veces no define la visión ni la estrategia del producto.
• No tiene la última palabra sobre los ítems que forman parte del producto.

Así pues, es una mejora respecto a no tener un PO, pero tener este rol conduce a resultados muy mejorables respecto al valor del producto, especialmente en organizaciones complejas con múltiples actores interesados.

Las organizaciones funcionales y el Proxy PO

Érase una vez una organización que agrupaba a sus miembros según el tipo de trabajo que realizan y sus capacidades. Estas agrupaciones reciben nombres como áreas de negocio, los departamentos o grupos de trabajo, y es el tipo de organización de las empresas más frecuente, y de largo, siendo una herencia del Management Científico, o Taylorismo.

Una organización funcional (departamental) suele tener a sus miembros divididos entre «Negocio» e «Informática», y dentro de estas áreas existen otros departamentos, p.e. márketing/RR.HH/ventas y desarrollo/sistemas/calidad respectivamente. En el gobierno IT tradicional, suele ser un responsable de cliente (Business Relationship Manager o Business Partner en inglés) quien gestiona la demanda de necesidades del negocio que debe realizar «Informática», y un jefe de proyecto quien lidera la realización de estas demandas.

Cuando se trata de adoptar Scrum, si no se tiene un buen entendimiento del rol de PO, suele identificarse este rol como un miembro de informática que debe continuar la interlocución entre el «Negocio» y el equipo de desarrollo. Además, se piensa frecuentemente que debe ocuparse de analizar, estructurar (e incluso definir las pruebas de aceptación) de las demandas. Esto encaja muy bien con el rol de jefe de proyecto, que además no suele verse a si mismo como Developer o Scrum Master, por lo que frecuentemente adoptan este rol de Proxy. Por otro lado, si se le plantea a los responsables de negocio, que serían los PO ideales, que deben estar dedicados a actividades funcionales como la gestión detallada del backlog y los requisitos, es lógico que piensen que supone un volumen de trabajo que hace incompatible ser el PO con sus actividades actuales. Así pues, tenemos todos los ingredientes para la receta «Proxy Product Owner».

Propuestas para conseguir un auténtico PO

En primer lugar, es necesario que las organizaciones y los Scrum Master (o Agile Coaches) que las asesoran, entiendan bien el rol de Product Owner. Además, y lo más difícil, deben entender el severo rediseño organizativo que esto supone, integrando en Equipos Scrum autónomos y autosuficientes a personas de «Negocio» (p.e. el PO) y otros roles desperdigados entre diferentes grupos de IT (p.e. desarrolladores, testers, analistas, etc.). Sin esto, la adopción de Scrum comienza con mal pie.

En segundo lugar, es importante que se entienda que un Development Team auténtico debe ser autosuficiente, y por ello se le puede delegar perfectamente las actividades de más detalle de la gestión del backlog, como su estructuración, definición de los ítems e incluso la definición de criterios de aceptación. Esto debe hacerse basándose en la transparencia, la confianza y el principo que el Product Owner debe estar informado y tomar las decisiones más importantes que afecten al valor del producto.

En tercer y último lugar, es necesario encontrar un buen encaje a los jefes de proyecto tradicionales donde éstos se encuentren cómodos. Si estos son expertos en gestión de equipo, quien mejor que ellos para entrar dentro del Development Team y ayudar a los demás miembros a desarrollar esta capacidad de gestión, teniendo claro desde el primer momento que debe fomentarse la autoorganización y que su rol no es el de líder de equipo.