Tag: Product Owner

Introducción

El Product Backlog es uno de los artefactos con los cuales trabaja el Product Owner pero no es de propiedad exclusivamente suya, de hecho cualquier miembro del Scrum Team debe tener acceso al Product Backlog pero el Product Owner es quien decide el orden de los items.

Si el backlog fuese secreto provocaría poca visibilidad por parte del Equipo de Desarrollo y lo que es peor no permitiría que todos los miembros del equipo contribuyan con ideas y opiniones recortando así la creatividad.

El Product Backlog, al igual que los demás artefactos, es propiedad del Scrum Team y para que éste lo pueda usar en su trabajo diario. Al ser un artefacto ligado con la táctica es necesario que todos en el equipo puedan verlo y sentirlo presente en el día a día.

Además de lo anterior el Product Backlog tiene otras características, tales como: ser finito, contener items que son diferentes entre sí en valor y nivel de especificación, ser dinámico, y ser alcanzable en un horizonte de tiempo corto.

Como tal el trabajo del Product Owner consiste en tener el Product Backlog ordenado incorporando el conocimiento más actual que viene del aprendizaje y la retroalimentación de los clientes. El trabajo del Scrum Mater será guiar al Product Owner y los desarrolladores para que el Product Backlog mantenga las características descritas en el párrafo anterior.

Producción versus Resultado

La producción es medible y observable, aun cuando el software es un elemento abstracto, pues esta ligada a la cantidad de algo que se produjo dentro de un Sprint. 

Por ejemplo podemos decir que en un Sprint cualquiera se implementaron X cantidad de items, se escribieron Y lineas de código, se escribieron Z pruebas automatizadas, o el porcentaje de cobertura de pruebas es del W%.

El resultado es más intangible y subjetivo pero aun así puede ser apreciado aunque no necesariamente se mida numéricamente. 

El mejor ejemplo de resultado es la percepción de si el equipo Scrum está construyendo el producto correcto que resolverá los problemas y necesidades de los clientes. Ligado a lo anterior está la percepción de los clientes que gustan del producto y lo compraran cuando este terminado.

Si bien es cierto que no se puede llegar al resultado sin la producción es económicamente mas conveniente tratar de alcanzar el mayor resultado con la menor cantidad de producción posible. La clave para esto es que el Product Owner pueda identificar que items del Product Backlog implementar primero. 

Existen varios atributos que pueden tener los items del Product Backlog que permiten ver si contribuyen mayor resultado, por ejemplo:

• items que tienen un componente visual, es decir que los usuarios finales pueden ver en el producto e interactuar con el
• items que al verlos en el producto los usuarios finales los conectan inmediatamente con una posible solución a un problema o necesidad que ellos tienen
• items que un gran número de usuarios potencialmente utilizaran

Demás esta decir que cualquier item que se espere que produzca resultados positivos tiene que tener insertada la calidad. 

Definiendo Valor

El valor de los items puede definirse desde diferentes perspectivas pero es importante no perder de vista que siempre debe estar conectado a algo que los clientes puedan ver y pagar por él.

Muchas veces los desarrolladores tienden a pensar que primero deben hacer todo el trabajo de las capas más inferiores, que tiene valor solo técnico, para en varios Sprints posteriores recién empezar a implementar items que los clientes puedan ver. 

En este punto es frecuente que los clientes hayan cambiado de opinion o pidan cambios en los items pero estos cambios ahora son costosos pues hay que bajar varias capas y tocar mucho código. La consecuencia natural es que los desarrolladores se resistirán lo mas posible a hacer cambios restringiendo de esta manera la adaptabilidad del producto.

Por el contrario sí el abordaje arquitectónico permite desde el principio ver el producto y realizar cambios rápido se tiene dinamismo y adaptabilidad. Precisamente es en este escenario en el cual se puede tener items con mejor definición de valor, items como por ejemplo:

• items que permitan realizar operaciones o flujos completos
• items que permitan aprender como interactuaran los clientes con el producto
• items que permitan descubrir nuevos clientes o descartar clientes que se consideraba que iban a utilizar el producto
• items que ayuden a reducir el riesgo de que algún item no se vaya a usar una vez implementado completamente
• items que permitan descubrir que tan frecuentemente serán utilizados

Un otro factor importante es considerar que en un producto están involucrados diferentes grupos y cada uno puede percibir el valor de manera diferente. Así por ejemplo:

• Los stakeholders del negocio pueden pensar que el valor se conecta a vender el producto a la mayor cantidad de gente al mejor precio
• Los usuarios y clientes perciben el valor de un producto que resuelve sus problemas y necesidades
• El Equipo de Desarrollo ve el valor de implementar items que los desafíen técnicamente o por el contrario puedan implementar con su conocimiento actual

La labor del Product Owner consiste en balancear estos intereses para que los items acaben contribuyendo valor para todos los grupos involucrados.

El valor también puede conectarse con indicadores econométricos como por ejemplo estos:

• costo total de propiedad es decir cuánto le constara al cliente adquirir y operar el producto a lo largo de su vida útil. Aquí es importante hacer notar que un producto con baja calidad sera muy costoso de operar y su horizonte de vida es mas corto.
• costo de retraso que tiene que ver no solo con llegar tarde a un mercado con el riesgo de ser sustituidos por competidores, sino también con el costo interno de pagar salarios y otros gastos por un tiempo extendido.
• margen entre cuento dinero esta costando desarrollar el producto y cuanto se espera recuperar y en cuanto tiempo

Ordenando Items

Ordenar los items del Product Backlog no es una tarea que debe considerarse tomando solamente una única perspectiva, por ejemplo ordenarlos tomando en cuenta el tiempo estimado de implementación de los items.

