En 2015, la división de Software e Informática de Agilent tenía problemas. El equipo estaba ultimando un nuevo producto importante, pero no iba a estar listo para la fecha de publicación. No era la primera vez: la división solo había conseguido publicar a tiempo alrededor del 20 por ciento de las veces.
Las fechas de publicación incumplidas crearon una enorme presión sobre los equipos de software. “Cuando los equipos están bajo presión, toman malas decisiones”, afirma John Sadler, vicepresidente y responsable general de la división de Software e Informática de Agilent. “Sacrifican la calidad y terminan pagando por ella en el backend. En general, el equipo estaba bastante desmoralizado y tenía dificultades para entregar cualquier cosa a tiempo”.
Parte del desafío estaba en que la división de Software e Informática de Agilent contaba con 150 empleados en dos continentes que colaboraban con contratistas que estaban en un tercer continente. Era una división muy distribuida de profesionales de ingeniería, marketing, control de calidad, soporte técnico y ventas. La empresa necesitaba establecer nuevas prácticas de equipo para ayudar a ofrecer valor más rápido, con mayor calidad y previsibilidad, y responder mejor a los cambios. En resumen, necesitaban una transformación ágil.
Rumbo a una transformación ágil
En 2015, Agilent diseñó una transformación ágil con los siguientes objetivos:
- Centrarse en la previsibilidad
- Desarrollar un ritmo de publicación fiable
- Crear un ciclo de entrega reproducible
- Impulsar la mejora continua
El enfoque ágil pone la calidad en primer lugar, el ritmo reproducible en segundo lugar y el alcance en tercer lugar. “Cuando los equipos no siguen estas prioridades, a menudo dan preferencia al alcance, el cronograma se impone en forma de plazo y la calidad se ve perjudicada”, afirma Sadler.
Agilent quería establecer procesos ágiles que incorporaran las prioridades a su desarrollo de software. Establecer la mejora continua como valor fundamental dio lugar a un cambio cultural que creó el caldo de cultivo para la transformación. Poner la calidad en primer lugar significaba mejorar la satisfacción de los clientes externos e internos. En Agilent estaban dispuestos a sacrificar el alcance para cumplir con las expectativas de los clientes en el campo.
La segunda prioridad era que la división creara un ciclo de publicación previsible que pudiera perfeccionarse con el tiempo. Con un ciclo de desarrollo más corto y fiable, el equipo evitaría problemas y mitigaría los riesgos de forma precoz para ofrecer un tiempo de respuesta adecuado.
Transformación ágil paso a paso
Desde agosto de 2015, Agilent se asoció con cPrime, una consultoría con experiencia en ayudar a organizaciones a llevar a cabo transformaciones ágiles, y más tarde con TCGen, una consultoría de desarrollo de productos líder del sector.
La implementación de la herramienta de gestión ágil de productos Jira fue el primer paso. Jira ahora proporciona un sistema de registro para todo el trabajo de desarrollo que realizan los equipos globales distribuidos de Agilent. Funciona como una única fuente de información que aporta transparencia sobre las funciones programadas, los plazos de publicación y qué lograron los equipos.
Adaptado con permiso de cPrime, Inc.
La formación en metodología ágil fue la siguiente prioridad, con el objetivo de instruir sobre principios y conceptos ágiles y establecer una terminología compartida. En su modelo de recetas para la gobernanza ágil en la empresa (RAGE, por sus siglas en inglés), cPrime describió las ceremonias clave, como las reuniones de planificación de publicaciones, las reuniones de scrum de scrums en equipo, las reuniones de scrum de scrums para propietarios del producto, las reuniones de limpieza del backlog de publicación, la revisión de la publicación y las reuniones de revisión de retrospectiva de la publicación.
Agilent también estableció roles de propietarios del producto para cada área y roles de responsables de programa, y midió el progreso con gráficos de trabajo completado. Además, adoptó técnicas ligeras de toma de decisiones, llevó a cabo ceremonias, utilizó artefactos de scrum ágil y adoptó otras prácticas ágiles.
La metodología ágil en acción
En noviembre de 2015, la división de Software e Informática de Agilent celebró Sprint Zero, una sesión de planificación ágil de dos semanas con catorce equipos capacitados. En ella, se desarrolló un plan de publicación de producto que abarcaba ocho meses para el sistema de datos de cromatografía OpenLab.
Las actividades de Sprint Zero se dividían en tres categorías:
- Informar a los equipos sobre los objetivos comerciales y técnicos, los impulsores y los requisitos de alto nivel para OpenLab a través de presentaciones y pósteres.
- Utilizar las técnicas recién aprendidas para desarrollar requisitos y hacer estimaciones sobre historias, epics y defectos.
- Añadir las historias, epics y defectos al tablero de planificación de publicaciones y marcar todas las dependencias entre equipos.
Agilent pronto descubrió que sus mejoras ágiles se extendían más allá del proyecto piloto. Uno de los primeros indicadores del éxito fue interno. “Como teníamos que colaborar con otras divisiones de Agilent, era fundamental cumplir con lo que habíamos prometido hacer”, afirma Sadler.
Agilent también apreció mejoras externas. Los comentarios de los clientes fueron fundamentales para que los equipos de Agilent respondieran mejor a los cambios del mercado. Al incluir a los clientes en las primeras etapas del proceso de desarrollo, Agilent consiguió aumentar la calidad del software y, al mismo tiempo, reducir los riesgos de integración.
Una de las ideas de Agilent consistía en incluir historias de actualización en cada epic ágil para considerarlo como completado. Babita Jain, directora de calidad de software, y Stefan Weiss, responsable de integración de software de Agilent, dirigieron la implementación de la transformación y ayudaron a los equipos a comprender el alcance total del proyecto. “No consideramos que el epic está terminado a menos que incluya las mejoras”, afirma Jain.
La transformación ágil no solo mejoró la calidad, sino también la fiabilidad. En 2016, el sistema de datos de cromatografía OpenLab se entregó a tiempo. Desde la transformación ágil, Agilent ha entregado software a un ritmo constante y los defectos notificados en el campo han disminuido.
Medir el éxito
Agilent define y mide el éxito de su iniciativa ágil como “bajas tasas de fallos de campo y alta fidelidad de los clientes”, afirma Sadler. La retención de clientes también es fundamental. En el mercado desarrollado y competitivo del sector de las ciencias de la vida, el abandono de los clientes es un peligro. La capacidad de vender un sistema nuevo a clientes antiguos es esencial.
Estas son cuatro métricas cruciales habilitadas por el modelo de capacidad basado en Jira de Agilent:
Gráficos de trabajo pendiente y trabajo completado
Antes, Agilent medía el trabajo en horas de ingeniería, días de trabajo por persona o puntos de historia. Ahora todo el mundo usa gráficos de trabajo completado para hacer un seguimiento del trabajo realizado y de la cantidad total de trabajo. Los gráficos de trabajo pendiente muestran cuánto trabajo queda por hacer.
Porcentaje de capacidad entregada al mercado (carga útil)
La capacidad de modelar y hacer un seguimiento de la capacidad desempeña un papel esencial en la forma en que Agilent mide el éxito. Jira permitió a Agilent crear un modelo de capacidad detallado. “Durante la fase de planificación, este modelo nos permitió informar al departamento de marketing de cuántos puntos de historia tenían que asumir para un lanzamiento. El departamento de marketing clasifica el backlog para ajustarse a esa capacidad”, afirma Sadler.
Tiempo total y medio dedicado a aplicar correcciones
El modelo de capacidad proporcionó una visión más detallada que permitió a Agilent ver la capacidad dedicada a corregir defectos críticos o graves notificados en el campo frente a los defectos que descubrió y notificó el equipo de calidad.
Porcentaje de tiempo dedicado a corregir defectos descubiertos mediante pruebas manuales
El modelo de capacidad ayuda a Agilent a medir el tiempo dedicado a crear funciones que los clientes valoran en comparación con el tiempo dedicado a mantener los productos existentes.
En poco más de tres años, la división duplicó con creces el porcentaje de capacidad enfocada en el trabajo de valor agregado, incrementándolo del 30 % al 65 %. A medida que mejoraba la calidad del software gracias al nuevo enfoque ágil, también había menos defectos que corregir más adelante.
Un año después de iniciar su proceso de transformación ágil, los miembros del equipo de Agilent nos describen varios “antes” y “después”:
 | Antes: el rendimiento se medía en horas de ingeniería, días de trabajo por persona o puntos de historia. |
