Scrum en la practica

Las 5 diferencias entre un product owner y un product manager

Trabajando en entornos ágiles con cierta envergadura, es normal encontrarse con dos figuras que, a través de la relación sobre el producto, en ocasiones tienen conflictos en cuanto a la definición de sus roles y sus tareas. Estos son el Product Manager y el Product Owner.

El Product Owner, en entornos que usan Scrum, es el último responsable del Product Backlog, de los ítems que contiene y del éxito del desarrollo del producto. Además, puede gestionar el presupuesto específico del producto -y lo hace en entornos que no tienen un Product Manager- y la cuenta de resultados del producto.

El Product Manager, en función del enfoque se utilice, es el encargado de manejar la parte de negocio de producto. Entre sus responsabilidades están la de manejar los KPIs, reportes, cuentas de resultados y responsabilidad sobre el resultado final. En el caso de organizaciones que usan SAFe, es la persona a quien otros Product Owners en la organización reportan. ¿Fácil, no?

Alto, porque hay que considerar más cosas en esta lucha de titanes. En primer lugar, está la estrategia de producto, en la cual hay que tomar decisiones importantes sobre como acercarse al mercado o encontrar financiación. En el otro está la táctica del mismo, y esta no es implementar el Product Backlog -gran error-, sino acercarse a los detalles del lanzamiento o actualización del mismo, canalización y otros. Estrategias de comercialización. Publicidad.

La gestión y desarrollo de Producto en Scrum, caen más del lado de la estrategia que de la táctica. Es aquí donde comienza la indefinición expuesta en la imagen de arriba. Cuestiones como la realización de historias épicas, definición de requerimientos tienen que considerar una parte previa de análisis del mercado y estrategia competitiva. Aunque también tienen una parte táctica. ¿Menos fácil?.

Si el equipo usa Scrum, debe tener un sólo Product Owner que trabaje con ellos. Él o ella tienen la última palabra sobre el Product BacklogLa parte táctica -sprint a sprint- es en que el Product Owner tiene que estar inmerso para asegurar el éxito del Incremento al final del Sprint. Eso hace que estas dos figuras tiendan a chocar de nuevo. Veamos las 7 diferencias.

El Product Owner tiene la última palabra sobre el contenido del backlog

El Product Backlog es competencia exclusiva del Product Owner como miembro del equipo Scrum. Son él o ella los que se encargan de transferir la estrategia de producto a partir de una fragmentación adecuada del Product Backlog.

En algunas organizaciones no es así. El Product Owner es solamente un títere del Product Manager sin posibilidad de decisión. Esto provoca una gran ineficiencia en el equipo Scrum. Cuando necesitas respuestas, sólo tienen a un minion que no puede hacer nada.

El Product Manager tiene responsabilidad ejecutiva sobre los resultados del Producto

Cuando los dos conviven en un entorno corporativo, es normal que el Product Manager sea quien tiene responsabilidad ejecutiva sobre el producto. Esto crea un problema en equipos que usan Scrum, debido al primer punto.

Un Product Owner que trabaja con varios Product Managers es normal en empresas pequeñas. En empresas grandes, es normal tener un VP de ProductoLa manera de solucionarlo es aceptar por parte del Product Manager que tiene que dar la cara pero no puede ejecutar la responsabilidad, lo cual es perfectamente normal. Una buena idea es utilizar una matriz RACI+F para solucionar este asunto. Quien es el responsable, da la cara, es consultado, informado o facilita cada proceso.

Las responsabilidades del Product Owner forman parte del espectro de las del Product Manager

Scrum se centra en el Product Owner como representante del negocio, quien tiene toda la información y la gestiona dentro del pequeño área que supone Product Ownership. El Product Management es normalmente mucho más amplio que sólo el Product Ownership. El PO puede cubrir esta parte, pero es importante diferenciarlo.

La colaboración es necesaria en este caso, para que la estrategia y la táctica en torno al producto están alineadas. No valen las medias tintas. El profesionalismo es lo que marca la diferencia en estos entornos.

El Product Owner es el emprededor, el Product Manager el ejecutor estratégico

En otras ocasiones, por ejemplo en el framework Nexus, el Product Owner posee el máximo nivel de propiedad sobre el producto, y los Product Managers se encargan de ejecutar pequeñas partes del producto trabajando en el día a día de los equipos y la estrategia a medio plazo.

Personalmente, creo que define bien, y es la opción con la que yo me identifico. El Product Owner tiene que ser responsable y estar disponible para la táctica y para la estrategia. Puede utilizar a un espectro de profesionales, desde un experto en SEO a UX para crear e implementar la estrategia.