Pensando sistemicamente [Senge90] el Product Owner deberá identificar cuales son las variables relevantes y luego analizar si prioriza una por encima de las otras cual será el impacto. Por ejemplo, un item puede tomar poco tiempo para implementarse pero una vez implementado produce poco impacto en los usuarios.

Estos son algunos ejemplos de variables o criterios relevantes:

• alineamiento estratégico con el objetivo que persigue el producto, es decir items que nos acerca mas a alcanzar la vision del producto
• valor de negocio percibido a través de items que harán que por ejemplo el producto se vaya distinguiendo de la competencia y el negocio mejore su imagen 
• valor para el usuario final determinado por el grado en que el item ayude a resolver un problema o mitigar un dolor
• el tiempo de comercialización que se conecta a la noción de cuanto tiempo total pasa desde que se construye un item, se distribuye y se empieza recuperar la inversion  

Creando y Refinando Items

Los items como tal pueden provenir de fuentes diversas como por ejemplo estas:

• Grupos de clientes que manifiestan sus necesidades y problemas que originan ideas de solución traducidas en items
• Requerimiento regulatorios como leyes y políticas de gobierno que fuerzan a que el producto incluya ciertas características
• Aprendizaje a través de validación de supuestos que derivan en items que si se deben incluir en el producto
• Defectos que se acarrean de Sprints pasados o peor aun de una versión previa del producto que ya esta en producción 
• Cuestiones técnicas como componentes, librerías, parches de seguridad, plataformas, etc. que si bien tienen un valor técnico presentan un riesgo de tiempo y desvío de enfoque importante

Una forma dinámica e iterativa de crear nuevos items es utilizar el concepto de un estudio de diseño en el cual se dibuja y se hablar acerca del item, como si se estuviese diseñando alguna parte de una casa en el estudio de un arquitecto. Bajo este enfoque se dibuja cómo debería lucir el item dentro del producto, se habla de porque y quién lo utilizara, se exploran alternativas, y se comentan riesgos y desafíos.

Las conversaciones pueden quedar registradas en videos y los dibujos en fotografías, todo este material puede ir a un wiki interno. El titulo de el item es el que se anota en una tarjeta que ira dentro del Product Backlog, si se una una herramienta en linea como Google Spreadsheet la lógica es la misma, el titulo del item ira en una celda de una hoja llamada Product Backlog [Larman17].

Para incrementar el envolvimiento y contribuciones de los clientes en el Product Backlog es posible, y de hecho recomendable, tener reuniones semanales o aun mejor tener a los clientes sentados cerca del equip para poder comunicación y retroalimentación fluida

Para refinar los items del Product Backlog resulta muy util realizar juegos colaborativos en los cuales intervendran clientes y el Scrum Team y cuyo objetivo es entender mejor no solo los items sino el porque son necesarios.

El refinamiento de los items debe realizarse como una actividad recurrente para ir incorporando descubrimientos y conocimiento a medida que se adquiere. Tratar de hacer un solo refinamiento para todo el Backlog consume demasiado tiempo y no necesariamente aportara valor pues los items no prioritarios cambiaran y necesitaran de todas maneras ser refinados posteriormente.

El propósito del Product Backlog a veces puede ser mejor comunicado a través de herramientas como: hojas de ruta del producto, wireframes y mapas de historias de usuario [Patton14].

Un producto enorme aun puede ser trabajado a través de un backlog pequeño pero que provea valor siempre y cuando este backlog corresponda al lanzamiento de un producto minimamente viable, un lanzamiento para aprender (globo de ensayo), o un producto con el mínimo de características que lo hagan comercializable. 

Conclusiones

El Product Backlog debe ser un elemento de uso cotidiano y que sirva para centralizar el trabajo y la discusiones del Scrum Team. Mas aun, debe reflejar el entendimiento actual del orden en el cual se quieren implementar los items para producir el mayor impacto posible.

Como tal este artefacto puede tomar formas diferentes pero en esencia no se debe perder de vista que es solamente una lista de cosas por hacer en un horizonte de tiempo finito.

Finalmente, el Product Backlog debe poderse ver, idealmente debe poderse tocar, para que cumpla mejor su función de elemento integrador y facilitador de la comunicación. 

Bibliografia 

Ohno13 Ohno T., 2013. Taiichi Ohno’s Workplace Management, McGraw Hill

Senge90 Senge P., 1990. The Fifth Discipline: The Art & Practice of The Learning Organization, Doubleday

Larman17 Larman C., Vodde B., 2017. Large-Scale Scrum More with LeSS, Addison-Wesley

Patton14 Patton J., 2014,  User Story Mapping: Discover the Whole Story, Build the Right Product, O’Reilly Media

Introducción

Un producto, cualquiera que éste sea, mientras está en una etapa temprana de su ciclo se basa en muchas suposiciones. Por ejemplo se supone que tenemos el conocimiento, los recursos económicos, y disciplina para construir el producto correcto. 

Desde luego las suposiciones anteriores pueden o no ser ciertas, en el mejor caso si lo son nos llevaran a construir un producto pero ese no es el fin de la historia. También suponemos que conocemos el alcance del producto, quienes lo compraran, cuando dinero pagaran y en que mercado se venderá.

Ese segundo grupo de suposiciones son aun mas inciertas que las primeras pues están conectadas a factores externos variables como fluctuaciones del mercado, competidores y la economía misma de un país.

En esencia crear suposiciones y creer que se materializaran no es equivocado, pero la clave esta en validar si son verdaderas o no lo más pronto posible. Por tanto el gran servicio que un Product Owner presta no sólo al equipo sino a la organización, los clientes y el mercado mismo, es contribuir productivamente a la validación temprana de suposiciones.