|---|---|
 | Antes: los equipos con diferentes niveles de formación en metodología ágil definían de forma distinta los epics, las historias y las subtareas. |
 | Antes: los expertos en scrum escribían código, dirigían reuniones en equipo y evaluaban las prioridades en cuanto a funciones. |
 | Antes: podían aprobarse funciones con errores, que llevaban consigo defectos a las fases de desarrollo posteriores. |
 | Antes: a menudo había problemas de última hora, lo que provocaba pánico y retrasos considerables. |
 | Antes: No había ningún mecanismo para medir la capacidad de un equipo para trabajar. |
El futuro ágil de Agilent
Como pasa con cualquier cultura de empresa que valora la mejora continua, Agilent no da por concluida su transformación ágil. Los siguientes pasos previstos incluyen seguir acortando la duración del ciclo y perfeccionar la capacidad de obtener información útil lo antes posible a partir del feedback del mercado, algunos elementos clave de las métricas de DevOps.
Agilent ya ha reducido drásticamente la duración del ciclo, dividiendo las publicaciones anuales en dos ciclos de seis meses, a pesar de que la empresa comercializa los lanzamientos anualmente. La empresa planea volver a reducir la duración del ciclo a la mitad, pasando a un ritmo trimestral.
Lograr que los clientes se involucren pronto y con frecuencia en el proceso de desarrollo también forma parte de la mejora continua. Según nos dice Sadler, su grupo opina que hay menos necesidad de arbitraje debido a conflictos de intereses durante las discusiones sobre el alcance del producto cuando está claro el feedback del mercado. Mantener la calidad y la facilidad de uso para los clientes sobre el terreno es una prioridad constante, y el contacto continuo con los usuarios ayuda a mantener las prioridades de la empresa: primero la calidad, y luego el ritmo de publicación y el alcance.
Lecciones aprendidas
Sadler atribuye el éxito a su equipo, incluidos los líderes Jain y Weiss, quienes adoptaron el desarrollo ágil como una forma de impulsar una mejora rápida y continua. Con las herramientas adecuadas, como Jira y Confluence, el equipo pudo consolidar el trabajo en un solo lugar y medir el progreso.
Agilent descubrió que una transformación ágil requiere un patrocinador que supervise la investigación y el desarrollo, el marketing de atracción y la calidad. “Si no puedes transformar esas tres cosas, no tendrás éxito”, afirma Sadler. “No se puede lograr una transformación ágil solo a través de la I+D”. Lo más importante no es el trabajo que se realiza dentro de las funciones, sino la forma en que trabajan juntas.
Agilent también se dio cuenta de que es fundamental no presuponer que se tiene una visión perfecta de las necesidades de los clientes. Un enfoque ágil implica publicar productos siguiendo un ritmo coherente y luego recibir directamente el feedback de los clientes. Para ello, es necesario que las fechas de publicación sean sagradas y, cuando suene la campana, el equipo lance el producto tal como está.
Finalmente, Sadler nos dice que el marco de metodología ágil aporta visibilidad sobre los problemas. Por ejemplo, la metodología ágil expone las brechas de capacidad. Revela las partes del proceso que no tienen valor añadido y que causan demoras, así como las deficiencias de calidad. Pasar de un enfoque en cascada a uno ágil no solo requiere cambios en la forma de trabajar de los equipos, sino que también implica un cambio cultural. La metodología ágil impulsa una cultura de mejora continua que es francamente contagiosa.