Todo esto puede pasar a la vez

Hay organizaciones que pueden tener a un über Product Owner, que trabaja con distintos Product Managers que se encargan de varios Productos y que a la vez tienen product owners para cada uno de ellos. Los Product Owners trabajan con los equipos y a la vez con el metaequipo. Los product Manager aportan experiencia a cada uno de los productos. Y todo puede funcionar ágilmente

No existe una solución común. Los distintos frameworks han reflejado una realidad a través de distintos enfoques. Hacer producto es algo personal de cada organización y no puede extrapolarse exactamente a otra. Es labor de la organización averiguar cual es la mejor manera de trabajar. Siendo transparente, inspeccionando y adaptando.

Si tienes interés en profundizar más, hemos hecho un video con las claves de un Product Owner.

¿Es normal la frustración de esta Scrum Master?

Hace unas semanas empecé a trabajar con una nueva Scrum Master en uno de mis clientes y ahora tiene una gran frustración. Durante los últimos meses en esta organización, hemos trabajado mucho en la auto-organización y en ser capaces de entregar un incremento terminado al final de cada Sprint.

En este cliente, los equipos de desarrollo son independientes y suficientes. Trabajan con el Product Owner en elaborar el Product Backlog y tienen poder para decidir a quien contratar y despedir, como realizar su trabajo -el CTO está especialmente orgulloso de Scrum y de las mejoras que ha traído- así cómo mejorar el producto. Ellos son responsables de la calidad, y también de su frustración.

A pesar de ser yo el primer filtro para Scrum Masters, no decido quien se incorpora. Son los propios equipos quienes lo hacen. Ellos son los que entrevistan y contratan a sus propios Scrum Masters. En este caso, Marta -nombre ficticio- demuestra ser una persona proactiva que entiende como funciona Scrum. Después de un año como Scrum Master en una organización y unos meses como Agile Coach en otra, se ve como una experta en Scrum. Y a pesar de ello, tiene una gran frustración.

Marta quiere hacer cosas, en lugar de centrarse en crear un espacio donde otros hagan

Al llegar a la oficina por primera vez, Marta se ha visto con ganas de hacer muchas cosas. Cree que hay que definir mejor el trabajo del Product Owner y el Product Backlog. También ve que el equipo no llega con el testing y ella misma se pone a testear. Lo mismo con las tareas no planificadas: ha propuesto crear un tablero donde visualizar todo el trabajo no planificado que tiene que hacer el equipo, el que no está previsto dentro del Sprint. En el caso de los Scrum Masters, cree que deberían hacer planes conjuntos sobre como cambiar la organización. Establecer metas comunes y luego implementarlas. Crear equipos de alto rendimiento.

Sin embargo, el resto del equipo no piensa que esas sean sus tareas. Ella no está de acuerdo. Quiere sentarse y preparar un plan de mejora, trabajar en que el equipo sea más feliz y se comuniquen mejor. Sin embargo, el equipo piensa que ya se comunican adecuadamente y no hacen falta mejoras. A veces, ellos mismos se sienten mal al no entrar en lo que Marta quiere hacer. Ella ve que hay miembros del equipo que no hablan lo suficiente o que no comunican como se sienten.

A nivel organizacional, quiere cambiar la manera en que las cosas funcionan, cree que hay espacio para hacer los procesos más eficientes. Eso pasa por decirle a la gente como tiene que hacer su trabajo. Además, durante las retrospectivas, se siente frustrada de que el equipo no encaje bien con las actividades que quiere realizar. Su relación con el Product Owner no es la mejor; él piensa que quizás está intentando abarcar demasiado.

Hace unos días, le pregunté: Desde que empezaste ¿Qué has aprendido que te haya hecho mejorar como profesional? ¿Hay algo nuevo que hayas aprendido de como funciona Scrum? Su respuesta fue que esas eran preguntas muy difíciles. Efectivamente ha aprendido cosas. Como funciona la empresa. Recursos humanos. Desarrollo de producto. Y yo me pregunto de nuevo ¿Es eso lo que debería haber aprendido? ¿Está haciendo su labor como Scrum Master correctamente?

Marta no entiende qué es ser una Scrum Master

Mi opinión personal es que no. Efectivamente, Marta conoce Scrum, pero como Scrum Master está todavía en una etapa de desarrollo personal y profesional muy temprana. Marta quiere hacer cosas, en lugar de crear un entorno donde todo el mundo puede hacer cosas. Se ve a si misma como un experto que sabe qué hay que hacer, en lugar de como un soporte que permita que otros se desarrollen al máximo. Y esto es un problema, porque cuando es enfrentada a este respecto, ella cree que ese es el trabajo. Si el equipo tiene impedimentos, resolverlos; Si la organización es ineficiente, decirle como puede ser más eficiente.

