Ventajas e inconvenientes de las metodologías Ágil y Predictiva

Dos equipos de la misma empresa entregan partes del mismo programa. Uno reporta en sprints de dos semanas y no sabe decirte qué estará terminado en noviembre. El otro tiene un cronograma que dice exactamente qué estará terminado en noviembre y no lo ha tocado desde marzo. El comité de dirección pregunta si el programa va según lo previsto y recibe dos respuestas que no se pueden sumar.

Ese es el problema que merece la pena resolver, y no consiste en elegir metodología. Es lo que ocurre cuando una organización trabaja con las dos sin haber decidido cómo se encuentran.

Dos formas de ordenar el mismo trabajo

Como sugiere su propio nombre, la metodología predictiva utiliza un diseño de proceso secuencial. El trabajo fluye desde un punto inicial hasta un punto final atravesando etapas: concepción, iniciación, análisis, diseño, construcción, pruebas, implantación y mantenimiento. Piensa en el montaje de un coche, donde ciertos pasos tienen que estar terminados antes de que empiece el siguiente. La planificación se hace por adelantado y ese plan se convierte en la línea base contra la que se medirán después las peticiones de cambio.

Ese modelo secuencial suele atribuirse al artículo que Winston Royce publicó en 1970 sobre la gestión del desarrollo de grandes sistemas de software, de donde procede el famoso diagrama en cascada. Conviene recordar que Royce presentaba la versión puramente secuencial como la arriesgada y defendía iterar alrededor de ella. La industria se quedó con su diagrama y descartó su advertencia.

La metodología ágil utiliza un acercamiento iterativo al producto final. No hay un plan de acción predeterminado que cubra el proyecto entero. En su lugar, el equipo fija una cadencia, habitualmente llamada sprint, y vuelve a decidir al principio de cada una qué construir a continuación. Los clientes intervienen mientras el trabajo está en marcha y las pruebas ocurren en paralelo a la construcción, no después. Como movimiento con nombre propio, lo ágil arranca con el Manifiesto Ágil de febrero de 2001, escrito precisamente en reacción a esos procesos secuenciales cerrados.

La entrega predictiva fija el alcance y controla el cambio contra una línea base. La entrega ágil fija la cadencia y vuelve a decidir el alcance en cada incremento.

Entre esos dos polos viven las variantes iterativa e incremental. Nuestro artículo sobre los ciclos de vida de un proyecto recoge la taxonomía completa.

	Predictiva	Ágil
Qué se fija antes de empezar	Alcance, calendario y presupuesto	La cadencia y el equipo, no el alcance
Cómo se absorbe el cambio	Control de cambios contra la línea base	Se reprioriza en el siguiente incremento
Cuándo ve el cliente el producto	Tarde, en la entrega o cerca de ella	Al final de cada incremento
Para qué sirve la documentación	Continuidad y relevo	Producto funcionando por encima de documentos
Coste de perder a alguien del equipo	Se absorbe, el plan guarda el conocimiento	Alto, el contexto vive en el equipo

Qué te aporta lo ágil

Lo ágil ofrece un modelo genuinamente flexible, capaz de adaptarse a medida que cambia el mundo alrededor del proyecto. El trabajo se divide en piezas pequeñas que asumen grupos independientes, que avanzan en paralelo y hablan entre ellos. Los clientes participan y el producto se prueba mientras se construye, con lo que el resultado se mantiene alineado con lo que de verdad hace falta y no con lo que hacía falta el día del arranque.

Eso hace que lo ágil resulte especialmente útil cuando el objetivo no está claramente definido, o cuando el cliente todavía no sabe exactamente qué necesita. El feedback mutuo va acercando las dos definiciones de éxito, en lugar de descubrir al final que nunca coincidieron.

Aquí el peso lo lleva la comunicación: dentro de cada equipo, entre los equipos que se reparten las tareas de un proyecto y entre todos ellos y el cliente. Es lo que mantiene el resultado coherente con unos objetivos que siguen en movimiento.

Qué te aporta lo predictivo

En un proyecto predictivo no se empieza nada hasta que hay un objetivo claro y una planificación meticulosa. Como sabes exactamente adónde quieres llegar y cómo, el proyecto tiende a llegar rápido y seguro una vez en marcha. Se pueden elaborar calendarios y presupuestos precisos antes de la ejecución y cumplirlos con pocas desviaciones, y esa correspondencia entre lo dicho y lo hecho es justo lo que más valoran los clientes.

La promesa solo se sostiene si mides el avance contra el plan y no contra las horas consumidas. Avance y horas son dos magnitudes distintas, y tratar la segunda como sustituto de la primera es la forma habitual de que un proyecto siga en verde hasta la semana en que se desploma.

Posición respecto al plan = % completado − % esperado hoy

Esa comparación necesita una línea base viva detrás. En ITM Platform el progreso se informa desde el parte de horas, la pestaña de progreso de la tarea o el diagrama de Gantt, nunca se deduce de las horas, que es lo que da sentido a los indicadores “% Esperado hoy” y “Línea base – % esperado”. Su configuración se explica en seguimiento de proyectos en cascada.

