Scrum está pensado como un marco simple pero suficiente para la entrega de productos complejos. Scrum no es una solución única, una bala de plata o una metodología completa. En cambio, Scrum proporciona los límites mínimos dentro de los cuales los equipos pueden autoorganizarse para resolver un problema complejo utilizando un enfoque empírico. Esta simplicidad es su mayor fortaleza, pero también es la fuente de muchas malas interpretaciones y mitos que rodean a Scrum. En esta serie de publicaciones, nosotros, sus ” Cazadores de mitos “, Christiaan Verwijs & Barry Overeem, abordaremos los mitos y malentendidos más comunes. 

PD: Las grandes imágenes son de Thea Schukken.

¿Es tu Product Owner la única persona que puede realizar cambios en el Product Backlog? ¿Su equipo de desarrollo le está pidiendo a su Product Owner que escriba y ordene Items en el Product Backlog? ¿Es el Product Owner la única persona con acceso de escribir a un Product Backlog en una herramienta digital como Jira?

En conjunto, el tema aquí es que el Product Owner es la persona responsable de mantener el Product Backlog. En este post mostraremos por qué esto es un mito.

¿Qué dice la guía Scrum?

La Guía de Scrum dice lo siguiente sobre el Product Backlog y quién es responsable de ella:

“El Product Owner es responsable del Product Backlog, incluido su contenido, disponibilidad y orden”.

Puede leer esta línea para reforzar la idea de que el Product Owner también debe hacer todas estas cosas. Por lo tanto, el Product Owner debe escribir todos los Item en el Product Backlog. El Product Owner debe ordenarlos. Y el Product Owner debe hacer que el Product Backlog del Productos esté disponible tanto para el equipo Scrum como para los Stakeholders.

Pero la Guía Scrum continúa describiendo que el Product Backlog es dinámico y evoluciona constantemente en “un proceso continuo en el que el Product Owner y el equipo de desarrollo colaboran en los detalles de los Items del Product Backlog”.

La palabra clave aquí es “responsable”. Pregúntate esto; ¿Puede un Product Owner maximizar el valor del trabajo realizado por el Equipo de Desarrollo si no está involucrado en lo que se incluye en el Product Backlog y en qué orden?

Causas comunes

Hay muchas razones diferentes para que este mito surja. Una causa común es cuando los Product Owners actúan como analistas (negocios) o entran en el rol desde este contexto. Desde esta perspectiva, puede parecer sensato que se encarguen de todos los ‘análisis de requisitos’ que se requieren para completar un Backlog del Producto. A menudo, los equipos de desarrollo fomentan esto para que puedan centrarse en lo que suponen que es su tarea más importante: escribir código. Pero no es así como se pensaron los roles.

Otra causa común es la interpretación de ‘Scrum como metodología’. Las organizaciones convierten con entusiasmo los roles de Scrum en descripciones formales de trabajo. Cuando Scrum es completamente nuevo para ellos intentan comprender los nuevos roles desde las perspectivas tradicionales: Product Owner son responsables de los requisitos (analistas), los Scrum Masters son responsables del equipo (líderes de equipo o gerentes de equipo) y los desarrolladores son responsables de escribir el código ( codificadores). Pero al hacerlo no entienden el propósito detrás del Marco Scrum. No entienden por qué estamos haciendo todo esto en primer lugar.

Así que volvamos a las raíces para que podamos entender.

Volver a lo esencial de Scrum

Para comprender mejor por qué esto es un mito, tenemos que volver a lo esencial. El Marco Scrum existe para disminuir los riesgos inherentes al desarrollo de productos y otros trabajos complejos. Con mucha frecuencia, el desarrollo de productos es un trabajo complejo en el que se desconoce más de lo que se sabe. Debido a esto, necesitamos una estrecha colaboración entre profesionales y la participación de muchas mentes para dar sentido a lo que está sucediendo e identificar los próximos pasos. En trabajos complejos la jerarquía solo se interpone en el camino de la creatividad, la motivación y la inteligencia de los equipos.

“En el trabajo complejo la jerarquía solo interfiere con la creatividad, la motivación y la inteligencia de los equipos”.

