¿Agile es no planificar?

¿Cuándo fue la última vez que le tocó gestionar un proyecto predictivo? Ya sabe, uno de esos en que se debe invertir mucho tiempo y esfuerzo en la fase de planificación, la mayor parte del trabajo empieza a quedar clara desde el principio, el cliente firma los requisitos, y su misión fundamental como Project Manager es minimizar las desviaciones de tiempo, coste, alcance y calidad.

No es que no vaya a haber cambios durante la ejecución, también habrá muchos problemas, pero los interesados esperan de usted que coordine todos los cambios de forma integrada, que les haga seguir un proceso de solicitud, evaluación, aprobación, etc. Todo el mundo es consciente de que los cambios tienen un alto coste, pocos se toman la molestia de defender la necesidad de alterar algo: no quieren ser los culpables de que el proyecto sufra retraso o sobrecoste.

Quizá en ciertos sectores (construcción, ingeniería, etc.) este tipo de proyectos siguen siendo la norma. Desde luego no es el caso de los proyectos de desarrollo de software, o en los proyectos de consultoría, donde al principio suele estar poco claro el producto del proyecto. ¿Podríamos generalizar a todo proyecto de los “trabajadores del conocimiento”, donde los entregables y el trabajo son de tipo “intelectual”?
 
Si nuestro proyecto fuera un viaje, usaríamos un enfoque de gestión predictivo cuando conocemos bien el destino, y la ruta a seguir ha sido muy transitada. Aquí tiene sentido usar mapas detallados para planificar distancias, velocidades, descansos, hoteles, restaurantes, destinos intermedios, etc. 

Durante el viaje, podemos usar navegadores GPS, medir el progreso real y compararlo con el planificado, tomar acciones correctoras para llegar a tiempo sin pasarnos del presupuesto. Probablemente ocurran problemas importantes que impliquen sobrecoste, o incluso la cancelación, pero esto no dejan de ser situaciones excepcionales.

¿Y si nuestro destino estuviera en una isla desierta? No hay mapas, ni tablas con distancias y velocidades medias. No hay señal GPS. Solo tenemos como guía algo parecido al mapa de la Isla del Tesoro. ¿Cómo se gestiona un proyecto así? El equipo discute los objetivos, acuerda una estrategia general y comienzan el viaje en la dirección que creen que es la más adecuada. Cuando se topan con algún acantilado, lago o montaña que no estaba en el mapa, en lugar de seguir ciegamente un plan, reconocen que el mapa era incorrecto y es necesario replanificar. Algo parecido ocurre en los proyectos del “knolwedge worker”. La naturaleza única y sin precedentes del trabajo implica que encontraremos muchos problemas y tendremos una alta tasa de cambios.

Los proyecto predictivos se gestionan de forma diametralmente opuesta, suponen un cambio de paradigma. 

Esta imagen, que se popularizó en la metodología DSDM, una de las primeras metodologías ágiles, resume muy bien el cambio de enfoque:

Es decir, en un proyecto predictivo el alcance es una restricción (los requisitos son predeterminados) y hay que estimar cuánto tiempo y qué presupuesto supone el proyecto, siendo muy importante que se haga lo que se ha planificado (y solo eso) y cualquier cambio o corrección persigue hacer cumplir la predicción inicial sobre los objetivos de tiempo y coste.

Por el contrario, en un proyecto adaptativo, o ágil, en ventanas prefijadas de esfuerzo y tiempo (timebox, en inglés) se estima qué requisitos se pueden entregar, buscando el máximo valor para el cliente en cada iteración. Quizá en un proyecto de un año pueda haber 12 ó 15 iteraciones, 4 ó 6 releases. 

En un proyecto adaptativo no es que no planifiquemos (¡al contrario!) lo que ocurre es que concentramos el esfuerzo de planificación en las iteraciones más cercanas. La siguiente figura representa este enfoque de planificación gradual, o progresiva, que empleamos a lo largo del ciclo de vida de un proyecto adaptativo. El número de rayas es proporcional al esfuerzo progresivo que supone planificar cada iteración.
 

 Al principio hay una fase de planificación inicial (en un proyecto de un año, ¿esta fase podría durar un mes?), en la que se justifica la necesidad del proyecto, se aprueba formalmente, se estima un orden de magnitud para los objetivos de tiempo y coste, se consideran los grandes riesgos, restricciones, supuestos, recursos clave, enfoque de gestión, órganos de decisión, etc. En esta planificación inicial ya elaboramos un plan de entregas y un plan de iteraciones, y comenzamos a planificar el detalle de cada iteración, pero solo hasta donde conocemos. Se genera una lista inicial con las funcionalidades del producto, ordenadas por prioridad. Si se propone un cronograma de 12 iteraciones, como en el ejemplo, es probable que comencemos a planificar bien las 4 primeras. Cuando comienze la primera iteración, acabaremos de planificarla completamente.

Si tomamos una foto del mismo proyecto en una fecha más avanzada, y medimos el esfuerzo de planificación realizado hasta la fecha, tendríamos otra imagen:

 

En este momento, ya se han planificado completamente las iteraciones pasadas y comenzamos a planificar las siguientes con mayor detalle, pero todavía no sabemos en profundidad qué tendremos que hacer en las últimas iteraciones. En un proyecto adaptativo, no dejamos de planificar hasta que termina el proyecto.

Ahora imaginemos que el proyecto ha se ha cerrado hace tiempo, satisfactoriamente para todas las partes. Viene un auditor y nos pide los documentos de planificación del proyecto. Tenemos un problema: sólo hemos dejado por escrito algunas actas con las decisiones que se tomaron en las retrospectivas. No hemos guardado los post-its que describían las funcionalidades, los riesgos, las tareas, los “story points”. El “product backlog” ahora está vacío. Él quiere pide evidencias que demuestren que hemos dedicado tiempo a planificar. 

Solo le podemos enseñar algunas fotos de la pared que el equipo usaba como tablero, también tenemos algunas fotos del “story map”. 

De paso, le enseñamos una foto del equipo, celebrando el éxito del proyecto, donde le podemos señalar al cliente, al fondo a la izquierda, el más contento de todos. 

No le vemos muy convencido.

¿Cómo podemos convencerle de que hemos dedicado mucho tiempo a planificar, incluso más que en un proyecto predictivo?