Las metodologías ágiles han llegado con el objetivo de acelerar de una manera flexible los proyectos, mejorando su calidad e incrementando la productividad gracias a una asignación de recursos óptima. Una de las claves de este enfoque es la formación de estructuras organizativas empoderadas para tomar decisiones, llamadas generalmente “tribus”, que se interrelacionan y colaboran a la hora de entregar valor al cliente.

Sin embargo y a pesar de que el ideal es que cada tribu sea lo más autónoma posible, lo cierto es que, por una mera cuestión de economías de escala, aparecen dependencias entre ellas, especialmente en organizaciones tan complejas y tremendamente reguladas como los bancos o el sector asegurador.

Saber gestionar estas dependencias resulta esencial para que las metodologías ágiles cumplan con el cometido para el que fueron concebidas; sin embargo, en buena parte de las ocasiones no se consigue y, de hecho, resulta complicado encontrar información documentada sobre la gestión de dependencias. En algunos marcos de escalado ágil, como SAFe o Nexus, se habla vagamente de los systems teams o los shared services.

De ser un guardián de la producción, el CIO y su área deben convertirse en habilitadores de los cambios

Por lo general, estas dependencias son de dos tipos. Por un lado, las puntuales: aquellas que se dan de manera esporádica entre tribus y que pueden consistir, por ejemplo, en la necesidad de una API determinada o de un servicio. Una vez resuelta esta necesidad, la dependencia desaparece. Por otro lado, y es aquí donde reside la mayor complejidad, encontramos las dependencias estructurales, o sea, las recurrentes que se concretan en la prestación de servicios de unas tribus a otras. Estas últimas, por una cuestión de economías de escala, son difícilmente eliminables.

Dependencias estructurales

Uno de los primeros pasos que damos cuando aterrizamos en una organización es crear una oficina de transformación (transformation management office) desde la que poder trazar planes de acción transversales a toda la organización. Para ello, lo primero es contar con unas métricas que indiquen qué grado de dependencias se está dando en la empresa.

Una de las medidas sería establecer múltiples flujos de pase a producción en función de la madurez de cada equipo

Con este objetivo hemos desarrollado un modelo, a partir del cual cada una de las tribus analiza sus dependencias en función de un cálculo de su nivel de exposición a ellas. En este análisis entran en juego múltiples factores, desde la probabilidad de que se dé esa dependencia, el impacto en la entrega de valor, su frecuencia o incluso el nivel de servicio que se está recibiendo de la otra tribu.

El resultado de todo este proceso analítico es un mapa de calor con el que somos capaces de identificar el nivel de exposición de una tribu a todas las demás. Con él podemos escalar los resultados de forma ordenada al comité de dirección para tomar medidas como la creación de grupos de trabajo específicos.

Procesos complejos y regulados

El despliegue a producción es un proceso que, en el caso de una entidad financiera, incorpora una complejidad añadida al sumar el riguroso marco regulatorio al que está sometida. La puesta en marcha de un nuevo servicio en la entidad toma mucho tiempo e implica atravesar numerosas fases. El visto bueno es responsabilidad de distintas tribus, comenzando por la validación de la arquitectura que tendrá el futuro servicio o aplicación que se vaya a poner en marcha.

Paralelamente, si no se desarrolla con tecnología de virtualización, la infraestructura puede suponer otro hándicap, pues es preciso adquirir una máquina o servidor, configurarlo, etc. Además, para poder desarrollar una aplicación o servicio ha de realizarse con un entorno y unos datos lo más parecidos posible a los que se encontrará cuando esté en producción. Esto es algo que, en el caso de un banco o una compañía del sector sanitario, no resulta sencillo dado que manejan información de carácter personal muy sensible. Una vez desarrollado el servicio, este ha de pasar por el equipo de testing.

Una vez culminado este proceso, aún habrán de transcurrir varias semanas antes de que el software vea la luz y pueda ser utilizado por el cliente, puesto que pasará a preproducción, donde volverá a ser sometido a testing. Asimismo, una vez superado, y contando ya con la validación final, aún necesitará la aprobación definitiva del comité de cambios, lo que puede ocupar varias semanas más.

Una de las medidas que el área del CIO podría adoptar sería establecer múltiples flujos de pase a producción

En este contexto de procesos tan complejos y regulados, al riesgo de la dilación en el tiempo se suma el de la creación de silos, y la posible pérdida de valor y métricas por el camino. Hasta la fecha, el CIO y su área han venido actuando como guardianes de la producción, y en esto se debe dar un giro copernicano para que se conviertan en habilitadores de los cambios.

 El CIO como habilitador de cambios

Al final, lo que encontramos en las grandes organizaciones es que, en un mismo equipo, pueden conjugarse tecnologías legacy, cuyo despliegue no se puede automatizar, con nuevas tecnologías y modelos como PaaS, cloud, etc. Se da una convivencia de sistemas tradicionales —de difícil evolución— con API, microservicios…, y todo ello con diversas tribus que presentan distintos niveles de madurez. Esto termina disminuyendo el potencial que podría tener un pipeline automático de despliegue que sobre el papel parecía perfecto, pero que nadie termina usando de forma eficiente.

El hecho de que únicamente exista una ruta o proceso de aprobación de la puesta en producción de un servicio, como el arriba indicado, resulta ineficaz. No parece tener demasiado sentido que, por ejemplo, para incorporar una nueva etiqueta a la página web sea necesario pasar por tantos filtros y tribus. Por ello, una de las medidas que el área del CIO podría adoptar sería establecer múltiples flujos de pase a producción en función de la madurez de cada equipo, encaminándonos hacia una filosofía de cambios preaprobados.

El equipo del CIO ha de abrir las puertas y generar una cultura de confianza y responsabilidad compartida

El mantra que impera en este cambio profundo de modelo es saltar de ITSM (ITIL v3) a Agile Service Management, trabajando para ello con marcos como ITIL V4. Para ello, el equipo del CIO ha de abrir las puertas y generar una cultura de confianza y responsabilidad compartida entre las tribus de negocio y las transversales. Esto es algo que se verá amplificado con un aumento del nivel de autoservicio de cada tribu, con autonomía para, por ejemplo, crear infraestructura como código o frameworks de automatización de pruebas. En esta misma línea, la apertura de mente ha de ser total y virar hacia una priorización por valor. Preguntas como “¿hasta qué punto aporta más valor al cliente pasar a producción la corrección de una incidencia determinada?” tienen que comenzar a formularse en las tribus.

Por último, pero no menos importante, entran en juego aquí otras metodologías de simplificación —como Lean— que tienen ante sí el reto, en un marco tan regulado como el financiero, de tratar de eliminar la burocracia e, incluso, de automatizar el cumplimiento regulatorio. Esto es algo que, aunque requiere mucho esfuerzo, es posible conseguir.