Scrum Soporta la Validación de Suposiciones

Uno de los puntos centrales de Scrum es obtener retroalimentación sincera de clientes reales al final de cada Sprint, es precisamente a través de ésta dinámica que Scrum enfatiza la necesidad de validar suposiciones.

En muchos equipos he encontrado la tendencia a esperar un Sprint más para tener más cosas que mostrar a los clientes; desde luego esto no es recomendable y es generalmente un reflejo de que Scrum no se entendió bien o técnicamente el Equipo de Desarrollo esta abordando la construcción del producto usando un enfoque arquitectónico que no permite tener funcionalidad observable al final de cada Sprint.

Existen suposiciones técnicas que el Equipo de Desarrollo debe validar lo mas pronto posible, la mas común de ellas es que podemos poner código en producción fácilmente [Humble10].

Scrum a través del empoderamiento que concede al Equipo de Desarrollo para tomar decisiones técnicas favorece el que éste pueda invertir en aprender cómo poner código en producción desde los primeros dias del primer Sprint.

Una otra suposición técnica es que todo código que se construya luego se podrá probar a mano de forma rápida, eficaz y exhaustiva. Desde luego esta es una suposición muchas veces herrada pues el testo manual es lento, puede tener errores y omisiones. 

Una vez más Scrum fomenta que el Equipo de Desarrollo mejore sus prácticas de ingenieria para que inserte la calidad en el producto mismo a través de pruebas automatizadas [Jeffries00].  

Enfoques para la Validación de Suposiciones

Decidir qué suposiciones son las que se validaran primero tiene una influencia directa en el ordenamiento del Producto Backlog y por eso el Product Owner debe estar consciente de que existe varios enfoques. Estos son tres de los mas comúnmente empleados:

• Validar primero las suposiciones que implican el mayor riesgo de negocio
• Validar primero las suposiciones que implican el mayor riesgo técnico
• Validar primero las suposiciones que ofrecen las mayores posibilidades de aprendizaje

Balancear la incertidumbre en estas tres esferas (negocio, técnica y conocimiento) es complicado pues el Product Owner tiende a priorizar el negocio por encima de las otras dos. Si esta acaba siendo la tendencia en todos los Sprints muy probablemente el Equipo de Desarrollo acabara construyendo un producto plagado de deuda técnica y acarreara hacia el futuro una deuda de conocimiento. 

Parte de la labor del Scrum Master es colaborar con el Product Owner para que el balance entre esas tres dimensiones se mantenga. La receptividad y pensamiento sistemico en el Product Owner son esenciales en este punto para poder entender y aceptar lo que el Scrum Master trate de exponer [Schwaber04].

Para decidir cual enfoque escoger muchas veces resulta util ver que tenemos disponible, es decir, si quiero validar riesgos de negocio tengo que tener disponible usuarios reales, si quiero validar riesgos técnicos tengo que tener la infraestructura o dispositivos, si quiero aprender tengo que tener disponibilidad de tiempo y recursos de aprendizaje.

En función de lo que haya disponible, sea más barato o sea mas accesible se podrá tomar una decision de que suposiciones validar primero. 

Conclusiones

El trabajo en ciclos, el empoderamiento, la retroalimentación, la comunicación constante, y el espíritu de colaboración son algunos de los elementos que ofrece Scrum para permitir validar suposiciones lo más pronto posible.

Un buen Product Owner debe conocer y utilizar estos elementos y estar siempre dispuesto a cambiar el rumbo del producto en función de lo que vaya aprendiendo.

Una suposición también importe a considerar es que el Product Owner es el adecuado para el producto, quizás esto no sea cierto y una vez más Scrum a través de la transparencia y el coraje ofrece la oportunidad de que el mismo Product Owner pueda darse cuenta de que alguien más puede tomar su lugar. 

Finalmente y reiterando lo antes mencionado, suponer no es malo pues es parte del ciclo de desarrollo de un producto, lo que es malo es no validar esas suposiciones a tiempo y generar gran desperdicio con un producto construido que no sirve a las necesidades de los clientes o simplemente es el producto equivocado.

Bibliografia 

Humble10 Humble J., Farley D., 2010. Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation, Addison-Wesley

Jeffries00 Jeffries R., Anderson A., Hendrickson C., 2000. Extreme Programming Installed, Addison-Wesley Professional

Schwaber04 Schaber K., 2004. Agile Project Management with Scrum

Introducción

El trabajo del Product Owner tiene mucho que ver con el descubrimiento y la validación. Para ambos tipos de trabajo la comunicación cercana y efectiva con los clientes y usuarios es esencial.

El descubrimiento parte del dialogo acerca de cuál es el problema, dolor o limitación del estado actual de las cosas. Frecuentemente ese descubrimiento detona la necesidad de construir una solución al problema traducida en un producto de software.

En otras oportunidades el descubrimiento puede tener que ver con la detección de un producto que puede prestar un servicio que el mercado todavía no descubrió qué necesita, o por lo menos no existe como producto de software. 

Cualquiera que sea la fuente del descubrimiento el Product Owner si se decide a iniciar el desarrollo de un producto, lo estará haciendo basándose en un sinnúmero de hipótesis.

La forma más efectiva de validar las hipótesis de un producto siempre sea la validación con clientes y usuarios reales que puedan interactuar con el producto mientras se construye y no cuando ya esté totalmente construido.

Investigación de Clientes

Al construir un producto se produce un fenómeno similar a la paradoja del huevo o la gallina; es decir, primero se define el producto y luego el cliente o al revés.  

Concebir un producto, construirlo y luego salir en búsqueda de clientes no es un trabajo fácil y de hecho el mundo esta lleno de productos que se fabricaron y luego no se vendieron.

