La ritualización de Agile: cuando las ceremonias pierden su sentido
En los pasillos sagrados de las corporaciones de todo el mundo, desde gigantes multinacionales hasta startups ambiciosas, ha echado raíces una nueva religión. Sus sacerdotes lucen notas adhesivas de colores (o su equivalente digital en tableros de Jira) en lugar de túnicas y títulos rimbombantes, y sus congregaciones se reúnen alrededor de pizarras y tableros virtuales de Kanban o Scrum en vez de altares. Bienvenidos a la Iglesia de Agile, donde las reuniones diarias de pie han reemplazado a las oraciones matutinas, y las retrospectivas de sprint hacen las veces de nuestros confesionarios modernos.
Pero, como ocurre con muchas religiones, ¿hemos perdido de vista el verdadero significado detrás de estos rituales?
Los textos sagrados y sus falsos profetas
Empecemos por revisar nuestros textos sagrados. El Manifiesto Ágil, al igual que las escrituras antiguas, estableció principios para una mejor forma de trabajar:
"Individuos e interacciones sobre procesos y herramientas. Software funcionando sobre documentación extensiva. Colaboración con el cliente sobre negociación contractual. Respuesta ante el cambio sobre seguir un plan."
Estas palabras estaban destinadas a liberarnos del desarrollo rígido al estilo cascada que se había convertido en nuestro capataz. Sin embargo, irónicamente, hemos logrado crear un nuevo conjunto de cadenas, forjadas por los autoproclamados "expertos en agilidad" que proliferan en nuestro ecosistema empresarial y por las mismísimas herramientas que se suponía debían facilitar nuestro trabajo.
Estos gurús modernos, contratados a tarifas exorbitantes por empresas desesperadas por subirse al carro de la agilidad, no son a menudo más que fanáticos de agendar reuniones y gestionar backlogs de Jira. Predican la palabra de Agile, pero en lugar de fomentar la entrega de software valioso, parecen más interesados en perfeccionar el arte de la ceremonia vacía y la gestión de tableros digitales.
Los rituales a los que nos aferramos
Pensemos en la reunión diaria de pie. Concebida originalmente como una sincronización rápida e informal, se ha transformado en una temida ceremonia donde los miembros del equipo recitan robóticamente sus tareas como versículos de un libro de oraciones, a menudo limitándose a leer sus tickets de Jira. "Ayer trabajé en el ticket JIRA-1234. Hoy trabajaré en JIRA-5678. No tengo bloqueos." Amén.
La reunión de planificación de sprint, que antes era un esfuerzo colaborativo para priorizar el trabajo valioso, hoy se asemeja a un proceso burocrático donde se regatean los puntos de historia como las indulgencias en tiempos medievales, todo mientras se contempla una pantalla llena de épicas e historias de usuario de Jira. "¡Te doy tres puntos de historia por esta funcionalidad, pero debes prometer entregarla antes de que termine el sprint!"
Y no olvidemos la retrospectiva de sprint, el equivalente ágil de la confesión. Los miembros del equipo anotan diligentemente lo que salió bien y lo que podría mejorarse, a menudo en otra herramienta digital más, pero ¿con qué frecuencia estas reflexiones conducen a un cambio significativo? Con demasiada frecuencia se convierten en un ritual catártico sin impacto en el mundo real, perdidas en el mar de notas adhesivas digitales y elementos de acción que nunca parecen llevarse a cabo.
Los falsos ídolos de las métricas
Como si la proliferación de ceremonias sin sentido no fuera suficiente, ahora enfrentamos una nueva amenaza para la verdadera agilidad: el culto al cargo de las métricas. La alta gerencia, en su infinita sabiduría, ha descubierto que los equipos ágiles usan números. Y si hay algo que la gerencia ama, es un buen número para poner en una presentación de PowerPoint.
Entra en escena la velocidad, el becerro de oro de las métricas ágiles. Esta medida, pensada como una herramienta de planificación específica de cada equipo, ha sido elevada a un estatus sagrado que haría sonrojar incluso al más fervoroso adorador de reliquias medievales. Gerentes que no sabrían distinguir una historia de usuario de un cuento para dormir ahora exigen que los equipos aumenten su velocidad, aparentemente bajo la impresión de que el desarrollo de software funciona como una línea de montaje de fábrica.
"El Equipo A tiene una velocidad de 50 puntos de historia por sprint, mientras que el Equipo B solo logra 30", proclaman desde sus alturas. "¡Claramente, el Equipo A es más productivo. El Equipo B necesita ponerse las pilas!"
No importa que el Equipo A y el Equipo B trabajen en productos completamente distintos, con definiciones diferentes de puntos de historia, tamaños de equipo distintos y diferentes niveles de deuda técnica. ¿Contexto? ¡Quién necesita contexto cuando tienes números!
Pero la velocidad es solo la punta del iceberg. Los gráficos de quemado se escrutan como augures examinando las entrañas de animales de sacrificio. Los porcentajes de cobertura de código se blanden como talismanes para ahuyentar a los espíritus malignos de los errores. Y ay del equipo cuyo tiempo de ciclo no disminuya sprint tras sprint, pues seguramente deben estar holgazaneando.
En este valiente mundo nuevo de las métricas ágiles, de algún modo hemos logrado recrear el mismísimo estilo de gestión vertical y descontextualizado del que se suponía que Agile nos salvaría. Nuestras nuevas herramientas digitales se han convertido en los látigos que se usan para hacernos avanzar cada vez más rápido, con poca consideración por la calidad o el valor de lo que producimos.
El Manifiesto Ágil nos recuerda valorar "software funcionando sobre documentación extensiva". Quizás sea hora de agregar "resultados significativos sobre métricas sin sentido". Pero ¿quién tiene tiempo de entregar software que funcione cuando hay tantos gráficos que actualizar?
El significado perdido
Así como muchos practicantes religiosos han olvidado el propósito de construir comunidad que hay detrás de sus rituales, muchos equipos ágiles han perdido de vista la verdadera intención del manifiesto. El Manifiesto Ágil nos instó a valorar "individuos e interacciones sobre procesos y herramientas", y sin embargo hemos creado un nuevo conjunto de procesos que seguimos ciegamente.
En la Biblia, Jesús criticó a los fariseos por su rígida adhesión a las leyes religiosas mientras pasaban por alto su esencia espiritual:
"¡Ay de ustedes, maestros de la ley y fariseos, hipócritas! Dan la décima parte de sus especias: menta, eneldo y comino. Pero han descuidado los asuntos más importantes de la ley: la justicia, la misericordia y la fidelidad." (Mateo 23:23)
¿No somos acaso culpables de lo mismo en nuestras prácticas ágiles? Rastreamos meticulosamente la velocidad, los gráficos de quemado y los tiempos de ciclo, pero ¿hemos descuidado los asuntos más importantes de la colaboración, la adaptación y la entrega de valor?
El camino a la redención
Es hora de una reforma ágil global. Necesitamos despojarnos de las ceremonias que ya no nos sirven y redescubrir el verdadero espíritu de la agilidad. Esto no significa abandonar toda estructura, sino más bien abordar nuestras prácticas con atención plena y propósito.
Pregúntense: ¿Esta reunión de pie realmente nos ayuda a colaborar y eliminar obstáculos? ¿Nuestra planificación de sprint de verdad nos permite responder al cambio? ¿Nuestras retrospectivas conducen a la mejora continua? Y lo más importante: ¿Estamos realmente entregando software valioso, o solo perfeccionando nuestra actuación en estas ceremonias?
Si la respuesta es no, tengan el coraje de cambiar. El Manifiesto Ágil nos recuerda valorar "respuesta ante el cambio sobre seguir un plan". Esto se aplica no solo a nuestros planes de proyecto, sino a nuestros propios procesos.
Es hora de cuestionar a los falsos profetas de la agilidad que prometen la salvación a través de más reuniones y más rituales. La verdadera agilidad no se mide por cuántas ceremonias realizamos, sino por nuestra capacidad de adaptarnos y entregar valor real a nuestros usuarios.
Liberémonos de las cadenas del Agile de culto al cargo y volvamos a la verdadera fe de la adaptabilidad, la colaboración y la entrega de software que funciona. Solo entonces podremos aspirar a la salvación del lodazal de la ineficiencia y redescubrir la tierra prometida del desarrollo de software verdaderamente ágil.
Amén. Que tus sprints sean productivos, tus backlogs estén siempre depurados, y que nunca olvides que el software funcionando es la verdadera medida de tu progreso.