Las Leyes de Lehman y la Agilidad

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.

Javier Garzás

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Ir arriba