Estudio de caso Scrum@Scale

Resumen

En este estudio de caso, Renee Tsielepi, una Scrum@Scale Trainer, transformó una organización de viajes "en cascada" de 2.000 personas utilizando Scrum@Scale, y los llevó de un total de 49 proyectos en curso inicialmente a un único backlog con enjambre. La escasa coordinación entre los componentes informáticos de la empresa se coordinó con un único objetivo y visión, y la EAT de la organización mejoró su escasa latencia de decisión de forma espectacular. Por último, se redujo la deuda técnica de 80% de la organización, abriendo así el ancho de banda de los desarrolladores para iterar sobre los casi 250 millones de búsquedas diarias de la organización en su API.

El dinosaurio

Renee Tsielepi fue contratada para llevar Scrum a una organización de viajes con 2.000 personas que tenía una estructura monolítica y muy cascada. No había colaboración entre los componentes de TI y de negocio de la organización y no había actualizaciones ni mejoras en casi 20 años. La organización estaba tan jerarquizada, de hecho, que a cada capa de la dirección se le asignaba un tipo concreto de silla: los directivos de más alto nivel tenían brazos y un pivote y los de más bajo nivel no tenían ninguno de los dos.

La organización no tenía el concepto de equipo, y los desarrolladores trabajaban por su cuenta en varios proyectos simultáneamente. Estaban tan lejos de los equipos multifuncionales y co-localizados como una organización puede llegar a estarlo. También había una gran cantidad de deuda técnica en la organización, con cerca del 80% del tiempo dedicado a la depuración. Evidentemente, había una gran urgencia por actualizar el sistema rápidamente.

Planificación e implementación de una solución escalable

El primer cambio que introdujo Renee fue ofrecer un modelo de referencia escalable a la organización para ayudar a localizar cualquier impedimento y destruirlo. Quería establecer una red de equipos interfuncionales y ubicados en el mismo lugar que fuera escalable y que pudiera formar un enjambre colectivo en los proyectos.

Una vez establecido el modelo de referencia escalable, los equipos de la organización fueron escalados. Tenía que examinar simultáneamente el tamaño y el alcance del programa, localizando alrededor de 49 áreas de cambio necesario. Estos cambios, sin embargo, no podían aplicarse de una sola vez: en ese momento, ya había unos 250 millones de búsquedas registradas en su API a diario.

Al principio de la transición para abandonar la jerarquía monolítica, hubo dificultades para comunicar claramente la visión a las partes implicadas. Afortunadamente, Renee contaba con un "wingman" de confianza que le ayudó a examinar los 40 sistemas que tenía la organización, a cortarlos verticalmente en su totalidad y a crear un único backlog que toda la organización pudiera utilizar. Un esqueleto de trabajo del modelo se dio a conocer antes de tiempo para que pudieran obtener muchos comentarios.

Crearon 12 equipos autoorganizados que estaban asociados a cuatro Scrums de Scrums, o corrientes. Cada equipo era estable e interfuncional, y tenía forma de T en la medida de lo posible. Sin embargo, en los casos en los que no había suficientes conocimientos especializados -como Salesforce o conocimientos de bases de datos aplicables-, el trabajo tendría que dirigirse hacia los equipos con los conocimientos pertinentes. Con el tiempo, los miembros de estos equipos se emparejarían con los desarrolladores de otros equipos para formar nuevos conocimientos.

La organización de viajes a la que asesoraba Renee también trabajaba con proveedores externos que inicialmente no eran de scrum. En algunos casos, estos proveedores pudieron implementar scrum y trabajar con la nueva cadencia de la organización.

Escala y Equipo de Acción Ejecutiva (EAT)

Uno de los cambios más importantes en la organización, que antes era una cascada, fue la configuración adecuada del nuevo Equipo de Acción Ejecutiva (EAT). El EAT ayudaría a los equipos a destruir los impedimentos anteriores, originados por la jerarquía monolítica de la organización, mediante la posesión de una cartera de pedidos de transformación.

Si, a nivel de los trabajadores del conocimiento, los problemas no pudieran resolverse, estos problemas se elevarían al Scrum de Scrums (SoS). Si, a su vez, el SoS correspondiente no pudiera resolver la cuestión, ésta se elevaría al Scrum de Scrums (SoSoS) y, finalmente, al EAT.

Una vez que un asunto llegara al EAT, los impedimentos se asignarían a los individuos del equipo. Este equipo se reuniría diariamente, con sus propios objetivos y el estudio del backlog de transformación. Todos los objetivos de cada iteración de scrum se agruparían, incluidos los del EAT, y se pondrían en un único backlog visible para toda la organización. Una vez finalizada la transición, Renee se alegró de ver que ya no había más funciones que merecieran sillones giratorios sobre los que no los había: todos los miembros de la organización estaban ahora organizados horizontalmente y no verticalmente.