Cuando los principios de cascada vuelven a colarse en flujos de trabajo ágiles

Resumen.

AgileFall describe una situación en la que los gestores de proyectos intentan cambiar a la metodología ágil, pero se ven obligados a seguir operando bajo muchas de las reglas y prácticas del desarrollo tradicional de cascada. Este artículo describe a un cliente donde está sucediendo esto, y cómo la compañía trabajó para reducir el papeleo y el lento tiempo de revisión que estaba cojeando el progreso.

AgileFall es un término irónico para la gestión de programas donde intentas ser ágil y delgado, pero sigues usando técnicas de desarrollo de cascada. A menudo produce un resultado que es como combinar una cera de piso y un relleno de postre.

Acabo de sentarme a través de una reunión de gestión de proyectos donde vi a AgileFall suceder de primera mano. La buena noticia es que algunos ajustes en proceso nos pusieron de nuevo en el camino.

La reunión tuvo lugar en una empresa Fortune 10. Les ayudamos a convertir una de las líneas de productos esenciales dentro de una división existente de un proceso tradicional de gestión de proyectos de cascada en Lean.

Nuestro cliente, su jefe de producto, es inteligente, innovador y motivado. Su empresa se enfrenta a la interrupción de nuevos competidores. Se dio cuenta de que el desarrollo tradicional de cascada no era apropiado cuando el problema y la solución tenían muchas incógnitas.

La línea de productos que nos enfoca cuenta con 15 gestores de proyectos que supervisan 60 proyectos. En los últimos meses le hemos ayudado a inyectar los principios básicos de Lean en estos proyectos. Todos son Horizonte 1 o 2 proyectos: crear nuevas funciones para productos existentes dirigidos a clientes existentes, o redestinar productos, herramientas o técnicas existentes a nuevos clientes. Los equipos están creando productos mínimos viables (MVP), saliendo del edificio para hablar realmente con los usuarios y las partes interesadas, y obteniendo permiso para pivotar, etc. Todos los buenos conceptos básicos de Lean.

Pero en nuestra última reunión, me di cuenta de que el jefe de producto todavía estaba administrar sus directores de proyecto utilizando un proceso de cascada. Los equipos solo se registraron, esperen por ello, cada tres meses en una revisión formal del calendario. Escuché mientras el cliente mencionó que los equipos se quejaron del volumen de papeleo que los hace llenar para estas revisiones trimestrales. Y no estaba contento con la calidad de los informes porque sentía que la mayoría de los equipos escribieron los informes la noche anterior a la revisión. Preguntó, ¿cómo podría obtener aún más medidas del desempeño y la presentación oportuna de informes por parte de los directores de proyectos?

A primera vista, pensé, ¿qué podría ser malo de más datos? ¿No es eso lo que queremos, decisiones basadas en pruebas? Estaba a punto de ser absorbido por el sendero seductor de sugerir aún más medidas de efectividad cuando me di cuenta de que nuestro cliente todavía tenía un proceso en el que el éxito era medido por informes, no por resultados. Fue el mismo proceso de presentación de informes utilizado para medir proyectos que utilizaban cascada lineal, paso a paso.

(Para ser justos, este equipo es una isla Lean en una empresa donde todavía domina la cascada. Aunque este grupo ha cambiado la mentalidad y la cadencia de la organización, las personas a las que informa aún no obtienen aprendizaje y resultados de Ágile/Lean. Ellos sólo quieren ver el papeleo.)

Tanto en la gestión hacia abajo como hacia arriba, necesitábamos una mentalidad de gestión de proyectos muy diferente.

A medida que avanzaba la conversación, acordamos las formas de gestionar proyectos utilizando algunos principios operativos de la gestión de proyectos Lean/Ágil (sin mencionar nunca las palabras Lean o Ágil).

1. Son los individuos los que estaban creando el valor (encontrar solución/ajuste de la misión), no los procesos e informes.
2. Sin embargo, el proceso y los informes siguen siendo esenciales para la gestión por encima de él.
3. Tener a los equipos que creen MVP incrementales e iterativos es más importante que obsesionarse con la documentación/generación de informes tempranos.
4. Permitir que los equipos pivoten hacia lo que aprendieron en el descubrimiento de clientes en lugar de seguir ciegamente un plan que le vendieron el primer día es esencial.
5. El progreso hacia los resultados (solución/ajuste de la misión) no es lineal y no todos los equipos progresan al mismo ritmo.

Sin demasiado convincente, nuestro cliente estuvo de acuerdo en que, en lugar de revisiones trimestrales, el equipo de liderazgo hablaría con 4-5 directores de proyectos cada semana, mirando 16 a 20 proyectos. Esto significaba que el ciclo de interacción —aunque aún fuera largo — pasaría de los tres meses actuales a por lo menos una vez al mes.

Más importante aún, decidimos que centraría estas conversaciones en los resultados en lugar de en informes. Habría más comunicación verbal y mucho menos papel. Los exámenes se verían sobre la ejecución frecuente, el desarrollo gradual y la manera en que el liderazgo podría eliminar los obstáculos. Y el equipo de nuestro cliente continuaría compartiendo informes de progreso entre los equipos para que pudieran aprender unos de otros.

En resumen, la idea radical era que el papel del jefe del producto no era empujar el papeleo hacia abajo. Fue para empujar hacia abajo una orientación hacia el resultado, y luego traducir su progreso de nuevo a la cadena. Si bien esto fue genial para los equipos, puso la responsabilidad en el jefe del producto informar sobre el progreso de nuevo a su liderazgo de una manera que ellos quisieran verlo.

Sabía que la bombilla se había encendido completamente cerca del final de la reunión. El cliente le preguntó a su equipo: «En el futuro, ¿quiénes son los miembros del equipo adecuados para gestionar un proceso Lean frente a una cascada?» Y sonreí cuando llegaron a la conclusión de que Lean podría ser administrado por menos personas que podrían operar en un entorno de aprendizaje caótico, en comparación con uno de ejecución impulsado por procesos.

No puedo esperar a la próxima reunión.

— Escrito por Steve Blank