Product Owner & Scrum Master: ¿Cómo hacemos dupla?

María Teresa Jara y Yudenia Ramírez trabajaron juntas en Sodimac, como Product Owner (P.O.) y Scrum Master, respectivamente. Ahí, estuvieron a cargo de un producto operacional que impactaba — y todavía impacta — a 5 países: Chile, Perú, Argentina, Colombia y Brasil. Actualmente, ambas están en distintas compañías: Tere se fue a Walmart, y Yude a Amazon, donde hoy se desempeña como Customer Solutions Manager. En esta conversación, nos cuentan cómo crear un producto y un equipo exitoso trabajando como dupla.

¿De qué se trata tu rol?

Tere: Yo siento que la explicación coloquial es esta: ser P.O. es la digievolución del jefe de proyectos. El jefe de proyectos se hace cargo, como dice su nombre, de un proyecto específico, pero la diferencia es que entra, hace lo que tiene que hacer, y sale. En cambio, el P.O. es alguien que tiene que hacer crecer y empaparse del producto, no solamente velar porque los desarrollos se hagan de manera correcta– o lo más correcta posible, porque nunca hay 0 error, siempre hay una brecha que podría mejorarse, por eso existen los MVPs. La idea del P.O. es ir generando valor oportuno, partir de algo pequeño y hacerlo crecer. Por eso, uno se involucra mucho dentro del producto, y es lo que me llevó a este rol, porque mi forma de trabajar era involucrarme mucho en lo que hacía, me gustaba ver cómo evolucionaba lo que yo desarrollaba, qué impacto generaba…porque además, el P.O. tiene que ver los KPI que impacta esto. Es decir, lo que yo estoy haciendo, en qué impacta, qué le trae como retorno a la compañía. Y si bien hay que pensar en un retorno de la inversión, también hay que pensar que hay un usuario detrás de eso que lo va a utilizar, y en cómo lo va a utilizar. Porque si el usuario lo usa bien… y es una frase nos encantaba declarar con la Yude: “un colaborador feliz, un cliente feliz”.

Yude: Yo diría que el rol de Scrum Master es una versión en los equipos Agile como de Project Manager, donde tú tienes la responsabilidad de velar porque el equipo siga las prácticas de agilidad que están establecidas, ver la salud del equipo y del producto que están trabajando. Es la versión menos técnica del Project Manager, donde tiene menos responsabilidad de lo que es finanza y el cronograma (esas partes más “duras” del proyecto), y tiene un componente más psicológico, porque una de las funciones principales del Scrum Master es facilitar que el equipo de trabajo evolucione no sólo como grupo sino que también individualmente. Cuando trabajaba con Tere hacía ese rol y me metía también en todas las demás cosas jajaja.

¿Cómo trabaja un P.O. con un Scrum Master?

Tere: La descripción formal es la “trilogía”, así se llama un proyecto trabajado en célula. La trilogía habla de que hay una parte que vela por el negocio, que es el P.O. O sea, yo velo por que los proyectos sean un retorno a la inversión del negocio. Después, la segunda parte es la parte del Scrum, que vela porque el equipo tenga un equilibrio entre lo que se está exigiendo, y que cumpla con las normativas que tiene el Agile. No sólo que se cumplan las ceremonias, sino que dentro de ellas exista una dinámica donde todos se respeten y se tomen en cuenta las opiniones de los demás. Por ese motivo, el Scrum Master tiene que ser el mejor amigo del P.O., si no ocurre esa cohesión, la verdad es que es bien difícil que fluya el equipo. De hecho, nosotros veíamos a otros equipos que estaban alrededor nuestro, donde habían P.O.s con Scrum Masters donde la relación era como una lucha, porque el Scrum trataba de imponer su punto, el P.O. trataba de exigirle al equipo ciertas cosas que tal vez el Scrum pensaba que eran absurdas…al final no lograban una cohesión entre ambos mundos, sino que eran polos opuestos. Y bueno, la tercera es la técnica. El P.O. no vive sin el equipo de desarrollo. Dentro del equipo de desarrollo no sólo hay desarrolladores o developers, sino que es todo el equipo que desarrolla el producto: devs, UX, y QA. Entonces, esa es la trilogía: tiene que existir un equipo técnico que crea en el Product Owner, que el P.O. tenga confianza con el equipo técnico, y finalmente un Scrum Master que sea un puente entre los dos.

