Cómo arruinarle la vida a un Product Owner

Una de las funciones de un Scrum Master es mejorar la efectividad del Product Owner, ayudándole gestionar el Product Backlog, diseñar y comunicar el Product Goal, y facilitar que pueda maximizar el valor resultante del equipo.

Es mucho más divertido pensar en las maneras en las que un Scrum Master puede contribuir decididamente a su angustia y fracaso. Para participar en este juego hay que tener una regla clara, quedan prohibidas actividades ilegales como rajarle las ruedas del coche. Solo es posible ejecutar las acciones que no contravengan la cultura y valores de una típica empresa media.

Manipular la esencia de Scrum

Esta es la más obvia, basta con desacreditar el framework como proceso de transparencia, inspección y adaptación. 

• Promover que los stake holders puedan incluir nuevas tareas en el backlog sin hablar con el Product Owner.
• Indicar al Product Owner que debe establecer compromisos, hitos, dependencias y porcentajes de dedicación.
• Promover el aislamiento entre el equipo y áreas de arquitectura, calidad y seguridad, sin ninguna participación o representación directa en el equipo.
• Organizar reuniones importantes con stake holders en paralelo con las reuniones de Scrum.
• Impedir que el Product Owner pueda relacionarse directamente con los desarrolladores.

Trabajo en Equipo

¿Qué tal si creamos el equipo Scrum más disfuncional posible? Una colección de individuos asimilables a los improbables héroes de la película “12 del patíbulo”.

• Como Scrum Master, promueve la microgestión invasiva de los equipos.
• Mantén dos modelos de reviews, primero la que se celebraría solo con los desarrolladores, después otra con el Product Owner, donde te asegures de que el mensaje que recibe esté lo más cocinado posible.
• Respalda que el acceso a recursos y herramientas sea un proceso de burocracia descorazonador.
• Desincentiva el trabajo en equipo y la cooperación
• Obliga a estimar al equipo minuciosamente cada tarea en horas y critica su falta de resultados.
• Jamás des, pidas o alientes el feedback en el equipo.
• Cada solicitud de información, coordinación o ayuda por parte del Product Owner debe ir precedida de la convocatoria de una reunión.
• Impide que el equipo pueda hablar con stake holders directamente.

Métricas

Procura que sean lo más arbitrarias posibles y obliga al equipo a que se conviertan en escribientes  cuyo único objetivo sea rellenar prolijos reportes sin sentido.

• El equipo debe dedicarse a la redacción de informes inútiles y a rellenar información por triplicado.
• Promueve métricas extravagantes sin consenso en el equipo. Y cámbialas a menudo.
• Mide por medir, sin intención de avanzar en nada sensato.
• Demanda información de avance, pero desprecia lo que te digan.

Gestión del backlog

Todo sabotaje se basa en el engaño, que el backlog sea un interrogante, dentro de una incógnita envuelto en un misterio, parafraseando a W. Churchill.

• Facilita métodos contradictorios de priorizar el backlog
• Insiste en la necesidad de estar presente en cada refinamiento, pero preséntate solo si no estás hablando a escondidas con los stake holders
• Introduce nuevos elementos en el backlog por tu cuenta
• Intenta fomentar que se incluyan en el sprint backlog elementos que no contribuyan al Sprint Goal
• Exige una herramienta de ticketing para reportar bugs, con los consecuentes informes.

Conclusión

No es difícil sabotear el trabajo de un Product Owner porque, a menudo, las organizaciones permiten comportamientos como los descritos y desalientan un proceso de trabajo en Agile, por lo que estas prácticas podrían, más allá de la ironía, ser ejecutadas sin consecuencias. Es más, son tendencias casi naturales por lo que hay que esforzarse para luchar contra la corriente cuando lo sencillo y aceptado es, precisamente, dejarse llevar por ella.

La empresa típica es un organismo adaptado a estos comportamientos con silos, burocracia, desconfianza y jerarquía. Un Product Owner, cuando lo es, debe compatibilizar a menudo su trabajo con la dedicación  parcial a una jefatura de proyecto convencional, con reportes tradicionales y comunicación ascendente que lastra la capacidad para toma de decisiones y su propiedad sobre el producto que, con su rol, debería tener, a la par que maximiza el valor del trabajo que se entrega gracias a una relación abierta y leal con el Scrum Master.