Cómo los equipos de desarrollo ágiles pueden generar valor: Introducción a la gestión

El desarrollo ágil  es un desafío de administrar y medir, especialmente cuando se compara con modelos de desarrollo tradicionales como  Waterfall .

La gerencia  a menudo no está segura de cuándo se entregará la funcionalidad y a qué costo, si brinda la calidad requerida y con qué riesgos inherentes. Debido a su naturaleza inherente de usar  Story Points  para evaluar el progreso, el valor de Agile es difícil de cuantificar.

Si algo es difícil de medir, es difícil de evaluar, administrar y garantizar la entrega de valor. A través de un ejemplo, este blog se propone mostrar que es posible contrarrestar estos desafíos y restablecer el equilibrio entre la relación de los equipos Agile y la administración.

Imagina este escenario común. Una importante aplicación orientada al cliente que ayudará a transformar digitalmente a la empresa lleva un año de desarrollo y la entrega de producción se adelanta cada trimestre. Los sprints están masticando el backlog, pero el backlog sigue llenándose con refactorización, errores y requisitos recién descubiertos. La rotación en el equipo crea desafíos en la productividad y la calidad, y la incorporación de nuevos miembros del equipo lleva demasiado tiempo, lo que afecta la productividad general.

La gerencia sigue recibiendo actualizaciones de la planificación del progreso que muestran una máquina de desarrollo ágil y fluida con sprints e historias a ritmo de entrega, pero luego el presupuesto sigue aumentando y la fecha de entrega se desplaza hacia la derecha. La gerencia está luchando por conciliar los informes con el costo real, la productividad, la calidad y el progreso de la fecha límite. Reemplazaron al gerente del proyecto una vez, pero están frustrados por los mensajes contradictorios y desconfían de la calidad y el progreso oportuno.

El equipo de desarrollo está confundido y los miembros del equipo abandonan el proyecto (y la empresa) debido a la presión de la gerencia para corregir un proyecto, donde el equipo siente que se está moviendo a través del proceso Agile de manera efectiva. Sienten que la “gerencia” no entiende cómo funciona Agile y su propuesta de valor; Viniendo de la gestión de proyectos de Waterfall, creen que la gestión simplemente no se vuelve ágil.

El equipo de desarrollo también siente que se ve obstaculizado por la rotación de personal, lo que resulta en pérdida de productividad y memoria institucional, y disminución de la calidad. Si la gerencia se relajara y los dejara trabajar, el proyecto se entregará de manera efectiva.

Detrás del interés de la gerencia en ver el producto hecho y entregado es que lo ven como clave para su transformación digital y una necesidad competitiva y defensiva frente a sus pares del mercado. Si Agile es mucho mejor que Waterfall, ¿por qué los costos, la duración y la calidad se salen de los pronósticos originales? Al menos con Waterfall, sabía cuáles eran los hitos y podía priorizar los resultados. Con Agile, se trata de backlog y Story Points.

La gerencia finalmente perdió la fe en el proceso de desarrollo para entregar la aplicación en el marco de tiempo competitivo necesario con un producto viable mínimo y una apariencia de control de costos. Sienten que han perdido el control sobre un proyecto que se les ha ido de las manos sin un final a la vista. Ambos grupos necesitan un proceso medible concreto que permita a todas las partes evaluar de manera objetiva y consistente el desempeño del equipo, la salud y la calidad del producto. Necesitan una forma confiable de visualizar el progreso (productividad, costo, velocidad de entrega, calidad, seguridad, mantenibilidad).

La empresa se suscribió previamente a la investigación de IDC y se enteró de la  solución Metri  Agile Value Management (AVM) de IDC que evalúa, compara y corrige el rumbo de los equipos de desarrollo Agile. AVM es una solución sistemática, cuantitativa, integral, basada en datos y repetible, basada en los estándares ISO, y ha demostrado un valor cuantificable para los clientes.

Trabajando con el equipo de soluciones IDC Metri AVM, comenzaron el proceso metódico de desglosar el proceso de desarrollo del producto y el producto.

A lo largo de múltiples sprints, se implementaron medidas de creación de valor. Se utilizó un análisis mejorado de puntos de función, basado en las normas ISO, para evaluar el progreso y la eficiencia en lugar de Story Points. Se realizó un análisis del código fuente para evaluar la calidad y la seguridad del código, para reducir la refactorización y la cantidad de CVE. Este análisis no solo identificó las brechas, sino que proporcionó recomendaciones tácticas específicas sobre cómo abordarlas. Además, se comparó el desempeño del equipo para comprender qué tan competitivo era su equipo en comparación con sus pares del mercado.

Después de seis semanas de trabajo, la gerencia y el equipo recibieron paneles y análisis que identificaron claramente las brechas y las soluciones.

Los tableros de ingeniería identificaron claramente código deficiente y CVE que permitieron al equipo de desarrollo abordar mejor y más rápidamente los problemas de calidad. A medida que adoptaron la guía del panel de ingeniería, el equipo de desarrollo descubrió que sus prácticas estaban mejorando. La calidad y el rendimiento mejoraron debido a los menores esfuerzos de prueba atribuidos a prácticas de codificación mejoradas. Además, mejorar las prácticas e identificar mejores prácticas redujo el estrés del equipo y permitió que los miembros del equipo recién incorporados se volvieran productivos más rápidamente.

La evaluación comparativa de las prácticas del equipo con las de sus pares permite a la gerencia identificar áreas para invertir y realizar mejoras en el equipo. El tablero de administración proporcionó a los gerentes una forma de verificar el pulso de los factores clave del proyecto y notar rápidamente y corregir las tendencias negativas de desempeño. Además, con base en la evaluación de pronóstico proporcionada, la gerencia se dio cuenta de que un problema era que el equipo de desarrollo no contaba con los recursos suficientes para cumplir con los hitos de entrega comercial requeridos, incluso si se desempeñaba para sus pares. Por lo tanto, la gerencia tomó la decisión de aumentar el equipo con personal externo para garantizar que se pudieran cumplir los hitos.

Tanto el equipo de desarrollo como la gerencia necesitaban lo mismo: una definición común y acordada de «realidad». Comenzaron con dos marcos de referencia diferentes. Para el equipo de desarrollo, su marco era la acumulación, los sprints, la velocidad y los Story Points. Para la gerencia, era el costo, el tiempo, la calidad y los hitos. Los dos grupos hablaban idiomas diferentes y no podían reconciliarse. Al incorporar AVM, la gerencia y el equipo de desarrollo ahora tenían un marco de referencia con el que todos podían estar de acuerdo y un análisis completo que reunía las necesidades técnicas y comerciales. El equipo tenía un idioma desde el cual podían entender mutuamente la salud del desarrollo y cómo abordar las brechas y brindar valor ágil.