Lo opuesto a la agilidad – Ritos, ceremonias y Cargo Cult en Scrum

“Lo opuesto a la agilidad – Ritos, ceremonias y Cargo Cult en Scrum” de Gabriel Casarini

Ritos, ceremonias y Cargo Cult

Unas semanas atrás recordaba que hasta hace unos años la Guía de Scrum se refería a los eventos como “las ceremonias”. El uso de la palabra ceremonia en Scrum nunca terminó de convencerme porque atribuía solemnidad y formalidad a algo que realmente no lo tiene. Las reuniones en Scrum son eventos vivos que tienen un objetivo muy concreto—inspeccionar y adaptar—justo lo opuesto a esa idea de calma y aburrimiento de las cosas solemnes.

Pero sin enredarme más con el significado de las palabras, hace pocos días volví a tropezar con la idea de ceremonias solemnes en Scrum mientras revisaba unas notas sobre el fenómeno de Cargo Cult en los equipos ágiles.

Así que se me ocurrió refrescar el concepto de Cargo Cult y ese peligro que siempre acecha a los equipos ágiles: que todo se convierta en una secuencia de ritos mecánicos, protocolarios y sin vida.

Para los que no estáis familiarizados con el concepto, veamos un ejemplo muy ilustrativo que ayuda a entenderlo. Durante la Segunda Guerra Mundial, las tropas americanas llegaban en avión y barcos a algunas islas del Pacífico y durante su estadía regalaban mercancías a los habitantes. Cuando la guerra terminó, las tropas dejaron de ir a las islas y los nativos dejaron de recibir las preciadas mercancías y regalos. Y entonces se produjo un fenómeno llamativo: los nativos empezaron a construir monumentos con forma de avión. Creían que repitiendo exactamente lo que habían visto hacer a aquellos dioses venidos de los cielos, mágicamente vendrían más aviones con mercancías y regalos.

Este fenómeno es lo que llamamos Cargo Cult. El concepto se usa como metáfora para describir un problema que no pierde vigencia: ese empeño por intentar replicar ciertos resultados imitando comportamientos—rituales—sin comprender las verdaderas causas que conducen a esos resultados.

Lo opuesto de la agilidad

El caso Toyota

En los años 80 las compañías americanas quisieron replicar el éxito del famoso modelo de fabricación de Toyota (Toyota Production System) implementando solo la parte más visible y mecánica de Lean: las actividades, eventos y procesos de Toyota. Fue un gran fracaso. Les llevó algo de tiempo entender que la esencia de Lean requiere entender el por qué de su filosofía y aplicar sus principios para mejorar los procesos propios.

El caso Nokia

Nokia es otro ejemplo. Invirtió millones en su proceso de transformación agile. Decenas de equipos aplicando “Scrum by the book“. Las métricas que usaba Nokia indicaban que la transformación de la organización estaba siendo exitosa. Pero la realidad era otra. La falta de visibilidad sobre el impacto y contribución del trabajo de los equipos en los resultados de negocio llevaron al fracaso y dejaron en evidencia la incapacidad de hacer la transición a una nueva era. Los equipos no estaban alineados con las nuevas necesidades y tendencias del mercado: pantallas táctiles, foco en el desarrollo de software y tiendas de aplicaciones. Básicamente las métricas que se usaban para medir la productividad de los equipos estaban desconectadas de la poca agilidad de la organización y del negocio. La aparente agilidad que Nokia creía tener no era real, aunque tuviera equipos que aplicaban Scrum escrupulosamente.

En otro orden, también vemos muchas manifestaciones de Cargo Cult en equipos ágiles. Muchos creen que están haciendo Scrum solo porque se han certificado y aplican los roles, asisten a eventos y usan artefactos. Pero no sienten que Scrum esté realmente ayudándoles en su trabajo. Más bien lo perciben como una pasada carga extra que les roba tiempo y flexibilidad.

– ¿Podría ser verdad?

En los casos anteriores vemos que hay una desconexión y falta de alineamiento entre el “output”—las actividades, las cosas que se producen—y el “outcome”—el impacto real que tienen.

Cómo detectar un Cargo Cult

Algunos equipos que hacen Cargo Cult de Scrum presentan estos síntomas:

• El equipo no tiene auto organización ni autonomía. Los integrantes se resignan a seguir como están. Se sienten impotentes. No son dueños de lo que hacen. No tienen ningún poder para implementar mejoras en su propia forma de trabajar.
• No hay innovación. La famosa “tiranía de lo urgente” les impide invertir tiempo y energía en cosas realmente importantes.
• El equipo está desconectado de los stakeholders. No conoce las necesidades reales de los usuarios. Hay una gran distancia entre las personas que usan el producto y los que lo desarrollan. En el medio hay intermediarios: analistas de negocio, jefes de departamento, managers y sponsors que recopilan requerimientos y los envían al equipo. Burocracia y poca agilidad.
• El equipo tampoco tiene mayor visibilidad sobre el contexto y las dependencias de lo que hacen. No saben cómo el producto que construyen ayuda a cumplir con la misión de la organización.
• Poco compromiso y motivación. Los integrantes del equipo sienten que son engranajes de una gran maquinaria que no comprenden.
• Falta de cadencia con las entregas. Al final de los sprints no hay un incremento terminado que pueda inspeccionarse.
• Aplican Scrum por inercia, sin saber si es la mejor opción. ¿Tal vez deberían adoptar Kanban? Ni se lo plantean.

A veces, la causa del problema es que se sigue aplicando un paradigma equivocado. La forma tradicional de gestionar una organización y el desarrollo de productos está diseñada para lograr lo opuesto a la agilidad. Es que lo que en inglés se llama “efficiency mindset” y su objetivo es aumentar la eficiencia intentando reducir la incertidumbre tanto como sea posible, para aumentar la predictibilidad de los equipos.

Cuando esto ocurre, vemos que Scrum se utiliza por las razones equivocadas: para ser más eficientes, para mejorar el output, para tener más velocidad. Es como intentar ser ágiles sin entender los principios y fundamentos de la agilidad.

El marco propuesto por Scrum tiene más que ver con ser efectivos que con ser eficientes.

En cierto modo es comprensible lo que les ocurre: con las prisas por “hacer”–y la presión de tener que demostrar que hacen algo—estos equipos solo se concentran en la parte mecánica de Scrum. Esto enmascara la realidad de que verdaderamente no funcionan como un equipo ágil. No se concentran en entregar valor de forma incremental y continua. Ni en mejorar. Ni en aprender. Ni en innovar.

Volver a las raíces

Y si nos encontramos antes un panorama de ceremonias Scrum que se han convertido en un Cargo Cult, ¿Qué alternativas tenemos cuando?

Un buen punto de partida es volver a los fundamentos y principios de la agilidad, entenderlos y aplicarlos a nuestro contexto. Esto en si mismo es un proceso de aprendizaje—iterativo e incremental.

Y por supuesto, recordemos que el marco propuesto por Scrum alienta a los equipos a descubrir sus propias soluciones y a encontrar nuevas formas de hacer las cosas.