Product Owner ó Scrum Master

¡Comparte!

Es común encontrar personas certificadas tanto Scrum Master como Product Owner. Por confuso que pueda ser para mí, no es extraño conversar – en persona o a través de redes sociales – con personas que por alguna razón se han certificado tanto Scrum Master, como Product Owner. ¿Acaso tiene algún sentido intentar especializarse en ambos roles? Este artículo te presenta argumentos para entender la diferencia entre los roles y cómo puedes apoyar tu crecimiento como Product Owner o Scrum Master.

Lo primero y lo más importante es definir cuál rol es el mejor para ti. Y la respuesta es: depende. Claro, como buen consultor, la respuesta más común que doy es «depende». Aunque si has leído mis artículos anteriores, sabes que no me gustan los puntos medios y me gusta aportar criterio a las personas que aún están indecisas o confundidas acerca de los roles Scrum Master y Product Owner.

Adelante te presento información clave para distinguir ambos roles y comprender mejor el potencial de cada uno. Más aún, si estás pensando en fortalecer tus capacidades o contratar a alguien con algún rol, este artículo de seguro será de mucha utilidad.

Scrum todo lo puede

Aunque Scrum es muy bueno, me rompe un poco ver que intentan aplicar Scrum en todas partes – un poco «a la maldita sea» diría un colombiano como yo.

Scrum no es nuevo y es muy similar a sus primos y hermanos ágiles. Un modelo iterativo de gestión que, a través de ciertas actividades y roles, promueve, entre otras cosas:

• Alineación
• Transparencia
• Mejor comunicación

Sin embargo, en nuestro tiempo – como ocurre con todas las modas – Scrum es nuestro nuevo «Martillo de Maslow».

Scrum: El nuevo martillo de Maslow

Maslow popularizó esta idea, también conocida como «La Ley del Martillo» o «El Martillo Dorado», en su libro The Psychology of Science publicado en 1966 que decía algo, más o menos así:

Es fácil suponer que, si la única herramienta que tienes a la mano es un martillo, puedes tratar cualquier cosa como si fuera un clavo.

Abraham Maslow

Scrum Master: El todopoderoso

En este sentido, si Scrum todo lo puede, pues el Scrum Master debe ser una suerte Dungeon Master cuyo poder es ilimitado.

En mi opinión, es todo lo contrario. Si tu sueño es convertirte en Scrum Master, lo primero y lo más importante es entender el poder del rol, las oportunidades que representa para ti y, desde luego, el contexto en el que te encasilla.

Así que vamos por partes.

¿Qué hace un Scrum Master?

Aunque la guía es Scrum es, IMHO un documento pobre y ambiguo con poco contenido, vamos a usarlo por respeto a los padres del modelo – que a diferencia de su guía que parece cada vez más un panfleto, si han dedicado su vida a cosas interesantes y proyectos destacados.

Scrum Master como embajador

Así que, desarticulemos la descripción del SM en la guía Scrum:

El Scrum Master es responsable^[1]La traducción de accountable por responsable no solo me parece inapropiada, también puede confundir al lector. Por eso mismo es importante que reflexiones las diferencias entre lo que significa «responsible» y «accountable» de establecer Scrum tal y como se define en la Guía de Scrum. Ellos hacen esto ayudando a todos a comprender la teoría y la práctica de Scrum, tanto dentro del Equipo Scrum como de la organización.

Tomado y traducido de la guía Scrum 2020 en inglés – https://scrumguides.org/scrum-guide.html

En resumen, el SM es un embajador del modelo. Algo similar a los PMBOK fan boys de hace unos años que andaban con sus entradas y salidas, sus procesos y herramientas como si no existiera un mañana y nada más allá del estándar.

El SM entonces se circunscribe al Equipo Scrum y a la organización donde ese equipo trabaja. Así que, si tu sueño es dirigir muchos equipos o grandes grupos, ser director de un área de TI o algo «un poco más amplio», ser SM no te va a llevar a allí.

Oportunidades del SM como embajador

1. Hoy en día hay muchas ofertas laborales para Scrum Master – aunque no es claro que esperan del rol, todas o casi todas exigen una certificación vigente.
2. Es un rol donde puedes desarrollar tus habilidades humanas y mejorar tus habilidades negociación y manejo del conflicto – a pequeña escala.
3. El marco Scrum – y más el modelo del Scrum Guide – es una lectura infantil e inocente. No necesitas años de estudio para comprender el rol. La comunidad ágil es muy activa en todo el mundo y de seguro podrás vincularte a grupos donde puedes debatir, aprender y experimentar.
4. Es un rol amplio y, si te apasiona, puedes ampliar tus capacidades más allá de Scrum, a gestionar equipos y motivar personas.

Riesgos del SM como embajador