Desde esta perspectiva, no tiene sentido tratar al Product Owner como la única persona que puede crear elementos para el Product Backlog y ordenarlos. Al tratar al Product Owner de esta manera estamos introduciendo el pensamiento jerárquico en un marco que es fundamentalmente anti e ético.

Y esto va en ambos sentidos. Los Product Owners deben trabajar en estrecha colaboración con su equipo de desarrollo para crear Items para el Product Backlog y ordenarles que maximicen el valor del trabajo realizado por ellos. Los equipos de desarrollo, por otro lado, también deberían buscar esto de manera proactiva al ofrecer sugerencias para ambos Items en el Product Backlog como su orden. Deben trabajar activamente con los Product Owners para refinar y aclarar Items, asegurándose de que tanto el equipo Scrum como los Stakeholders ​​los entiendan. Scrum Masters, a su vez, debería ayudar tanto al Product Owner como al equipo de desarrollo a comprender que esta es la forma más efectiva de colaborar en un trabajo complejo.

De hecho, está perfectamente bien que el equipo de desarrollo sea aún más proactivo y ponga Items en el Product Backlog del producto o los vuelva a ordenar si el Product Owner cree que esta es la mejor manera de maximizar el valor de su trabajo. Pero, en última instancia, el Product Owner sigue siendo responsable de lo que figura en el Product Backlog del producto y en qué orden: tienen la última palabra. El Product Owner es la persona a la que debe acudir cuando este no sea el caso.

Está perfectamente bien que el equipo de desarrollo sea aún más proactivo y ponga elementos en la cartera de pedidos del producto o los vuelva a ordenar si el propietario del producto siente que esto maximiza el valor del trabajo que realizan

Consejos

• Organice ‘Talleres de descubrimiento de productos’ (Product Discovery Workshops) en los que invite a todos los miembros del Equipo Scrum a colaborar en la creación y el orden de Items en el Product Backlog. Pero tenga en cuenta que este tipo de talleres funcionan mejor cuando no se requieren y las personas pueden ‘optar’ con su participación;
• Cuando utilice herramientas digitales como JIRA, reduzca las restricciones sobre quién puede cambiar el Product Backlog e incluya el Equipo de desarrollo. Si solo el Product Owner puede hacer esto, solo está reforzando este mito. En cambio, haga acuerdos de trabajo sobre qué tipo de cambios puede hacer el Equipo de Desarrollo por sí mismo y qué nivel de comunicación con el Product Owner desea;
• Como Scrum Master, asegúrese de enfatizar que el Framework Scrum ofrece un enfoque sensato para reducir el riesgo de trabajo. No explique el Marco Scrum, sus roles, sus reglas y sus eventos como si estuviera citando la Biblia. Mitos como estos comienzan a aparecer cuando las personas solo entienden las reglas, no el propósito detrás de ellas;
• Si eres fanático de Liberating Structures, como nosotros, tienes acceso a un impresionante repositorio de microestructuras para activar exactamente el tipo de colaboración que estamos buscando. Puede usar Ecocycle Planning o Min Specs con el equipo Scrum para limpiar y ordenar el Backlog del producto. O use estructuras como 1–2–4-ALL , TRIZ y 25/10 Crowd Sourcing para generar ideas. O invite al equipo Scrum a trabajar juntos para elaborar estrategias de productos con incertidumbres críticas;

Si quieres profesionalizarte en agilidad a través de Scrum te invitamos a las próximas fechas abiertas al público

Conclusiones

Este mito subraya fuertemente que Scrum es mucho más que un montón de roles, reglas y eventos. Cuando nos encontramos con mitos como este, es útil volver a lo que estamos tratando de lograr con Scrum e interpretarlo desde esa perspectiva.

El Product Owner se asegura de que haya un Product Backlog del producto, que esté ordenada y que esté disponible tanto para el equipo Scrum como para los Stakeholders. Esta es la persona a la que va cuando este no es el caso. Pero esto no significa que el Product Owner sea la única persona en el Equipo Scrum que haga esto. Para maximizar el trabajo realizado por el Equipo de Desarrollo en cada Sprint, tiene sentido que el Product Owner trabaje activamente con el Equipo de Desarrollo para escribir los Items, refinarlos y ordenarlos. En trabajos complejos, se trata de una colaboración efectiva entre profesionales.