Y esa es la otra pega del P.O., ser líder. Es la clásica diferencia entre líder y jefe, que tal vez sea un poco obvio de decir, pero el P.O. tiene que convencer al equipo de que lo que está haciendo es algo bueno. Porque el equipo de desarrollo te puede cuestionar, y así debería ser en todo caso– ya sea trabajando en Agile o cascada, o lo que sea. Cuando el equipo de desarrollo dice “¿Por qué estoy haciendo esto?”, “¿A quién le va a servir esto?”, a mí me encanta que hagan esas preguntas porque significa que también están involucrados dentro del proyecto, están empapados con el producto, y les gusta lo que hacen. Todo el equipo tiene que estar convencido de que lo que está haciendo va a generar un valor — si el P.O. logra generar ese convencimiento, la dinámica es demasiado genial.

Yude: Bueno, por definición, el P.O. es el dueño del producto: es responsable de interactuar directamente con las áreas de negocios y los stakeholders para tener una estrategia de crecimiento, de desarrollo del producto, definir qué cosas se van a hacer, qué cosas son importantes, cómo se van a trabajar cada una de las funcionalidades que se tienen, por qué son importantes, cómo se van a hacer, y obviamente posicionarlo dentro del equipo. El P.O. es quien tiene la palabra final, pero obviamente tiene que contar con la opinión del resto del equipo con el que está trabajando. En mi visión, el Scrum Master normalmente debería estar muy alineado con el P.O., porque al final es quien vela porque el equipo avance y que tenga una buena dinámica con el liderazgo.
Muchas veces se dan conflictos por P.O.s que son un poco “elevados” y dicen: “yo soy el dueño y lo que digo yo es lo que vale”, pero el equipo puede tener otra opinión desde el punto de vista técnico, que es importante y tiene que ser considerada. Entonces, la intención es lograr que haya ese balance entre lo que está viendo el P.O. y lo que puede hacer el equipo, para que la señal que se dé sea la más saludable posible y los productos puedan crecer. Con la Tere era muy fácil, porque la Tere es una persona que escucha, siempre estaba abierta a que el equipo le diera su opinión de qué podíamos construir, qué veíamos como prioridad, cuál era el esfuerzo, además, de que el equipo entendiera el porqué. Ese era un valor muy importante que la Tere aporta como P.O., y ojalá todos lo hicieran, y es que el equipo entienda por qué una funcionalidad es importante para el cliente final. O sea, no es que “este botón va aquí y tiene que actuar de esta manera”, sino por qué son importantes, qué valor le traen al cliente final, qué valor le traen a la organización… porque tienes que sentir orgullo cuando salga a producción.

¿Y qué pasa cuando no hay Scrum Master en el equipo?

Tere: Que la agilidad ya esté instaurada no significa que un equipo no necesita un Scrum Master, siempre se necesita. Eso sí, hay equipos que lo necesitan más que otros. Por ejemplo, cuando un equipo llega a tal madurez, y se da esa cohesión entre el P.O. y el equipo, el Scrum no va a tener que gestionar tanto o influir tanto en los procesos. Por eso, la Yude era más que un Scrum Master, porque era fuera de lo común: la Yude conocía demasiado el negocio. Incluso, para mí, era una reemplazante natural dentro del equipo. Si yo no estaba, la Yude podía perfectamente liderar al equipo sola. El equipo nos veía a las dos como líderes, y ambas éramos respetadas porque sabían que estábamos de acuerdo.

