"Para terminar rápido, hay que enfocarse solo en el código", una creencia que impide la agilidad
Agile no es “entregar más rápido”, sino la capacidad de adaptarse rápidamente a las circunstancias cambiantes para mantener y mejorar los buenos resultados
Hay un comic de Dilbert, de Scott Adams, que ilustra perfectamente lo que quiero decirte hoy y es este:
A principios del siglo XXI, había un diagnóstico respecto a la forma de trabajo estándar en el desarrollo de software:
Los procesos eran demasiado pesados.
La forma de trabajo es muy lineal, con muchos tiempos muertos.
Existe demasiada documentación, planificación y puntos de verificación, que retrasan el desarrollo.
En resumen, el proceso añadía mucho overhead administrativo, impidiendo lograr los deadlines, y no garantizaba la buena calidad de la entrega, ni en requerimientos ni en ausencia de defectos. Esto era causado por muy malas implementaciones de modelos como ISO y CMMi, así que las empresas estaban desesperadas en busca de una solución para ese “problema” de procesos pesados y burocráticos.
Sin embargo, una mala implementación de un modelo tiene como origen una mala comprensión del modelo. Esa mala práctica se manifestó cuando escucharon acerca de la filosofía Ágil.
Si recuerdas, la filosofía ágil está basada en cuatro principios, escritos en esta forma: “preferimos esto sobre esto otro”. Por ejemplo: “Software funcionando sobre documentación extensiva”. ¿Qué ocurrió cuando muchas organizaciones trataron de interpretarlo? Que, en su mente, el principio era abandonar la documentación por completo. Lo mismo con “Individuos e interacciones sobre procesos y herramientas”, que en su mente se tradujo como “no necesitamos procesos”.
Así, con esta creencia errónea, eliminaron muchas actividades de su proceso para concentrarse en dos:
Comenzar a escribir el código tan rápido como se pueda
Probar y arreglar el código en un ciclo infinito
Para algunos, es una buena alternativa, porque cada vez hay más código entregado y es mejor estarlo arreglando en producción que en desarrollo; sin embargo, genera más problemas en el largo plazo:
Código difícil de mantener, por la ausencia de estándares
Fixes rápidos, que se convierten en bugs catastróficos
Ausencia de una base de conocimiento
Lentitud, conforme los sistemas se vuelven más complejos
Dificultad para responder a los cambios de requerimientos
Es decir, en el afán de considerar al código como la actividad de mayor valor, eliminan actividades y habilidades que facilitan lograr ese valor. En verdad, la planificación y la documentación son valiosas; el propósito es hacerlas adecuadas para el trabajo.
Quiero concluir con que Agile no es “entregar más rápido”, sino la capacidad de adaptarse rápidamente a las circunstancias cambiantes para mantener y mejorar los buenos resultados. Eso no se logra enviando a la gente a escribir código como sea, sino encontrando maneras diferentes de escribirlo, según la ocasión y el equipo. De eso quiero hablarte con detalle después.
¿Quieres lograr esto en tu organización? ¡Contáctame y establezcamos una estrategia adecuada para ti!
Agenda una sesión de descubrimiento: https://www.edgarfernandez.com/booking/