Cuando los principios de Waterfall vuelven a introducirse en los flujos de trabajo ágiles

AgileFall describe una situación en la que los directores de proyectos intentan cambiar a la metodología ágil, pero se ven obligados a seguir trabajando según muchas de las normas y prácticas del desarrollo tradicional de Waterfall. Este artículo describe a un cliente en el que está sucediendo esto y cómo la empresa trabajó para reducir el papeleo y retrasar el tiempo de revisión, lo que estaba obstaculizando el progreso.

••• _Caída ágil_ es un término irónico para la gestión de programas en el que se trata de ser ágil y ágil, pero sigue utilizando técnicas de desarrollo en cascada. A menudo produce un resultado que es como combinar cera para suelos y una cobertura de postre. Acabo de asistir a una reunión de gestión de proyectos en la que he visto AgileFall de primera mano. La buena noticia es que unos cuantos ajustes en proceso nos han permitido volver a encarrilarnos. La reunión tuvo lugar en una empresa de la lista Fortune 10. Los estamos ayudando a convertir una de las líneas de productos fundamentales de una división existente, de un proceso tradicional de gestión de proyectos en cascada a Lean. Nuestro cliente, su jefe de producto, es inteligente, innovador y motivado. Su empresa se enfrenta a la disrupción de los nuevos competidores. Se dio cuenta de que el desarrollo tradicional de cascadas no era apropiado cuando el problema y la solución tenían muchas incógnitas. La línea de productos en la que nos centramos cuenta con 15 directores de proyectos que supervisan 60 proyectos. Durante los últimos meses, lo hemos ayudado a introducir los principios básicos de Lean en estos proyectos. Todos lo son[Horizon 1 o 2](/2019/02/mckinseys-three-horizons-model-defined-innovation-for-years-heres-why-it-no-longer-applies) proyectos: crear nuevas funciones para los productos existentes dirigidas a los clientes actuales o reutilizar los productos, herramientas o técnicas existentes para nuevos clientes. Los equipos ahora están creando productos mínimos viables (MVP), salen del edificio para hablar realmente con los usuarios y las partes interesadas y obtienen 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 seguía siendo _gestionar_ sus directores de proyectos utilizan un proceso de cascada. Los equipos solo se registraban (espere) cada tres meses en una revisión formal de la programación. Escuché al cliente mencionar que los equipos se quejaron del volumen de papeleo que les hace rellenar para estas revisiones trimestrales. Y no estaba contento con la calidad de los informes porque pensaba que la mayoría de los equipos los redactaron la noche anterior a la revisión. ¿Cómo, preguntó, podría obtener aún más medidas del desempeño e informes puntuales de los directores de proyecto? A primera vista, pensé: ¿qué podría tener de malo tener más datos? ¿No es eso lo que queremos, decisiones basadas en pruebas? Estaba a punto de dejarme llevar por el seductor camino de sugerir aún más medidas de eficacia cuando me di cuenta de que nuestro cliente todavía tenía un proceso en el que el éxito se medía por los informes, no por los resultados. Era el mismo proceso de elaboración de informes utilizado para medir los proyectos que utilizaba una cascada lineal y gradual. (Para ser justos, este equipo es una isla magra en una empresa en la que la cascada sigue dominando. Si bien este grupo ha cambiado la mentalidad y el ritmo de la organización, las personas a las que denuncia aún no aprenden ni obtienen resultados de Agile/Lean. Solo quieren ver el papeleo.) Tanto en la gestión descendente como en la ascendente, necesitábamos una mentalidad de gestión de proyectos muy diferente. A medida que avanzaba la conversación, nos pusimos de acuerdo sobre las formas de gestionar los proyectos utilizando algunos principios operativos de la gestión de proyectos Lean y Agile (sin mencionar nunca las palabras Lean o Agile). 1. Son las personas las que creaban el valor (encontrando la solución o la misión adecuada), no los procesos y los informes. 2. Sin embargo, el proceso y los informes siguen siendo esenciales para la dirección por encima de él. 3. Hacer que los equipos creen MVP incrementales e iterativos es más importante que obsesionarse con la documentación o los informes tempranos. 4. Es esencial permitir que los equipos se basen en lo que han aprendido en el descubrimiento de los clientes en lugar de seguir ciegamente el plan que le vendieron el primer día. 5. El progreso hacia los resultados (ajuste a la solución/misión) no es lineal y no todos los equipos progresan al mismo ritmo. Sin convencerlo demasiado, nuestro cliente estuvo de acuerdo en que, en lugar de revisiones trimestrales, el equipo directivo hablaría con 4 o 5 directores de proyectos cada semana y analizaría entre 16 y 20 proyectos. Esto significaba que el ciclo de interacción, aunque aún era largo, pasaría de los tres meses actuales a al menos una vez al mes. Y lo que es más importante, decidimos que centraría estas conversaciones en los resultados y no en los informes. Habría más comunicación verbal y mucho menos papel. Las reseñas tratarían sobre la entrega frecuente, el desarrollo gradual y la forma en que los líderes podrían eliminar los obstáculos. Y el equipo de nuestro cliente seguiría compartiendo los informes de progreso entre los equipos para que pudieran aprender unos de otros. En resumen, la idea radical era que la función del jefe de producto no consistía en retrasar el papeleo. Era para reducir la orientación hacia los resultados y, luego, traducir su progreso de nuevo en la cadena. Si bien esto fue fantástico para los equipos, hizo recaer en el director de producto la responsabilidad de informar sobre los avances a sus líderes de la manera que querían verlos. Sabía que la bombilla se había encendido por completo cerca del final de la reunión. El cliente preguntó a su equipo: «De ahora en adelante, ¿quiénes son los miembros adecuados del equipo para gestionar un proceso Lean en lugar de una cascada?» Y sonreí cuando se dieron cuenta de que Lean podría gestionarlo menos personas que pudieran trabajar en un entorno de aprendizaje caótico, en lugar de en un entorno de ejecución impulsado por procesos. Me muero de ganas de que llegue la próxima reunión.