Entonces, eso es lo que nos gustaba de trabajar juntas, porque en general, entre las mujeres (en la generación mía) cuando nos conocíamos era como competencia, e incluso la gente a tu entorno te metía cizaña para que compitieras. Escapar de esa lógica fue el gran logro que tuvimos con la Yude. El éxito que tuvimos como dupla fue porque fuimos un complemento y no una competencia. La Yude tenía ciertas habilidades que yo no tenía, y viceversa. De repente llegábamos a reuniones donde una tomaba la postura severa y la otra ponía los paños fríos. Con la Yude nos mirábamos no más y ya sabíamos qué rol teníamos que tomar cada una en esas instancias. Se nos daba de forma súper fluida, pero tiene que ver con la generosidad que tuvimos las dos en el proceso. Tiene que ver con el respeto también, era un respeto mutuo donde las dos nos admirábamos en cada una de nuestras fortalezas.

¿Qué desafíos había en el trabajo juntas?

Tere: Lo más desafiante es lograr conocerse y complementarse, porque al final, la pega de alguna forma la vas a hacer, el tema es cómo la haces sin sufrir en el proceso. Porque los otros Scrum con los otros P.O., tal vez se peleaban, pero llegaban al resultado igual — el tema es que se demoraban más. En consecuencia, nosotros teníamos mejores resultados como producto. De hecho, éramos el producto estrella porque lográbamos hacer cosas con mayor rapidez, y bien.

Yude: Un desafío fue lograr que las prioridades fueran realmente acordes a las capacidades del equipo. La Tere como P.O. me apoyaba a mí, en una cosa que era más bien mi responsabilidad, el crecimiento del equipo. Era un equipo súper joven, que armamos prácticamente de cero, entonces, entre más joven es el equipo tienes que ayudar a que las dinámicas entre ellos sean saludables, a que los conflictos aporten valor, sean constructivos, y que tengan retornos positivos para el equipo. Ese era uno de los puntos donde la Tere me apoyaba mucho, y lográbamos tener las conversaciones difíciles, que no tenían que ver con el producto, tenían que ver con el perfeccionamiento de cada una de las personas del equipo, cómo crecían, qué estrategia y feedback teníamos con ellos. Eso más allá del producto, creo que fue una de las cosas más importantes que trabajamos juntas, uno de los desafíos más grandes fue lograr que un equipo tan joven, tan junior, pudiera hacer un producto con un alcance regional, en todas las tiendas, para todos los trabajadores, y que además, las distintas gerencias nos buscaran para tratar de tener una funcionalidad dentro del producto, es decir, que el producto le diera soporte a los procesos que ellos hacían — porque veían el valor de las cosas que se estaban logrando.

Otro challenge o momento difícil, fue en casos donde tuvimos que despedir gente del equipo. Cosas de este tipo siempre son difíciles, y tratamos de manejarlo como un frente unido. Si bien podemos tener diferencias de opinión, tratamos de llegar a un acuerdo, a un punto que sea conveniente para todos, y a partir de ese momento actuamos como un solo frente con la decisión que hayamos tomado. Una vez que el equipo haya tomado una decisión, mantenerse ahí y evolucionar en favor de eso.

¿Definieron alguna metodología para que se diera así, o se dio orgánicamente?

