Introducción
El rol del Product Owner es de alto valor estratégico pues traza la dirección en la cual ira un producto construido por un equipo de desarrollo. Muchas veces este rol es confundido por el de alguien que simplemente escribe requerimientos detallados y se los pasa al equipo para que este los implemente sin desviarse.
En otros casos el rol del Product Owner es mimetizado con el de un Project Manager que hace que el cronograma se cumpla y se entregue un producto que puede que tenga o no calidad o peor aún, que puede o no que vaya a resolver alguna necesidad de clientes reales.
Desde los inicios del movimiento eXtremme Programming se vio la necesidad de tener como parte de un equipo a alguien que tenga conocimiento del negocio e interactúe efectivamente con los stakeholders [Beck99]. Scrum enfatiza más esta figura al crear un rol e introducir el término “Product Owner” que implica que de hecho la persona en este rol tiene poder de decisión sobre el producto.
Es muy común escuchar que la herramienta principal del Product Owner es el Producto Backlog, lo cual es una verdad a medias pues existen muchas otras herramientas y conocimiento de otras disciplinas que pueden ayudar a que el Product Owner se desempeñe mejor en su rol. Es labor del ScrumMaster conocer estas herramientas y técnicas para poder pasárselas al Producto Owner a través de coaching y mentoría.
Pasos para Descubrir el Producto y el Product Backlog
Antes de pensar en crear un Product Backlog existen ciertos pasos que muchas veces por ser ignorados repercuten a la larga en un producto que no resuelve problemas o los resuelve de manera muy costosa.
El primer paso fundamental es entender el sistema dentro del cual habitará el producto; es decir no solo pensar en un producto como tal sino enfocarlo desde una perspectiva sistemática. Es vital entender que no solamente se trata de darle al cliente lo que pide sino ver cuáles son las variables que se verán afectadas por este curso de acción [Larman17].
El segundo paso a partir de entender el sistema consiste en diagnosticar cuál es el problema que se tratará de resolver con el producto que se construirá. Desde una perspectiva Lean el producto no resuelve el problema, lo mitiga y habrá que evolucionar el producto buscando cada vez mejores mitigaciones.
El tercer paso consiste en evaluar con el equipo de desarrollo la factibilidad del producto, desde luego esta validación debe no sólo incluir la perspectiva técnica sino también financiera, legal, de mercadeo, etc. Aquí aparece una trampa muy frecuente que consiste en invertir mucho tiempo prototipando y explorando antes de proseguir con la construcción del producto real; precisamente la agilidad se trata de minimizar este tiempo y validar dentro del gemba.
El cuarto paso consiste en descubrir qué tendrá el producto, es decir, qué características (features) serán incluidas, para qué usuarios, y cómo estas se beneficiarán usándolas [Watts17]. Las técnicas de Juegos de Innovación (Innovation Games) descritas por Hohmann [Hohmann07] han probado en la práctica ser de gran ayuda a la hora de entender y descubrir el producto. Una recomendación importante es utilizarlas dentro de un workshop presencial en el cual se tenga un grupo de trabajo compuesto por stakeholders reales, el Product Owner, algún miembro del equipo de desarrollo y el ScrumMaster como facilitador.
El quinto paso consiste en poner todas las ideas juntas en un Product Canvas [Pichler10] en el cual resulta también muy conveniente comenzar a bosquejar cómo lucirá la interfaz del producto.
El sexto paso implica descubrir cuáles serán los PBI que se incluirán en el backlog y tratar de ordenarlos, User Story Mapping [Patton14] es la técnica mejor equipada para esta tarea.
El séptimo y a veces controversial paso es estimar los PBI del Product Backlog. Este paso es controversial por lo que la estimación implica. Hay que recordar que las estimaciones son solamente eso estimaciones y no compromisos y que además serán reestimadas constantemente a medida que avancemos en el desarrollo del producto. De hecho, una estimación no es más que un marcador de posición para recordar que después hay que seguir discutiendo y refinando el entendimiento respecto al PBI.
El octavo y último paso consiste en trazar la estrategia del producto [Pichler16], la estrategia tiene un componente importante que es el Release Plan que a su vez incluye la definición de frecuencia de los releases. El Release Plan debe incluir también la alineación del desarrollo de software con las áreas circundantes, por ejemplo, con un plan de marketing, aprovisionamiento de infraestructura, redacción de contratos, etc.
Finalmente, cualquier que sea el producto descubierto, el backlog creado y el Release Plan escrito hay que siempre recordar que no es definitivo, que por el contrario debe e irá cambiando y ese es precisamente el punto de la agilidad.
Ver el Backlog Como Sólo una Lista
Una de las grandes confusiones que he observado en muchas empresas y equipos es la sobre-complejización del concepto de backlog. Herramientas online para Agile Lifecycle Management añaden complejidad adicional con terminología, interface y opciones que hay que aprender para poder usar la herramienta.
Algunos Project Managers también contribuyen a la confusión pensando que el backlog es una especie de gráfica Gantt unidimensional y en el cual hay que aplicar un proceso de control de cambios para realizar cualquier movimiento.
Una simplificación de este concepto viene de la mano del trabajo de Richardson [Richardson05] que desde el pragmatismo nos invita a pensar en el backlog (cualquiera que sea este) como en una lista de cosas por hacer o cosas por comprar en un supermercado.
Si seguimos el enfoque anterior una lista debe tener las siguientes características:
- Públicamente visible y disponible, es decir no hay una lista secreta del Product Owner y otra del equipo sino una sola lista que todo el mundo puede mirar y cambiar
- Priorizada, pero utilizando varios criterios de priorización, no solamente la estimación de cuánto durará en implementar un ítem
- En una línea de tiempo que implica que debe haber un horizonte cercano que indica cuándo deberían terminarse los ítems de la lista, si el tiempo se agota antes de completar todos los ítems pues no se implementan algunos de baja prioridad
- Activa y no estática, es decir que va cambiando con el tiempo en función del aprendizaje del equipo de desarrollo, del mismo Product Owner y de los stakeholders
- Medible que implica que se puede determinar en un criterio binario cuando algo se ha completado o no
- Con un objetivo claro que quiere decir que estamos implementando ítems de un producto, no ítems por si acaso que luego de implementados se archivarán para no usarse nunca
Herramientas Para Mantener un Product Backlog
En el mercado actual de herramientas online existe una gran variedad que van desde las que hacen una sola cosa hasta las que son partes de un ecosistema y posibilitan la trazabilidad entre herramientas.
Un denominador común que he podido observar en estas herramientas es que están orientadas a generar reportes para la alta gerencia, es decir agregan información y permiten ver quién movió qué tarjeta a qué estado y cosas por el estilo.
La otra característica dominante es que estas herramientas no permiten gran experimentación ya que vienen con opciones y terminología definida que apunta a la estandarización de procesos. Recuérdese aquí que bajo un enfoque Lean nosotros queremos flexibilidad en las herramientas que nos permita kaizen de mejora continua.
Ante este panorama una alternativa muy simple es usar hojas de cálculo compartidas (Google Spreadsheets) para mantener el backlog y un wiki para detallar cualquier PBI. Aunque esto parezca poco tecnológico respeta el principio de simplicidad en las herramientas, economiza costos, promueve la experimentación, reduce la curva de aprendizaje y facilita la comunicación.
No es solamente mi experiencia personal la que permite decir que equipos de desarrollo con herramientas simples como las descritas pueden trabajar efectivamente, sino que es un hecho observado a gran escala tal como documenta Larman [Larman10].
Tratar de Incluir al Product Owners en el Equipo
Idealmente el Product Owner debería ser parte integral y a tiempo completo del equipo de desarrollo, pero la figura del outsourcing muchas veces distorsiona esta condición ideal.
Si el Product Owner pertenece a la compañía que contrata los servicios de outsourcing y además vive en otro país es muy recomendable que viaje por lo menos una vez al mes para pasar tiempo con el/los equipos con los que trabaja remotamente.
Tener la presencia física del Product Owner resulta muy valioso no a la mitad de un Sprint porque eso provocaría interrupciones sino al final para el Sprint Review, el Sprint Retrospective y el Sprint Planning que vendría al día siguiente.
Si el Product Owner participa en las retrospectivas podrá escuchar de primera mano los problemas e ineficiencias que el equipo mencione además de poder aportar su visión desde afuera.
De igual manera el estar presente le permitirá escuchar cómo su rol es percibido por el equipo y las ineficiencias que el equipo puede observar en su accionar.
Un tercer beneficio es que la presencia del Product Owner añade una visión más conectada al negocio a la hora de proponer kaizens de solución de problemas o kaizens de mejora continua.
Conclusiones
Los Product Owners tiene el potencial de redefinir el panorama de las industrias en las que trabajan a través de la creación de productos innovadores pero tal cosa no ocurrirá si carecen de una mentalidad ágil y emprendedora reforzada por un sólido conocimiento del negocio y de la teoría, técnicas y herramientas propias de su artesanía.
La práctica es esencial y considero más enriquecedor que un Product Owner cree varios productos en un horizonte de digamos cinco años a que trabaje en solamente mantener un sistema operando por el mismo periodo de tiempo.
Finalmente quiero enfatizar una vez más un concepto fundamental: el rol del Product Owner y de hecho la idea detrás de un Equipo Scrum, es tener un equipo altamente efectivo y motivado que construya un producto que impacte en el mercado.
Bibliografia
Beck99 Beck K., 1999. Extreme Programming Explained: Embrace Change, Addison-Wesley
Larman17 Larman C., Vodde B., 2017. Large-Scale Scrum More with LeSS, Addison-Wesley
Watts17 Watts G., 2017. Product Mastery: From Good to Great Product Ownership, Inspect & Adapt Ltd
Hohman07 Hohman L., 2007. Innovation Games: Creating Breakthrough Products Through Collaborative Play, Addison-Wesley Professional
Pichler10 Pichler R., 2010. Agile Product Management with Scrum: Creating Products that Customers Love, Addison-Wesley Professional
Patton14 Patton J., 2014. User Story Mapping: Discover the Whole Story, Build the Right Product, O’Reilly Media
Pichler16 Pichler R., 2016. Strategize: Product Strategy and Product Roadmap Practices for the Digital Age, Pichler Consulting
Richardson05 Richardson J., Gwaltney W., 2005. Ship it!: A Practical Guide to Successful Software Projects, Pragmatic Bookshelf
Larman10 Larman C., Vodde B., 2010. Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum, Addison-Wesley Professional
