[Scrum] El Valioso "NO" del Product Owner

Hola a todos

Según la Guía de Scrum(1), el Dueño de Producto o Product Owner (PO). lo define como:

• El responsable de maximizar el valor del producto y el trabajo del Equipo de Desarrollo (2)
• Es la única persona responsable de gestionar la Lista del Producto (Product Backlog)
• Expresa claramente los elementos de la Lista del Producto;
• Ordena los elementos en la Lista del Producto para alcanzar los objetivos y misiones de la mejor manera posible;
• Optimiza el valor del trabajo que el Equipo de Desarrollo realiza;
• Asegura que la Lista del Producto es visible, transparente y clara para todos y que muestra aquello en lo que el equipo trabajará a continuación;
• Asegura que el Equipo de Desarrollo entiende los elementos de la Lista del Producto al nivel necesario.
• Es una única persona, no un comité. El Dueño de Producto podría representar los deseos de un comité en la Lista del Producto, pero aquellos que quieran cambiarla prioridad de un elemento de la Lista deben hacerlo a través del Dueño de Producto.
• Para que  pueda hacer bien su trabajo, toda la organización debe respetar sus decisiones
• Durante el Sprint el alcance puede clarificarse y renegociarse entre el Dueño de Producto y el Equipo de Desarrollo a medida que se va aprendiendo más.
• Solo el Dueño de Producto tiene la autoridad para cancelar el Sprint
• El Dueño de Producto hace seguimiento de este trabajo restante total al menos en cada revisión de Sprint.
• Decide si libera o no el incremento

Lo anterior podríamos parafrasearlo un poco como

• Es alguien con empoderamiento y capacidad de decisión sobre el producto
• Es el responsable del  ROI -return on investment-
• Es voz del cliente ante el equipo
• Define, refina y prioriza el Product Backlog
• Esta disponible para el equipo
• Hace seguimiento del avance y la construcción del producto
• Decide cuando cancelar el sprint 
• Decide cuando salir a producción.

Pero este post se enfoca en que le corresponde Product Owner respecto al producto y al alcance decir

• qué se hace 
• y qué se posterga para próximas versiones (un NO PARCIAL, o sea hoy te digo que NO, mañana tal vez lo hagamos)
• y qué definitivamente NO SE HACE

Esto se alinea perfectamente con el décimo principio ágil (3) en donde se refleja el pensamiento Lean:

la simplicidad o el arte de maximizar la cantidad de trabajo no realizado es esencial

Decifrando este juego de palabras podemos parafrasearlo diciendo para el mundo del software

Nos esforzaremos al máximo en NO crear ni software, ni alcance, ni trabajo de desperdicio o que no sea necesario (o hacer algo que terminará siendo inútil)

Por lo tanto, es clave que el Product Owner aprenda de a DECIR NO, y al negociar con sus interesados para ciertas funcionalidades les dirá:

• eso NO se puede hacer aún, 
• es que necesitamos generar valor con lo mínimo posible
• eso va para otra versión o release
• eso aun NO tiene prioridad
• eso NO agrega valor
• eso definitivamente NO se hará

Es decir la misión del PO es mantener el Backlog de cada release lo mas pequeño posible de forma que se genere valor con la menor cantidad de alcance requerido y de esa manera se alcance prontamente el máximo ROI.

Cerrando

Un buen PO sabe:

• Que cada sprint tiene software funcionando y potencialmente liberable (punto a favor del PO y de la organización)
• Pero que si se permite decir que SÍ todas las funcionalidades que se le ocurran tanto a el como al negocio, NUNCA va a salir a producción, pues a mayor alcance más cantidad de sprints se van a requerir para salir a producción, y a mayor tiempo menor ROI (un peligroso circulo vicioso)
• Que si se demora mucho en salir a producción el impacto en el ROI y en el negocio puede ser nefasto dado lo disruptivo y cambiante del entorno actual.

Recuerdo mucho una frase que le escuche a Ángel Medinilla.

NUESTRO TRABAJO NO ES HACER SOFTWARE, ES HACER LA MENOR CANTIDAD DE SOFTWARE POSIBLE QUE MAXIMICE EL VALOR DE NEGOCIO DE NUESTROS CLIENTES.

Por lo tanto cuando vayas a escoger a un PO, cerciórate de que el o ella tienen claro los siguientes aspectos respecto al alcance:

1. Que conoce que problema de negocio está resolviendo
2. Que tiene claro cual es la solución que debe entregar al negocio para resolver ese problema
3. Que dice NO, pues esta interesad@ en salir a producción lo antes posible
4. Que comprende que el NO es de las mejores formas de controlar el ROI

Bienvenido el Feeback

Saludos ágiles

Jorge Abad

Notas, Aclaraciones, Comentarios y Referencias

1. Guía de Scrum - clic aquí para descargarla. De igual forma les recomiendo leerla encontrarán elementos que de seguro estaban ocultos a su primer entendimiento (como me pasó a mí).
2. El nombre del Equipo de Desarrollo crea por lo general confusión en la industria del software, se debería llamar Equipo Solucionador
3. Principios ágiles - http://agilemanifesto.org/iso/es/principles.html
4. Este post está altamente relacionado con: La Ilusión del Control o ¿Cómo Hago para Controlar un Proyecto Ágil?