Agile está muerto, larga vida a los marcos personalizados – Agile611

Blog

Agile está muerto, larga vida a los marcos personalizados

¿Agile está muerto? ¿Es Agile el “arte de la felicidad”? ¿Agile cumple lo que promete? A medida que las organizaciones se acostumbran cada vez más a ser ágiles usando Scrum o otros marcos en el mercado, también comienzan a cuestionar las maneras como se hace la agiidad en las organizaciones.

Últimamente, la gente parece decir que los marcos ágiles no cumplen su promesa. Si habéis estado en la industria del software durante algunos años, lo ha visto antes seguro.

Yo he oido muy poca gente hablando bien de Scrum, o de Kanban o sobretodo de SAFe. Ya no quiero entrar de los comentarios que he oido de organizaciones Big 4 como McKinsey, Accenture o KMPG sobre sus estrategias para implementar agilidad en las organizaciones.

No veo lo de Agile está muerto cuando estas Big 4 se gastan millones y millones para hacer negocio en las implementaciones de estrategia apostando por Agile.

Estás trabajando de una manera específica pero sigues escuchando acerca de esta otra fantástica “bala de oro” que otros están usando. Cosas como qué bonico es el método Spotify o qué bien hacen agilidad en tal otra organización.

Las organizaciones lo intentan durante algún tiempo, pero realmente no lel ven la grandeza, así que deciden probar otra cosa. Algo que realmente revolucionará la forma en que trabajamos.

Parece sucede con la mayoría de las metodologías. Tengo una hipótesis sobre por qué sucede esto.
En primer lugar. Vivimos en un mundo de cambios. Los métodos y los marcos son construcciones para el mundo tal como fueron cuando se crearon. Recordad que hay documentos donde se habla de Scrum en 1993 y el Manifiesto Ágil de Software es de 2001. Dejadme insistir aquí en el concepto de “Manifiesto Ágil de Software”, no habla del “manifiesto ágil sobre como proporcionar soluciones en un mundo complejo”.

A medida que el mundo cambia, las premisas que construyen los fundamentos de un marco o metodología dejan de ser válidas. También evolucionan.

Pero, ¿es eso cierto para la agilidad en este momento? ¿Seguimos sin avanzar hacia una sociedad y un paisaje donde las condiciones cambian rápidamente? ¿Dónde tenemos que responder a los cambios?

¿No es eso de lo que se trata Agile? Creo que eso todavía se mantiene, y probablemente seguirá siendo así durante una década más o menos. Sinó mirad al 2020 en su totalidad.

Aplicar la teoría de los primeros en adoptar

Entonces, si el mundo todavía necesita Agile, ¿por qué hay tantos artículos que afirman que Scrum y Agile están muertos? Mi hipótesis es que Agile sigue la curva tradicional de los primeros usuarios. Scrum es ahora la corriente principal y está en su apogeo. Ahí es cuando comienza la prensa negativa. Vea la imagen a continuación.

Curva de los Early Adopters

Si aplica esta teoría a Scrum, potencialmente puede ayudarnos a comprender algunas cosas. Mi reflexión personal es que al principio, cuando los primeros usuarios comenzaron a investigar y usar Scrum y otros marcos ágiles, eran expertos.

Habían llegado a “Ri” en Shu-Ha-Ri. Estas personas, que eran se consideraban con el mindset Agile, no tenían un marco estándar completamente descrito para usar. Tuvieron que fallar, reflexionar, inspeccionar y adaptarse, y trabajar duro para entender qué funcionó.

A medida que aumentaba el interés y comenzaba la exageración de los medios de comunicación, estas personas sabían qué había funcionado y qué no. Las conclusiones se basaron en años de experiencia en experimentos. Gran parte de ese conocimiento probablemente fue tácito. A medida que aumentaba la demanda, surgió la necesidad de crear marcos fáciles de entender para que otros pudieran aprovechar la experiencia y ser ágiles.

Estos primeros usuarios, que probaron Scrum, probablemente aún provenían de un mundo de experiencia en cascada, RUP, Prince2 y otras metodologías. Cambiar la forma de trabajar requiere mucha comprensión. Entender por qué se necesitaban cambios e ideas diferentes. Pasar de un modelo mental a otro es difícil. Eso requiere que comprenda lo que hace y por qué.

