Sí, efectivamente, el cliente siempre quiere más y sí, la velocidad del equipo, probablemente, cada vez será menor
HOY se cumplen 29 años de la MUERTE de Lehman, considerado el padre de la evolución software (no te asustes por la palabra software que este post es para que lo entienda todo el mundo).
En los viejunos años 70, Lehman formuló las que se conocen como leyes de la evolución de los productos de base IT (software), es decir, qué pasa en esos productos, cómo se comportan según pasa el tiempo.
Y sus Leyes siguen VIGENTES HOY.
¿Y por qué son IMPORTANTES para lo nuestro?
¿Por qué Agile Coachs, Product Owners, Product Managers, Agile Leads, Scrum Master u otros deben conocer su trabajo para aplicarlo a lo suyo? ¿Qué aportó para luchar contra el Lado Oscuro?
Te cuento, resumido y explicado para TODOS los PÚBLICOS…
Lehman escribió muchas cosas técnicas, datos y demostraciones complicadas, que me ahorro en este post, para no perder el foco en lo importante que tienes que saber.
Entre sus Leyes hay varias que se han mantenido en el tiempo, invariantes, y que aplican a los actuales tiempos de gestión Ágil.
Vamos allá, con las Leyes de Lehman adaptadas a la gestión Ágil. Según sus estudios:
La funcionalidad de una aplicación debe incrementarse continuamente para mantener la satisfacción del usuario.
Ojo Product Owners y Product Managers, tod@s lo sabíais, y ahora también sabes que existe soporte teórico: siempre hay que añadir nueva funcionalidad a una aplicación, siempre, raro es que esté completa.
Lehman argumentó esta Ley en que las restricciones de tiempo y presupuesto hacen que se añadan a la aplicación las funcionalidades más prioritarias.
Y, con el tiempo, se acaban añadiendo otras de menor prioridad, nuevas que van apareciendo y hay que ir modificando las más antiguas.
Una aplicación en evolución se deteriora por dentro (se hace más difícil de mantener), haciendo cada vez más difícil su crecimiento funcional
Ojo, especialmente Scrum Masters, Agile Coachs, Agile Leads, etc., porque esto viene a confirmarnos que con el tiempo, el crecimiento funcional implica más complejidad para evolucionar.
Dicho con un poco más de precisión, aplicaciones más grandes son más difíciles de evolucionar y esa complejidad crece de manera no lineal. Hay quien llama a esto la «entropía» aplicada al crecimiento de una aplicación.
Es decir, que el tiempo que lleva desarrollándose una aplicación afecta a la velocidad. A más tiempo de vida de la aplicación, más complejidad supone añadirle funcionalidad.
SALVO que se trabaje muy activamente en controlar ese deterioro.
Y de ahí la imperiosa necesidad de dedicar tiempo no sólo a el incremento funcional SI NO TAMBIÉN a mejorar la MANTENIBILIDAD de la aplicación, quitar Deuda Técnica, etc.
Antes de terminar: The Agile Way Model
Desde principios de 2023 voy a empezar a compartir contigo, el método resultado de 20 años trabajando en Agilidad, algo que llevo contando desde hace años sin haberle puesto nombre, ni haberlo empaquetado para que lo podáis usar.
Pero este año 2022 hemos terminado de pulir el packaging y le hemos puesto nombre: The Agile Way Model (un modelo, qué no framework ni metodología) para guiar una transformación Ágil aportando Valor al negocio.
Que la Agilidad te acompañe y feliz año 2023.
La cita de hoy
Un sistema [IT] en evolución aumenta su complejidad a menos que se trabaje para reducirla. -Meir Lehman.
- Debes crear apps sin saber programar (no hay que saber nada) + Crea Test con IA + Scrum es el nuevo Excel - 12 septiembre, 2024
- Las 6 técnicas prompting + 1ª Ley del Manager Oscuro + Mantenlo sencillo, estúpido - 5 septiembre, 2024
- Guía de Métricas Ágiles (versión agosto 2024) - 22 agosto, 2024