El esfuerzo que requiere la transformación ágil es, por lo general, enorme; y esto es válido para cualquier organización sin importar su tamaño o su sector de actividad. Este tipo de proyectos están asociados siempre a una inversión importante en tiempo y dinero.
Pero, además, en el caso de las grandes organizaciones que aún disponen de sistemas host en perfecto estado de funcionamiento, el reto es aún mayor. Cuando la mancha de aceite de la agilidad alcanza a los equipos que trabajan con estas tecnologías, se dan circunstancias especiales que pueden complicar el proceso enormemente, o bien facilitarlo si se tienen en cuenta con suficiente antelación. Esto es algo que hemos podido observar en algún caso de éxito.
Al tratarse de modelos de infraestructura más antiguos y consolidados, generalmente la gestión y operación del servicio vienen determinadas por patrones de trabajo más clásicos. Además, hay que considerar también el aspecto generacional sobre los propios equipos que gestionan estos sistemas host, en lo que a evolución cultural y transformación ágil se refiere.
El ritmo de la transformación ágil
La gestión de proyectos orientados a un plan determinado pone el foco en la entrega. Este es un momento crucial, que se produce —si todo sale según lo esperado— una sola vez. Tender hacia un modelo de integración y despliegue continuos supondría un cambio de enorme calado en los procesos diarios de los equipos host, por lo que parece lógico adecuar su ritmo de transformación.
La buena noticia es que la agilidad también se puede aplicar al propio proceso de cambio (agile change), entendiendo este como su producto. Definir ciclos cortos de cambio con planificación específica, objetivos claros y mediciones del avance facilita una adopción gradual, más simple y fácil de digerir. Todo ello basado en incrementos de cambio en los procedimientos, la interiorización de los pilares de la cultura ágil (transparencia, inspección continua, adaptabilidad) y la adopción de nuevas herramientas de trabajo.
Tender hacia un modelo de integración y despliegue continuos supone un cambio de calado en los procesos diarios
Un ejemplo de cambio ágil podría ser la definición de estadios intermedios, como por ejemplo kanbanizar los proyectos orientados al plan, es decir, utilizar el método kanban para hacer aflorar lo que se está haciendo y tratar de mejorarlo. De esta forma los equipos podrían empezar a aplicar determinados conceptos de agilidad y aprender a sacar el máximo potencial de herramientas como Jira, ServiceNow o cualquier otra solución de gestión.
Aunque aún no se está hablando de sprints, de este modo empezarían a familiarizarse con términos y conceptos como historias de usuario, definition of done, jerarquía de las tarjetas, obtención de informes, etc.
Modelo de sourcing
Los equipos de desarrollo host basados en factorías suelen trabajar mediante un modelo de bolsa de horas que se van consumiendo a medida que se van estimando y contratando proyectos. Este enfoque funciona correctamente en un modelo de gestión de proyectos de tipo waterfall. De esta manera, una vez analizado el alcance del proyecto la factoría realiza una estimación de tiempos y coste de desarrollo, y se efectúa una única entrega al final.
En este sentido, como parte del cambio gradual es preciso revisar el modelo de sourcing para garantizar que los equipos permanezcan de forma sostenible en el tiempo. Además, es importante que participen activamente en las ceremonias, de manera que sea posible minimizar el impacto de la variabilidad en cuanto a cálculos de capacidad y velocidad en los equipos de desarrollo.
En definitiva, se trata de garantizar una cierta estabilidad en los equipos que permita consolidar un ciclo de aprendizaje y mejora continuos.
En cualquier caso, es necesario que seamos conscientes de que la transformación ágil requiere tiempo y es preciso contar con una planificación adecuada. El cambio hacia el modelo de agile sourcing exige una profunda revisión de procedimientos internos y una intensa negociación con proveedores y partners de manera que se establezca un nuevo modelo de provisión con mayor foco en la entrega de valor y resultados.
Métricas
En el caso de que el proceso de transformación sea más lento, si se usan estadios intermedios —como la kanbanización antes mencionada—, no necesariamente se aplicarían las mismas métricas que para equipos scrum puros.
Podríamos explicar esta situación con el símil del desvío provisional: las obras van a desdoblar la carretera en una fantástica autovía, pero de momento nos han desviado por un carril auxiliar repleto de baches, curvas, camiones de gran tonelaje y señales de limitación de velocidad. Si medimos la velocidad en estas condiciones, ¿qué resultado obtendremos? Una de dos: o se muestra lentitud, o no es fiable.
Se trata de garantizar cierta estabilidad en los equipos, consolidando un ciclo de aprendizaje y mejora continuos
De igual firma, con este resultado tendríamos dos opciones: abandonar durante un tiempo la cultura de beauty contest, en la que todos los indicadores deberían ser perfectos; o, en su defecto, diseñar métricas específicas para los equipos host teniendo en cuenta que es más que probable que no ofrezcan resultados comparables a los equipos scrum puros, que ya han empezado a circular por la autovía.
Por ejemplo, los desarrollos estándar planificados para una única entrega final, y sin despliegues intermedios, permanecerán en stand by largos períodos, ofreciendo un lead time incoherente si se comparan con desarrollos en scrum.
Impacto en las áreas de negocio
Si nos centramos en las distintas áreas de negocio de una organización, podemos observar que los usuarios —y los demás perfiles demandantes— están más acostumbrados a redactar un documento de requisitos y esperar el resultado final. Por tanto, el cambio hacia la agilidad les impacta directamente.
Cambiar la manera de confeccionar presupuestos de un modelo orientado a proyecto a un nuevo modelo más ágil, orientado a producto, es difícil en todos los casos. Además, esto resulta especialmente complicado en las áreas de negocio relacionadas con equipos host. Ello se debe a la dificultad añadida para cambiar los procedimientos tradicionales en el seno del ámbito TI, que, en principio, se espera que sea el área que tome la iniciativa de transformación.
La agilidad obliga a dedicar más recursos por parte de las áreas de negocio a lo largo del desarrollo en cada ciclo
La agilidad obliga a dedicar más recursos por parte de las áreas de negocio a lo largo del desarrollo en cada ciclo, para planificar primero y evaluar después. En el caso de que se cumpla con una adecuada involucración de los usuarios en la definición y evaluación del valor esperado, parece bastante probable que el resultado final vaya a estar mucho más cerca de la opción ideal.
En cualquier caso, el grado de involucración requerido deberá ser negociado con mucha mano izquierda y buenos argumentos. Hay que tener en cuenta que, en primera instancia, el modelo utilizado hasta ahora era suficiente y más barato. Pero es que, además, en él era más sencillo, relativamente, eludir la responsabilidad en aquellos casos en los que el resultado no fuera del todo satisfactorio.
Un aspecto esencial en la transformación agile será el de involucrar, concienciar y formar a los usuarios clave en determinadas prácticas, como, por ejemplo, realizar validaciones parciales de aquello que solicitan. El motivo es que, hasta ahora, habían estado acostumbrados a ver —al final del proceso de desarrollo— una demo de aquello que pedían. Con el cambio de modelo, a partir de cierto momento deberán ir validando incrementos de producto no necesariamente desplegables.
Hay que tener en cuenta que, en la mayoría de las ocasiones, organizar las peticiones en sprints obliga a trocear historias de usuario cuya redacción del definition of done pasa a ser esencial. Esto es algo que tampoco será posible aprender y consolidar de un día para otro.