Encontrar clientes con un problemas y a partir de ahi derivar un solución/producto implica menos riesgo pero a su vez trae el gran desafío de identificar el segmento del mercado global que contiene potenciales clientes [Watts17].

Si el producto es para el consumo dentro de una organización el fenómeno se repetirá, en lugar de construir el producto y luego imponerlo a los usuarios funcionara mejor determinar quienes son ellos y qué características de un producto necesitaran.

Una forma simple de segmentar un mercado es considerar variables como ubicación geográfica, es decir no hacer un producto para el mundo entero sino para un mercado más pequeño y definido [Pichler16]. Esta simple distinción geografía reduce grandemente la complejidad sistémica del producto que se intentara desarrollar. 

Cuando un segmento esta bien definido, o por lo menos más reducido, será mas sencillo tratar de interpretar el problema o necesidades de los clientes del segmento. Sin embargo esto llevara muchas veces a la existencia de prioridades en conflicto.

Existen varios técnicas que un Product Owner puede utilizar para tratar de dilucidar con un grupo de clientes que podría ser prioritario, la base de estas técnicas siempre es la comunicación efectiva que permite que alguna de las partes en contraposición acabe descubriendo que puede mover su opinión sin ver sus interés seriamente lastimados.

De esas técnicas “Buy a Feature” que es parte de Juegos de Innovación [Hohmann06] es una de las que mejor funciona a la hora de dilucidar con un grupo de clientes con opiniones en conflicto que vale la pena o no incluir en un producto.

Una vez definidos los segmentos resulta muy util emplear técnicas como Personas   [Cooper04] para poder identificar y entender que objetivos y expectativas tendrá un grupo de usuarios con el producto.

Las personas pueden tomar diferentes formatos que van desde los más sencillos a los más complejos y crearlas puede tomar mucho o poco tiempo, pero lo que yo recomendaría es mantener la simplicidad tanto en el formato y el la inversion de tiempo en su creación. Después de todo siempre debe ser posible cambiar la descripción de estas personas a medida que se va entendiendo mejor el producto y sus potenciales usuarios. 

Personas es una excelente técnica para conceptualizar usuarios potenciales pero tiene la limitación de que no permite recolectar retroalimentación real acerca de cómo los usuarios utilizarían la aplicación [Adzic09].

En la practica si se tiene un esqueleto que camina este debe presentarse a los usuarios reales para ver cómo interactúan manos en el teclado con el producto que se esta desarrollando.

En este punto enfatizó que es vital que los usuarios “toquen” el producto, es decir que puedan verlo e interactuar con él, solamente así se puede saber cómo se comportarían y si el producto resolvería alguna de sus necesidades o no. 

Antes de construir un esqueleto que camina se podrían utilizar técnicas para tratar de entender qué quieren los clientes, como por ejemplo observar sentados junto a ellos como hacen realmente su trabajo y cuales son los problemas o limitaciones que experimentan. Entrevistas y grupos focales también pueden servir para el mismo objetivo. 

Lo anterior siempre trae el riesgo de caer en una larga fase de análisis en papel y con discusiones pero sin construcción del producto de software en sí. Por esta razón recomiendo hacer las cosas en paralelo, es decir, tener a los usuarios cerca, ver qué quieren hacer con el producto, implementar rápidamente y mostrárselos para ver si es lo que querían.  

Descubrimiento de Productos

Durante la fase de descubrimiento del producto existen varios aspectos que luego contribuirán positivamente con los resultados que el producto puede alcanzar. Estos aspectos se basan en poder entender que harán los usuarios con el producto, es decir cómo interactuaran con él. 

Para poder apreciar las interacciones de los usuarios con el producto es necesario que estos puedan verlo y es ahi donde intervienen instrumentos como diseño de la experiencia de usuario, diseño de la interacción y diseño visual.

Este tipo de diseño puede realizarse con herramientas de software o mejor aun todavía solamente con papel y marcadores, la idea siempre es mantener la simplicidad y permitir que cualquier cambio sea tan rápido como borrar o dibujar de nuevo.

Técnicas que vienen en formato de Juegos de Innovación [Hohmann06] son especialmente útiles para permitir “ver” con mayor claridad que características podría tener un producto.

Sin embargo descubrir un producto en papel no es lo mismo que verlo funcionando en una computadora o dispositivo móvil por lo cual urge validar la hipótesis de cómo podrá lucir realmente en esos dispositivos.

Abordar el desarrollo del producto de software usando un concepto de arquitectura como el Esqueleto que Camina [Hunt99] permite ver en pantalla el producto desde el primer Sprint y así descubrirlo con los usuarios de manera efectiva.  

Conclusiones

Partimos de la observación de que la correcta definición de un producto no existe como tal antes de construirlo; por tanto se necesita un proceso de descubrimiento y aprendizaje continuo en el cual interviene todo el Equipo Scrum junto con los stakeholders, clientes y/o usuarios finales.

Este proceso de aprendizaje requiere ser dinámico y para esto herramientas ligeras y comunicación efectiva son fundamentales. Al abordaje de la arquitectura del producto también debe estar acorde con la adaptabilidad que se requiere para un aprendizaje dinámico. 

Finalmente el Product Owner será el actor que articulara al producto y sus clientes, en esta función sus habilidades interpersonales, comunicativas y de negociación serán vitales.

Bibliografia 

Watts17 Watts G., 2017. Product Mastery: From Good To Great Product Ownership, CreateSpace Independent Publishing Platform

Pichler16 Pichler R., 2016. Strategize: Product Strategy and Product Roadmap Practices for the Digital Age, Pichler Consulting

Hohmann06 Hohmann L., 2006. Innovation Games: Creating Breakthrough Products Through Collaborative Play, Addison-Wesley Professional

