Escalar en Scrum

Un problema de escala

Paula es Product Owner en un equipo Scrum, junto con un Scrum Master y un equipo de desarrollo de cinco personas. Ella ha recibido noticias de que el producto que están desarrollando se expandirá enormemente y que se necesita un equipo más grande. Paula sabe que escalar Scrum con éxito para respaldar un proyecto más ambicioso requerirá nuevas técnicas y herramientas. Ella reflexiona sobre la estructura actual del equipo y cómo Scrum ha ayudado al equipo a construir y mejorar los proyectos y luego comienza a investigar las mejores prácticas para escalar Scrum.

Una revisión de Scrum sin escala

El equipo de Paula es típico de un equipo Scrum sin escala, que consta de un Product Owner , que asegura que el desarrollo del producto maximiza el valor, un Scrum Master , que facilita el proceso Scrum, y un Equipo de Desarrollo de tres a nueve miembros que ejecuta el trabajo. . Scrum tiene tres pilares: transparencia , inspección y adaptación . Estos pilares se facilitan a través de una serie de eventos que se organizan en Sprints .

Los sprints son ciclos de desarrollo que duran un tiempo fijo, generalmente al menos dos semanas y nunca más de un mes. Cada Sprint comienza con un evento de Planificación de Sprint en el que el equipo se compromete a una cierta cantidad de trabajo seleccionando elementos del Product Backlog , una lista de características deseadas para el producto ordenado por prioridad. El Product Backlog es mantenido por el Product Owner. Los elementos seleccionados del Product Backlog van al Sprint Backlog , que es propiedad del Equipo de Desarrollo. El Sprint Backlog representa un compromiso del Equipo de Desarrollo de los elementos que completarán durante el Sprint. El Sprint Backlog también incluye un Sprint Goal, una declaración que resume el resultado clave del Sprint. A lo largo del Sprint, hay un evento de Scrum diario en el que cada miembro del equipo de desarrollo analiza brevemente lo que han hecho y lo que planean hacer a continuación. Al final de cada Sprint, se entrega un Incremento (el término Scrum para una versión funcional del producto) y se llevan a cabo dos eventos Scrum: una Revisión del Sprint para demostrar el último Incremento y recopilar comentarios de las partes interesadas, y una Retrospectiva del Sprint para discutir el proceso de desarrollo y formas de mejorarlo para Sprints posteriores.

Usar el marco de Nexus para escalar

Paula investiga las mejores prácticas para escalar Scrum y decide intentar usar Nexus , un marco para escalar Scrum desarrollado por Ken Schwaber y Scrum.org. Si bien existen muchos enfoques para escalar Scrum (por ejemplo, LeSS, Scrum a escala), la mayoría se enfoca en escalar extendiendo Scrum con eventos, roles y artefactos adicionales para facilitar que múltiples equipos Scrum colaboren e integren su trabajo en un solo producto. Nexus es un marco flexible y relativamente simple que se presta bien a organizaciones como la de Paula que están comenzando su viaje para escalar un equipo Scrum.

Un diagrama general del marco Nexus con dos equipos Scrum

Nexus adapta Scrum para facilitar el escalado de las siguientes formas:

• Hay un nuevo equipo, llamado Nexus Integration Team , que consta de un Product Owner, un Scrum Master y miembros del equipo dedicados a las tareas de integración (técnicas y no técnicas).
• Si bien se mantiene un solo Product Backlog para todos los equipos Scrum, hay un nuevo artefacto Nexus Sprint Backlog que combina los Sprint Backlogs de los equipos individuales y un Nexus Goal que es una contraparte similar a los Sprint Goals de los equipos individuales.
• Si bien cada equipo Scrum entrega su propio Incremento al final del Sprint, también hay un Incremento Integrado que representa su trabajo combinado.
• Hay cuatro eventos nuevos que reflejan los eventos estándar de Scrum.
  • Planificación de Sprint Nexus : La planificación de Sprint Nexus abarca las Planificaciones de Sprint del equipo individual, pero hay una discusión adicional entre los equipos para coordinar el trabajo, identificar puntos de integración y crear un objetivo Nexus compartido.
  • Nexus Daily Scrum : representantes individuales de cada equipo de Scrum se reúnen en el Nexus Daily Scrum para discutir el progreso de su equipo, identificar dependencias emergentes y problemas de integración, y compartir información. Cada equipo todavía tiene su propio Scrum diario
  • Revisión de Nexus Sprint : Durante la Revisión de Nexus Sprint, el Incremento Integrado se demuestra a las partes interesadas. Dado que el Incremento integrado es el resultado final del Sprint, no hay Revisión de Sprint para equipos individuales.
  • Retrospectiva del Sprint del Nexus : La Retrospectiva del Sprint del Nexus abarca las Retrospectivas del Sprint del equipo Scrum individual, pero incluye tiempo adicional para inspeccionar y adaptar los procesos relacionados con la integración o relevantes para más de un equipo Scrum.

Propietarios de productos de escala

Paula implementó Nexus con éxito y escaló hasta seis equipos Scrum. Sin embargo, le resulta difícil ser la única Dueña de Producto para un proyecto tan grande. Nexus y otros enfoques formalizados para escalar Scrum a menudo sugieren que hay un Product Owner incluso en Scrum escalado, pero muchos practicantes de Scrum experimentados han encontrado que es muy beneficioso escalar Product Owners (por ejemplo, un Product Owner por dos equipos Scrum). La organización de Paula acordó expandirse a múltiples Product Owners y promoverla a Chief Product Owner. Lógicamente, divide el producto en tres componentes funcionales de dos equipos, cada uno de los cuales puede ser propiedad de los Product Owners. El papel de Paula como Jefe de Producto Propietario es desarrollar la visión global del producto y gestionar las relaciones con las partes interesadas de alto nivel. Paula y los demás Product Owners gestionan juntos un solo Product Backlog. Cada Product Owner maneja la administración diaria de sus respectivos componentes, con deberes que incluyen la creación de historias de usuario, trabajar con el Equipo de Desarrollo para estimar cada artículo y colaborar con los Product Owners en artículos con interdependencias de equipo. Todos los Product Owners colaboran en la ordenación del Product Backlog, pero Paula, en su calidad de Chief Product Owner, tiene la última palabra.

Resumen de la lección

Paula ha tomado su pequeño equipo Scrum y lo ha escalado a un equipo mucho más grande sin sacrificar los pilares centrales de Scrum de transparencia , inspección y adaptación . Ha utilizado el marco Nexus para escalar a múltiples equipos Scrum. Nexus agrega un nuevo Nexus Integration Team para integrar el trabajo de todos los equipos Scrum, un nuevo Nexus Sprint Backlog que combina los Sprint Backlogs de todos los equipos Scrum y agrega un Nexus Goal , y cuatro nuevos eventos ( Nexus Sprint Planning , Nexus Daily Scrum , Nexus Revisión del Sprint , y Nexus Sprint Retrospective) para gestionar el escalado. Cuando los equipos combinados se volvieron demasiado grandes para que Paula los gestionara por su cuenta, asumió el papel de Jefe de Productora y contrató nuevos Dueños de Producto para gestionar cada componente funcional del producto. Si bien ha enfrentado muchos desafíos para escalar el equipo Scrum, el uso del marco Nexus y la división del trabajo entre múltiples Product Owners ha ayudado a Paula a lograr el éxito en la gestión de un producto mucho más grande de lo que un equipo Scrum podría manejar por sí solo.

Rodrigo Ricardo Editor y fundador