La segunda ventaja es la documentación. Esta forma de trabajar deja un registro extenso de lo que hay que hacer en cada momento, de modo que si alguien del equipo no puede llegar al final, otra persona puede ocupar su lugar después de ponerse al día de la situación.

Dónde duele lo ágil

Precisamente por esa flexibilidad, lo ágil puede mostrar una estructura muy débil. La exactitud de la planificación sufre, desde los plazos de entrega hasta los presupuestos, y sin un plan concreto todo parece flotar.

• La comunicación, la implicación personal y la colaboración no son extras opcionales, son la condición para que el método funcione. Con equipos que colaboran mal, lo ágil se atasca.
• La comunicación estrecha y permanente consume tiempo, en reuniones y en el intercambio de contexto que las hace útiles.
• Lo ágil depende mucho más de que estén las mismas personas de principio a fin. Perder a alguien del equipo duele más que en un proyecto predictivo.

La respuesta a la queja de la estructura débil no es colgarle un Gantt a un equipo ágil. Es medir otra cosa. Un gráfico de Burndown muestra el avance esperado frente al real, pero esconde el trabajo en curso y aguanta mal un backlog que crece. El diagrama de Flujo Acumulado corrige ambas cosas y da el Trabajo en Curso (WIP) y el Tiempo de Ciclo, los dos números que dicen si un equipo ágil es predecible, en un contexto donde una desviación de calendario no significaría nada. Los dos gráficos están descritos en seguimiento de proyectos ágiles.

Dónde duele lo predictivo

El principal inconveniente de la entrega predictiva es que es menos flexible, y lo es por una razón: la certeza que ofrece se paga planificando con mucha antelación. Alterar el proyecto en cualquiera de sus etapas puede ser una pesadilla para el project manager, porque una vez analizada toda la planificación, introducir cambios es muy difícil. Hay que revisar cada dependencia que viene por detrás.

El segundo inconveniente es el momento. El feedback del cliente y los resultados de las pruebas no llegan hasta estados muy avanzados del proyecto. Si algo está mal, no puedes reaccionar hasta tarde, y las reacciones tardías cuestan mucho más tiempo, esfuerzo y dinero que las tempranas.

Entonces, ¿cuál es mejor?

Elegir entre una y otra es tarea del project manager, y se decide en función de las necesidades del proyecto, las exigencias del cliente y el equipo del que realmente se dispone.

Lo ágil encaja con quien sabe en qué dirección quiere caminar pero no exactamente adónde quiere llegar. Lo predictivo encaja con proyectos que se espera que se queden quietos, en los que no se anticipan cambios durante la ejecución.

Son directrices, no reglas, y la elección pertenece a cada proyecto. En cualquier organización que lleve más de un puñado de proyectos a la vez, la respuesta honesta a nivel de portafolio no es una u otra, son las dos.

Convivir sin obligar a todos a trabajar igual

Las dos pueden convivir en un mismo entorno, pero solo si esa convivencia se diseña. Empieza por las personas: project managers, ejecutores de tareas e interesados necesitan entender las diferencias y apreciar qué aporta cada enfoque. Buscar culpables, o colocar una por encima de la otra, solo retrasa el conjunto.

Después, dales una unidad de tiempo compartida, que es la versión práctica del consejo de “mantenerlas sincronizadas”. Los sprints no tienen por qué pertenecer solo a los tableros ágiles: un proyecto predictivo también puede llevar sprints, de modo que el Gantt se puede filtrar y ordenar por sprint mientras el tablero se navega por ese mismo sprint. Actívalos por proyecto o por tipo de proyecto y asigna tareas de forma masiva, tal como se describe en sprints, y el portafolio mixto pasa a tener una sola cadencia contra la que reportar en lugar de dos calendarios que nadie sabe reconciliar.

La otra mitad es el gobierno. Una oficina de gestión de proyectos mantiene a los dos tipos de equipo apuntando a los objetivos de la organización y lee cada uno con el instrumento adecuado. Esa es una PMO distinta de la que solo vigila planes, y es el asunto de nuestro artículo sobre la PMO ágil.

El obstáculo real no es la metodología

El mayor reto al que se enfrentan las empresas no es decidir entre ágil y cascada. Es el miedo al cambio. Obligar a la gente a abandonar su forma de trabajar es difícil, a menudo desastroso e innecesario. Deja que cada equipo conserve el método que encaja con su trabajo, acordad cómo se mide el avance y cuándo se reporta, y la unión entre ambas deja de ser una concesión para convertirse en una ventaja.

Siguientes pasos

• Empieza una prueba gratuita de ITM Platform y lleva un tablero ágil y un proyecto con Gantt en paralelo dentro del mismo portafolio.
• Descubre cómo planificación y seguimiento trata los dos tipos de proyecto en un mismo sitio.
• Activa primero una cadencia compartida: los sprints funcionan igual en tableros ágiles y en cronogramas predictivos.