Tere: Yo creo que como nos respetábamos, yo respetaba su espacio y ella el mío. Por ejemplo, cuando me fui con pre y post natal, la Yude me reemplazó. De hecho cuando me preguntaron quién me puede reemplazar, yo dije “la Yude”. Y eso que no éramos tan amigas, sólo nos conocíamos y yo cachaba que era súper seca, por eso pensé en ella. Y la Yude como también me respetaba, me preguntó “oye Tere, ¿Cómo abordamos estos temas?, ¿Qué hago cuando te vayas?” Ella me incluía, porque cualquier persona hubiera dicho “ya, que se vaya luego, y cuando yo lo tome lo hago como quiero”. Nosotros nos juntamos, coordinamos mi salida, ordenamos el backlog, y de a poquito le empecé a traspasar tareas de liderazgo. De hecho, alguien me dijo una vez “estoy preocupado porque no conozco tanto a la Yude, no sé si va a hacer las cosas como tú”. Y yo le dije, tranquilo, la Yude va a hacer las cosas incluso mejor que yo. Es decir, también yo dejé la confianza instaurada en los stakeholders, porque podría haber dicho “yo también estoy nerviosa, porque no sé si va a hacer las cosas igual”, o “no te preocupes, voy a volver luego”. Eso habría sido feo de mi parte. Así que le dije a la Yude que no me llamara, porque lo iba a hacer bien y porque todas las decisiones que ella tomara, a mi vuelta yo las iba a respaldar.

Siempre conversamos mucho. Y esa es la clave, conversar mucho. Yo le digo a mi equipo que puede ser aburrido que conversemos tanto, pero es la única forma de conocernos para acoplarnos. Me gusta hacer analogías, y tengo esta donde cada persona de un equipo es parte de un motor: cada parte tiene su función, y al acoplarse hace que el motor pueda partir. Muchas veces, en nuestro caso, el motor no partió. Porque los equipos también mutan, cuando se va una persona, se tiene que volver a acoplar. Y esa es la otra analogía que yo cuento: cuando tú estás en un grupo bailando, todo fluye porque todos ya se saben la coreografía, pero cuando alguien se va y entra alguien nuevo, la coreografía cambia. Ese es otro desafío, poder replantear los equipos y poder reconstruirse.

¿Y cómo se acopla tu rol con el equipo UX?

Tere: De partida, nosotros no teníamos UX, y eso me tenía enferma. De hecho, tuvimos que defender con la Yude el incorporar un equipo de UX. Lo que pasa, es que yo vengo del mundo del ecommerce, y ahí es normal trabajar con UX. Por eso cuando llegué a operaciones, consideré que UX era necesario, porque cuando tu vas a la operación, te das cuenta de que tiran una pantalla, escupen tres botones y mandan a leer el manual para aprender a usarlo. Entonces, con la Yude nos empezamos a dar cuenta que la aplicación no la usaban, había baja adherencia, habían muchos problemas que no se entendían. Y ahí empezamos a ir a locales, algo que hasta el día de hoy hago mucho: ir a terreno. Y vimos cómo la estaban usando, si se entendía o no…entonces, necesitábamos el apoyo de un UX Research que fuera a investigar.

Además, las aplicaciones operacionales se tienen que adaptar a los procesos operacionales. Y nosotros cuestionábamos esos procesos, porque un error que se suele cometer es que toman un proceso operacional, le meten una aplicación, y el mismo proceso operacional malo que tenías lo terminas automatizando. Entonces, nosotros decíamos “ya, así se hace hoy día, pero para mejorar esto, tenemos que implementar esto otro primero…y tiene que conversar con la parte tecnológica”. Entonces, ¿Cómo vendimos la idea de tener un equipo UX?, un día un gerente nos dijo que para qué lo queríamos si esto no lo veía el cliente final. Le dijimos, la respuesta es súper simple: para tú poder lograr la promesa de venta, yo antes necesito ejecutar un proceso operacional que me permita cumplir con esa promesa. Si yo no cumplo, tú no cumples y perdemos un cliente. Antes no se preocupaban de darle una aplicación atractiva al usuario, no le vendían la app. Nosotros la brandeamos como si fuera una app de venta, pero en vez de ser de venta, era operacional. Era usable, bonita, más simple. Nosotras éramos vendedoras de nuestro producto, se lo vendíamos a los colaboradores.

