El pasado 22 de mayo asistimos al tercer congreso BAC (Business Agility Corporation, club del que formamos parte) en el impresionante auditorio de la Ciudad Financiera que el Santander tiene en Madrid.
Nuestra aproximación al BAC es reciente, como lo es a los conceptos que anidan tras las palabras «DevOps», «Agile» o «Responsive», entre otras… y ya les aseguro que las distinciones conceptuales no son sencillas al margen de la práctica.
Como a estas alturas ya saben los lectores habituales de este blog, en mi empresa no nos dedicamos precisamente al mundo del software sino a la producción de componentes metálicos de automoción, así que podríamos decir que el concepto de «Agile» nos ha llegado tarde y mal.
«Agile» nació como un manifiesto promovido por un grupo de desarrolladores de software que proclamaron lo siguiente:
Manifiesto por el Desarrollo Ágil de Software
Estamos descubriendo formas mejores de desarrollar
software tanto por nuestra propia experiencia como
ayudando a terceros. A través de este trabajo hemos
aprendido a valorar:
Individuos e interacciones sobre procesos y herramientas
Software funcionando sobre documentación extensiva
Colaboración con el cliente sobre negociación contractual
Respuesta ante el cambio sobre seguir un plan
Esto es, aunque valoramos los elementos de la derecha,
valoramos más los de la izquierda.
Se dotaron de unos principios fundamentales que, si tienen la curiosidad de leer (se lo recomiendo vivamente), creo que les conducirán inevitablemente a interpretaciones que van mucho más allá del corsé del software y que les propondrán revisar mentalmente algunas de las seguridades que culturalmente tenemos asumidas desde hace tiempo.
Para poner en práctica el manifiesto y sus principios, las empresas de software comenzaron a desarrollar metodologías y formas de trabajo con notables dosis de contraculturalidad, por lo tanto, así como a integrar algunas prácticas desarrolladas en paralelo en el territorio de la gestión empresarial en general.
Entre las primeras, destacan con fuerza SCRUM, como modelo metodológico y de organización para la gestión de equipos de proyecto, o DevOps, una especie de marco general de trabajo que descansa sobre la integración de desarrolladores y sistemas (u operaciones, en terminología de software, que conceptualmente no va mucho más allá que los ya históricos equipos interdisciplinares de desarrollo de proyectos que integran la ingeniería de proyectos, la producción y la ingeniería de instalaciones), aunque en este caso con el añadido de herramientas de automatización de procesos que permiten a los desarrolladores centrarse en su core y hacerlo con seguridad y calidad del producto.
Entre las segundas, hay que mencionar inevitablemente todo concepto lean (lo que incluye desde el kanban hasta el lean startup y el concepto de MVP) y el design thinking como modelo de aproximación a la resolución de problemas y al desarrollo de retos, configurado en forma de propuesta iterativa de observación y de orientación permanente a clientes y usuarios (basada en ciclos continuos de experimentación, prototipado rápido y aprendizaje desde las mismas) y en una amplia colección de herramientas metodológicas que ayudan a recorrer el camino y a configurar la salida.
Ejem… ya empezamos con la ensalada de palabros que vamos echando al puchero de la gestión de la empresa sin aparente sentido, ¿no creen?
A ver…
Elevándonos a un plano no demasiado estricto, podemos decir que una empresa «agile» es equivalente a decir «una empresa ágil», entendiendo por tal una empresa capaz de adaptarse con gran rapidez, productividad y eficacia a los cambios que en su entorno se fueran produciendo, de forma previsible o imprevisible.
En ese sentido, «Agile» tiene mucho que ver con la idea de «Responsive» que ya citamos en el post anterior y que ya habíamos trabajado en Co-Society, pero el hecho de que el origen sea diferente (desde el lado operacional hasta el estratégico en el caso de agile… e inverso en responsive), hace muy visible que aún no se ha convergido suficientemente y que por tanto queda camino por recorrer.
El intento de «Agile» de llegar hasta la estrategia tiene su base precisamente en su origen. Nace ligado al desarrollo de producto… en empresas cuya tecnología operativa es precisamente el software y el hardware ligado a las TIC. Eso hace que el paso de lo operativo a lo estratégico se dé de forma muy natural, porque está en la naturaleza de su negocio.
Por eso también, las empresas más avanzadas en agile (aparentemente), son bancos, aseguradoras, empresas de telefonía… que en el fondo soy hoy «empresas TIC». Si observamos realidades agile avanzadas en otro tipo de empresas, es raro encontrarlas al margen de su área TIC.
Todas ellas, no obstante, visualizan con claridad que en un entorno extraordinariamente cambiante, marcado por la velocidad, la reducción de los lead-time y los ciclos de vida y, sobre todo, por la incertidumbre creciente que rodea toda actividad empresarial actual, la idea de «agilidad» responde a una absoluta necesidad, sea cual sea el sector en el que se opere.
Construido desde la experiencia y la reflexión de las «empresas TIC» que antes mencionaba (es una humilde hipótesis personal, no contrastada), BAC ha elaborado un muy interesante esquema visual que reproduzco a continuación:
Acierta en muchas cosas, en mi opinión, como en el cimiento lean, los pilares de personas y cultura (cuidado con la cultura), la permanente orientación a la idea de valor y, sobre todo, el esquema de Organización / Infraestructuras / Producción / Negocio como elementos necesariamente ágiles en una organización ágil.
Aclara también cuál es el lugar que primordialmente corresponde a piezas concretas del puzzle, incluida la importancia de mimar los elementos de trasformación de cultura o la de los cambios que suponen en el ámbito de compras o finanzas la «contratación agile«.
Pero, desde la analogía «agile» y «responsive» que antes les proponía… se queda corto. Una empresa «no-TIC» ve el desafío de agilidad desde lugares de prioridad que para las empresas TIC son más secundarios. Para las «no-TIC», la integración de proveedores en la cadena de valor y singularmente en la mejora e innovación de procesos, es un elemento de agilidad muy poderoso… incluso (permítanme la provocación) si se realiza desde planteamientos waterflow o clásicos de gestión de proyectos. Lo mismo podríamos decir de los procesos de innovación abierta, de inteligencia competitiva o de otros aspectos relevantes de la gestión empresarial.
En el III Congreso BAC, solo la ponencia de Siemens-Gamesa pertenecía a esa categoría de «no-TIC». Trataba sobre una iniciativa de «open innovation»… y parecía un marciano verde en un campo de amapolas (perdóname, Mónica 🙄 ). Casi que hubiera sido necesario explicar por qué había una ponencia así en ese congreso…
Y sin embargo… son asuntos que aportan una innegable agilidad a la organización.
Dentro de nuestro equipo, Yuri Noda ha construido recientemente aportaciones interesantes desde este punto de vista. No incluiré aquí los mapas mentales que ha elaborado (son intelectualmente suyos… 😉 ) pero sí me voy a tomar la licencia de citar algunos de los conceptos clave que incorpora, como (además de los tres anteriores), el trabajo con startups, el marketing o el aprendizaje desde la idea de agilidad, los modelos de gobernanza, la automatización sobre tecnologías «no-TIC», el trabajo en redes, las relaciones de transparencia y confianza…
Nuestros esquemas mentales son siempre un limitante, ya lo ven… Incluso para quienes van por delante. 😉
Queda camino por recorrer… y eso siempre está bien. 🙂
inquietos 