Cooper04 Cooper A., 2004. The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity, Sams – Pearson Education

Adzic09 Adzic G., 2009. Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing, Neuri Limited

Hunt99 Hunt A., Thomas D., 1999. The Pragmatic Programmer: From Journeyman to Master, Addison-Wesley Professional

Introducción

Un producto tiene muchas formas de ser concebido, a veces proviene de la idea de un soñador y otras de una concepción colectiva, pero sin importar su origen necesita de alguien que se encargue de llevar la idea a través de un viaje para que se torne en un producto viable en el mercado. 

Haciendo una analogía, un producto es como un barco que navega pero precisa de alguien que pueda ver la costa en el horizonte y diga hacia allá vamos. Continuando la analogía, la linea recta hacia el objetivo no siempre es el mejor camino o el más seguro, por lo cual a medida que se navega se van haciendo adaptaciones sin perder de vista el objetivo.

Un Product Owner tiene dentro de su rol trazar la vision del producto, descubrir un propósito inspirador, y concebir una estrategia que sea lo suficientemente flexible y adaptable que permita evolucionar el producto escuchando al mercado.

Como cualquier otro de los roles que Scrum propone, el rol del Product Owner no es para cualquier persona pues ciertas características, experiencias, y rasgos de personalidad preparan mejor a un individuo para triunfar en este rol.

Estrategia del Producto

La visión de un producto es la que permite tener un propósito articulador, algo que ayuda a que la gente que trabaja en el producto entienda que están construyendo algo que tendrá un gran impacto y no simplemente perdiendo el tiempo construyendo algo que nadie vaya a utilizar. 

Descubrir la visión de un producto es el primer paso para poder entender porque haremos lo que haremos, a quienes servirá el producto, qué causa defenderemos, y que problema queremos resolver o cambiar.

Existen varias formas de descubrir la vision, una de las más sencillas pero a la vez eficientes que he encontrado es utilizar la metáfora del Circulo Dorado [Sinek11] que permite encontrar el porque antes que el cómo y el que. 

He utilizado el Circulo Dorado en múltiples contextos, países y organizaciones, y estos son algunos consejos que puedo proveer:

• Tener un grupo diverso y multidisclinario fisicamente presente en el mismo lugar
• Utilizar un papelógrafo, post-its y marcadores
• Poner un timebox de no mas de 15 minutos
• Incluir en la articulación del porque frases incluyentes como “nosotros creemos” o “nosotros queremos”
• Incluir en la articulación del porque palabras que toquen sentimientos como por ejemplo “familia”, “madre tierra”, “vida”, “salud” o “comunidad”

El poder del Circulo Dorado está en que él porque descubierto con esta técnica debe resonar con quienes los escuchen; dicho de otra forma ésta será la causa inspiradora que motivará al grupo de personas a perseguir una vision de un futuro mejor. 

Según Pichler [Pichler16] una vision efectiva tienen cuatro características principales:

1. Es amplia lo cual permite al producto tener grados de maniobrabilidad y hacer adaptaciones para de todas maneras alcanzar el objetivo
2. Es compartida por toda la gente que trabaja en el desarrollo del producto y quienes lo consumirán
3. Es inspiradora pues busca hacer una diferencia en el mundo a través de un producto o servicio
4. Es concisa y fácil de comunicar con palabras simples y consecuente todos la entienden 

Una vision clara es la que permite derivar una estrategia más concisa y realista. La estrategia trazará el camino para alcanzar la vision, es decir del cómo la vision se hará realidad. 

Para que la estrategia cobre vida ésta necesita de pasos más concretos y es ahi donde interviene la táctica. A nivel táctico también se incluyen los detalles necesarios para desarrollar el producto, muchas veces al hacer el desglozamiento en lo táctico detona un descubrimiento que acaba haciendo que la estrategia cambie.  

Por tanto, de la vision se deriva la estrategia y de la estrategia la táctica. Lo anterior es de vital importancia para un Product Owner que no debe perderse solamente en la escritura de historias de usuario. 

Planificación y Pronóstico de Productos

La planificación de cuando se entregará un producto tiene mucho que ver con el ciclo de lanzamientos que este tendrá. Si el producto es software no buscamos una sola entrega del producto cuando esté completamente terminado, por el contrario, buscamos hacer lanzamientos parciales en ambientes de producción reales para que los usuarios puedan proveen retroalimentación realista.

Como parte de la planificación el Product Owner deberá decidir con el resto del equipo y los stakeholders la frecuencia con la cual se pondrá en producción. La periodicidad de estos lanzamientos dependerá de varios factores y en muchos casos puede verse una correlación directa entre la capacidad técnica del Equipo de Desarrollo y la frecuencia con la cual este puede llevar código a producción. 

Algunos ejemplos típicos de periodicidad puestas en producción incluyen:

• Una vez al año 
• Una vez por semestre
• Una vez por cada trimestre del año
• Una vez al final de cada mes
• Al final de cada Sprint de dos semanas (dos veces al mes)
• Una vez cada semana
• Una vez cada día
• Varias veces al día

Desde luego la periodicidad que se escoja puede estar desasociada de las lanzamientos formales [Forsgren18]. Así por ejemplo el equipo puede tener la capacidad de poner código varias veces al día en producción pero el Product Owner puede decidir lanzar el producto formalmente en un ciclo de cuatro meses.

El punto anterior es especialmente importe porque muchas veces he encontrado la confusion entre el concepto de lanzamiento (release) y puesta en producción. Un lanzamiento puede implicar cosas como marketing, aspectos legales, difusión en redes sociales, etc. y una puesta en producción es una práctica ingenieríl que permite validar las hipótesis de que el producto que construye el Equipo de Desarrollo es el correcto y funciona en un ambiente real.

