Un proyecto ágil es una asignación temporal para crear un producto, servicio o resultado único, en que los requisitos no están claros al principio y deben elaborarse progresivamente a partir de la retroalimentación continua de los interesados (=valor), que regularmente atienden a demostraciones donde pueden ver un incremento del producto del proyecto funcionando.
En un proyecto ágil, después de cada demostración, los interesados manifiestan abiertamente su opinión sobre el incremento que han visto y el product owner utiliza esta retroalimentación para validar los requisitos (en agile se dice «historias de usuario») o bien para eliminar incertidumbres. Esta forma de avanzar en un proyecto se denomina «ciclo de vida orientado al valor».
Si los requisitos pueden consensuarse en una fase inicial, debido a la incertidumbre funcional, lo que suele ocurrir en proyectos de ingeniería y construcción (también denominados proyectos EPC), se considera un error metodológico seguir un modelo de ciclo de vida orientado al valor. Lo correcto es seguir un modelo de ciclo de vida orientado a la planificación, predictivo, u orientado a procesos: A partir de los requisitos se determina el alcance, y a partir del alcance se estiman los tiempos y los costes, y se desarrolla un plan para la dirección del proyecto especificando el resto de áreas de gestión: calidad, recursos, comunicaciones, riesgos, adquisiciones e interesados.
Si los requisitos no pueden consensuarse en una fase inicial, lo que suele ocurrir en proyectos de software, se considera un error metodológico seguir un modelo de ciclo de vida orientado a la planificación. En este caso, lo correcto es seguir un modelo de ciclo de vida ágil, orientado al valor, adaptativo, o que da la bienvenida a los cambios. Hay que determinar el tiempo disponible, calcular el coste de un equipo estable, y dividir el proyecto en fases sucesivas que se entregan cada 2-3 meses (releases), y en cada release suelen demostrarse incrementos en reuniones con los interesados, que tienen lugar con periodicidad fija, típicamente cada 2 semanas. La retroalimentación de los interesados nos permite validar los requisitos entregados y deducir los nuevos. Podemos decir que el alcance se va desarrollando progresivamente.
Los proyectos pueden aplicar ciclos de vida ágiles en unas fases y ciclos de vida predictivos en otras. Cuando esto ocurre, se dice que el proyecto sigue un modelo de ciclo de vida híbrido.
Un project manager profesional suele estar capacitado para gestionar proyectos predictivos y ágiles. Se le presupone un conocimiento práctico para aplicar las técnicas y herramientas que permiten que cualquier proyecto entregue el valor y cumpla los objetivos de gestión, principalmente para que termine a tiempo y dentro del presupuesto. Evidentemente, hay multitud de factores que pueden provocar que no se entregue el valor o se cumplan los objetivos de gestión y entonces se considera que el proyecto ha sido fallido y el project manager suele considerarse como el principal responsable. Los buenos project managers suelen registrar las evidencias del fracaso no al final del proyecto o fase, sino en cada reunión de seguimiento, cuando es posible que los involucrados ayuden a buscar soluciones antes de que sea demasiado tarde.
Casi siempre, es injusto culpar al project manager del fracaso del proyecto, dada la multitud de variables que lo afectan, pero para eso precisamente nos ponen al mando los jefes, para tener un culpable identificado.
Los jefes nos quieren al mando de un proyecto para tener un culpable identificado 🙁
Sabiendo que estas son las reglas del juego, juguemos bien nuestras cartas: Los project managers profesionales queremos rendir cuentas en reuniones de seguimiento, en las que podemos informar y también involucrar a los miembros del comité de seguimiento, de manera que la culpa no sea solo nuestra.
¿No hay Reglas en un Proyecto Ágil?
Los directivos de las organizaciones, cada vez que autorizan un proyecto ágil, suelen experimentar una disonancia cognitiva:- Quieren que el proyecto cumpla los objetivos de gestión y entrega de valor: es decir, que termine antes que una fecha, por debajo de un presupuesto y satisfaciendo las necesidades, como cualquier otro proyecto.
- Saben que el equipo debe auto-organizarse sin jefes. Cuando haya dudas, ya preguntarán a otras personas que tienen el conocimiento del negocio (e.g. product manager). ¿Para qué hace falta un project manager en un proyecto ágil?