Cuando la dueña de producto no podía decir que no
Este es un escenario compuesto; el equipo y las personas son inventados para ilustrar un patrón que vemos a menudo. Un equipo Scrum distribuido, recién pasado al teletrabajo durante la primavera de 2021, tenía todo lo que pide la Guía Scrum: un Product Owner, un Scrum Master, desarrolladores, un Product Backlog, los eventos. Sobre el papel era de manual. En la práctica, los sprints terminaban con trabajo a medias y un backlog que cambiaba de forma cada pocos días. El diagnóstico llevó tiempo porque el problema no era visible en ningún evento concreto. Vivía en quién decidía realmente qué.
El síntoma
La Product Owner del equipo, llamémosla Dana, era concienzuda y bien querida. Pero cada decisión importante sobre prioridad la sorteaba. Un director sénior escribía directamente a un desarrollador con una petición «urgente». Una parte interesada reordenaba el backlog en una conversación aparte. Dana redactaba los elementos y dirigía las revisiones, pero no podía decirle que no a nadie, de modo que el backlog reflejaba a quien había hablado con el equipo más recientemente en vez de lo más valioso. El equipo estaba ocupado y no iba a ninguna parte.
Lo que dice realmente la Guía Scrum
La Guía Scrum es clara: el Product Owner es responsable de maximizar el valor del producto, y es una sola persona, no un comité. Sobre todo, señala que para que el Product Owner tenga éxito, toda la organización debe respetar sus decisiones. Esas decisiones son visibles en el Product Backlog y en el orden de sus elementos. Toda la organización puede intentar cambiar el backlog persuadiendo al Product Owner — pero pasa por él, no a su alrededor. Dana tenía la responsabilidad sin la autoridad, la forma más común en que el rol fracasa.
Qué cambió
El arreglo fue organizativo, no de procedimiento. Se redujo a unos pocos movimientos concretos.
Un backlog, una dueña. Toda petición — sin importar el rango del solicitante — se encauzaba a Dana y se reflejaba en el único Product Backlog. Sin canales paralelos hacia los desarrolladores.
Decisiones hechas visibles. El orden del backlog se convirtió en el registro público de la prioridad. Si una parte interesada quería algo antes, defendía su caso ante Dana y el intercambio era explícito: otra cosa bajaba.
El liderazgo la respaldó en público. El director patrocinador dijo al grupo de partes interesadas, en términos claros, que el orden de Dana se mantenía salvo que la convencieran de lo contrario. Esa frase hizo más que cualquier cambio de proceso.
Empezó a decir que no, con razones. Un verdadero Product Owner rechaza mucho más de lo que acepta. Dana comenzó a explicar por qué un elemento estaba donde estaba, lo que construyó la confianza que permitió a la gente dejar de sortearla.
En pocos sprints el backlog se estabilizó, los sprints terminaron lo que empezaban, y el ajetreo constante se desvaneció. Nada de la tecnología ni de la destreza del equipo había cambiado. Lo que cambió fue que por fin se permitió decidir a una persona, y la organización aceptó vivir con sus decisiones. Un Product Owner que no puede decir que no no es un Product Owner; es un escribano de las prioridades de todos los demás.
Si sus equipos de entrega tienen los roles de Scrum pero no la autoridad que debería acompañarlos, el asesoramiento en entrega de programas y proyectos de XNM puede ayudarle a poner verdaderos derechos de decisión donde ya reside la responsabilidad.