Escalar Scrum: Cuántos Product Owner debería haber

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.