1. El Scrum Master está circunscrito al Equipo Scrum dentro de una organización. Si tienes ambiciones de crecer o tener mayor poder – como dirigir un área o grandes equipos, el SM no te apalanca para esos roles. Incluso su pensamiento de pequeña escala puede ser un verdadero obstáculo si quieres liderar un gran equipo – hablo aquí de muchas personas, decenas o centenares.
2. Si te gusta tener el control sobre los requerimientos o el trabajo, definitivamente vas a sufrir como Scrum Master. No eres un jefe, eres un facilitador, incluso algunos hablan de «catalizador».
3. Si necesitas algo más que Scrum – que seguramente así es – un curso o certificación de SM es la mitad del primer paso. Lastimosamente muchos cursos y certificaciones solo te explican la guía y poco o nada te ayudan con la experiencia.
4. Es un rol amplio y un poco genérico. Si el tema de facilitar y apoyar no te apasiona, vas a aprender con muchos tropiezos que la guía no te ayuda a resolver en absoluto en el día a día de tu trabajo.

El Scrum Master construye sobre un marco abierto

El Scrum Master es responsable de la efectividad del Scrum Team. Lo logra al permitir que el equipo Scrum mejore sus prácticas, dentro del marco de Scrum.

Tomado y traducido de la guía Scrum 2020 – https://scrumguides.org/scrum-guide.html

Bueno, el Scrum Guide es, como lo he dicho varias veces, algo simple… tirando a incompleto^[2]Y no lo digo solo yo. La misma guía 2020 dice: «The Scrum framework is purposefully incomplete, only defining the parts required to implement Scrum theory«. Para muchos puede ser maravilloso. Para otros, un verdadero dolor de cabeza. De alguna manera debes llenar los espacios en blanco. Así que si tienes mucha experiencia, Scrum es una excelente ficha base, si no la tienes, estas perdido en el espacio de la ambigüedad y «las ideas bonitas».

Oportunidades del SM dentro de un marco incompleto

1. No tener un marco prescriptivo es bueno y evita los «trolls» que intentan hacer todo «by-the-book». Al mismo tiempo, expande el potencial de alcance del marco a proyectos más allá del SW – donde originalmente fue creado Scrum.
2. El pensamiento empírico es poderoso si se toma con seriedad. El empirismo no es sinónimo de «improvisación».

Riesgos del SM dentro de un marco incompleto

1. Si estás empezando, no tener un marco detallado es un dolor de cabeza. Los retos y problemas que enfrentarás requerirán de mucho estudio de tu parte y, en muchas ocasiones, apoyo de personas con experiencia.
2. El empirismo se confunde rápidamente con improvisación. No te dejes seducir. Aunque los agilistas radicales odian las recetas predefinidas, a veces para aprender a ser un gran chef es necesario aprender algunas recetas de cajón para luego, darles tu toque particular y especial – Te recomiendo darle una mirada al concepto Shuhari.

¿Cuál es el objetivo del Product Owner?

El Product Owner es responsable de maximizar el valor del producto resultante del trabajo del Scrum Team. La forma en que se hace esto puede variar ampliamente entre organizaciones, equipos Scrum e individuos.

Tomado y traducido de la guía Scrum 2020 – https://scrumguides.org/scrum-guide.html

El PO, como ven, tiene un rol fundamental en la entrega de valor. Siempre he pensado que se confunde con facilidad el rol del PO con el de un analista de negocio o incluso un «documentador». Y, aunque comparten cierta base no son iguales.

Maximizar el valor del producto significa que el trabajo del Equipo Scrum tiene una clara orientación a resultados y beneficios para el negocio. Y esto implica tener un pensamiento incremental.

Las responsabilidades del Product Owner

El marco Scrum define el rol de Product Owner, PO, o dueño del producto. Este rol es una persona con visión de negocio – y solo una persona. Esta persona debe tener un pensamiento orientado al beneficio o valor de negocio. Y en este sentido, es una persona cuyas responsabilidades incluyen además escuchar al cliente o consumidor, la organización, y en general el mercado en busca de «oportunidades y amenazas» para generar valor dentro del contexto del producto o servicio en desarrollo.

Más allá del marco Scrum, el rol del PO cumple ciertas funciones claves dentro de cualquier iniciativa.

• Identificar las oportunidades y amenazas para el negocio – dentro del contexto del producto o servicio en desarrollo
• Explorar nuevas y/o mejores funcionalidades para fortalecer el producto o servicio
• Establecer la ruta de desarrollo de un producto o servicio
• Gestionar el backlog
• Considerar los requerimientos o necesidades más allá del valor de negocio para mitigar la deuda técnica^[3]Esta función tiene detractores. Sin embargo, en mi experiencia, el PO no puede solo priorizar el negocio por encima de la tecnología que habilita la entrega de producto. Incluso sin ser experto técnico, debe aprender a equilibrar el avance del producto para mitigar luego productos que funcionalmente sean maravillosos, pero no sean capaces de escalar a una demanda exponencial, o que no puedan coexistir con otros productos y servicios de la misma empresa

El poder detrás del PO

