¿Cuándo utilizo Agile? La respuesta que estabas esperando

He escuchado ésto una y otra vez a lo largo de los años y espero aquí responder la pregunta del millón o por lo menos darte una orientación firme. En entradas anteriores te hablé sobre la importancia que tiene en el software la forma y el caudal de los requerimientos a la hora de analizar la posibilidad de utilizar las metodologías Agile/Scrum o seguir con los métodos tradicionales. Ahora te demostraré porqué…

Sistemas con requerimientos estables
En un sistema donde los requerimientos son efectivamente estables (como ser quizá una aplicación bancaria), el emplear los métodos tradicionales es una buena idea. No obstante, hay que tener en cuenta que la percepción sobre estabilidad puede ser errónea ya que el sistema se clasificaría como estable pero quizá un elemento externo (la competencia) podría inesperadamente forzar a un cambo de rumbo (nuevo producto lanzado al mercado, etc). De acuerdo con la ley de Ziv’s, el desarrollo de software no es predecible.

«Ley de Ziv: el desarrollo de software no es predecible»

Por el otro lado, el sistema puede parecer estable pero el cliente no realmente conocer lo que quiere y la única forma de confirmar lo que finalmente desea es mostrándole la aplicación funcionando.

«Ley de Humphrey: el cliente no sabe lo que desea hasta que no lo vea implementado y funcionando en una aplicación»

La ley de Humphrey dice que «El cliente no sabe lo que desea hasta que no lo vea implementado y funcionando en una aplicación»; cosa que parece ser sistemáticamente ignorada cuando nos enseñan en la Universidad y por la mayor parte de los jefes de proyecto. Piensa por un segundo… ¿Cuantos de tus trabajos se han llevado acabo exactamente de la forma estipulada?

Si finalmente sorteamos estos dos obstáculos de forma positiva, hay un tercer factor a tener en cuenta… la estructura de la empresa.

La estructura de la empresa y su impacto
Uno de los problemas no incluidos a la hora de estimar un proyecto de software es lo que se expresa mediante la ley de Conway. Ésta indica que la estructura de la organización está reflejada en el código; sería algo así como ignorar que tu personalidad influirá en tu relación amorosa.

«Ley de Conway: La estructura de la organización se refleja en el código»

Una jerarquía de empresa poco flexible impactará negativamente en el diseño orientado a objetos, resultando en fuentes más rígidos y poco resistentes a los cambios.
Por otro lado, el ser poco flexible implica que se darían casos de «ellos y nosotros», sistema aplicado históricamente por muchas empresas para responsabilizar a una persona en vez de aprender proactivamente sobre el error. Esto último evidentemente crea problemas en el resto de la organización y es un ejemplo claro donde forzar el uso de las metodologías Agile sin un cambio de pensamiento puede causar un dolor de cabeza.

Metodologías Agile como visión global
Cuando finalmente encontramos una salida a los temas anteriores, tendremos que focalizarnos en que las metodologías Agile sean realmente comprendidas por la totalidad de los individuos en la empresa y no solamente seguidas por mandato divino, esto es, todos desde desarrollo, pasando por la parte gerencial, ventas, etc conocen los beneficios y trabajan proactivamente con una meta común empleando las reglas de transparencia, confianza mutua y respeto por las personas. Todo el mundo en la empresa debe ser re-educado a la nueva filosofía y optimizar los procesos de forma constante, inspeccionando y adaptando cada vez que se encuentre un problema, o lo que es igual, aprendiendo efectivamente y brindando los resultados a los colegas para un cambio real.
La visión del producto y las reglas de trabajo tienen que ser claras, no se deben contar con políticas que obstruyan a los individuos de ser productivos así como se debe embarcar en un proceso de comprensión y cuestionamiento positivo de los problemas .

«Los valores Agile nos guiarán en tiempos de poca claridad y ambiguedad y nos harán sustentar porqué hacemos algo de una forma determinada»

Los 4 tipos de proyecto
Finalmente me gusta inculcar a las personas que asisten a mis seminarios la idea que ha sido plasmada en el libro «Strategic Management and Organisational Dynamics, segunda edición» de Ralph Stacey.

En ella se indica que los proyectos pueden ser clasificados en 4 ramas:

1. Simples
2. Complicados
3. Complejos
4. Anárquicos

Los simples son aquellos que están llenos de cosas conocidas, esto es, sumamante parecidos a muchos que hemos realizado anteriormente, sabemos exáctamente que se necesita, conocemos las herramientas y el funcionamiento de la relación con los clientes.
Tan pronto como nos alejamos de la zona de confort, los requerimientos, la tecnología o ambos dejan poco a poco de ser conocidas, lo que agrega inestabilidad al sistema. Quizá no conocemos alguna de las herramientas o los usuarios no tienen claro lo que efectivamente desean. Ello hace que los proyectos sean mas difíciles de predecir y estimar.
Sin llegamos al tipo de «Complicados», tendremos más y más agujeros negros, donde no sabremos las respuestas y trataremos de adivinarlas (gracias a nuestro ego y… ¡Asumiento que las respuestas son correctas por supuesto!). Quizá sea una tecnología que no utilizamos anteriormente en nuestros equipos o desconcemos el área de producto. Al llegar al 4to tipo (Anárquico), éste contendrá cientos de dudas.

«Cuando las compañías se encuentran en el modelo de proyectos anárquicos, deberían centrarse en solucionar primero los problemas que la pusieron en este estado en vez de comenzar a construir un sistema de software»

Ésto nos demuestra que en cualquier lugar donde se esté a excepción del «Simple», se tendrán cientos de cambios durante la vida del proyecto, tanto sea a nivel de requerimientos, tecnológicos o quizá ambos. Aquí es donde las metodologías Agile se especializan… absorver cambios y tener la certeza de que el rumbo cambiará frecuentemente.

«Entendiendo que los cambios serán inebitables es un buen comienzo para comprender porqué se debe profundamente cambiar la forma de pensar y emplear Agile.»

Como siempre digo, las metodologías Agile son fáciles de comprender pero difíciles de poner en práctica; en teoría, teoría y práctica son iguales, pero en la práctica son diferentes. Espero te sea de utilidad ésta entrada.

Si quieres recibir mis novedades y artículos haz clic en la pestaña SEGUIR de abajo a la derecha; también te podría interesar alguno de mis otros artículos…

10 reglas de oro para medir un proyecto Agile

Descubriendo los problemas de equipos Agile

Implementar Ágil en paises hispanoparlantes vs. anglosajones

Resultados de 7ma. encuesta anual del estado de Ágil

Psicología profunda de las retrospectivas Ágil

6 problemas típicos en retrospectivas Ágil

¿Gastar en tecnología o metodologías de gestión de proyecto?

¿Qué hacemos con los recursos humanos en Ágil?

Agilidad y la verdad contundente sobre programación en parejas

Resistencia institucional y cambio hacia Agile (Parte 1)

Resistencia institucional y cambio hacia Agile (Parte 2)

Lo que no se dice de Ágil