Dueños de nada: los “Product Owners” de juguete y la agilidad de mentira

por Sergio Nouvel*

En Continuum hemos sido testigos de cómo muchas organizaciones intentan, con diferentes grados de éxito, adoptar una manera de trabajar ágil. Y también hemos visto cómo dichos intentos en muchos casos se deforman hasta transformar la “agilidad” en un esperpento — el Agile Industrial Complex— que no sólo falla en democratizar la toma de decisiones y el flujo de conocimiento, sino que termina incluso consolidando las estructuras jerárquicas y “waterfall” que supuestamente venía a derribar.

Una de las varias manifestaciones de la pseudoagilidad es el rol de Product Owner de juguete. Pero para entender por qué es “de juguete”, primero hace falta recordar qué es lo que distingue a los Product Owners de verdad.

Cuando un/a Product Owner es de verdad…

(y en este punto es bueno volver a la definición original de lo que supuestamente debe ser un/a Product Owner)

• Tiene la última palabra sobre el backlog, y por ende, sobre qué se desarrolla y qué no.
• Sus decisiones son respetadas en toda la organización; por mucho que escuche, coordine y necesite dejar contentos a otros stakeholders, dichos stakeholders no pueden anular sus decisiones.
• Es quien tiene más clara la visión del producto (condición necesaria para ser “owner”)
• Hay solo un@ por equipo.
• Está presente y trabaja directamente junto al equipo que desarrolla el producto, sin intermediarios.

Pero si intentas en serio satisfacer estas premisas, te das cuenta que tener Product Owners de verdad implica varios cambios de fondo:

• La capa del management no puede estar separada de quienes trabajan en el producto. Esto choca con el perfil corporativo de las “gerencias”, que tienen oficina separada, varios niveles de reporte por debajo a los que les delegan la ejecución, y que evitan mezclarse o meter las manos en la masa.
• Es decir, el management también está metido en la trinchera. Si toca contestar el teléfono para calmar a un cliente enojado, escribir FAQs de producto o hacer wireframes de las nuevas funcionalidades, se hace sin chistar. Nada que afecte la experiencia, la satisfacción de clientes o el valor agregado es trabajo indigno de un verdadero líder de producto.
• Por lo mismo, no tiene sentido una “Gerencia de Productos” que maneja portafolios de 10, 20 o 30 productos desde una perspectiva puramente comercial. El rol de “Gerente de Producto” que sólo se preocupa del P&L no tiene la visibilidad ni la dedicación ni el poder de decisión para ser un Product Owner.
• Esto a su vez significa que no pueden haber silos en la construcción y puesta en marcha del producto. Para que el Product Owner pueda tener bajo su alero a todas las funciones necesarias, dichas funciones no pueden responderle a líderes separados. No sacamos nada con tener una Product Owner si el equipo que desarrolla ese producto en realidad le responde a la gerencia de TI, o si la estrategia de comercialización está “tercerizada” a Marketing.
• Los objetivos/métricas/KPIs deben ser de producto, no de área. Tampoco sirve de mucho tener a los Product Owners “debajo” de gerencias funcionales, donde terminan respondiendo a objetivos y métricas de área y no de producto.
• No puedes tener “Product Owners Junior”. Lo lamento, jóvenes aspirantes a Product Owners, pero por la misma razón por la cual no existe un ‘VP Junior” o un “CEO Semi-Senior”, llegar a ser un Product Owner de verdad (que toma decisiones estratégicas sobre un producto, prioriza, alinea stakeholders y define objetivos) requiere años de circo. Y claro, a esa persona super-senior no le andas dictando instrucciones; la dejas liderar y decidir.

Y nos damos cuenta que “implementar Scrum” o “incorporar metodologías ágiles”, que parecía algo tan inofensivo, demanda transformaciones organizacionales mucho más profundas. La organización no estaba ni preparada ni dispuesta a realizar cambios tan serios, especialmente cuando todo lo que querían era que el equipo de desarrollo hiciera releases un poco más frecuentes.

Es como si quisiéramos correr un triatlón porque queremos lograr la buena salud y el físico de los triatletas, y contratamos a una personal trainer para que nos diga qué hace falta; pero cuando nos dice que hay que entrenar todos los días a las 6AM, acostarse a las 9PM, dejar el trago, el pan y las parrilladas, termináramos pidiéndole que nos invente una categoría especial de triatlón, más “realista”, consistente en andar 50m en bici, correr 30m y nadar ida y vuelta en una piscina.

Esa categoría “especial” de triatlón, que no demanda tantos esfuerzos, es el Agile Industrial Complex:

EMPRESA: ¿Me vas a decir que para poder incorporar agilidad tengo que empezar a mover mis divisiones, mis KPIs y mis gerencias? ¿Tienes idea de cuánto nos tomaría esto en tiempo y en esfuerzos para convencer a las cabezas? ¿Y todo esto para que los de TI puedan trabajar en sprints y hacer retrospectivas?

CONSULTOR/AGILE COACH: No, no, claro, tienes razón, siempre se pueden flexibilizar las cosas, empecemos con algo un poco más acotado para no revolver tanto el gallinero…

Y así nacen los Product Owners de juguete. Son fruto de la presión y el regateo de organizaciones a las que les gusta la idea de agilidad y los resultados que trae, pero no están dispuestas a hacer los esfuerzos necesarios.

Cuando un/a Product Owner es de juguete…

• El roadmap de desarrollo viene dictado desde “las áreas de negocio”. Otros stakeholders son los verdaderos “owners” del producto y se pelean, o se turnan, las decisiones sobre qué es lo que se desarrollará a continuación.
• El Product Owner es meramente un tomador de requerimientos — o antena repetidora — de los verdaderos owners, y se queda con la “tarea sucia” de aterrizar dichos requerimientos a descripciones funcionales y asegurarse que se ejecuten. En realidad sigue siendo un Project Manager a la antigua, sólo que ahora se trabaja bajo Scrum y en Scrum no existe la figura del Project Manager.
• Los plazos y prioridades han sido definidos en “planeamientos estratégicos” a los que ni la Product Owner ni el equipo de desarrollo fueron invitados. En la clásica división Taylor-fordiana de “los managers” y “los que ejecutan lo que dicen los managers”, el Product Owner pertenece definitivamente al segundo grupo.
• Los Product Owners están en la cuarta o quinta línea de reportería. Les precede la gerencia del área donde los tienen enterrados (usualmente el área de TI o su versión apta para millenials, la Fábrica Digital), gerencias de canal, de división, tal vez un VP y finalmente la Gerencia General.

Al final, el problema con los Product Owners de juguete es un caso específico del problema de fondo: la falta de empoderamiento y la poca disposición de las organizaciones de cultura vertical y autoritaria a ceder control. En estas organizaciones, “agilidad” es otro proceso vertical, donde sólo se imponen los aspectos externos (trabajo por sprints, retrospectivas, los nuevos roles, etc), pero se mantiene la división de labor, el trabajo por silos y la jerarquización de las decisiones.

A las personas en una organización ágil, por el contrario, se les entrega la capacidad de decidir sobre la mejor manera de realizar su propio trabajo, y el management, en lugar de ser un centro de control, encargos y órdenes, es el encargado de proveer contexto, alineamiento y de remover obstáculos.

Como le escuché a Daniel Mezick:

A menos que haya un cambio en la manera en la cual las decisiones se toman, no hay “Transformación Ágil” en lo absoluto.

Originalmente publicado en el Blog de Continuum.