Transformando la TI de una agencia gubernamental en ágil

El gobierno está compuesto por programas independientes que, debido a su organización, inhiben cadenas de valor eficientes. Según mi experiencia, los contratistas del gobierno proporcionan servicios de TI inconsistentes. Esto se debe a esfuerzos duplicados, planes y resultados inciertos y una cultura que favorece la adhesión al proceso en detrimento de los resultados (y no de una buena manera). Décadas de numerosas iniciativas en las agencias del gobierno han dado origen a extensos portafolios de aplicaciones desatendidos. Para simplemente mantener el negocio en funcionamiento y realizar la inversión tecnológica obligatoria, se consume mucho dinero y tiempo.

Las agencias enfrentan este año un nuevo recorte presupuestario inminente y luchan por equilibrar dos prioridades contrapuestas: a) atender la meta de demanda urgente con capital limitado (debido al alto porcentaje del presupuesto consumido por el área de operaciones y mantenimiento) y b) alcanzar y superar las expectativas de soporte al cliente. Muchas agencias buscan eliminar las ineficiencias en TI enfocándose en la efectividad operativa. Según mi experiencia, la mejor forma de hacerlo es mediante la práctica lean. Afortunadamente, he observado un cambio en los últimos años, en los que la aceptación del statu quo ha dado paso a una apertura al pensamiento lean y al espíritu de experimentación. En todas las funciones – en las áreas de compras, gestión de programas, infraestructura y ciberseguridad –, las personas están creando entornos de aprendizaje, experimentando y retribuyendo.

Aprendiendo de un experimento lean

Cuando he visto a agencias federales y organizaciones externas formar buenas alianzas, el foco estaba en ayudar al negocio a priorizar el trabajo diario de acuerdo con las necesidades, elevar el perfil de seguridad del portafolio, mejorar la satisfacción del cliente y – lo más importante – liberar capital que pueda aplicarse a una nueva iniciativa (por ejemplo, análisis de datos, TI móvil y almacenamiento en la nube) eliminando otras ineficiencias de la agencia y del portafolio de aplicaciones.

Recuerdo haber trabajado con una agencia civil que se había preparado para más recortes presupuestarios. El equipo de liderazgo consolidó de forma proactiva los servicios de soporte de TI para abordar dos preocupaciones: costo y satisfacción del cliente. El equipo de alta dirección seleccionó a mi equipo para ayudarlos a repensar la producción de software. Comenzaron consolidando la función de operaciones y mantenimiento (O&M) y apoyando el desarrollo de todo el portafolio, transformando la producción de software en una única cadena de valor en lugar de un ejercicio de navegación entre silos funcionales. Aunque la motivación de la agencia era la reducción de costos, aquí había una oportunidad para cambiar fundamentalmente la naturaleza del modelo obsoleto de comando y control y adoptar uno alineado con los principios del manifiesto ágil y centrado en el cliente. Juntos, también nos enfocamos en las personas – enfatizando comportamientos de responsabilidad y mejora continua en el personal.

Mi equipo y yo trabajamos con esta agencia para mejorar la capacidad de los miembros del equipo mediante una combinación de principios y prácticas lean/ágiles, visualizando el trabajo y enfocándonos más en los resultados que en la adhesión a los antiguos procesos. Estos principios se convirtieron en lo que ahora llamamos Agile O&M®. Estas son las cuatro áreas principales de Agile O&M® (y se refuerzan entre sí):

1) Use kanban

Cuando aplicamos los principios del kanban a un trabajo basado en flujo, como las operaciones y el mantenimiento de TI, los interesados perciben una mejora significativa en el rendimiento y una reducción de la latencia, lo que reduce en consecuencia el costo total. El kanban dio a esta agencia una visibilidad completa del trabajo real que se está realizando, y las personas pudieron priorizar el trabajo atrasado sobre una base just-in-time o de acuerdo con sus necesidades organizacionales. Los límites del trabajo en curso hacen que el equipo de soporte se enfoque en las mejoras y permiten perseguir los objetivos de “cero defectos”. El kanban también permitió a la agencia atender la demanda del negocio, distribuir el conocimiento sobre el sistema por todo el equipo (evitando que una sola persona sea un punto de falla), maximizar las capacidades del personal y obtener una nueva perspectiva para apoyar la mejora continua mediante el intercambio de ideas, mejores prácticas y lecciones aprendidas.

La tarea principal del gobierno no es dominar el área de TI, pero el flujo irrestricto depende de su compromiso constante. En esta agencia, el cambio cultural de una mentalidad de comando y control a una en la que las decisiones las toman quienes hacen el trabajo fue el mayor desafío. Quienes son dueños de los productos de TI deben percibir las modificaciones continuas y el soporte de datos – estas cosas constituyen el trabajo de “polea” del software presente en su negocio.

2) Adhiera a los principios del manifiesto ágil para el desarrollo de nuevos productos

Las grandes mejoras y los desarrollos “desde cero” implican una revelación progresiva de los requisitos. Los sistemas del gobierno (productos) son, muchas veces, regulatorios por naturaleza, respaldados por las políticas públicas. Implican el cumplimiento de las reglas de negocio, la recolección de datos, el procesamiento de tasas industriales y los informes de cumplimiento. Para esta agencia, impartimos un entrenamiento sobre el manifiesto ágil destinado a quienes ejecutan el trabajo y a sus equipos de desarrollo. Y el modelo ágil que evolucionó después de muchas retrospectivas fue una mejora pragmática de la estructura tradicional de scrum. Adopta las actividades de desarrollo del scrum y expande la estructura a cinco etapas progresivas y superpuestas (para proporcionar un contexto de gestión de actividades periféricas que son críticas para la implantación exitosa de un software).

Las cinco etapas son:

• Alineación – Esta etapa garantiza que los interesados y el equipo de scrum compartan la comprensión del objetivo final del software. El equipo se enfoca en el valor del negocio en lugar de en las funcionalidades, y las decisiones técnicas del software se alinean con los objetivos del negocio.

• Crecimiento – Esta etapa se enfoca en el equipo y en las herramientas, habilidades y procesos de scrum para obtener un buen resultado del software. Cada miembro entiende su rol en el equipo y es capaz de contribuir positivamente al éxito del software. Los equipos son autoorganizados y reciben entrenamiento de un especialista en scrum.

• Iteración – Esta etapa garantiza que el equipo de scrum y los interesados sigan la estructura scrum de forma adecuada, produciendo las funcionalidades de mayor prioridad y los artefactos necesarios del scrum para maximizar los beneficios del manifiesto ágil. La persona que realiza el trabajo, el especialista en scrum y el equipo se reúnen con frecuencia, pero brevemente, para corregir continuamente el rumbo a fin de producir primero el mayor valor.

• Lanzamiento – Esta etapa se enfoca en un lanzamiento exitoso y previsible, así como en una adopción exitosa del software por parte de sus usuarios finales. Todos los interesados participan desde el origen hasta el lanzamiento del producto.

• Expansión – Esta etapa enfatiza las principales etapas del software que están por venir. Se enfoca en las actividades de operaciones y mantenimiento y en las próximas iteraciones de lanzamiento. Con un contratista de soporte de TI, la transición del desarrollo a O&M es perfecta, y la persona que realiza el trabajo pasa a ser dueña del sistema.

3) Haga visible el trabajo

Durante años, el pensamiento convencional hizo que esta agencia trabajara con una oficina de proyectos (PMO) cada vez más grande, que recopilaba datos de varios proveedores. Esa oficina destilaba la información útil, formateaba los datos en una estructura de informes y luego hacía presentaciones para una gran audiencia. Este enfoque de compartir el trabajo estaba desconectado de los hechos, consumía mucho tiempo, era costoso y no era muy relevante para la toma de decisiones en las diferentes unidades de negocio.

Uno de los requisitos para asumir el rol de contratista de soporte de TI era mostrar avances en la toma de control del portafolio, sistema por sistema. Nuestra organización adoptó un principio que llegó a conocerse como Lean PMO®: informes de los productos de trabajo del proyecto generados por drives en lugar de manualmente. Colaboramos con los representantes técnicos de contratación de la agencia (COTR) en el desarrollo de un panel de control ligero que generaba informes directamente de los artefactos de gestión del proyecto: cronograma del proyecto, riesgos, eventos destacados, actividades y presupuesto. Después, fue solo cuestión de mejorar la gestión general del proyecto y la resolución de problemas mediante coaching y mentoría.

4) Cree estructuras para apoyar a los equipos altamente colaborativos

Usar la tecnología de forma efectiva depende de usar la herramienta adecuada para la situación (el kanban para el trabajo basado en flujo y el ágil para el desarrollo), de visualizar los datos y de una comunicación frecuente. Esta agencia eligió comprar un conjunto de herramientas que ayudara a visualizar su trabajo. Ahora tiene un punto de referencia común sobre el cual se dan conversaciones significativas. Tienen transparencia sobre el trabajo real del proceso en lugar de artefactos fabricados. La alta dirección observa ahora un compromiso negocio/TI enfocado en individuos e interacciones sobre procesos y herramientas; trabaja con el software por encima de trabajar con una documentación exhaustiva, valora al cliente por encima de la negociación del contrato, y responde al cambio por encima de seguir un plan.

Reflexiones y resultados

Mirando lo que ocurrió, ¡este proyecto atravesó muchas dificultades y obstáculos! Descubrimos que el mayor desafío era sostener el cambio cultural. Cada cambio de liderazgo en la agencia exigía un esfuerzo de reeducación y nueva justificación. Parece haber un sesgo a favor de la estructura de comando y control que, aunque necesaria en las fuerzas armadas, no es aplicable al desarrollo de software.

Involucrar a las personas en el trabajo de mejora llevó tiempo y esfuerzo, y ambos son recursos escasos. Muchas personas compartieron con nosotros que la responsabilidad tuvo que volverse “compartida” en lugar de algo que se delegaba. Y percibimos que todavía había un sesgo a favor de las estrategias tradicionales de gestión de costos, que fueron probadas y demostraron no influir en la productividad. Por ejemplo:

Independientemente de ello, con el compromiso de la alta dirección con las nuevas formas lean de pensar, esta agencia logró alcanzar los siguientes resultados en nueve meses:

• Una transformación exitosa de cascada a ágil.
• 100% de transparencia de la TI en cuanto a costo, personal, cronograma, riesgo, elementos de trabajo y avance.Una transformación exitosa de cascada a ágil.
• 50% de aumento en la producción de nuevas funcionalidades sin aumento de costo.
• Reducción de veinte veces de los errores de producción con respecto al nivel original.
• 66% de disminución del porcentaje del presupuesto destinado a las operaciones.
• Más del 90% de satisfacción del cliente según el Net Promoter Score.

Solemos pensar en el software como el objetivo final, pero no lo es. El software es un medio que se usa para alcanzar un fin – una forma de agregar valor para el cliente.

En las organizaciones de TI, el software apoya los servicios de la agencia. Mejora continua, comunicación mediante la transparencia, reducción de costos por medio de una mayor eficiencia del personal – estos son los principales beneficios sostenibles que es posible alcanzar con la TI lean. Visto de esta forma, el desarrollo de software puede considerarse un proceso de descubrimiento continuo de lo que es necesario, de planificación antes del desarrollo, de ejecución y, luego, de verificación de los resultados para ajustarlo para el próximo ciclo.

Fuente: Lean Post.