El 83% de los ejecutivos en banca y servicios financieros dicen que, en los próximos 12 meses, su negocio sufrirá un cambio disruptivo derivado de las tecnologías digitales. Y un 20% dice que su negocio sufrirá un cambio masivamente disruptivo. ¡Vaya panorama!

Pero no es algo específico de esa industria, tenemos ejemplos en muchas otras áreas, como por ejemplo Kodak y la fotografía digital o Blockbuster y el streaming. Es algo que le puede pasar a cualquier empresa en cualquier industria.

¿Cuál es la vacuna? La agilidad empresarial. Una empresa ágil es aquella que es capaz de detectar y responder al cambio con rapidez y confianza. Según la escuela de administración y dirección de empresas MIT Sloan, ser una empresa ágil tiene todo menos contraindicaciones: producen un 30% más de beneficios y, además, un 37% más rápido.

En paralelo a esta necesidad, parece emerger una corriente de pensamiento basada en que, ahora, todas las empresas son empresas de software. Y esto está derivando hacia la denominada digital enterprise. En su momento, los primeros que dentro de este sector financiero se lanzaron a este proceso como compañía me lo explicaron con facilidad: se trata de transformar el área de tecnología para que la capacidad de cambio no estuviera limitada por una TI diseñada en la era del papel.

Se trata de cambiar las formas con el objetivo de conseguir agilidad en el negocio a través de la agilidad en el portfolio y en la ejecución. Los modelos actuales de startup ya responden a este escenario como unas máquinas perfectamente engrasadas para pivotar. El reto es aplicar estas técnicas a las grandes organizaciones.

Las startup ya responden como unas máquinas perfectamente engrasadas para pivotar

Modelos de implantación

Ahora mismo, la gran mayoría de estas organizaciones ya han pilotado con éxito pequeños —algunos no tanto— proyectos ágiles, pero mantener la predictibilidad sin perder la flexibilidad de estas técnicas no es camino fácil.

Los éxitos en pequeños proyectos parecen no garantizar éxitos a escala media y grande. Aquí las tendencias parecen dividirse en dos grandes ramas: aquellos que abogan por la implantación de modelos más puros, como el de Spotify, y aquellos que se sienten más cómodos con enfoques más estructurados como scaled agile framework (en adelante, SAFe).

Spotify plantea un modelo de equipos independientes, con completa autonomía y foco concreto de impacto en una parte del producto. Por ejemplo, tendríamos un squad (así llaman a los equipos en la cultura Spotify) cuya actividad estaría centrada en mejorar la experiencia de búsqueda en el app. Esta autonomía les permite implantar sus cambios con independencia de la actividad del resto de los squads, medir los resultados obtenidos y evolucionarlos hasta obtener el impacto deseado. Agrupan a los equipos en tribus para que los squads que trabajan en el mismo producto compartan espacio y colaboren entre ellos. Para que estos squads puedan poner en producción sus cambios y realizar el análisis del impacto, otros squads, llamados “de infraestructura”, construyen las herramientas y devops que luego los primeros usan.

El modelo de Spotify requiere de una serie de características que debe cumplir el software a evolucionar. Por ejemplo, si la arquitectura subyacente no está completamente desacoplada, la independencia y autonomía de los equipos difícilmente será tal. Con una arquitectura no modular, altamente acoplada y totalmente monolítica, un cambio mínimo puede afectar a una gran parte del sistema dificultando la independencia en la entrega del valor del equipo. Primero sería necesario invertir en crear componentes y capas de servicios que permitan minimizar el impacto potencial de los cambios en una parte de la funcionalidad respecto al resto del sistema, abriendo así la posibilidad de que los equipos puedan ser independientes entre sí en la entrega de valor.

Con independencia de este factor, este es un gran modelo como objetivo. Permite un nivel de flexibilidad tal que cada área de un sistema puede ser explotada, de forma independiente, en busca de ventajas competitivas.  Sin duda, el nivel de autonomía de los equipos, y su cohesión, aumenta la motivación y reduce la rotación. Todo esto sin contar que este nivel de independencia de las unidades facilita la colaboración entre ubicaciones geográficas. El uso de inner sourcing —para vencer las pocas dependencias inevitables entre equipos y programas— mantiene la máquina engrasada y funcionando sin esperas. 

En España ya vamos viendo iniciativas de modelos tendentes al de Spotify a escala de equipo. La semana pasada tuve la oportunidad de conversar con algunas personas implicadas en el proceso de transformación de un gran banco español, y hablamos sobre los primeros éxitos en pilotos agiles integrando design thinking, lean startup y agile en alguna de las divisiones internacionales de esa entidad.

Por otro lado, SAFe —que tiene un currículo impresionante de referencias, como pueden ser Intel, John Deer,  Phillips o Banco Santander— puede generar estructuras demasiado jerárquicas, que podrían llegar a dificultar la creatividad y limitar la motivación de las personas. En cambio, cuando el nivel de dependencias en un sistema es el habitual, este modelo se adapta muy bien a la realidad. Es más aplicable en los primeros estadios de una transformación.

La dificultad no está en determinar el modelo que necesita, sino en facilitar un camino adecuado a ese modelo