Ejemplos típicos de ciclos de lanzamiento incluyen:

• Oportunista, es decir cuando una condición externa o de mercado disparan la necesidad de lanzar inmediatamente el producto
• Tiempo fijo, que implica que se lanzará el producto en una fecha especifica
  • Multi-Sprints, es una variación de Tiempo Fijo pues implica que después de X Sprints que equivalen a N meses se lanzará el producto
• Alcance fijo, que solamente permitirá lanzar públicamente un producto cuando todas sus características se hayan implementado. Desde luego esto es no solo costoso y riesgoso, sino que también desvirtúa el principio de porque usar un enfoque ágil de alcance adaptativo y tiempo finito

Un Product Owner tiene a su disposición varias técnicas y herramientas para planificar el desarrollo y entrega de un producto a través de un horizonte de tiempo definido.

La herramienta más básica es un Product Backlog que se ordena constantemente en base al descubrimiento de nuevas prioridades/items, retroalimentación de los stakeholders y capacidad técnica del equipo. 

Los mapas de impacto [Adzic12] son otra valiosa herramienta que permite ir analizando que items del producto están causando que impacto en que stakeholder y hacer adaptaciones en el producto en función de ese análisis.

Priorizar y repriorizar con los stakeholders una hoja de ruta del producto es una otra herramienta muy valiosa a la hora de tratar de definir que es importante y que no, que debe incluirse en el lanzamiento actual y que podría esperar para futuro.

Las tres técnicas anteriormente mencionadas en su esencia buscan adaptar el alcance en función de que tiene sentido, desde la perspectiva de los usuarios finales, incluir o no en el producto. 

Este tipo de pronóstico se distancia de la forma tradicional de tratar de predecir sí vamos a llegar a la fecha X con todo el alcance completado que se descubrió inicialmente. 

La gran labor del Product Owner es precisamente convencer a los stakeholders de que para construir un producto que tenga alguna chance en un mercado cambiante y evolutivo, es necesario adaptar el alcance multiples veces dentro de un tiempo finito, descubriendo en cada ciclo como el producto puede aportar mas valor.

Conclusiones

Un Product Owner es en esencia un estratega y un visionario; como estratega su mente debe estar abierta a cambiar la estrategia con tal de llegar al objetivo del producto, como visionario descubre cual es la visión del producto y los traza los objetivos que ayudaran a materializarla.

Si bien el trabajo del Product Owner no lo distancia de lo táctico pues hay un artefacto con el cual debe trabajar, el Product Backlog, su trabajo con el no debe se al nivel de detalle minucioso sino más bien orientado al ordenamiento que busca major impacto con menos funcionalidad implementada.

Finalmente, la efectividad de alguien en rol del Product Owner no debe medirse por que tan bien hizo ejecutar un alcance descubierto pues eso seria un indicador de que su rol ha sido completamente mal entendido.

Bibliografia 

Sinek11 Sinek S., 2011. Start with Why: How Great Leaders Inspire Everyone to Take Action, Portfolio

Pichler16 Pichler R., 2016. Strategize: Product Strategy and Product Roadmap Practices for the Digital Age, Pichler Consulting

Forsgren18 Forsgren N., Humble J, Kim G., 2018. Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations, IT Revolution Press

Adzic12 Adzic G., 2012. Impact Mapping: Making a Big Impact with Software Products and Projects, Provoking Thoughts

Introducción

El rol de Product Owner completa la triada de roles en los cuales se basa el enfoque colaborativo del marco de trabajo Scrum. Esta triada, independientemente de la nomenclatura, buscar tener representación y participación del negocio, la parte humana, y la parte técnica. 

El rol del Product Owner es especialmente importante pues es quién definirá el producto que construirá el Equipo de Desarrollo, los tiempos en los cuales será liberado, las características esenciales del producto, y a quienes serán sus principales consumidores.

Yendo un paso mas atrás, el Rol del Product Owner se hace necesario cuando vamos a construir nuevos productos o cuando queremos llevar productos existentes a nuevas alturas. Si lo anterior no ocurre habría que partir por el primer cuestionamiento de si vale la pena usar Scrum o no.

La carrera de un Product Owner estará marcada por varios lanzamientos de productos −algunos exitosos con suerte− y la constante lectura del mercado y sus tendencias. 

Es vital también entender que la organización donde trabaja el Product Owner le concede total poder de decisión acerca del producto; para esto desde luego la organización deberá repensarse a si misma como una organización que crea productos y no solo ejecuta proyectos.

Fundamentos del Rol de Product Owner

El rol de Product Owner muchas veces es confundido con el de un Project Manager que se encarga de hacer que todo funcione bien, es decir lo mismo de antes pero sólo con un cambio de nomenclatura. Desde luego ésta es una disfunción de Scrum y no conduce a resultados positivos y duraderos.

En la práctica he observado que algunos Product Managers transicionan al rol de Product Owner y eso produce mejores resultados por dos razones:

1. La existencia de Product Managers indica que la organización ya trabaja en función de productos y no sólo proyectos
2. Los Product Managers ya tienen poder de decision suficiente para decidir el curso de acción sobre un producto

Lo anterior no es mencionado como una receta para maquillar el esquema actual y ahora llamarlo Scrum, lejos de eso sólo lo menciono con el afán de enfatizar que el Product Owner necesita tener poder de decisión y que el enfoque organizacional debe estar ahora en productos. 

Existen varias responsabilidades para el rol de Product Owner, algunas de las más importante son:

• ayudar a la organización a crear productos comercialmente y técnicamente viables que acaben deleitando a los clientes finales
• trabajar de la mano con los clientes para descubrir como solucionar sus problemas y atender sus necesidades a través de un producto
• descubrir a través del ordenamiento del Product Backlog que características no se incluirán (o por lo menos no todavía) en el producto
• promover dentro del equipo, la organización y con los clientes el enfoque minimalista y de retroalimentación rápida (basado en Lean Startup [Reis11]) para construcción de productos
• fomentar el crecimiento técnico dentro del Equipo de Desarrollo a través de la inversion de tiempo para aprendizaje
• educar a los clientes y la organización acerca de la realidad en la variabilidad del alcance 

Cuando el Product Owner llega a dominar las competencias de su rol se podrían esperar beneficios como estos:

• Haber desarrollado una vision estratégica para colocar el esfuerzo del equipo en la implementación de características con gran futuro
• Tener un pensamiento sistémico que le permitirá ver el producto y su ciclo de vida considerando múltiples variables [Senge90]
• Concebir el producto como un ente viviente que se extiende a lo largo del tiempo, las tecnologías, los mercados y los clientes
• Dominar el vocabulario del cliente y entender a cabalidad su giro de negocio
• Desarrollar una intuición de hacia donde debe ir el producto a futuro

El rol del Product Owner mal interpretado puede degenerar en anti-patrones que afectan grandemente al equipo Scrum y a la organización. Algunos de estos anti-patrones son:

• El Product Owner es solamente un tomador de ordenes y escritor de historias de usuario sin poder de decisión sobre el producto
• El Product Owner es incapaz de ordenar el Product Backlog y sostiene que todos los items son igualmente importantes y se deben implementar
• El Product Owner trabaja a tiempo parcial en otra función y no dispone de tiempo para cumplir a cabalidad con las responsabilidades de su rol
• La organización pone a alguien técnico que no conoce del nada del mercado y los clientes en el rol de Product Owner
• El Product Owner solamente aparece en el Sprint Planning y el Sprint Review dejando al equipo a la deriva durante el Sprint

Estos anti-patrones son desde luego lo opuesto a lo que se debería esperar de un Product Owner que entiende y cumple a cabalidad con las responsabilidades que su rol implica.

El contexto organizacional dentro del cual opera el Product Owner también tiene un efecto sobre el rol, los siguientes son algunos ejemplos de estos contextos:

• La organización le confiere poder absoluto sobre el producto al Product Owner, es decir, esta en sus manos conocer y decidir acerca del problema, la solución, el producto y el mercado
• El Product Owner recibe el mandato de construir un producto que a alguien más se le ocurrió y para un mercado que el no conoce a cabalidad
• El Product Owner en realidad no trabaja en un producto sino en varios proyectos de corta duración
• El Product Owner no construye un producto para un mercado interno sino que más bien provee soluciones para otros equipos o departamentos 

Si bien Scrum se podría llegar a aplicar en los cuatro contextos anteriores he observado que el primero explota a cabalidad el potencial del rol del Product Owner. Cabe aquí puntualizar que en esencia Scrum se pensó para creación de productos, no para ejecución de proyectos o prestación de servicios. 

Trabajando con los Stakeholders

Gran parte del trabajo del Product Owner consiste en mantener el respaldo de los stakeholders; para esto mostrar el progreso en la construcción del producto es esencial [Pichler16]. La lógica detrás de esto es mostrar a los stakeholders que se esta avanzando hacia un objetivo. 

Para mostrar avance existen varias maneras, dos de las más comunes son:

1. Con indicadores y métricas como el product roadmap y el release burn-up chart
2. Con software funcionando con el cual los stakeholders pueden interactuar en el Sprint Review o en cualquier otro momento durante el Sprint

La segunda manera es la que a la larga provee mejores chances de conseguir retroalimentación real y una apreciación más realista del grado de progreso del producto. 

Los stakeholders necesitan permanecer interesados en el producto para que su participación sea activa y voluntaria en lugar de pasiva y forzada [Watts17]. Hacer preguntas directas es siempre la forma preferida pero hay situaciones en las cuales las respuestas pueden ser muy largas o el grupo de stakeholders es muy grande.

En situaciones como las mencionadas en el párrafo anterior se pueden aplicar técnicas como estas para tener a los stakeholders participando e involucrados con el producto:

• Grupos de afinidad que se forman con stakeholders que comparten la misma opinion, interés o punto de vista
• Votación con puntos en un papelógrafo para decidir acerca de que item, idea o alternativa tiene mas futuro
• Votación con los dedos de la mano que permite decidir incorporando el voto de la mayoría 

El Product Owner podría llegar a actuar como un facilitador neutral con los stakeholders en situaciones como estas:

• Cuándo un stakeholder presenta una idea que le parece descabellada al resto e interrumpe a quien la propone sin dejar que termine de proponerla
• Cuando los stakeholders tienen opiniones contrapuestas acerca de un item o característica del producto

En ambas situaciones el Product Owner podría proponer la escucha como mecanismo para la información, el entendimiento y el posterior debate. 

La no-neutralidad podría generar una fractura en la relación con un stakeholder o un grupo de ellos; o lo que es aun peor, perderse de la creatividad que viene de la diversidad de opiniones que solo ocurre cuando el grupo es funcional [Lencioni02]. 

Sin embargo existirán situaciones en las cuales el Product Owner deberá tomar un abordaje diferente, por ejemplo cuando se ha perdido demasiado tiempo debatiendo y se necesita una decisión rápida.

En situaciones como estas el Product Owner puede usar su prerrogativa y decidir por ejemplo en qué orden se implementaran los items del Product Backlog, o si un item merece la pena o no ser incluido en el Product Backlog.

