Lo de escalar Scrum, o llevar la agilidad a empresas grandes, esta de moda. Veremos cuántas, y en que condiciones, consiguen hacerlo una realidad, pero, al menos, la inquietud está “ahí fuera”, y eso es bueno. Por escalar, yendo a lo facilón, estamos hablando de trabajar de manera ágil con más de un equipo.
Te recuerdo que un equipo Scrum no supera las 9 personas (recuerda el post de qué mucha gente en un equipo no es buena cosa), por lo que si tu empresa es más grande, y quiere trabajar de manera ágil, debería empezar a poner equipos en paralelo, todos ellos de menos de 10 personas.
Llegado este punto aparecen un montón de dudas. Scrum ya es bastante popular en nuestro entorno, sus roles son conocidos, su ciclo de vida, etc., pero el tema de escalar Scrum es mucho menos maduro, hay varias visiones (en ocasiones contrapuestas) del tema, y desconocimiento, al menos, en las empresas grandes nacionales.
Muchas de esas dudas vienen de la estructura de los equipos y el Product Owner. Intentaré dejarte una serie de post sobre dudas típicas al escalar Scrum (extraídas de las que a mí me hacen en aquellas empresas grandes en las que 233 Grados de TI está con temas de escalar Scrum).
Vamos con una breve… ¿cuántos Product Owner hay que tener? Tengo varios equipos y… ¿un Product Owner por equipo? ¿o un Product Owner para muchos equipos? (porque muchos Product Owner para un sólo equipo queda… descartado 🙂
Vamos primero a ver que dice la teoría. Por ejemplo, el marco LeSS, uno de los marcos de referencia para guiarse a la hora de escalar Scrum. Sin dar una cifra exacta, LeSS habla de que es posible escalar el rol del produc owner con una sola persona, es decir, propone la opción de un Product Owner para varios equipos.
Otro popular, y polémico, marco para escalar Scrum es SAFe. Según su protegida página (protegida porque su web no deja seleccionar texto para copiar y pegarlo, por ejemplo, para citarlo en este post, sí, increíble), normalmente un Product Owner es responsable de uno a dos equipos. Simplificando, un Product Owner por cada dos equipos.
El que se ha convertido en un modelo “de facto”, el envidiado y deseado por muchos a la hora del escalado ágil es… el modelo de Spotify, basado en una organización más plana. La idea que sugiere Spotify es un Product Owner por equipo. Es decir, Spotify hace uso de un Product Owner dedicado por equipo.
También otros más puristas de Scrum hablan de que debería haber un único Product Owner dedicado exclusivamente al equipo, es decir, un Product Owner por equipo.
En las propuestas de un Product Owner dedicado por equipo también entraría otro de los marcos que proponen cómo escalar Scrum, Nexus, que sugiere un Product Owner por equipo y a una escala superior un “Nexus Integration Team”, por cada 9 equipos, en el que hay otro Product Owner.
En resumen… que no está cerrado 100% este tema. La mayoría de las propuestas sugieren un único Product Owner dedicado por equipo. Pero algunas (SAFe y LeSS, principalmente) hablan de un Product Owner para varios equipos. Conclusión… experimenta, ten la visión clara, y prueba qué es lo que a ti mejor te funciona.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Las 3 matrices de priorización Ágil - 19 octubre, 2023
- Etapas del Agile Product Management - 12 octubre, 2023
- Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023
Nosotros solemos tener un mínimo de dos product owners por equipo. La teoría está muy bien, pero lo cierto es que muchas veces una sola persona no está disponible todos los días, o no tiene todo el know how necesario del negocio.
Como yo digo, con dos product owner en modo activo – activo, se reparten la carga de trabajo y tenemos backup!
Miguel, a menos que haya dos partes diferenciadas del producto que no se sobrepongan, tener dos voces con potestad para modificar el rumbo puede ocasionar muchos malos entendidos y una necesidad más de sincronización. En el caso de haber dos partes diferenciadas, estaríamos hablando simplemente de dos posibles equipos y estaríamos de nuevo en un PO por equipo.
Por otro lado, no hay que confundir que haya un único PO para que lo que diga éste sea fruto del conjunto de diferentes ideas y propuestas de diferentes personas. Simplemente significa que hay una persona a la que se le da total potestad para marcar el rumbo del producto. Del mismo modo no hay que confundir que una persona marque el rumbo del producto a que sea la persona que puede resolver todas las preguntas. Por un lado el PO responde qué y no cómo y por otro lado, no significa que tenga que ser el experto en todas las materias, no hay problema en que se traiga a una persona externa para cubrir las preguntas de un área que no es conocida por el PO (y no puede ser resuelta por el equipo).
Por otro lado el grado de necesidad que el equipo tiene del PO y la disponibilidad de éste puede ser un tema que tratar en una próxima retrospectiva.
Saludos.
Lo primero, gracias por el post Javier.
Interesante lo de 2 product owners por equipo, aunque me surgen algunas dudas del día a día. ¿Tienen absolutamente los dos la misma visión del producto para priorizar el backlog o a veces se pisan entre sí sus decisiones? Yo pienso que el product owner tiene que estar siempre disponible para el equipo, y si resulta que por funciones o responsabilidades de su puesto no puede, entonces hay que buscar otro. Por otro lado, cuando los necesitáis, ¿los convocais a los dos juntos o primero uno que luego le pregunta al otro? Por supuesto que no estoy diciendo que la teoría tenga que inmponerse, además de que cada empresa es un mundo, realmente estoy interesado en como funcionais de ests forma 😉 salu2
Hola,
Salvo que yo lo escribiera mal en el post, puse un P.O para dos equipos (según visión LeSS y SAFe) no dos P.O para un equipo, que cambia mucho.
Saludos
Hola Javier, me refería al comentario de Miguel Expósito, pero no le día al «responder» adecuado. Un saludo