En el post anterior discutimos con cierto detalle las aportaciones de Agile a la Maduración Digital. Antes de hablar más de Agile, creo que conviene que expliquemos qué entendemos por Agile. De esta manera podremos saber, de entre las toneladas de artículos, libros, vídeos, que tenemos a nuestro alrededor hoy sobre Agile (basta teclear en Google), a qué nos estamos refiriendo.
También pretendemos que este post pueda ser útil a quién se está comenzando a acercar a Agile y quiere empezar a hacerse una idea de qué es y en qué hay que hacer para comenzar a trabajar con este esquema.
Lo primero que tenemos que decir es que hay muchas maneras de llegar a Agile. Me refiero tanto a los seres humanos individuales como organizaciones. Todos tenemos nuestra historia (pasado), individual o colectivo, que tenderá a que evolucionemos (futuro) de una u otra manera.
Así, algunos se encuentran con Agile como la traslación al desarrollo de software de las ideas Lean. Otros, sin embargo, ven Agile como una evolución del TQM (Total Quality Management) o el BPR (Business Process Reingeneering) en el mundo de la ingeniería de software. También otros identifican a Agile con alguna de sus prácticas concretas (por ejemplo, Scrum o Kanban).
Mi mensaje aquí es bienvenidos todos. Cada uno puede empezar a ver el asunto como le sea más cómodo. Todos estos caminos son válidos y, seguramente, muchos otros que no hemos dicho.
En todo caso, en algún momento hay que empezar a entender qué es Agile de una forma más rigurosa para poder identificar el uso más adecuado por cada uno, los beneficios que se pueden esperar, los riesgos del camino y el propio proceso de maduración en Agile.
A continuación intentaremos proporcionar esa visión general de lo que es Agile partiendo de su propia definición forma, es decir, el Manifiesto Agile.
Entre el 11 y el 13 de febrero de 2.001, 17 gurús de la ingeniería de software se reúnen en lSalt Lake Cisty para discutir cómo debería producirse el software para mejorar el resultado final. Eran entonces (y lo siguen siendo ahora) personas muy heterogéneas con opiniones y puntos de vista encontrados sobre lo que había que hacer, pero todos ellos compartían la visión de que era necesario un profundo cambio de paradigma en la industria del software.
Ya entonces, había multitud de síntomas sobre la gravedad del problema. Así, por ejemplo, un estudio de Standish Group sobre 10.000 proyectos IT indica que en 1.994 únicamente tenían éxito el 15% de los proyectos y la desviación media en tiempo y coste es del 170%. En 2.004 la tasa de éxito fue del 34% y el sobrecoste medio en tiempo y dinero del 70%.
El caso es que el grupo de los “padres constituyentes” de Agile compartían el diagnóstico (hacer cambios drásticos en la sistemática de producción de software), pero no conseguían ponerse de acuerdo sobre el tratamiento (en qué consiste exactamente ese cambio). Después de días de discusiones consiguieron ponerse de acuerdo en cuatro valores y doce principios a cumplir. Con ello, redactaron un documento, el Manfiesto Agile, que firmaron los 17 y publicaron unos días después.
Desde entonces, El Manifiesto Agile es accesible en la web en 66 idiomas. Siguiendo este enlace está la versión en español, donde se puede leer la redacción original de los valores y principios Agile. En general, son frases sencillas y que pueden parecer obvias, pero si uno las piensa despacio puede comenzar a comprender el tamaño de la brecha de cambio que eso significa respecto a lo que está viviendo actualmente en su organización.
Por ejemplo, el primer valor es “personas e interacciones sobre procesos y herramientas; eso no significa que no valoremos los procesos y las herramientas, sino que son más importantes las personas y las interacciones entre personas”. Como frase abstracta es evidente, pero ¿cómo se está comportando mi organización en este punto? ¿Qué cambios habría que hacer para darle la vuelta?
Cuando uno empieza a ser capaz de responder a esas preguntas, intuyendo la complejidad y ambigüedad de las respuestas, se suele hacer nuevas preguntas. ¿Pero de verdad hay que aplicarlo hasta el final o vale solo un poquito? Y, sobre todo, ¿Cuáles son los beneficios de hacerlo?
De momento, pido al lector que se crea que la respuesta a estas dos últimas preguntas es sí y muchos, dejando su argumentación para otro momento. Prometo cancelar esa deuda de fe en otro momento en este Blog, pero este post no quiero desviarme de la definición de Agile que se despende del propio Manifiesto.
Lo mismo ocurre con el segundo valor: “valoramos más tener software funcionando que documentación exhaustiva”. Nuevamente, esto no significa que no tengamos que realizar ningún documento, alguno aportará valor, sino que no perdamos el foco de que el objetivo es disponer de software funcionando cuanto antes. Es impresionante el overhead administrativo que tiene el software en algunas organizaciones, siendo relativamente frecuentes casos que superan el 60% (es decir, de cada 100 € que invierten en construir software, únicamente 40€ se gastan el escribir código dedicando los 60€, la mayoría de la inversión, en labores administrativas y de control.
Lo mismo ocurre con el tercer valor del manifiesto: “colaboración con el cliente por encima de negociación contractual” y con el cuarto “respuesta al cambio sobre seguir un plan”. No significa que en Agile no haya contratos o no se confeccionen planes, sino que éstos son puros medios al servicio de un fin superior: colaborar con el cliente o responder al cambio, respectivamente.
En este link se puede encontrar un interesante artículo de Jeff Sutherland sobre el significado de los valores Agile. Jeff Sutherland es uno de los firmantes del Manifiesto Agile y coautor de SCRUM junto con Ken Schwaber. Con esta lectura se puede tener una idea bastante completa de lo que significan los valores del Manifiesto Agile.
De esta manera, la definición formal de Agile es sencilla. Para considerar que algo (práctica, metodología, herramienta, modelo organizativo, etc) es Agile, es necesario que ese algo cumpla con los valores y principios de Manifiesto.
Ahora bien, como dice Jurgen Appelo, Agile es también un memeplex que tiende a incorporar y hacer suyas prácticas que son más antiguas o tienen aplicación en otro cuerpo de conocimiento.
Un magnífico ejemplo de lo primero es el propio SCRUM, ampliamente considerada hoy como la metodología Agile más extendida. El caso es que SCRUM es muy anterior a Agile. Como ya hemos dicho, el manifiesto Agile se firma en 2001 y Jeff Sutherland y Ken Schwaber inventan SCRUM en 1993. Es decir, aunque estrictamente hablando, SCRUM es pre-Agile, nadie discute hoy que sea una metodología Agile. Lo mismo ocurre con muchas otras prácticas y herramientas, lo que pone de manifiesto la potencia de Agile como memeplex que hace suyo y potencia elementos anteriores a su propia existencia.
Pero también Agile se expande en horizontal saltando a otros campos y haciendo suyos elementos de otros cuerpos de conocimiento. Esto es así empezando por el propio ámbito de actuación de Agile. Como se lee en el propio manifiesto, los firmantes se refieren a la ingeniería de software. Sin embargo, hoy nadie discute que la aplicación de Agile a equipos cuyo objetivo no es la producción de software. Por ejemplo, Scrum se utiliza mucho para hacer experimentos de negocio o Kanban para la realización de servicios donde no se tiene por qué desarrollar o corregir software.
Mi último mensaje de este post es que la aplicación de los principios y valores Agile requiere una práctica y una disciplina. Se trata de interiorizarlos y ponerlos en práctica a la vez, día a día, poco a poco, pero no esperando a tenerlo perfectamente claro antes de empezar a actuar, porque entonces, no empezaremos nunca. La reflexión e interiorización de los valores y principios es imprescindible, pero tiene que ir acompañada con la acción, la práctica diaria.
Ilustro la idea con una anécdota. Me decía la semana pasada un directivo de un grupo multinacional en plena transformación Agile, que desde hace año y medio, cuando le contamos los cuatro valores Agile, él los repite todos los días en voz alta en el coche, por la mañana al ir y por la tarde al regresar a casa.
En el viaje de ida repite los principios para recordarlos y tenerlos presente en su actividad diaria, y, en el viaje de regreso, para revisar si durante el día tomó decisiones alineadas con esos principios o no. Él ha inventado esta práctica y la ha integrado de forma natural en su día a día. Ha sido su llave para el necesario cambio de paradigma, le está ayudando a avanzar con rapidez y paso firme en su propio proceso de maduración digital y le está facilitando desempeñar bien y con fuerte potencial de éxito su role como directivo clave en la Transformación Agile de su compañía.