Cabe sin embargo recalcar que el Producto Owner no construye un producto que le sirva a él sino que contribuya valor para los stakeholders. La lógica aquí es no imponer la voluntad o preferencia del consultor por encima de la necesidad del cliente [Lencioni10]. 

Trabajando con el Equipo de Desarrollo

El Product Owner colaborar con el equipo en varias instancias, una de las más importantes es en la Definición de Terminado. Esta definición es un acuerdo de trabajo creado y mantenido por el Scrum Team y la intención es tener claridad acerca de cuándo algún item se considerara realmente terminado.

Cabe enfatizar que “terminado” para que tenga valor debe ser algo que los stakeholders puedan ver y de lo cual puedan dar retroalimentación. Como corolario, items que cumplen con condiciones solamente técnicas, como por ejemplo que no rompan el build, no presentan valor de negocio y por tanto no accionan el feedback de parte de los stakeholders. 

Otra instancia cuando el Product Owner debe colaborar con el equipo de desarrollo, y principalmente con los stakeholders, es descubriendo el Product Backlog con las cosas que tendrá el producto. 

Descubrir el Product Backlog es una tarea central y funciona mejor bajo un enfoque colaborativo y dinámico en el cual en grupo de personas exploran juntas las características, mercados, usuarios y problemas que potencialmente resolverá el producto [Patton14]. 

En eventos como el Refinamiento el Product Owner tendrá la oportunidad la oportunidad de trabajar lado al lado con el Equipo de Desarrollo ordenando los items que vendrán en el siguiente Sprint; cabe hacer notar que es el Equipo de Desarrollo el que se encarga de descomponer y estimar los items para el siguiente Sprint.

También es factible que el Equipo de Desarrollo planifique solamente suficientes items para uno o dos dias y que en la reunion de Refinamiento se planifiquen los siguientes items; este tipo de planificación en base a items terminados y capacidad liberada se basa en un sistema pull [Ohno13].

Es importante recalcar que él Product Owner no conoce en detalle cada uno de los items del Product Backlog pues esta labor seria demasiado exhaustiva y lo desviaría de la verdadera función de su rol que es tener la vision y estrategia del producto.

Lo anterior nos lleva a que el Product Owner debe saber quien originó el requerimiento para que así pueda direccionar al desarrollador que trabajará en ese requerimiento para que hable directamente con el usuario. 

Si las conversaciones deben ser registradas para la posteridad por razones pragmáticas como poder recordar lo dicho entonces grabar un video resulta la forma mas eficiente. Aun mejor es cuando se graba un video de la conversación que va ilustrada con dibujos en un papelógrafo.

Product Ownership con Multiples Equipos

Ser el Product Owner de multiples equipos implican desafios como por ejemplo:

• El principal y mas grande desafío siempre es la comunicación, empeora cuando los equipos se hallan en zonas horarias diferentes y hablan idiomas distintos
• Un segundo gran desafío es hacer que todos lo equipos tomen items del Product Backlog que sea de alta prioridad y que contribuyan valor perceptible para los stakeholders
• Finalmente esta el desafío de mantener un producto congruente creado por un único equipo aunque este este globalmente distribuido

Los desafíos anteriores son solamente algunos ejemplos de los que encontrara un Product Owner que trabaje con múltiples equipos. Desde una perspectiva sistémica mientras mas equipos se tiene mayor es la complejidad y por tanto habría que tender a la simplificación.

Como se sugiere en LeSS [Larman17] para lograr simplicidad sistémica a la hora de trabajar con multiples equipos abría que mantener la simplicidad y elegancia de Scrum a través de condiciones como: trabajar con equipos locales, mantener un solo Product Backlog y tener un único Product Owner.

El escalamiento solamente debería intentarse cuando no hay otra alternativa, mas aun, en lugar de escalar con mas gente habría que de-escalar reduciendo la complejidad sistémica para rescatar así la esencia de Scrum que se basa en equipo autónomos y auto-manejados.

Conclusiones

El rol del Product Owner bien entendido puede llevar a las organizaciones a construir productos que realmente produzcan un impacto positivo en el mercado beneficiando a los usuarios o clientes finales. 

Para que lo anterior acabe ocurriendo se necesitara no solamente de Scrum dentro del equipo sino también del cabal entendimiento por parte de la alta gerencia de la organización que implica el cambio hacia Scrum.

Un punto esencial de ese cambio es entender que el Product Owner tiene total poder de decisión acerca del rumbo del producto, decidiendo qué características tendrá el producto y en qué orden se implementaran.

Finalmente, quien asuma este rol deberá poseer entre otras cualidades una mentalidad estratégica y un espíritu emprendedor que le permita fallar rápido de ser necesario o perseverar hasta alcanzar los objetivos del producto. 

Bibliografia 

Reis11 Reis E., 2011. The Lean Startup, Crown Business 

Senge90 Senge P., 1990. The Fifth Discipline: The Art & Practice of The Learning Organization, Doubleday

Watts17 Watts G, 2017. Product Mastery: From Good To Great Product Ownership, CreateSpace Independent Publishing Platform

Pichler16 Pichler R., 2016. Strategize: Product Strategy and Product Roadmap Practices for the Digital Age, Pichler Consulting

Lencioni02 Lencioni P., 2002. The Five Dysfunctions of a Team: A Leadership Fable, Jossey-Bass; 1st edition

Lencioni10 Lencioni P., 2010. Getting Naked: A Business Fable About Shedding The Three Fears That Sabotage Client Loyalty, Jossey-Bass; 1st edition

Patton14 Patton J., 2014,  User Story Mapping: Discover the Whole Story, Build the Right Product, O’Reilly Media

Larman17 Larman C., Vodde B., 2017. Large-Scale Scrum More with LeSS, Addison-Wesley