Archivo por meses: julio 2009

Rol y perfil del Product Owner

Product Owner, ,

A raíz de la entrada anterior: Sprint heroico – Planificación y Task Board me dejaron comentarios y enviaron un mail Victor y Ana:

Hola Fernando, en la empresa para la que trabajamos con Victor, estamos investigando sobre Scrum porque queremos implementar esta metodología.
Tenemos una duda respecto al rol de Product Owner, ese rol lo cubre un empleado del Cliente? y Cuál es el perfil de la persona que cumple este rol?
Desde ya agradecemos la infomación que nos puedas facilitar
Saludos

Primero que nada, veo que la empresa está muy interesada en implementar Scrum, ¡felicitaciones y bienvenidos al mundo ágil! Gracias por acudir al blog para despejar sus dudas, les recomiendo que acudan también a Foro agiles, la comunidad hispanohablante de metodologías ágiles de desarrollo.

Ya que me estaba extendiendo mucho en la respuesta en los comentarios, lo convertí en una entrada nueva, aprovechando que a alguien más le pueda servir. A continuación mi humilde aporte, espero lograr responder lo mejor posible desde mi conocimiento y experiencia personal:

El Product Owner

El rol del Product Owner, puede venir de parte del cliente o dentro de la empresa misma, depende. Generalmente no se aconseja que el Product Owner sea parte también del equipo de desarrollo, o el Scrum Master mismo, sus intereses se pueden ver enfrentados, pero esto puede variar según el caso. Por defecto, probablemente venga de parte del cliente.

Como Product Owner representa al cliente, y es el encargado de negociar con el equipo, con el Scrum Master por medio como facilitador, la prioridad del trabajo a realizar. Esto desde una perspectiva del retorno de inversión para el negocio.

Una de las analogías que nos comentaron durante el curso de CSM, es que el Product Owner sería como un embudo. En un extremo están los «stakeholders» o interesados: director de Marketing, de Finanzas, otros directivos, etc. El P.O. debe juntar y filtrar las necesidades de cada uno y hacérselas llegar al equipo, priorizando según el retorno de inversión.

En mi caso en particular, estoy en un desarrollo propio para la empresa donde trabajo. El rol de Product Owner es asumido por el jefe, ya que es quien tiene la visión general del producto.

Según la definición de la Scrum Alliance de los roles en Scrum, los roles del Product Owner son:

  • Definir las características del producto;
  • Decidir sobre las fechas de lanzamiento y contenido;
  • Ser responsable de la rentabilidad del producto (ROI);
  • Priorizar las características según el valor de mercado;
  • Ajustar las características y prioridades por iteración, según sea necesario; y
  • Aceptar o rechazar resultados del trabajo.

Debe estar presente entonces en las reuniones de planificación de Sprint, para priorizar las tareas del backlog. También es el encargado de llevar a cabo el review del producto, para aceptar o rechazar los resultados, según el concepto de listo. Viendo todos estos datos, espero estén en condiciones ya de responder qué perfil debe tener la persona a cumplir con este rol, y quién sería la más adecuada.

Se puede obtener entrenamiento para certificarse como Scrum Product Owner de la Scrum Alliance.

Espero haber aclarado el panorama, aunque agradezco cualquier aporte de lectores con más experiencia en el asunto. Desde ya les deseo mucha suerte con la implementación de Scrum, y espero compartan cualquier experiencia, duda y demás tanto con este blog, como la comunidad hispana de metodologías ágiles que pueden encontrar en: Foro agiles

Actualización:

Desde Foro ágiles justamente, tengo más material para comentar respecto al rol del Product Owner. Xavier Quesada Allue respondió sobre este post, y agregó la siguiente información:

Otra página similar para tener en cuenta es la del sitio Proyectos Agiles de Xavi Albaladejo:
http://www.proyectosagiles.org/cliente-product-owner

Recordemos que el Product Owner o bien es el Ciente, o bien representa al Cliente. En este ultimo caso a veces se lo llama ‘Proxy’ Product Owner para distinguirlo del Cliente real. Ser PO de un proyecto mediano/grande suele ser una dedicación full time, o como mínimo requiere tiempo de respuesta rápida durante el Sprint si el equipo te necesita. Muchas veces el Cliente o Senior Manager no está disponible cuando lo necesitamos y por eso hacen muy malos Product Owners.

