Por qué existe esta web

Agile nació para liberarnos de la burocracia. Acabó pareciéndose a ella.

Hace unos quince años, Agile representaba una ruptura con la rigidez del desarrollo en cascada. Hoy, para mucha gente, la palabra evoca reuniones diarias interminables, ceremonias sin propósito e informes que nadie utiliza. Creé esta web para recordar qué problema intentábamos resolver.

En el desarrollo en cascada se podían pasar meses redactando una especificación y otros tantos construyendo lo que decía. Solo al final se descubría que el cliente necesitaba otra cosa. Entre tantos documentos y firmas, apenas quedaba espacio para hablar con él.

Quienes desarrollaban software propusieron hablar más con las personas y entregarles algo que funcionara cada pocas semanas. Así podían comprobar si iban en la dirección correcta mucho antes de que terminara el año. Funcionó, y muchos quisieron imitarlo.

Resultó fácil copiar la forma y mucho más difícil entender el fondo. Una dirección puede imponer reuniones, tableros, cargos y certificados. La confianza, la autonomía y la curiosidad requieren otras condiciones. En muchas organizaciones cambió el vocabulario, pero se mantuvieron los controles, los informes y la distancia con el cliente.

La industria que vendía Agile prosperó, en parte, gracias a una confusión: adoptar las ceremonias parecía más fácil que compartir las decisiones.

Esta web nació de mi artículo «Make Agile Great Again», de diciembre de 2024. En él contaba cómo una idea revolucionaria había acabado reproduciendo aquello que intentaba cambiar.

Entiendo a quienes se han apartado de Agile después de vivir esa experiencia. Pero abandonar también lo que funcionaba nos devuelve a los problemas de partida. Por eso quiero recuperar sus valores y examinar para qué sirven los rituales.

Cronología

Del Manifiesto a la industria de Agile

  1. 2001

    Una rebelión de profesionales

    Diecisiete personas con experiencia en desarrollo de software y equipos se reúnen para cuestionar los procesos pesados. Su manifiesto cabe en una página.

  2. 2005–2012

    Los años del auge

    Scrum y Agile se popularizan. Los resultados de equipos pequeños llaman la atención de la dirección. Se multiplican los cursos, congresos y certificados.

  3. Década de 2010

    La industria de la certificación

    Un curso de dos días basta para obtener un título de «master». Agile se vende con licencias, consultores y programas de transformación de varios meses.

  4. Desde 2011

    Agile a gran escala

    Las grandes empresas quieren extender Agile a toda la organización. Los marcos de escalado añaden niveles de responsabilidad, artefactos y reuniones. Muchos equipos vuelven a recibir órdenes desde arriba.

  5. 2014

    «Agile is Dead»

    Dave Thomas, uno de los firmantes del Manifiesto, escribe que el marketing se ha apropiado de la palabra «agile». Propone hablar de agilidad como una capacidad que se desarrolla.

  6. 2016

    Dark Scrum

    Ron Jeffries describe lo que llama «Dark Scrum»: reuniones diarias para fiscalizar a cada persona, compromisos impuestos por la dirección y falta de confianza.

  7. 2018

    Agile Industrial Complex

    Martin Fowler habla del complejo industrial de Agile y de cómo se vuelve a imponer el proceso desde fuera del equipo. Jeffries publica «Developers Should Abandon Agile».

  8. Década de 2020

    El retroceso

    Las empresas recortan puestos de Scrum Master y de acompañamiento ágil. En grandes organizaciones, «Agile» ya se asocia con burocracia, reuniones y Jira. Vuelven los controles centralizados y los planes anuales.

Comparación

El Manifiesto y su versión corporativa

Dale la vuelta a cada tarjeta para ver qué ocurre cuando se invierten las prioridades.

Autoevaluación

¿Repite tu equipo los rituales de Agile?

Marca las situaciones que reconozcas en tu equipo u organización. Las respuestas se guardan exclusivamente en tu navegador.

Tu resultado

0 / 12

Marca las situaciones que reconozcas

El resultado aparece cuando marcas al menos una opción.

Volver a los orígenes

Seis pasos que no requieren un certificado

01

Identifica el problema antes de elegir un marco

¿Las entregas tardan demasiado? ¿Hay fallos de calidad? ¿Faltan opiniones de quienes usan el producto? Elige una práctica que responda al problema concreto.

02

Mide el efecto del trabajo

Observa cuánto pasa desde la idea hasta la entrega, con qué frecuencia llega algo nuevo a producción y si les sirve a los usuarios. Contar puntos o reuniones no responde a esas preguntas.

03

Prueba a reducir las reuniones a la mitad

Pregunta qué decisión permite tomar cada reunión. Si no cambia ninguna, el equipo puede acortarla, modificarla o quitarla del calendario.

04

Invierte en la calidad técnica

Las pruebas automatizadas, la integración y entrega continuas y la refactorización permiten iterar en periodos cortos con software que se puede entregar.

05

Acerca las decisiones a quienes conocen el trabajo

El equipo decide cómo resolver el problema. El Product Owner decide qué hacer y en qué orden. La dirección les da condiciones para hacerlo con autonomía.

06

Vuelve a leer el Manifiesto

Son cuatro valores y doce principios. Volver a ese breve texto ayuda a resolver muchas de las discusiones actuales sobre Agile.

Todavía hay buenas razones para trabajar con agilidad.

En el blog cuento lo que he visto en equipos y organizaciones: qué prácticas funcionan, cuáles fallan y por qué.