Diría que los primeros en adoptar Scrum tuvieron éxito porque entendieron por qué eran necesarios los cambios. Podían ver dónde habían fallado antes y dónde tendrían sentido las nuevas ideas. Diría que estaban en la etapa Ha de Shu-Ha-Ri.

A medida que alcanzamos la actividad más allá de los primeros usuarios y las nuevas generaciones que nunca han trabajado con otros métodos … Bueno, leyeron las 17 páginas de la Guía Scrum y comenzaron a realizar los eventos y crear artefactos sin tener una comprensión más profunda de por qué.

Nunca tuvieron que entender el por qué. Scrum es la forma en que siempre ha trabajado des del inicio de los tiempos.

Para estas personas, Scrum describe el CÓMO trabaja, no el POR QUÉ. A esto se le llama corte de carga. Este es, por supuesto, el enfoque equivocado. Piense en la metáfora clásica del iceberg. Solo ves lo que está por encima de la superficie.

La metáfora clásica del iceberg. Este Iceberg ilustra la diferencia entre cómo y por qué. La ilustración también coincide con el patrón Shu-Ha-Ri.

La mala noticia es que realmente no se puede cambiar el comportamiento hasta que se descubra que no funciona y averiguar POR QUÉ no funciona.

Eso requiere experiencia y que reflexiones sobre el por qué. Aquí es donde muchos se dan por vencidos y no van más lejos. Estas personas están en la etapa “Shu”.

Entonces, ¿qué pasará después?

Un escenario muy probable es que Agile seguirá siendo necesario y útil. Y sobretodo que vaya dando el valor que le toca.

Sin embargo, lo más probable es que las empresas tengan que darse cuenta de que el solo hecho de seguir las ceremonias y crear artefactos no ayudará. Por lo tanto, necesitarán ayuda y ganarán sus propias experiencias reñidas. Esto siver para obtener una comprensión más profunda.

Las empresas necesitarán ayuda para crear marcos que se adapten a la cultura, estructura, mercado, producto, regulaciones y personas específicas de sus organizaciones.

Puede ser que vivan en un mundo híbrido, dónde haya partes que navegan en métodos diferentes a otras. En estos casos no pasa nada, porqué la diversidad hace el color y facilita la entrega de valor.

La comprensión debe ir de “Shu” a al menos “Ha” y preferiblemente “Ri”.

Esto se abre para los maestros de los frameworks. Las personas “Ri” ágiles y calificadas pueden ingresar a una organización y personalizar un marco que se adapte a esa organización.

SAFe ha empaquetado una solución muy bien. Creo que las organizaciones se darán cuenta de que SAFe no es útil para todos. Tiene grandes ideas y principios, pero probablemente no debería simplemente sacarlos de su zona de confort.

Lo mismo sucedió cuando la gente descubrió que el modelo de Spotify era solo para Spotify. El modelo de Spotify se personalizó para Spotify. Si no lo has descubierto aún, el modelo Spotify es para un empresa casi monoproducto de cultura muy joven con una visión muy clara. Pero claro si no triunfamos siendo Spotify, Agile está muerto.

Las organizaciones tendrán que encontrar expertos en los marcos que puedan ayudar a crear su propio marco ágil customizado. Habrá una necesidad de muchos marcos nuevos y sobretodo personalizados para el contexto donde se están haciendo las transformaciones ágiles. Y recuerda, no hay 2 transformaciones iguales.

El objetivo de crear su propio ecosistema agile agrega el beneficio de que las personas de su organización (con suerte) ayudan a crear y decidir las reglas.

Al participar en la creación de las reglas del juego, también te das cuenta de que puedes darles forma y romperlas según sea necesario. Esto te da el POR QUÉ.

Solo se aplicó el clásico “Inspeccionar y adaptar” en el contexto de manera satisfactoria.

Para resumir, lo que le está sucediendo a Agile y Scrum es probablemente normal y, a medida que avancemos, Scrum y Agile evolucionarán hacia algo diferente. A algo poco mejor. A algo un poco diferente, inspeccionando y adaptando lo que los propios practicantes propopen.

Agile está muerto en completa evolución.

WhatsApp chat