Yude: Inicialmente, casi que el gerente nos daba un diseño de lo que esperaba que tuviera, la Tere lo procesaba un poco, lo validaba, y ahí el equipo de desarrollo lo implementaba. Después, llevábamos propuestas basadas en todo el research que hace UX/UI, con la data en la mano. Entonces, cambiamos todo ese approach, y además le incorporamos toda una propuesta comunicacional. Fue una estrategia combinada con la UX Designer y también con los stakeholders lo que nos dió un gran apoyo en posicionar la app como una herramienta de trabajo.

Yo creo que de un rol de Scrum estándar, la relación con un UX/UI es que tengan las tareas, pero yo me metí un poco más de lo que corresponde porque me gusta y porque creo que si uno como Scrum Master tiene que lograr que el producto evolucione, la cara del producto es importante, y eso es responsabilidad en buena medida de UX. Entonces, trataba de siempre ayudar a organizar, o traer nuevas ideas, buscar referentes, etc. Y creo que ahí tuvimos la suerte que los perfiles de UX/UI que trabajábamos también tuvieran la pasión no solo de hacer la maqueta, sino que se aplicara conocimiento de research, de análisis de datos, etc.

Tere: Y lo otro, nos preocupábamos de que cada uno del equipo se mostrara, de que brillara.

Yude: Ese es un tema super importante, y que a veces es medio complicado, porque cuando tienes un equipo, debería ser capaz de presentar cada una de las cosas que hace, de mostrarse. Pero muchas veces, tienes malas prácticas donde el P.O. es quien presenta todo, es el dueño de todo y quien brilla. En nuestro caso, tratábamos de que en las presentaciones y demos cada uno pudiera presentar, aunque fueran súper introvertidos, y fuera una tortura para ellos jajaj. Pero para ayudarlos a crecer, y para que los demás de la organización vieran que aportaban valor, los invitábamos a participar. Tratábamos de que brillaran todos, y creo que es una dinámica saludable que la Tere debe mantener ahora en Walmart.

Tere: Tal cual, UX es un referente para el negocio al igual que yo.

¿Qué tips le darías a alguien que está comenzando el rol de PO o de Scrum?

Tere:

1. El primer tip es: conoce lo que están haciendo en terreno. No te quedes con lo que dice el gerente o el stakeholder. Anda a “donde las papas queman” a ver quiénes ocupan tu app, qué edades tienen, qué dispositivos usan. Y con eso, conoce a tu usuario final para ser una contraparte válida con tu stakeholder y que tengas una conversación enriquecedora con él.
2. También, es necesario que el PO conozca el negocio, así tiene su mirada y puede cruzarla con la de los stakeholders. Porque tenemos que ofrecerles algo que les genere valor a ellos. Por eso, mi segundo tip es: conoce los KPI que te mueven. Porque después tienes que hacerle seguimiento a todas las funcionalidades que tú implementas, tienes que ver si realmente generó el efecto que tú esperabas. Y si no aporta, sobra.
3. Y tercero: trabaja la confianza con tu equipo. Si no confías en tu equipo, es súper difícil que la cosa fluya.

Yude:

1. Primero, trabaja tu relación con el P.O. Tienes que conocer al producto y entender las intenciones detrás de cada una de las cosas que el Product Owner quiera hacer. No puedes estar ajeno al producto, y tienes que tratar de actuar como un frente unido.
2. Segundo: genera relaciones con cada una de las personas dentro del equipo. No basta con ser sólo quien gestiona, sino que tienes que conocer las fortalezas y debilidades de cada uno, lo que aporta cada uno, para poder reconocer qué está pasando, cuáles son los conflictos, cómo usar esos conflictos de forma constructiva para promover el crecimiento. Y para eso necesitas más inteligencia emocional, empatía, respirar profundo…a veces hacer un poco de yoga. Trata de potenciar tu parte psicóloga de un Project Manager.

¿Te hicieron sentido estos consejos?, ¿Quieres saber más sobre Tere y Yude? Te invitamos a seguirlas a través de LinkedIn:

María Teresa Jara

Yudenia Ramírez