Noticias, comentarios y reflexiones sobre liderazgo y gestión en organizaciones digitales, o que se mueven hacia lo digital
lunes, 20 de noviembre de 2017
¿Qué es Agile?
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.
martes, 7 de noviembre de 2017
Aportaciones de Agile en la Transformación Digital
Una manera muy frecuente y, en mi opinión, muy adecuada, de comenzar o impulsar el proceso de maduración digital es introducir y potenciar Agile en la organización. En algunos casos el impulso de Agile es una línea de trabajo definida dentro de un marco de Transformación Digital más amplio (por ejemplo, PSA ó Banco Santander). Pero no es así en todos los casos. A veces es una iniciativa única hacia la Tansformación Digital ó convive con otras iniciativas, pero de un modo inconexo. Esta segunda aproximación es actualmente mayoritaria entre las compañías españolas. Normalmente, explícita o implícitamente, se trata de una primera etapa en la que se prueba mientras la organización gana en madurez para encontrar su propio camino hacia lo digital.
En uno u otro caso, se haga por unas razones o por otras, la introducción de Agile significa sin duda un paso importante hacia la maduración digital. Pero dejemos claro desde el principio que Agile puede ser necesario para alcanzar un buen grado de madurez digital, pero no es suficiente en sí mismo para asegurar nuestra maduración.
La razón esencial es porque Agile es un excelente medio para hacer más líquida la organización y moverla con rapidez, pero no garantiza que el avance sea en la dirección adecuada en todas las dimensiones. Podemos ver esto con un poco más de detalle si utilizamos el modelo de cinco prácticas empresariales para la madurez digital del MIT que comentamos en nuestro post anterior. Para ello hemos elaborado la siguiente tabla, donde resumimos el impacto de Agile en la implantación de cada uno de ellas.
Es decir, Agile nos puede servir en sí misma para implementar los cambios sistémicos reclamados en la primera práctica. Esto ya es una gran aportación que justifica el uso de Agile desde la perspectiva de avanzar en la maduración digital.
Además, nos puede proporcionar el marco de operativo y de pensamiento para realizar experimentos y escalarlos. Esto no resuelve completamente la implantación de la práctica pues falta dotar de una dirección (o intención) a esos experimentos y definir un modelo de financiación de la innovación, pero, aun así, realiza una aportación significativa.
También Agile aporta a la hora de convertirse en imanes para el talento. Nuevamente, no resuelve completamente el asunto pero hoy está ampliamente documentado que uno de los beneficios de uso de Agile es la mayor facilidad para atraer talento. Para convertirse en un imán de talento de pleno derecho digital, falta definir la estrategia digital (el reto del negocio) y su repercusión en el tratamiento de los recursos humanos (mecanismos de atracción y retención, competencias, recompensas, etc).
En jugar el juego a largo, la aportación de Agile es pequeña, y en muchos casos marginal, pero lo reflejamos en la tabla porque en otros casos puede ser significativa. Agile puede cambiar la percepción de lo que la organización es capaz de hacer. Desde luego, esto no nos resuelve en absoluto cómo definimos nuestro juego a largo, pero en muchas ocasiones, hace posible que la organización pueda empezar a pensarlo.
Con todo esto hemos pretendido argumentar por qué Agile es importante para la Transformación Digital y proporcionar un primer esquema del perímetro de la aportación Agile en el contexto más amplio de la Transformación Digital. Además es una buena manera de comenzar, de manera que si el lector quiere avanzar en la TD y no sabe muy bien cómo empezar, una buena respuesta es empezar por experimentar con Agile mientras piensa qué más hacer.
Suscribirse a:
Entradas (Atom)
Comunidad Abierta Passion for Digital Learning
Estoy convencido de que estamos viviendo una transformación rápida y profunda que afecta a toda la sociedad. Todos los días estamos vivie...
-
En el post anterior mencionamos el reciente estudio del MIT “Achieving Digital Maturity” (G. C. Kane, D. Palmer, A. N. Phillips, D. K...
-
Ayer celebramos el primer evento abierto de AHDALID en el salón de actos de las oficinas de El Corte Inglés en la calle Tomás Bretón de...
-
En este artículo terminamos la serie que analiza los principales aspectos del estudio G. C. Kane, D. Palmer, A. N. Phillips, D. Kir...