Esta situación es muy común y es el estado de evolución que sigue al Scrum Master “Ordeno y mando”. Existe un siguiente nivel en el cual los Scrum Masters entienden que su trabajo no es cambiar la organización, sino que tienen que eliminar los impedimentos que impiden que la organización sea cambiada… por otros.

La receta para conseguir un buen Sprint Review

El Sprint Review es el meeting de negocio por excelencia. Durante el mismo se pone de manifiesto la transparencia en torno al incremento, se inspecciona y se adapta el Product Backlog.El Sprint Review es la oportunidad para que todos los Stakeholders, incluido el propio equipo Scrum, inspeccionen el incremento terminado durante el Sprint. Para ello es importante, además de invitar a los Stakeholders para promover la transparencia, tener claras cuales son las condiciones actuales de negocio y el Product Backlog, para poder actualizarlo al terminar la Review. La Sprint Review se organiza y coordina por el Product Owner
, no por el Scrum Master ni el Development Team.

Ingredientes para el Sprint Review

El equipo Scrum
Un Incremento terminado (que cumpla la Definition of Done)
El Sprint Backlog
El Product Backlog
Las condiciones actualizadas del negocio.
Un puñado de Stakeholders.

Y el resultado es:

Un Product Backlog actualizado con el feedback de Stakeholders

Si los Stakeholders no acuden a el Sprint Review, entonces se pierde la transparencia, especialmente si estos necesitan de “reuniones” y “reportes” especiales. La interacción entre los Stakeholders y el equipo Scrum es fundamental para que ambos tengan una sensación adecuada de cómo van las cosas.

El Sprint Review no es una demo

En ocasiones, el Sprint Review se convierte en una “demo” e incluso se le llama así. Esta es una señal de una manera bastante pobre de hacer Scrum. Muy pobre. El Sprint Review tiene dos objetivos: Inspeccionar el incremento terminado y adaptar el Product Backlog.

Para cumplir estos objetivos se revisa el Sprint Backlog y se muestra el producto, dando la oportunidad a las partes interesadas de poner en cuestión y preguntar lo que deseen sobre el mismo. También se da información sobre condiciones que pudieran afectar a los objetivos del negocio o del producto. En ocasiones, el Product Owner hace una reunión de pre-planning o similar con los Stakeholders. Esta reunión no sirve a la transparencia, pata fundamental de Scrum.

Tampoco es el momento de aplaudir al equipo de desarrollo. El concepto de aplaudir va asociado a un buen trabajo, y a pesar de que puede dar la sensación de que es la manera de dar feedback al equipo Scrum, no es la más adecuada. El motivo es que esta es una reunión de trabajo, no una demostración del trabajo. La mejor manera de retroalimentar al equipo es mediante el feedback sobre el Incremento y el Product Backlog.

Si hoy aplaudo… ¿Quiere decir que mañana puedo abuchear?.

El Sprint Review no es el momento de aceptar Product Backlog Ítems terminados

Otras dos señales de una manera pobre de hacer Scrum son cuando el Product Owner “acepta” los PBIs terminados en el Sprint Review. Esto puede indicar falta de colaboración entre el equipo Scrum -o “Product Owner ausente”- o que el equipo trabaja en todas las tareas del Sprint Backlog a la vez, creando un burndown plano con una caída el último día del Sprint. Estos equipos probablemente son principiantes en Scrum y todavía tienen problemas de colaboración y comunicación entre ellos.

El Product Owner debe de ir inspeccionando y aceptando ítems durante todo el Sprint y, por tanto, conocer de primera mano como es el Incremento. Al contrario, el Product Owner ES la persona responsable de mostrar el incremento durante el Sprint Review a los Stakeholders y rendir cuentas por sus decisiones.

El Sprint Review es el momento de actualizar información del negocio

Algunas organizaciones están implementando reuniones especificas -tipo all-hands– para informar a todo el mundo de las condiciones de negocio actualizadas. Durante el Sprint Review es un momento perfecto para esta operación. Todos los Stakeholders juntos. Los equipos Scrum. ¿Qué mejor?

