miércoles, marzo 22, 2017

[Scrum] El Product Owner "NO" Necesariamente Escribe las Historias de Usuario o Ítems de Backlog

Hola a todos

Como lo había compartido en el post anterior (clic aquí) el Product Owner:

  • 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 lo que quiero resaltar en este post es lo que dice la guía(1) dice expresamente acerca del Product Backlog y la Lista de Elementos (o ítems) del Producto y como debería trabajar con ella el Product Owner


"El Dueño de Producto es la única persona responsable de gestionar la Lista del Producto (Product Backlog). La gestión de la Lista del Producto incluye: 

  • Expresar claramente los elementos de la Lista del Producto;
  • Ordenar los elementos en la Lista del Producto para alcanzar los objetivos y misiones de la mejor manera posible;
  • Optimizar el valor del trabajo que el Equipo de Desarrollo realiza;
  • Asegurar 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; y,
  • Asegurar que el Equipo de Desarrollo(2) entiende los elementos de la Lista del Producto al nivel necesario. 
El Dueño de Producto podría hacer el trabajo anterior o delegarlo en el Equipo de Desarrollo*. Sin embargo, en ambos casos el Dueño de Producto sigue siendo el responsable de dicho trabajo."

Cabe aclarar que he estado en proyectos donde las historias de usuario o ítems de backlog son escritas por otra persona diferente al Product Owner que no hace parte del Equipo Scrum(2), pero esto no exime que el Produt Owner siga al frente de este trabajo y de sus responsabilidades frente al Equipo y al Producto.



Por lo tanto, el Product Owner (de un producto de software), respecto a
  • los requerimientos en prosa,
  • historias de usuario,
  • casos de uso, 
  • o cualquier forma de expresar la Elementos del Producto o ítems de backlog
 podría de acuerdo a su contexto:
  • Elaborar la Lista de Elementos del Producto (Product Backlog) - esta es la práctica más común  -,
  • Delegarla o apoyarse en el equipo de desarrollo para su construcción, o
  • Delegarla en otros por fuera del equipo de desarrollo - esta es fruto de mi experiencia y de varios coaches en la industria, y nos ha sido bastante útil en contextos donde el Product Owner no tiene tiempo para explicitar reglas de negocio compleas -.
Cada Equipo Scrum debe experimentar y entender cual es la configuración que más le conviene.

Basados en la sorpresa anterior quisiera hacerte una pregunta:
¿Cuándo fue la última vez que leíste la guía de Scrum? 

Es bueno leerla cada cierto tiempo, pues en la medida que ganas conocimiento y destreza con Scrum la lees y la comprendes mejor.

Hasta acá esta pequeña nota curiosa.

Les recomiendo este otro post  Un vistazo a la guía de Scrum - Clic Aquí relacionado con la guía y sus apartes "ocultos a nuestro rapido mirar" de mi estimado amigo Lucho Salazar - @LuchoSalazarC traductor de la versión actual al español.

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. Recordemos que el Equipo Scrum esta constituido por: El Product Owner, El Equipo de Desarrollo y el Scrum Master.

domingo, marzo 12, 2017

[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?