[02/09/2013] A pesar de que soy un fanático de Agile, inclusive yo tengo que adminitr que la agilidad tiene sus debilidades. Hasta escribí una lista sarcástica de las mejores maneras de hacer explotar un proyecto ágil. Pero la lista de verificación era un montón de síntomas a evitar, en lugar de algo que usted pueda medir específiccamente y para lo cual pueda establecer umbrales de proyecto.
Vamos a examinar los dos enemigos constitucionales de la gestión de proyectos ágiles, y veremos cómo se pueden medir.
El primer enemigo del Agile Project Management: La distancia
La cercanía de la colaboración entre desarrolladores y usuarios hace que los proyectos Agile sean rentables y responsivos. Idealmente, hay una continuidad de relaciones, con actualizaciones diarias para todos los miembros de equipos. Después de todo, las reuniones “de pie” diarias no son motivadoras ni tienen otros propósitos de un jefe incisivo.
Como consecuencia, la proximidad física ayuda. Recomendamos que el equipo humano principal esté a una distancia en la que se puedan gritar unos a otros. Si los usuarios descubren un nuevo requerimiento sutil, cada hora que los desarrolladores trabajan antes de entender las ramificaciones puede ser una hora perdida. Si los desarrolladores identifican una estrategia alternativa para satisfacer los requerimientos de un usuario, realmente importa qué día los usuarios validan (o rechazan) esa alternativa.
Con la distancia física se presenta una creciente oportunidad de malentendidos o comunicaciones retrasadas. Aún si lo miembros de un equipo están en un piso diferente del edificio, necesitará más puntos de verificación y comunicaciones redundantes para mantener a todos sincronizados.
Una vez que el equipo ya no está en un edificio, el problema no se vuelve mucho peor hasta que algunos miembros del equipo están en diferentes zonas horarias. El horario de trabajo escalonado hace que la comunicación estrecha sea mucho más difícil.
Sin embargo, hay otra variable de la distancia: la distancia en el organigrama. Un equipo humano de Agile prospera cerrando las brechas y haciendo conexiones directas entre los desarrolladores y usuarios. Parte de la magia de Agile -minimizar los espacios burocráticos que aíslan la colaboración efectiva -se vuelve más vulnerable a medida que los miembros del equipo son cada vez más.
Las cosas dan un salto exponencial cuando el equipo debe traspasar las fronteras nacionales. No es solo un asunto de idioma. Es la cultura de gerencia y la habilidad de comunicar sutilmente, quizás puntos espinosos, sin problemas de comunicación. Esto es particularmente problemático cuando una cultura es muy directa, pero la otra se avergüenza de comunicar cualquier información negativa.
Por supuesto, algunos trucos técnicos y de administración pueden mitigar cada uno de estos problemas. Es sorprendente lo efectivos que resultan incluso servicios gratuitos como Google Drive y Google Hangouts para mejorar la colaboración remota. Pero cada una de esas técnicas requiere algo de disciplina que involucra algún costo al proyecto. Cuando tiene que tomar en cuenta todos esos costos, la flexibilidad y velocidad de Agile puede ser cuestionada.
Nuestra consultora ha encontrado que el gasto de estar realmente on site se transforma en un mejor acuerdo para el cliente, y -al mismo tiempo- es menos doloroso que intentar manejar los recursos desde fuera del lugar.
Otros departamentos importantes con Agile abordan el tema de forma diferente: tienen on site todo el personal del “lado suave” -como analistas de negocios, arquitectos y soporte ejecutivo-, y todas las abejas obreras en otro país. Cada entregable es especificado on site, en la ubicación del cliente, y todos los productos de trabajo llegan juntos en iteraciones durante la noche.
Esta extensión del modelo de Agile funciona bien para proyectos más grandes, a medida que la redundancia requerida y los gastos generales se vuelven insignificantes cuando el 80% de las horas se encuentran en áreas de costos bajos. Sin embargo, aún no he visto un caso donde esto pueda ser escalado en forma fiable a una firma pequeña, por no hablar de un proyecto pequeño.
La mejor métrica numérica, entonces, es el porcentaje de los miembros del equipo que no están en el mismo edificio. Una cifra debajo del 20% es insignificante, un número entre 20 y 40% requiere especial atención, y una cantidad por encima del 50% requiere procesos específicos, herramientas y redundancia para mantener los proyectos funcionando.
Segundo enemigo del Agile Project Management: El tiempo:
Es irónico que la velocidad y respuesta de Agile esté en la cima de la vulnerabilidad. La cuestión con Agile es tener iteraciones rápidas que respondan a la lista de prioridades actual. Sin embargo, si retrasa un proyecto Agile solo unas cuantas semanas, podría tener que redefinirlo.
¿Por qué? En cualquier proceso de negocios importante las cosas evolucionan -algunas veces muy rápidamente. Si un proyecto Agile fue concebido, luego puesto en el congelador mientras el proceso de negocio y el organigrama evolucionaban, entonces las historias (requerimientos) y los requerimientos definitorios (prioridades) para un período (sprint) podrían estar incorrectamente definidos, o incluso podrían ser irrelevantes.
En contratos de proyectos en cascada, los equipos Agile no trabajan con requerimientos que abarcan todo. Al evitar todo lo de arriba, los requerimientos de Agile son escasos y los presupuestos más pequeños. Pero tienen fecha de expiración. Para usar una mala analogía, Agile son vegetales frescos que son buenos para usted, pero no tienen la duración de la comida enlatada.
El efecto es particularmente severo cuando los presupuestos permanecen inmóviles. Lo que pensaba que podrían costar antes todas las interrupciones, los cambios en los miembros del equipo y las modificaciones a los umbrales, los criterios y la selección de valores no son lo que costarán al final -aún si ninguno de los requerimientos cambia.
Los retrasos y las largas interrupciones de los proyectos Agile revelan problemas más profundos: El proyecto no es tan importante, no tiene los miembros de equipo adecuados, sirve como cancha política, tiene metas que son un blanco móvil, o simplemente ha sido mal concebido. Considere todas esas cosas como la causa raíz de que un proyecto Agile no pueda ponerse en marcha.
Hay una consecuencia desagradable con los retrasos e interrupciones. Devoran la confianza y la credibilidad -para todos. Las empresas tienen muy mala memoria, aún si las personas tienen impresiones duraderas. Debido a que la confianza es el ingrediente crítico de la colaboración, y una colaboración estrecha es la base de Agile, puede darse cuenta de cuán destructivos son los retrasos.
Por supuesto, los retrasos causan el movimiento de las fechas límites, pero también causan un deterioro del alcance. Aun si nada cambia, el retraso multiplica la curva de aprendizaje y los costos de administración de la configuración. Comience y detenga un proyecto Agile lo suficiente y los sobre costos serán inevitables.
La mejor métrica es expresar la interrupción de retraso acumulado como un porcentaje del ciclo nominal del período (sprint) del proyecto Agile. Una cifra por debajo del 50% es insignificante, particularmente si tiene ciclos de dos semanas, un número entre 50 y 150% requiere especial atención, y una cifra por encima del 150% indica que el proyecto ya está en problemas.
Agile óptimo vs. no tan óptimo: la prueba está en el pastel
Nuestra firma tiene un claro ejemplo de un proyecto Agile que fue realizado on site sin interrupciones, versus uno fuera de la locación con las interrupciones típicas de una empresa grande. El equipo fue el mismo, el alcance era directamente comparable y los resultados, claros.
La primera etapa (sprint) implicó un viaje a Europa para acciones on site intensivas. El segundo sprint fuera del lugar, que en realidad era un entregable más pequeño, costó al menos un 50% más (aun incluyendo los ahorros del viaje) y tomó más de un mes adicional fuera de calendario. La satisfacción del usuario fue similar.
Optimizar un proyecto Agile significa minimizar el tiempo y el espacio. Si la distancia y el retraso son realidades para su equipo, asegúrese de aplicar cada medida correctiva que pueda imaginar y reduzca las expectativas de los usuarios y de los responsables de los presupuestos.
David Taber, CIO (EE.UU.)
David Taber es el autor del libro de Prentice Hall, "Salesforce.com Secrets of Success" y es el CEO de SalesLogistix, una consultora certificada de Salesforce.com centrada en la mejora de procesos de negocio a través del uso de sistemas de CRM.