Christine Hegarty de Scrum Inc. escribió esto hoy, justo antes de irse de vacaciones, por supuesto, así que lo publico por ella - jj
En Scrum Inc. hemos estado pensando mucho últimamente en el papel de Product Owner. Es algo con lo que muchas empresas tienen dificultades. En el mundo del Scrum se sabe que un buen Product Owner aumentará los ingresos al mantener los pedidos pendientes de modo que produzcamos antes los de mayor valor. Pero no siempre está claro cómo lo consiguen. Así que hemos decidido ofrecer las clases definitivas de Product Owner para ayudar a educar a los Product Owners sobre cómo pueden aumentar el valor empresarial y los ingresos. He estado trabajando con Catherine Louis, para lanzar este mes nuestra primera formación Product Owner en la zona de Boston. A principios de marzo, Jeff impartirá en Los Ángeles el curso Product Owner que ha desarrollado.
En la construcción de la clase, Catherine y yo hemos pasado mucho tiempo discutiendo la importancia del papel para una gran implementación Scrum. Los siguientes pasajes reflejan algunas de nuestras conversaciones sobre el papel de la Product Owner y pensé que serían interesantes para la comunidad para hablar.
P: ¿Qué es lo que hace que la función de Product Owner (PO) sea especialmente difícil?
R: El PO es la persona que puede responder a esta pregunta: "¿Es esto lo correcto para el cliente?". Es un trabajo difícil. El PO es alguien que se enfrenta al mercado: es capaz de elaborar y transmitir una visión. El PO es alguien muy cercano al cliente; el PO es el propietario de un Product Backlog y se centra en aportar valor (¡y "deleite"!) al cliente. También es responsable de mantener un Product Backlog ordenado, de manera que los elementos en la parte superior del backlog tengan el tamaño adecuado para que el equipo empiece a trabajar en ellos y estén listos para el primer Sprint.
Se trata de una función que no puede desempeñar solo: el PO se considera parte del equipo, y puede necesitar la ayuda de muchas partes interesadas para ordenar el backlog, asegurándose de que tenemos en cuenta el factor Pareto: es decir, los 20% superiores del backlog deben contener el valor más alto.P: ¿Cuáles son los principales escollos?
R: Por lo general, nos encontramos con nuevos PO que proceden de una cultura de desarrollo tradicional por lotes/fases, que trabajan con equipos más grandes y especializados, con un objetivo de perfección inicial y "aprobación de requisitos".
En el desarrollo tradicional/en cascada, se desalienta la rotación de requisitos y existe un plan perfecto y un objetivo asociado para entregar valor al final de una versión. No podemos descartar el enorme cambio cultural necesario para gestionar un Product Backlog emergente. Queremos ver un flujo de valor, colaboración con el cliente, equipos autoorganizados más pequeños e integrados, con valor impulsado de forma incremental.
Se trata de un cambio cultural que nos hace pasar de la elaboración de un plan a prueba de fallos que queremos ejecutar y entregar al final de una versión, a un marco "a prueba de fallos" en el que aprendemos y mejoramos en cada iteración. Hacer este cambio cultural nos permite convertir este cambio de requisitos esperado en nuestra ventaja competitiva.
P: Así que este cambio cultural implica a mucha más gente que el equipo Scrum...
R: El PO es clave para la transición a Agile, pero como se trata de un cambio de mentalidad para toda la organización, y muchos jugadores necesitan estar involucrados desde el principio, roles que normalmente no se consideran roles Scrum. No hay que olvidar, en particular, las funciones de apoyo.
Tomemos el ejemplo de RRHH. Ahora formamos equipos autoorganizados, automotivados y autogestionados, y la estructura de recompensas debe actualizarse para reconocer y recompensar el rendimiento del equipo. Imagínese lo que podría ocurrir si esto no cambia. Pensemos en la gestión de proyectos: Ahora estamos formados en estos mismos equipos, pero hay un Jefe de Proyecto que se responsabiliza de los resultados y pide informes de situación diarios en reuniones semanales.
Al tomar la decisión de pasar del desarrollo de productos tradicional/en cascada al Lean/Agile/Scrum, recomiendo tener en cuenta a todos los implicados, desde la decisión inicial hasta la entrega de valor al cliente. No hay que olvidar el cuadro de roles de apoyo que necesitan estar ahí como Servant Leaders para eliminar impedimentos, despejar el camino y apoyar el flujo de valor (los entregables) al cliente. Todo el mundo tiene que estar de acuerdo: En cada decisión que tomen, cada día, pregúntense: "¿Es esto lo correcto para el cliente?". Si la respuesta es "no", no lo hagáis. Si la respuesta es "sí", di "¡por supuesto que sí!" y hazlo de inmediato. Si la respuesta es "no lo sé", tomad la decisión en el Product Owner.
El Curso Product Owner de Catherine en Boston se celebrará los días 14 y 15 de febrero en Boston. El curso Product Owner de Jeff Sutherland, para los que estéis en la costa oeste, tendrá lugar en Los Ángeles los días 1 y 2 de marzo.
Spanish 
English 
French