“AgileFall” es un término que describe un modelo de gerencia en el que trata de ser ágil y lean (esbelto), pero sigue regresando a las tradicionales técnicas de desarrollo en cascada (waterfall).
Recientemente me senté en una reunión con una compañía de la lista Fortune 10 donde observé de primera mano mientras ocurría el AgileFall.
Estábamos ayudando a la empresa en la transición de una de sus líneas de producto de un proceso de dirección de proyecto en cascada a uno esbelto. Nuestro cliente estaba enfrentando disrupción de parte de nuevos competidores. El jefe de producto entendió que el desarrollo en cascada no era apropiado porque el problema y la solución tenían muchos elementos desconocidos.
La línea de producto en cuestión tenía 15 gerentes de proyecto supervisando 60 proyectos. Nuestra meta era ayudar al cliente a inyectar los principios básicos del enfoque esbelto en esos proyectos. Todos los proyectos buscaban crear nuevas características de producto que se dirigían a consumidores existentes, o reacondicionar productos para nuevos consumidores. Los equipos también tenían la tarea de crear productos mínimamente viables, salir del edificio para hablar con usuarios y partes interesadas, y obtener el permiso para pivotear, todos son partes del proceso lean básico.
Sin embargo, durante nuestra reunión me di cuenta de que el jefe de producto seguía dirigiendo a sus gerentes de proyecto usando el proceso en cascada. Los equipos sólo se reunían con él cada tres meses para revisiones formales y agendadas. El jefe de producto mencionó que los equipos se quejaban de la cantidad de papeleo que los hacía llenar para esas revisiones trimestrales. Él estaba infeliz con la calidad de los reportes, porque sentía que la mayor parte de los equipos los redactaban la noche previa a la revisión. ¿Cómo, preguntó, podría obtener más mediciones de desempeño y reportes oportunos de parte de los gerentes de proyecto?
A primera vista pensé, ¿qué podría estar mal acerca de más datos? ¿No es eso lo que queremos, las decisiones basadas en evidencia? Estaba a punto de dejarme llevar por el seductor sendero de sugerir incluso más mediciones de efectividad, cuando entendí cuál era el problema real: El cliente seguía utilizando un proceso en el que el éxito se medía por reportes y no por resultados. Era el mismo tipo de reporte usado en proyectos que siguen el método de cascada. (Para ser justo, este equipo es una isla lean en una compañía donde las técnicas de cascada siguen dominando.)
Conforme avanzó la conversación, llegamos a un acuerdo con el jefe de producto respecto a formas de manejar proyectos usando algunos principios operativos de la administración de proyectos ágil y esbelta (sin mencionar en ningún momento las palabras esbelto o ágil). Concluimos lo siguiente:
1 Eran los individuos quienes estaban creando el valor (encontrando la solución o el ajuste respecto a la misión), no los procesos y reportes.
2 Sin embargo, el proceso y los reportes seguían siendo esenciales para los niveles directivos situados por encima del jefe de producto.
3 Hacer que los equipos construyeran productos mínimamente viables en forma incremental e iterativa era más importante que obsesionarse acerca de los reportes iniciales.
4 Era esencial permitirle a los equipos pivotear con base en lo que aprendieron al investigar a los consumidores, en lugar de seguir a ciegas un plan que estaba impuesto desde el inicio.
5 El avance hacia resultados (la solución o el ajuste respecto a la misión) no era lineal y no todos los equipos progresaban al mismo ritmo.
Sin necesidad de demasiado convencimiento, nuestro cliente aceptó que, en lugar de revisiones trimestrales, el equipo de liderazgo hablaría cada semana con cuatro a cinco gerentes de proyecto para revisar de 16 a 20 proyectos. Esto significaba que el ciclo de interacción pasaría de cada tres meses a por lo menos una vez al mes.
Lo más importante, decidimos que el jefe de producto enfocaría estas conversaciones en resultados más que en reportes. Habría más comunicación verbal y mucho menos papeleo. Las revisiones serían acerca de entregas frecuentes, desarrollo incremental y cómo los líderes podrían remover obstáculos. Los equipos seguirían compartiendo reportes de progreso entre sí, de forma que puedan aprender de los demás.
En suma: La idea radical fue que el rol del jefe de producto no era empujar el papeleo; era impulsar una mentalidad basada en resultados desde arriba hacia abajo, y luego traducir el progreso obtenido hacia arriba de la cadena. Esto le adjudicó al jefe de producto la responsabilidad de reportar los avances ante los altos directivos.
Supe que la bombilla se había encendido por completo al final de la reunión. El jefe de producto le preguntó a su equipo, “de ahora en adelante, ¿quiénes son los miembros adecuados del equipo para dirigir un proceso esbelto a comparación de una cascada?” Sonreí cuando concluyeron que el primero podía ser dirigido por menos personas, las que podrían operar en un caótico entorno de aprendizaje, a comparación de otro impulsado por procesos.
No puedo esperar para nuestra siguiente reunión.