Es importante hacer una actualización de las condiciones de negocio (competencia, market share, profitability, etc..) durante esta reunión para poder proceder a adaptar el Product Backlog a la vista de todos, con la información que tiene el Product Owner. El principal impedimento en estos casos es la reticencia a ser transparente, ya que esta operación deja muy poco margen para la política corporativa de pasillo, obligando a los implicados a retratarse frente al resto de compañeros. Así es cómo debe ser. Así es como Scrum funciona.

Si Scrum tiene que ser reducido a una sola cosa, esta es entregar un incremento terminado cada Sprint, y en esto el Sprint Review juega un papel fundamental.

Empezar en Agile: guía fundamental para Managers

Tanto si usas Scrum o cualquier otra metodología ágil y eres Manager, tu trabajo va a experimentar un gran cambio. Pronto. Un cambio casi total. Mientras que antes tu trabajo consistía en gestionar o coordinar, ahora tu trabajo consiste en facilitar que los equipos ágiles puedan hacer su trabajo.

La historia del Management

El management es un invento del siglo XX, una reminiscencia de la Revolución Industrial. Aunque nos suele muy lejano, todavía vivimos en esa era. Transformación Digital. No es sino una vuelta de tuerca más al fenómeno de la automatización que comenzó con el ferrocarril.

Management es un invento que da una respuesta a algo que nunca había pasado antes. Gracias a la automatización, ahora se podía separar el hacer el trabajo y pensar sobre el trabajo. Los operarios de una fabrica se podían concentrar en una tarea relativamente complicada y ser parte de algo mayor, como hacer puertas de un vehículo a motor. Separación total. El Manager sabía del proceso completo y el operario de su trabajo. El manager estaba arriba. El operario abajo.

Hace 80 años, el manager podía medir lo que hacía el operario porque conocía el trabajo mejor que el. A día de hoy, el manager desconoce la mayor parte del trabajo que hacen sus reportes directos. Y eso está bien..El problema es que el trabajo ha cambiado. En 50 años hemos pasado de una situación en la que el manager sabía sobre todo el trabajo a una situación en la que, especialmente en el software, el desarrollador sabe más sobre lo que está haciendo y las herramientas que está usando que lo que sabe su jefe. Eso ha hecho que el concepto de management quede completamente obsoleto. El trabajo del Manager en Agile no tiene nada que ver con lo que ha hecho anteriormente.

La complejidad de desarrollar software

Desarrollar software es complejo. De hecho es más complejo que cualquier otro tipo de ingeniería. Las condiciones cambian, la tecnología nunca llega a poder ser dominada -y para cuando lo es, cambia drásticamente- y los requerimientos cambian cada vez que el usuario mira la aplicación. Si existiera una organización que representara a todos los ingenieros, su motto sería: Esto no es lo que yo quería.

Para lidiar con la complejidad es necesario maximizar la capacidad de gestionar el riesgo. Utilizar iteraciones cortas. Ciclos de feedback rápidos. Ser capaz de inspeccionar y adaptar de forma inmediata. Para poder hacer eso, es necesario trasladar gran parte de las responsabilidades del Manager hacia abajo.

En un entorno ágil, los managers no toman decisiones, sino que facilitan que otros las tomen. No gestionan, sino que ayudan a otros a gestionar. Dividimos la organización en pedacitos pequeños en los que cada persona tiene una pequeña responsabilidad. Si se hace demasiado grande, la dividimos aún más. Nadie posee suficiente para ser demasiado poderoso y al mismo tiempo nadie posee suficiente para poner en peligro a toda la organización.

La alternativa ágil al Management tradicional

Jurgen Appelo, con su Management 3.0 did un pistoletazo de salida a una nueva forma de ser Manager en un entorno ágil. En estos entornos el manager tiene una influencia indirecta, y lo que hace es gestionar un entorno, de la misma manera que gestionaría un entorno en la naturaleza.

¿Extraño? Aquellos que cultivan bonsais, crían acuarios o tienen una pequeña huerta nunca pensarían en decirle a sus peces que coman o hacer performance reviews sobre el crecimiento de su pequeño Ficus. En lugar de eso, intentan reproducir entornos reales, añadiendo sales o eliminando plagas. Lo mismo hace un Manager en un entorno ágil.

Un Manager ágil no tiene por qué asistir a un curso de Management 3.0, ni haber leído un libro sobre Agile Management; es más, es probable que muchas de las cosas que haya hecho antes ya estén orientadas a crear ese entorno donde la gente pueda crecer y desarrollarse.

Algunas responsabilidades de un Manager en un entorno ágil