El camino

De hecho, cada vez está más claro que la dificultad no está en determinar el modelo que una organización necesita, sino en facilitar, desde la realidad actual, un camino adecuado a ese modelo.

En esta línea SAFe es un excelente modelo de transición y no un fin en sí mismo. Una corporación puede “agilizarse” inicialmente con SAFe y avanzar hacia su propio modelo con paso firme, desnormalizando las estructuras en paralelo a la ejecución de los cambios en los sistemas para permitir, por ejemplo, el modelo Spotify o, lo que sería mejor, su propio modelo eligiendo lo mejor de cada casa.

Lo mismo pasa con los modelos derivados de la realidad startup en devops. En el caso de las entidades financieras, la realidad es un tanto distinta: hay oficinas, sucursales, empleados, etc. Todos estos elementos deben estar alineados para que pasemos del paradigma ágil de la entrega de valor continua a la realización de valor continua. Aquí, lo difícil no es poner en producción cambios continuamente, sino que las personas puedan utilizarlos al mismo ritmo.

En este caso, estructuras derivadas directamente de SAFe, como por ejemplo el comité de versiones, permiten alinear a todos los grupos de gestión del cambio para garantizar que la organización pueda realizar el valor entregado por el programa ágil inmediatamente después de su puesta en producción. Es decir que las oficinas y sucursales estén preparadas y formadas para los cambios que se han introducido en los sistemas que soportan sus servicios, con anterioridad al momento en el que esos cambios estén disponibles en producción.

En cualquier caso, a la hora de implementar SAFe hay formas y formas. Personalmente, abogo por deshacer las jerarquías en las fases iniciales para convertirlas en comunidades con completa transparencia. Esto afecta directamente al gobierno de la funcionalidad de un programa, donde pasaremos pronto de una jerarquía program manager y los product owner a una comunidad de gobierno funcional, en el que el program manager se convierte en su facilitador y primer contacto con el nivel de portfolio.

La apertura interna del código, como modelo para la colaboración ágil entre programas, es otro paso más de desnormalización de estructura y creación de comunidades internas que, además, ayuda a reducir tiempos de espera innecesarios.

Por otro lado, abrir un programa a un grupo importante de personas, sin pararse a reflexionar si lo que hacen es óptimo, no parece la mejor manera de comenzar. Durante el lanzamiento de un programa ágil hay que realizar talleres de mejora lean y que las personas, que son al final las que entregan el valor, acuerden entre ellas aquellas mejoras sobre el proceso que quieren aplicar. No creo que mejoremos la vida de las personas si les pedimos que repitan lo que hacían antes, pero ahora con la presión de entregas en sprint. Facilitemos un entorno de reflexión constructiva para que se produzca un dialogo inicial que sirva de base para la mejora continua en los programas. Estos talleres lean iniciales son un eje fundamental del cambio cultural necesario en una empresa ágil.

Una vez los programas ágiles estén en marcha, se trata de ir desnormalizando el modelo desde el feedback

Gobierno y compromiso

En cualquier caso, para que exista el compromiso necesario, es necesario ofrecer proyectos a largo plazo a las personas que colaboran para hacer software. De nada sirve comenzar una transición ágil si las personas que van a construir el software no ven continuidad a su trabajo. Su nivel de compromiso no va a ir más allá del que la empresa tenga con ellos.

En esta línea es necesario un cambio en el modelo de gobierno actual, de tal forma que se financien los equipos de manera estable en función de las necesidades a medio y largo plazo de los sistemas que evolucionan. El objetivo es que vayan teniendo trabajo de forma continua, en contraposición a la constante creación y destrucción de equipos al terminar y comenzar proyectos. En muchas ocasiones no se tienen en cuenta los esfuerzos necesarios para montar un equipo, y se descarta innecesariamente toda la inversión realizada tan solo porque el proyecto ha terminado. La tónica habitual es invertir de nuevo en el proceso de creación  y captación ¿Por qué? Si hace unos días tenías uno fantástico y que funcionaba a las mil maravillas.

Esta tendencia no solo va a afectar a las empresas clientes. Realmente va a suponer todo un reto ver como colaboran a equipos de distintos proveedores al unísono en un programa ágil. Eso sí, para llegar a esta fase del proceso de transformación será necesario modificar los contratos que actualmente regulan las relaciones entre empresas de servicios y clientes. 

Y el cambio puede ser tal que estas empresas de servicios vean cada equipo de alto rendimiento como algo a conservar y ofrecer a sus clientes. Lógicamente, tampoco tendrá sentido, económicamente hablando, deshacer un equipo cuando se ha convertido en una unidad que puede ofrecerse como tal a otro cliente. Esto transformará las políticas de recursos humanos a ambos lados del contrato.

Creo que vivimos un momento un tanto especial. Puede que sea la primera revolución tecnológica que no venga de la mano de un producto o tecnología, sino del modo en el que hemos decidido tratarnos y organizarnos. Puede parecer un tanto naif, pero viene derivado de la decisión, tomada de forma consciente, de respetarnos y tratarnos como personas, del alineamiento que solo puede producir la transparencia. Al final, de respetar a las personas, porque ellas son las que hacen y usan el software.