¿Ha muerto Agile tal y como lo conocemos?

El agilismo se ha extendido hasta tal punto que, prácticamente, ya no queda ni una sola compañía que, en mayor o menor medida, no esté desarrollando software de este modo.

Todos hemos comprobado los beneficios que aportan sus principios y frameworks respecto a métodos más tradicionales:

• Acercar negocio y tecnología.
• Ser más adaptativos al cambio y manejar mejor la incertidumbre.
• Entregas frecuentes.
• Tener en cuenta el feedback de los usuarios durante la construcción.
• Ahorrar tiempo y esfuerzo, no analizando funcionalidades que, en muchas ocasiones, nunca llegan a implementarse.
• Reducir riesgos, definiendo un MVP y desarrollando de forma incremental.
• Eliminar silos y cuellos de botella mediante equipos multidisciplinares.
• Fomentar la inspección y mejora continua tanto de la solución como de la forma de trabajo.
• Etc.

Sin embargo, como cualquier playa virgen que se pone de moda, con el boom de los últimos años, se han adulterado algunos de estos principios o, como poco, han pasado a un segundo plano.

Agile is dead

Hace 6 años, en 2015, Dave Thomas, uno de los creadores del Manifiesto por el Desarrollo Ágil de Software, presentó la charla "Agile is dead" en una importante conferencia internacional de desarrollo de software (si no has visto el vídeo, te lo recomiendo encarecidamente).

En ella, ponía en entredicho el uso actual de los principios y valores que un día crearon. La esencia se ha desvirtuado a base de construir toda una industria Agile alrededor, donde se endiosan los métodos y las prácticas por encima de los resultados y objetivos, y las certificaciones y formaciones por encima de las experiencias reales.

De este modo, Agile, así en mayúsculas como dice D.Thomas, se ha convertido en un fin en sí mismo, generando nuevos términos, roles y formas de trabajar que todo el mundo se ve obligado a adoptar para no quedarse atrás, sin importar tanto el sentido ni el para qué.

Este fanatismo genera a su vez una inflexibilidad hacia otras prácticas igualmente válidas y útiles, que son desechadas simplemente por no estar explícitamente recogidas en el framework de turno.

Y es que a pesar de que la propia guía de Scrum dice: “funciona bien como contenedor para otras técnicas, metodologías y prácticas”, seguimos buscando la bala de plata que nos salvará de todo.
Lamentablemente, intentar aplicar siempre la misma fórmula mágica solo provoca frustración y fracaso, ya que nunca va a funcionar si no se presta atención a las diferentes condiciones de entorno:

• Magnitud y naturaleza de la necesidad.
• Contexto organizativo (trámites imprescindibles, estándares, limitaciones, etc.).
• Relaciones contractuales con terceros.
• Envergadura tecnológica.
• Escenario de colaboración (número de actores, áreas e incluso empresas involucradas).
• Equipo humano (experiencias, valores, seniority, puntos fuertes y débiles, etc.).

No rules are universal. All rules need context.

Dave Thomas

Creador y firmante del manifiesto Agile

Complejidad al cuadrado

Si añadimos a esta reflexión la particular realidad de la consultoría de software, la complejidad crece exponencialmente y el agilismo de hoy día se tambalea aún más.
Y es que no es lo mismo desarrollar software para uno mismo o para un tercero, y esto impacta directamente en el cómo.

Imagina un escenario en el que tienes la necesidad de desplazarte de un punto “A” a un punto “B”, puedes lograrlo de al menos tres formas:

