Estudio de caso Scrum@Scale

Resumen

Según el formador de Scrum at Scale, Hiren Doshi, una organización que carece de equipos de Scrum que funcionen bien antes de escalar verá cómo se multiplican las disfunciones a medida que escalan. Por este motivo, establecer un modelo de referencia sólido antes de escalar es absolutamente esencial. El objetivo de una importante organización de almacenamiento de datos era crear un producto estrella que se utilizara en una compleja infraestructura de TI de múltiples proveedores. El producto puede instalarse en una máquina que luego gestiona toda la red de área de almacenamiento, proporcionando servicios como la elaboración de informes, la planificación y el aprovisionamiento.

Un legado moribundo

Con unos ingresos de más de $600m anuales, la organización tenía más de 250 empleados repartidos por tres continentes: Norteamérica (Boston), Europa (Irlanda) y Asia (India). Aunque el producto estrella de la organización servía de forma fiable a más de 4.000 clientes activos diariamente, el software heredado se escribió hace unos 15-20 años y la actualización de su base de código monolítica se había convertido en un problema. El software se escribió antes de la revolución de la virtualización, y esta organización tenía un enorme problema de deuda técnica. El producto en el que se basaban no era escalable y no tenía ninguna automatización: si, por ejemplo, se lanzaba una nueva pieza de firmware de Cisco para sus máquinas, necesitarían muchos meses antes de poder soportar la actualización. Por tanto, su reto era cambiar o perecer.

Unas cuantas iteraciones de sprint de prueba

Tanto por su antigüedad como por su tamaño, que contiene unos 27 millones de líneas de código, no se podía reescribir todo el código de una vez. Hiren se enfrentó al reto de cómo reescribir una sección de código. Dividió el trabajo en módulos y eligió un módulo de un conjunto de módulos para actualizarlo, manteniendo la funcionalidad del sistema. Otra preocupación era que si los cambios sólo se realizaban en un sitio, los demás sitios se quedarían atrás, así que también formaron tres equipos Scrum transversales distribuidos geográficamente para establecer un modelo de referencia inicial.

Hiren puso en marcha un equipo de Scrums de Scrums (SoS) que se reunía en el Scrum Diario Escalado, inició un Equipo de Acción Ejecutiva (EAT) y un Metascrum. Una vez introducidos, pusieron a prueba este modelo de referencia ejecutando unas cuantas iteraciones de sprint y recopilando opiniones sobre la marcha. Tras la inspección, descubrieron algunas conclusiones: Los equipos no entendían bien el concepto de Agile y Scrum, trabajaban a un ritmo insostenible y se acumulaba el trabajo ad hoc, la base de código monolítica era un lastre y la latencia de las decisiones era escasa, con muchos niveles antes de que se pudiera aprobar una decisión. Su respuesta adaptativa fue Un Proceso Ágil dedicado a la formación formal para Scrum Masters y Developers, un acuerdo para conseguir un producto mínimo viable (MVP), un único backlog de producto ordenado para ayudar a priorizar el trabajo, una arquitectura de Transferencia de Estado Representacional (RESTful) escalable para empezar a actualizar la deuda tecnológica, y Equipos Scrum coubicados en cada sede para garantizar que todo fuera visible en todas ellas.

Algunas exigencias, responsabilidad, antes y después

Tras aplicar el plan de respuesta, pudieron centrarse en las áreas que debían abordarse primero. Reconocieron la necesidad de eliminar despiadadamente los residuos e impedimentos, lo que les permitió adoptar la integración continua y la entrega continua. Pidieron herramientas, entorno, infraestructura y comprensión de las dependencias, y facultaron al Scrum de Scrums para abordar todas las disfunciones ocultas que se revelaron. Necesitaban aprobaciones presupuestarias, formación, contratación, mejora de las habilidades, y pidieron a la EAT y al Centro de Excelencia Ágil (ACOE) que financiaran e implementaran los programas y la formación necesarios para permitir el crecimiento. Y, por último, el EAT y el Metascrum aceptaron la necesidad de refinamiento, pidieron un único backlog de productos con una responsabilidad clara y aplicaron el MVP (regla 20/80).

Estos cambios tuvieron grandes resultados. Al cabo de un año, la organización pasó de un ciclo de lanzamientos de 12 a 18 meses a un ciclo trimestral y eliminó el sistema monolítico para implementar una arquitectura RESTful en todos los módulos. Además, las encuestas de felicidad de los miembros del equipo también subieron de forma espectacular: de 20% inicialmente descontentos a 80% muy contentos en el mismo periodo, lo que demuestra un aumento significativo del compromiso y la satisfacción en el trabajo. Y, por último, dos métricas que indicaban un cambio y una mejora significativos al implantar Scrum a escala fueron la tasa de defectos -que mejoró de un estado inicial de 20.000 defectos a un estado final de menos de 200- y los ingresos -que pasaron de un estado operativo inicial de una pérdida anual de $100m a una ganancia anual de $200m-.