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.
Por qué existe esta web
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
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.
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.
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.
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.
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.
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.
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».
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
Dale la vuelta a cada tarjeta para ver qué ocurre cuando se invierten las prioridades.
Autoevaluación
Marca las situaciones que reconozcas en tu equipo u organización. Las respuestas se guardan exclusivamente en tu navegador.
Tu resultado
El resultado aparece cuando marcas al menos una opción.
Volver a los orígenes
¿Las entregas tardan demasiado? ¿Hay fallos de calidad? ¿Faltan opiniones de quienes usan el producto? Elige una práctica que responda al problema concreto.
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.
Pregunta qué decisión permite tomar cada reunión. Si no cambia ninguna, el equipo puede acortarla, modificarla o quitarla del calendario.
Las pruebas automatizadas, la integración y entrega continuas y la refactorización permiten iterar en periodos cortos con software que se puede entregar.
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.
Son cuatro valores y doce principios. Volver a ese breve texto ayuda a resolver muchas de las discusiones actuales sobre Agile.
En el blog cuento lo que he visto en equipos y organizaciones: qué prácticas funcionan, cuáles fallan y por qué.