En mi opinión, el rol del PO es mucho más estratégico y clave para el éxito de una evolución ágil, incluso más allá del Scrum Master. En otras palabras, una transformación del modelo de trabajo y gestión solo puede considerarse exitosa si se establece un buen flujo de valor de negocio y, por lo tanto, si el modelo escogido de base es Scrum, entonces el rol de PO es esencial. Por el contrario, ante la ausencia de un Scrum Master, aún es posible que el deseo o la necesidad de cambio, lleve al equipo y la organización a un modelo ágil exitoso – el SM en teoría reduce la resistencia al cambio.

El PO gestiona el Backlog de Producto y negocia con el equipo el Backlog del Sprint. Además, según la guía Scrum 2020:

1. Desarrolla y comunica explícitamente el objetivo del producto
2. Crea y comunica claramente los elementos del Backlog del producto
3. Ordena – aunque me gusta más da prioridad – a los elementos del Backlog de producto, y
4. Se asegura de que la Backlog de producto sea transparente, visible y entendido por todos los interesados

El rol del PO en un proyecto u organización

El PO se circunscribe al desarrollo y operación de un producto o servicio. Si el producto esa nuevo, seguramente hablamos de «proyecto», si el producto o servicio está en curso, tal vez el PO está asociado a un área o unidad de la organización.

En este sentido, un buen Product Owner ve la oportunidad de consolidar, unificar, priorizar y detallar todas las ideas, oportunidades, amenazas y retos que tiene un producto o servicio en desarrollo u operación.

Así mismo, comprende la importancia de mantener baja la deuda técnica, incluso si no comprende el detalle técnico. Así que vamos con un ejemplo hipotético:

Supongamos que he decidido construir una casa de descanso. Yo, un ingeniero de familia de arquitectos quisiera tener control sobre los requerimientos, funcionales e incluso algunos de diseño. Sin embargo, no soy arquitecto y debo equilibrar mis deseos con las restricciones técnicas que disponga el arquitecto, algún ingeniero estructural y, por supuesto, el presupuesto disponible.

Como PO, no puedo solo llenar la lista de requerimientos – backlog – con ideales o temas funcionales, desconociendo las restricciones propias del contexto de desarrollar el producto. Debo mantener el foco en el valor y el beneficio.

Oportunidades para el PO

• Si te gusta diseñar, definir y detallar productos o servicios. El rol de PO es para ti.
• No todo el mundo es bueno «estructurando productos» de forma incremental, así que hay muchas oportunidades y, un PO bueno y reconocido, tendrá siempre excelentes proyectos.
• Eres el puente entre negocio y desarrollo. Esto te conecta muy bien en la organización.
• Ves y controlas el resultado. Está en tus manos qué tan exitoso es un producto o servicio.

Riesgos para el PO

• Si no tienes poder sobre los requerimientos y otros elementos del Backlog podrías convertirte en un documentador, y así mismo, en el cuello de botella del proceso.
• Si no eres bueno estructurando productos, el concepto de incremental, puede ser muy doloroso y terminarías definiendo productos «incompletos» que siempre dependen de «otra cosa» para ser funcionales.
• Si la organización para la que trabajas no ve valor en tu rol, seguramente siempre tienes las manos atadas para proponer o estructurar. El juego político-organizacional puede ser un desafío en algunos contextos empresariales conservadores.
• Una gran deuda técnica socava la capacidad del PO de proponer funcionalidades valiosas. Muchas veces tu trabajo se puede convertir en «arreglar» y no en «proponer».

Nunca unificar Scrum Master y Product Owner

Si conoces de agilidad sabes que es un despropósito lo que acabas de leer. Pero la es que sucede, y mucho. Muchas organizaciones no comprenden este juego de pesos y contrapesos, ni ven valor en dar foco a ciertas funciones y responsabilidades.

Yo nunca he sido un defensor de un Scrum Master 100% dedicado y creo fielmente que un equipo maduro lo último que necesita es un SM o un facilitador de tiempo completo. Con un coach que pase de cuando en vez está más que bien. Bueno, eso creo yo.

Sin embargo, el Product Owner si es un rol clave y muchos proyectos se detienen o frenan porque no hay buenos insumos para avanzar en el trabajo. No están las prioridades o nadie ha pensado la manera de entregar valor de forma incremental.

En este sentido, siempre he defendido la importancia del rol de PO.

Comparación SM vs. PO

Consideraciones finales de los roles Product Owner y Scrum Master

1. Nunca intentes unificar ambos roles
2. Son roles diferentes y complementarios que ejercen un pulso de fuerzas -natural y sano para las organizaciones
3. El PO está orientado a los detalles del producto o servicio en desarrollo o mantenimiento. El SM está orientado al equipo y las «buenas maneras»
4. La proyección profesional de ambos roles es diferente
5. Las habilidades clave para el éxito de ambos roles son diferentes en algunos casos

Tienes comentarios, experiencias o sugerencias, déjame saber en los comentarios tu opinión.

¡Comparte!