1. Usas tus propios recursos: Tu coche, tu gasolina, tu tiempo, tus reglas. Si quieres parar a hacer un recado, puedes hacerlo, si intuyes que hay una calle atascada puedes cambiar de dirección o coger un atajo, confías plenamente en ti mismo y si te equivocas, lo que estás gastando solo repercute en ti (de un modo directo).
2. Coges un taxi en la calle: Le das al taxista la información sobre el punto B al que quieres llegar y como mucho algún detalle adicional. En este escenario entra en juego la confianza: cuestionas el recorrido elegido, miras el taxímetro ¿y si está dando rodeos para cobrarte más? Además (para los más miedosos), no sabes nada de la persona que te está llevando, ¿y si te pasa algo malo?
3. Recurres a una app de servicios de VTC: De primeras tienes una estimación de tiempo y coste de tu trayecto, que puedes o no aceptar sabiendo que puede haber ciertas fluctuaciones. En seguida ves información sobre la persona que va a conducir el vehículo (datos y estadísticas), puedes incluso compartirla con otras personas. Todo esto te da tranquilidad y hace que aumente tu confianza, por lo que durante el trayecto vas más relajado y no fiscalizas tanto cada movimiento del conductor.

Volviendo al software, el escenario 1 sería un desarrollo ágil in house. Una startup o una empresa de producto, donde es más fácil fomentar el sentimiento de equipo, hay menos barreras para la comunicación y el alineamiento, se facilita la toma de decisiones y los cambios de rumbo no impactan en contratos y acuerdos con terceros.

El escenario 2 es más parecido a lo que pueden sentir las empresas que contratan un desarrollo ágil de software. No saben bien cuánto van a pagar, cuándo van a tener el producto deseado, hay cierta desconfianza y sensación de falta de control.

En definitiva, se sienten inseguros y eso les lleva a usar sus mejores armas de protección: contratos axfisiantes, micro-management, etc. Pero estas armas solo consiguen dificultar aún más el desarrollo ágil de software.

Y por último, el escenario 3 entiende esa realidad y miedos del cliente, y extiende la forma de dar servicio para cubrir sus necesidades, sin perder la esencia. Cuando una empresa contrata a una consultora de software es porque la tecnología es un medio para mejorar el servicio que ofrece a sus usuarios.

Por tanto, tener clara la necesidad de negocio, optimizando la solución y midiendo el impacto de lo desarrollado es fundamental, así como entender, que no todo termina con la entrega de software, detrás suele haber campañas de marketing, estrategias de ventas, etc. y para ello hace falta compaginar la previsión con la inspección y adaptación.

Además, la propia decisión de externalizar el desarrollo nos indica que probablemente hablemos de una gran empresa, con la complejidad organizativa que eso implica y procedimientos poco adaptativos respecto al cambio, como son los procesos de licitación y las áreas de compras, la gestión de presupuestos, estándares de seguridad o temas regulatorios.

Esto no quiere decir que debamos rendirnos o que no sea posible trabajar de forma ágil como un único equipo integrado (cliente y proveedor). Pero tampoco podemos obviar esta realidad y aplicar nuestro framework ágil de libro, porque esto solo va a conseguir generar fricción, dificultar la adopción de principios y valores ágiles y no obtener los beneficios y resultados esperados, frustrando a clientes y equipos de desarrollo.

Agile is dead not enough

En Paradigma, llevamos 15 años desarrollando productos digitales de forma ágil para grandes empresas. Esto nos ha dado la valiosa ventaja de conocer las necesidades reales de los proyectos y clientes pero, sobre todo, de saber qué aspectos están cubiertos por los métodos ágiles y cuáles hemos tenido que reforzar con prácticas propias para conseguir el éxito de estos proyectos.

El agilismo no está muerto, simplemente sus métodos son a veces insuficientes para cubrir todas las necesidades añadidas en un contexto cliente-proveedor.

Porque el objetivo no puede ser clavar el timing de los eventos y calcar un framework. Seguir un método al dedillo y que el proyecto vaya mal o algunas de las partes no esté satisfecha es un fracaso.

Con máximo respeto hacia los principios y valores ágiles, estamos firmemente convencidos que en lo operativo los métodos necesitan ser extendidos para cubrir el contexto real, no el ideal, y que en lo filosófico se necesita un revulsivo que mejore la conexión de los equipos con el verdadero valor entregado por encima del cumplimiento metodológico.

Próximamente haremos público el resultado tangible de esta reflexión. Una extensión del agilismo que no reinventa ni sustituye nada, que muy lejos de ser un nuevo dogma es simplemente lo que nosotros, con nuestra experiencia, creemos necesitar para entregar más y con menos fricción.