Desde que conozco a nuestra compañera Esther, ella siempre me recuerda que no existe el manifiesto ágil, sino el “desarrollo ágil de software”, y que no es una doctrina “Agile” si no una manera de desarrollar. Y es verdad, realmente “ágil” es un adjetivo que se asocia al desarrollo software y que apareció gracias a 17 programadores que decidieron lanzar al mundo una declaración de intenciones de cómo ellos hacían el mejor software.
Por tanto, “ágil” no es una metodología, una cultura, un método, una filosofía o una forma de vivir, es un adjetivo. Por ejemplo, realmente no soy un “Agile Coach”, soy un “coach para el desarrollo ágil de software”. ¿Cómo cambia esto nuestra perspectiva?
Si Agile deja de ser un adjetivo, pasa a ser una etiqueta, y la etiqueta en producto. Una vez convertido en producto aparece la parte oscura del desarrollo ágil de software: marketing, vender como sea, aparentar… Todo, menos un cambio real. ¿Esto os suena?
¿Qué significa el desarrollo ágil de software?
Muchas organizaciones han entendido que si los equipos realizan un desarrollo ágil entonces eso debería reducir los tiempos de entrega. Esto nos debería permitir que, por ejemplo, nuestro proyecto de doce meses se reduzca a ocho meses. Quizás por esto, muchas organizaciones se han lanzado como lobos a usar el “Producto Agile”. Dado que está etiquetado, usamos el concepto agile para todo: enterprise agility, rrhh ágiles, agile en financiero y 300 cosas similares. Todo esto lo convierte en moda, y como moda, pasará y dejará mucho dinero invertido con poco retorno.
Al final, el concepto “Agile”, se asocia a una “eficiencia de procesos”. Si somos ágiles, seremos más eficientes, esto reduce los costes, podremos ser más competitivos. Por eso, aplicamos el producto “Agile” a todo. Sin embargo, esto se lleva haciendo desde la época de Taylor y se llama: “eficiencia de procesos”. Por eso, cualquier proceso es susceptible de ser hecho más eficiente, y por tanto “agilizables”. Es curioso, acabamos haciendo Agile para ser mejores “tayloristas”.
En un mundo muy muy lejano
Había un equipo que comenzaba un proyecto. Cuando se vendió, nadie del equipo de desarrollo participó de la estimación, había que contestar a la RFP de turno. El equipo se puso manos a la obra para hacer lo imposible. Usaron Scrum como marco de trabajo, cada Sprint le enseñaban al cliente lo que habían terminado y este les solicitaba cambios. Un día, descubrieron que no llegaban a la fecha, y empezaron a tener millones de reuniones para solucionarlo: reuniones de motivación, de bronca, de reestimación, de expectativas, con la gerencia, con recursos humanos (una persona no quería echar horas extra), etc.
¿Os suena esta historia? Lo curioso no es la historia, es bastante típica, lo curioso es que, nunca se tienen conversaciones con los usuarios sobre el software que se construye. Tan obsesionados con la entrega en fecha y mantener el margen, que no somos ágiles en lo que queremos serlo: con el desarrollo que entregamos al cliente.
Se trata de ser ágil en el servicio, en la entrega de valor. Asumamos que no sabemos todo lo que quiere nuestro cliente, que tenemos que descubrirlo, y por eso tenemos que ser ágiles, para adaptarnos a lo que realmente quiere.
¿Sobre qué debo ser ágil?
El desarrollo ágil consiste en ser flexible y rápido, un concepto clave es la inspección-adaptación: prueba una cosa, aprendo, pruebo otra. Esta manera de funcionar nos permite ser ágiles en el sentido de que, entregamos lo que nuestro usuario final realmente quiere. Para que eso ocurra, es esencial nuestra capacidad de inspeccionar-adaptar y de tener conversaciones.
Es decir, somos ágiles desarrollando el software que sí quiere nuestro usuario. Aquí está la agilidad. No es cuestión de inspeccionar-adaptar sobre un plan basado en estimaciones que dimos cuando apenas teníamos información y experiencia. La gracia del desarrollo ágil es tomar decisiones a medida que ocurren imprevistos.
Las conversaciones deben tenerse en torno a:
- al valor sobre lo que estamos entregando
- a cómo mi usuario usa el software
- qué le motiva y qué no
- qué necesidades aún no están cubiertas
- cómo las cubre mi competencia
- cúal es la satisfacción de nuestros customers
- cuál es la satisfacción de nuestros accionistas y miembros del equipo
- cuál es nuestra capacidad de entregar desde que recibimos una petición
- etcétera…
Si os fijáis, las conversaciones giran entorno a lo que importar: el software que alguien quiere. No es que no tengamos en cuenta la “fecha”, pero esas conversaciones no nos dicen si lo que hacemos realmente lo quiere alguien.
No es picar líneas de código más rápido, es picar las líneas de código que aportan valor. Esto supone ser ágil cubriendo las necesidades de mis usuarios, no tratando de llegar corriendo a una fecha.
Transformación ágil
La Transformación Agile está cada vez más de moda. Para muchos es eficientar la organización que se transformar, justo lo que nos vendió Taylor. Si cada proceso de una organización lo vemos una máquina cuyos piezas son las personas (llamadas recursos), podemos “agilizarlo” todo, con lo que ahorraremos costes. Esta visión para mí es errónea, nunca hablamos de eso en el manifiesto por el desarrollo ágil de software.
Lo que tratamos de realizar mediante un desarrollo ágil de software es enseñar a nuestra organización a funcionar en torno a los usuarios, sus necesidades y nuestra capacidad de entregar. No tratamos de entregar grandes cosas en menos tiempo sino que, tratamos de resolver pequeñas necesidades más rápido.
Y ¡cuidado! ¡la calidad es clave! Si no mantienes la calidad acabas llenando tu software de “basura” que nos ralentizará en el futuro lo que nos restará agilidad. Por eso, no hablamos de “desarrollo rápido de software”, sino de “desarrollo ágil”.
Una vez hemos entendido que tenemos desarrollo ágil de software, el resto de la organización se pone al servicio de los equipos que desarrollan para que no ralentizar la capacidad de entrega. Si nuestro objetivo es ser capaces de entregar más frecuentemente hay muchos asuntos sobre los que tendremos que tener conversaciones:
- Reducir los tiempos de espera entre departamentos ¿equipos multidisciplinares?
- Toma de decisiones más rápidas ¿empoderar a los Product Owners?
- Disponen de alta calidad ¿sistemas de automatización y calidad?
- Subidas rápidas a producción ¿cultura DevOps?
Por tanto, una cultura “ágil” es la que genera equipos de desarrollo ágil de software que generan valor a los clientes.
Y tú, ¿cómo agilizas?
