scrum de scrums

Scrum de Scrums: Como Implementar a Gran Escala

Scrum de Scrums

Acerca del Editor: Jhon Robert Quintero H.

El Scrum de Scrums es un mecanismo para escalar. Scrum escala de una manera fractal y al hacerlo limita el número de vías de comunicación necesarias para transmitir información relevante para el éxito de la empresa. El Scrum de Scrums es análogo al nivel de equipo Scrum diario, a excepción que Scrum de Scrums es un equipo virtual compuesto por representantes de varios equipos Scrum individuales que colaboran para integrar y enviar un producto. Los Scrum Masters y cualquier otra persona también necesitan entregar el Scrum de Scrums en colaboración para definir y comunicar obstáculos, progreso y cualquier coordinación de equipo cruzado que debe hacerse contestando para el equipo las mismas tres preguntas utilizadas en el Scrum diario.

Resumen:

Un Scrum de Scrums correctamente ejecutado es un equipo de liberación mínimo viable (minimum viable release team) para productos y líneas de productos. Elimina la basura introducida en muchas implementaciones de Scrum por equipos de integración, equipos de liberación y equipos de administración de liberación, introducidos por marcos de escala que distorsionan Scrum y lo hacen menos ágil al aumentar las vías de comunicación. Ken Schwaber lo llamó un Scrum de Integración en su libro sobre Enterprise Scrum.

Para los equipos que trabajan en proyectos o productos diferentes que no tienen integración, el Scrum de Scrums se utiliza a menudo como un mecanismo de coordinación para la organización y, por lo tanto, puede reunirse con menos frecuencia.

Fuera de la reunión Scrum de Scrums, los individuos relevantes de la reunión se ofrecen como voluntarios para tratar de eliminar los impedimentos operacionales identificados relacionados con el proceso de liberación y despliegue. Esto es de una manera fractal equivalente a los miembros del equipo Scrum trabajando juntos en un Sprint. Por ejemplo, un Scrum de Scrums tendría mecanismos de coordinación para hacer frente a las dependencias entre equipos relacionadas con la finalización de las épicas requeridas para la liberación.

El papel de la dirección en un Scrum de Scrums es crítico. Tienen la responsabilidad de que el Scrum de Scrums Master sea responsable de la entrega. Como resultado, el Scrum de Scrums Master suele ser una persona mayor, usualmente el Director de Ingeniería o algún nivel superior. El Scrum de Scrums no es el Enterprise Action Team (EAT – el equipo directivo que se ocupa de los impedimentos de la empresa). El Scrum de Scrums puede referir asuntos de la compañía al EAT, aunque el Scrum de Scrums se ocupa directamente de las cuestiones operacionales.

Funciones: 

Scrum de Scrums hace:

  • Reunirse una vez al día después de que todos los sub-equipos involucrados hayan llevado a cabo su Stand-up diario
  • Reflejar el status diario a nivel de equipos. Con 15 minutos o menos y posiblemente 15 minutos más de conversación de seguimiento (usualmente llamado el estacionamiento).
  • Eliminar impedimentos para equipos individuales si es posible. Si no, los elevan al siguiente Scrum de Scrums y así sucesivamente hasta que los impedimentos se eliminan o se elevan al EAT.
  • Trabajar con el EAT para ayudar a coordinar las mejores prácticas en toda la empresa.

Scrum de Scrums no hace:

  • Desarrollar el backlog. Sin embargo, puede añadir historias al backlog.
  • Descomponer el backlog
  • Coordinar Épicas
  • Plan de liberaciones
  • Administrar releases

Roles de escala adicionales

Executive Action Team (EAT): Es un equipo individual de Scrum compuesto por ejecutivos de alto nivel. El Product Owner de este equipo debe ser el Chief Product Owner (CPO) para toda la organización. Los miembros individuales del equipo son idealmente miembros de diferentes departamentos organizacionales que ayudan a ejecutar la visión de la organización expresada por el CPO. Por ejemplo, es probable que el CPO sea el CEO y su equipo puede estar formado por el CIO, CFO, COO y un ejecutivo de Recursos Humanos. La composición del EAT dependerá del contexto de la organización, pero al igual que cualquier equipo de Scrum debe ser funcional, auto organizado y autogestionado.

https://34slpa7u66f159hfp1fhl9aur1-wpengine.netdna-ssl.com/wp-content/uploads/2015/06/Scrum-at-Scale-Keynote-Jun-2015-copy.030.jpg

Meta Scrum: El Meta Scrum es la forma en que el Product Owner (PO) se escala en Scrum. El Meta Scrum es un equipo virtual compuesto de cuatro a cinco Product Owners que coordinan Épicas, lanzamientos de productos y líneas de productos. Una Épica creada por el EAT es muy probable que sea demasiado grande para ser completada por un equipo Scrum individual. Como mecanismo de coordinación, los PO de todos los equipos que trabajan en una Épica grande se reúnen cuando sea necesario. Esto suele estar coordinado por una red escalada de Meta Scrums incluyendo el EAT. El EAT es responsable de crear el backlog organizacional que alimenta a grandes Épicas a la red de PO.

https://34slpa7u66f159hfp1fhl9aur1-wpengine.netdna-ssl.com/wp-content/uploads/2015/07/Slide11.jpg

Orígenes 

El Scrum de Scrums se utilizó por primera vez en IDX Systems (ahora GE Healthcare) en 1996-2000. Jeff Sutherland (SVP Desarrollo) y Ken Schwaber (consultor) lo implementaron como una técnica para escalar a los equipos Scrum individuales a nivel empresarial. Había ocho unidades de negocios, cada una con múltiples líneas de productos. Cada producto tenía su propio Scrum de Scrums, algunos productos tenían Scrum de Scrums múltiples con un nivel más alto Scrum de Scrums. Cada producto tenía que entregar al mercado con un ciclo de lanzamiento de tres meses o menos y todos los productos tenían que ser completamente integrados, actualizados y desplegados cada seis meses para apoyar a los proveedores regionales de salud como el Stanford Health System.

El Scrum de Scrums evolucionó aún más en PatientKeeper, donde Sutherland fue CTO durante 2000-2008, para apoyar múltiples lanzamientos empresariales tanto a sistemas hospitalarios como a socios (GE y Cerner) cada sprint. El Scrum de Scrums fue una reunión de 15 minutos todos los días para (1) eliminar cualquier impedimento para cualquier release durante el sprint y (2) escuchar un reporte de nivel de equipo que corresponda a las preguntas del Daily Scrum.

Fuente: ScrumInc

Experiencia Scrum en Google

¿ Scrum Master está desplazando al PMP ?