Product Owner Anti-Patterns
Tenes un mal Product Owner si…

  • El PO no viene a la demo
  • El PO no viene al sprint planning
  • El PO no puede explicar bien las historias durante Sprint Planning
  • El PO no está disponible cuando el equipo lo necesita durante el Sprint
  • El PO no está manteniendo el Product Backlog actualizado y en perfecto estado
  • El PO no está autorizado a priorizar el backlog, y tiene que andar validando todo lo que hace con el cliente o un gerente a nivel micro-management
  • El PO no tiene autoridad suficiente como para negociar entre todos los stakeholders, en el caso de hacer de ‘embudo’

En cualquier caso en el que el PO no esté en total control del Product Backlog, o no lo esté manteniendo por falta de tiempo o ganas, o no pueda explicar lo que está pidiendo, o que el equipo sienta que está teniendo que tomar decisiones que debería tomar el PO… tenes un mal Product Owner.

¡Muchas gracias Xavier por la información!

Sprint heroico – Planificación y Task Board

Scrum, ,
Task Board Scrum
Task Board Scrum

Como comenté en una entrada anterior (Implementando Scrum: Cómo empezamos), nuestro Product Owner se encontraba hasta hace poco fuera del país. Recientemente volvió a trabajar desde nuestra oficina, lo que nos permitió realizar una primera planificación de Sprint con el Product Owner presente. Las ventajas de contar con su presencia saltaron a la vista, ya que la priorización y negociación de tareas se hizo de una forma muy fluída, así como también se despejaron algunas dudas instantáneamente durante la planificación misma.

Además de eso, este Sprint tuvo varias características que lo hicieron único respecto a los anteriores:

  • La planificación se realizó fuera de horario. Debido a complicaciones varias del lunes, nos juntamos en la tarde, mientras que los Sprints anteriores se hacían lo más temprano posible. Esto no cumple con el espíritu de Scrum en cuanto al enfoque de time-box, mantener el ritmo, la disciplina y compromiso. Sin embargo, hay que tomar lo que sirve, y en este caso nos sirvió hacerla tarde.
  • El equipo constaba de 7 programadores. Ahora se sumaron a la planificación los 2 diseñadores gráficos del proyecto. Estamos en etapa de maquetación e integración del código PHP con el diseño, por lo que volvimos a juntar a todos los responsables del desarrollo del proyecto. Además, el Scrum Master (yo) abandona temporalmente su puesto de director en el equipo, por razones planteadas en el siguiente punto, y se integra como un programador más.
  • Nos encontramos muy cerca a una fecha de entrega, dos semanas. Teníamos varias características del producto definidas para esta entrega, que veíamos difícil de implementar. Por esto, hicimos una planificación bastante profunda, para tratar de meter todas las tareas importantes en un Sprint que por primera vez contaría con dos semanas de duración. Esta era la idea inicial, pero al estar empezando con Scrum, decidimos que una semana permitiría estimaciones más precisas. Desde mi punto de vista, el equipo ya se encuentra en condiciones de planificar los Sprints a dos semanas. Además la presencia del Product Owner facilita las cosas.
  • Implementamos el Scrum Task Board. Como comenté, usábamos el pizarrón como Task Board. Ahora usamos un espejo que hay en la oficina de desarrollo. Ya lo habíamos usado en nuestra primer implementación fallida de Scrum. Usamos los post-it amarillos para mostrar las tareas que fueron estimadas y asignadas durante el planning del Sprint. Los post-it naranja son tareas nuevas que fueron surgiendo, y trataremos de mechar con otras, o realizar si da el tiempo. También agregamos post-it verdes, que son tareas opcionales, para tiempo que sobre. Todos los movimientos en el Task Board se realizan únicamente en el Daily Meeting, de manera que todo el equipo esté al tanto de lo que sucede, y por el compromiso que implica llevar una tarea a la columna de «finalizado»
  • En lo personal, es un Sprint más «feliz», ya que dejé mi puesto de Project Manager y Director, para meterme de lleno en el código. Así que ahora estoy cumpliendo el rol de Scrum Master así como de desarrollador del equipo.

Lo interesante de la planificación fueron las etapas . En un principio se sentía mucha tensión, presión, nervios, miedo, stress… Pero la presencia del Product Owner (también jefe del equipo), se hizo notar, y las cosas llegaron a una buena conclusión. Demoramos algunas horas en definirlo, pero llegamos a una planificación completa de las dos semanas siguientes de trabajo. Esto fue el lunes de la semana pasada, y a más de una semana, puedo decir que ha resultado. Hoy el Task Board tiene mucho más tareas naranjas agregadas, así como algunas amarillas más (mayor granulación de algunas tareas), pero la columna de «terminado» está colmada.

Un Sprint muy especial, por todo lo comentado. En teoría, tendríamos un review y reflexión de este «Sprint heróico» el día 3 de agosto, así que ya comentaré cómo estuvo eso. Mientras tanto, ¡a programar!