Facilitar la adopción de un método que ayude a lidiar con la complejidad, como Scrum o Kanban. Los Managers en ocasiones son el mayor impedimento a la implantación ágil, cuando en realidad pueden ser su mayor aliados. Estar convencido del paso, para asegurar la supervivencia y competitividad de la organización es fundamental. En un entorno ágil, el Manager es el coach del método y no el director del trabajo.
Gestionar riesgos a través de la transparencia. Un Manager ágil ayuda a la gestión de riesgos manteniendo la transparencia. Una política de e-mail o salarios abierta. Facilidades para saber lo que pasa en la organización como las kudos-box o la promoción de herramientas de valor como el Net Promoter Score son parte del trabajo de un manager ágil.
Promocionar la auto-organización y auto-gestión como parte de la gestión de la complejidad. La auto-organización juega un papel fundamental, y aceptar la incertidumbre sobre lo que puede ocurrir forma parte de esa promoción. Muchas organizaciones invierten ingentes cantidades de recursos en intentar predecir en lugar de aceptar que este mundo y la economía son cambiantes e intentar adaptarse tan pronto como detectan una desviación.

Y después… ¿Qué?

Es probable que como Manager, pienses o conoces a alguien que piense que esto no es para ellos. Incluso que esto es una moda pasajera. O un poco más de humo. Te entiendo perfectamente. Sin embargo, si eres manager, quizás también tengas esa sensación de que tu trabajo está cambiando y todavía no sabes muy bien hacia donde se dirige.

Es el momento de, al menos, echar un vistazo al otro lado de la puerta y saber lo que te espera. Créeme. Te va a gustar.

Cuatro herramientas básicas de un Product Owner

La labor del Product Owner es maximizar el valor del producto. Muchos Product Owners centran su labor en el análisis de requerimientos y gestión del Product Backlog y desconocen cual es el valor que el producto que gestionan ofrece al usuario final. Además, las métricas y la gestión del presupuesto también son responsabilidad del Product Owner. ¿Qué herramientas utilizar para asegurar que el producto deleita a los usuarios?

Business model canvas

El Business Model Canvas es una herramienta de gestión y estrategia de producto diseñada por Alexander Osterwalder. Es un mapa visual con elementos que describen la propuesta de valor del producto, infraestructura, clientes y financiación.

Es una herramientas excepcional para alinear expectativas en torno al producto, ya que permite una visión holística de muchas variables que afectan a la forma, tiempo y orden en el que se desarrolla el producto.

Product Box

Product Box es una actividad de Juegos de innovación orientada a descubrir los elementos básicos del producto que mejor representan la esencia del mismo. Cómo actividad colaborativa, también ayuda a alinear cuales son las expectativas en torno al producto, y enfocarse en aquellas características que realmente resuelven problemas para el consumidor o usuario final.

Durante el curso de Product Owner, muchos estudiantes descubren aspectos básicos sobre el producto que desarrollan en la actividad del Product BoxEl Product Box no tiene por qué aplicarse exclusivamente a productos orientados a consumidores, sino que es perfectamente viable para empresas y organizaciones que trabajan para otras empresas. De hecho, es en estas situaciones donde cobra más sentido; establecer una propuesta de valor clara para el desarrollo facilita el desarrollo de producto y alineamiento de la organización alrededor del mismo.

Product Vision

El libro Crossing the Chasm es considerado una de las biblias en torno al marketing y venta de productos tecnológicos. Una de las actividades que sugiere para identificar la propuesta de valor del producto es establecer una visión en torno al producto, tal y cómo se expone en la imagen de arriba. La declaración de visión incluye al cliente, el problema, la solución y las mejoras en torno a la competencia.

En general, el libro es una lectura obligada para todos aquellos que, como Product Owners, tienen un papel fundamental en las decisiones en torno a la dirección que tiene que tomar el desarrollo de producto.

Métricas

EBMgt es a la organización lo que Scrum es al desarrollo de producto, un marco para medir y facilitar el cambio de forma iterativa e incrementalSorprendentemente, quizás debido al foco de las implantaciones ágiles en la tecnología y no en el producto, es la falta del uso de métricas que permitan entender el valor de un producto y la agilidad organizacional. Este punto, que debería ser el inicio de cualquier esfuerzo por ser más ágiles, normalmente se olvida por completo. Así, el éxito de una iniciativa no puede ser medido y lo único que quedan son sensaciones alrededor, opiniones subjetivas.

Evidence based-management es una propuesta para tomar decisiones de management y facilitar el cambio organizacional de Scrum.org. En el whitepaper de EBMgt, Gunther Verheyen desgrana cuales son los elementos de este framework poco conocido para medir la transformación que la agilidad supone en los productos y las organizaciones.