¿Ágil o Cascada (Secuencial): cuál es mejor?

Como profesional ágil, entrenador, coach y consultor, podrías esperar que dijera: "Agile es la única forma de tener éxito, ¡págame mucho dinero y te mostraré por qué!"

Pero aquí está la verdad (alerta de spoiler): solo puedo responder a esta pregunta con "depende". Puede sonar vago, pero a menudo es la respuesta más honesta y valiosa.

Al final, solo tú puedes decidir qué es lo mejor para tu proyecto y organización, basándote en los factores y limitaciones que entiendes mejor que yo. Espero que este artículo te ayude a resolverlo por ti mismo.

Comencemos examinando las ideas centrales detrás de cada enfoque.

La gestión de proyectos en cascada sigue un enfoque secuencial y predictivo. El alcance suele estar fijado, y la solución a menudo se especifica completamente antes del desarrollo. La entrega puede ocurrir como un único 'big bang' o en fases, donde cada fase entrega una parte significativa de la solución general.

Un método de cascada típico involucra estos pasos:

1. Análisis: Identificar, documentar, acordar y aprobar los requisitos y cualquier estándar de calidad. En TI, esto incluye requisitos no funcionales.
2. Diseño: Crear y aprobar un diseño detallado que cumpla con los requisitos acordados y criterios de calidad.
3. Construcción: Construir la solución de acuerdo al diseño, asegurando que cumpla con todos los requisitos especificados y estándares de calidad.
4. Prueba: Probar exhaustivamente la solución para confirmar que cumple con los requisitos acordados, el diseño y otros criterios de calidad.
5. Despliegue: Poner la solución en uso para entregar su valor comercial previsto.

Cada paso debe ser planificado y dotado de recursos, con todas las actividades claramente identificadas, estimadas y asignadas. En muchos casos las actividades se dividirán en tareas detalladas y se capturarán en forma de un diagrama GANTT. Para un proyecto por fases, el análisis y diseño de alto nivel deben ocurrir primero para establecer el contexto y alcance de cada fase.

El enfoque en cascada requiere un estilo predictivo de gestión de proyectos en el que cada paso produce documentación que describe lo que el siguiente paso necesita hacer.

Todo el trabajo para cada paso se planifica basándose en la expectativa (en sí misma una predicción) de que el resultado coincidirá con lo que se acordó. La documentación debidamente aprobada es la principal forma de comunicar la intención del proyecto a todas las personas involucradas o afectadas.

El control del proyecto se basa en demostrar que el trabajo entregado coincide con la documentación del paso anterior, así como en seguir el plan aprobado para el paso actual. Cualquier cambio debe pasar por un proceso formal en el que la documentación se revisa y aprueba. Idealmente, la documentación se revisa regularmente para asegurar que aún satisfaga las necesidades empresariales en evolución.

Los cambios pueden identificarse a partir del trabajo en los pasos posteriores del proceso en cascada. Por ejemplo, con problemas que se descubren durante el paso de Pruebas que identifican una discrepancia entre los requisitos especificados y la necesidad empresarial actual. Se requiere un análisis de esa discrepancia con cualquier cambio acordado que se propague en cascada hasta ser probado nuevamente.

La percepción del éxito en el modelo en cascada tiende, por lo tanto, a estar relacionada con qué tan bien la predicción coincide con la necesidad real y qué tan estrechamente se alinean los resultados con la predicción en términos de presupuesto, cronogramas y calidad.

El proceso de cascada puede parecer simple al principio, pero a menudo resulta ser más complejo de lo esperado. Depende en gran medida de la documentación, utiliza aprobaciones jerárquicas y sigue una planificación centralizada. Debido a que exige documentación y planificación detalladas desde el inicio, el proceso puede volverse complicado, con muchas partes relacionadas que necesitan conectarse para que el proceso logre el resultado deseado.

Ventajas:

• Estructura Directa: El enfoque paso a paso es fácil de entender para los gerentes de proyecto y de explicar a las partes interesadas.
• Planificación Predecible: El análisis y diseño exhaustivos al inicio respaldan una planificación y presupuestación clara y precisa.
• Seguimiento Simple: El progreso se puede monitorear a través de documentación (mostrando cómo se cumplen los hitos) y verificar contra el plan (para confirmar que las tareas se completan a tiempo y dentro del presupuesto).

Desventajas:

• Gestión de Cambios Compleja: Manejar los cambios necesarios puede ser engorroso, a veces llevando a los equipos a saltarse el proceso por completo y resultando en una pérdida de control.
• Detección Tardía de Problemas: El desarrollo en grandes incrementos con pruebas enfocadas principalmente al final del proceso puede revelar problemas demasiado tarde, causando retrasos inesperados y sobrecostos.
• Enfoque Reducido en el Valor del Negocio: El análisis y documentación extensivos desde el inicio no ofrecen valor directo al negocio; existen únicamente para guiar el proceso.

Aunque todavía tiene un elemento de proceso distintivo para enmarcar el desarrollo, un enfoque ágil de gestión de proyectos se enfoca más en las personas que en el proceso. El trabajo inicial es intencionalmente ligero, moldeando solo la solución y el plan de alto nivel mientras deja los detalles más finos hasta el último momento responsable antes del desarrollo. Típicamente, el desarrollo procede característica por característica dentro de "Sprints" de duración fija.

Los participantes del proyecto –incluyendo, de manera importante, personas del ámbito empresarial dentro de los equipos de desarrollo– colaboran durante todo el proyecto. Construyen incrementos más pequeños que en el modelo tradicional en cascada, utilizando un proceso iterativo.

Cada iteración incluye análisis, diseño, construcción, pruebas y, idealmente, despliegue, en ciclos que pueden durar solo unas pocas horas o extenderse varios días o semanas (en lugar de las semanas o meses que se ven a menudo en cascada). El objetivo es desplegar partes de la solución tan pronto como puedan generar valor.

El desarrollo se basa en la colaboración detallada de individuos conocedores y habilidosos, empoderados por la organización para desarrollar una solución que satisfaga la necesidad del negocio.

Esos individuos definen el detalle de la necesidad antes de planificar el trabajo de desarrollo requerido. Luego ejecutan este plan, ajustándolo continuamente para mantenerse enfocados en entregar el máximo valor. Para una verdadera agilidad, los equipos a menudo siguen valores como los que se encuentran en Scrum, que actualmente es el enfoque de entrega ágil más ampliamente adoptado.

El enfoque iterativo es altamente tolerante al cambio porque pospone la planificación detallada hasta el último momento responsable, utilizando datos en tiempo real y ciclos de planificación cortos. En lugar de ser completamente predicha desde el principio, la solución emerge gradualmente para satisfacer necesidades que fueron esbozadas (pero no definidas meticulosamente) al inicio del proyecto.

Al priorizar los requisitos de alto nivel desde el principio y manejar primero los más importantes, permite que los equipos ágiles mantengan un control estricto sobre los plazos y presupuestos. El desarrollo simplemente termina de manera controlada una vez que se alcanzan los límites de tiempo o presupuesto, con solo los elementos menos valiosos siendo excluidos de la entrega final.

Debido a que los ciclos de desarrollo son cortos (generalmente alrededor de dos semanas) y fijos, tiene sentido medir el éxito a través de la entrega incremental de valor a un ritmo predecible.

El enfoque iterativo e incremental, con ciclos cortos impulsados por equipos autoorganizados empoderados, a menudo parece caótico. Pero con personal competente, colaborativo y disciplinado es altamente eficiente y efectivo. Dicho esto, el riesgo de usar un enfoque ágil con individuos que no son competentes, colaborativos y disciplinados muy probablemente llevará al fracaso. Esto hace que la supervisión (pero no la gestión) sea esencial hasta que los equipos hayan demostrado su capacidad colectiva para entregar resultados.

Ventajas:

• Desarrollo Iterativo: Ciclos de desarrollo rápidos con oportunidades de colaboración y retroalimentación continua reducen el riesgo de construir una solución que no satisfaga necesidades reales.
• Entrega Incremental de Valor: Entregar valor tangible en intervalos cortos mejora el control general al hacer que el progreso sea más fácil de rastrear y las acciones correctivas más fáciles de identificar.
• Adaptabilidad: Dejar los detalles para el último momento responsable permite que las soluciones emerjan para satisfacer necesidades actuales en lugar de necesidades predichas.

Desventajas:

• Puede parecer no estructurado: Especialmente para quienes están acostumbrados a controles basados en procesos. No es adecuado para gerentes y líderes con altas necesidades de control.
• Alta competencia y colaboración de todos los involucrados: Los líderes requieren confianza para confiar y competencia para empoderar a sus equipos colaborativos.
• Potencial para el caos y el fracaso: Los equipos que carecen de competencia demostrada y profesionalismo pueden fracasar sin la supervisión adecuada.

Nota: las desventajas descritas anteriormente se aplican a equipos u organizaciones que son nuevos en la forma ágil de trabajar donde existe competencia genuina con la agilidad es difícil identificar inconvenientes universales aunque pueden surgir algunos específicos del contexto.

Las diferencias clave entre un enfoque ágil y un enfoque en cascada se pueden resumir en 5 dimensiones:

1. Desarrollo de Soluciones – Emergente vs. Especificado:

• Ágil: La solución emerge con el tiempo para satisfacer las necesidades empresariales cambiantes. Los detalles evolucionan más cerca del desarrollo, manteniendo la solución flexible.
• Cascada: La solución se define por adelantado para satisfacer una necesidad esperada. Se necesita un control de cambios cuidadoso para mantener la alineación con las necesidades cambiantes.

2. Participantes del Proyecto – Colaborativo y Multifuncional vs. Compartimentado y Especializado:

• Ágil: Los miembros del equipo trabajan juntos con roles amplios, haciendo lo que sea necesario para alcanzar su objetivo compartido. El objetivo es evitar la comunicación a través de documentación y minimizar las transferencias donde sea posible.
• Cascada: Aunque a menudo se observa cierto grado de colaboración, suele centrarse en actividades específicas y especializadas (como la recopilación de requisitos). Los participantes del proyecto tienden a adoptar el enfoque compartimentado de Ingeniería Industrial que dominó el pensamiento del siglo XX, típicamente con comunicación y control gestionados a través de documentación.

3. Gestión – Autoorganizado vs. Gestionado:

• Ágil: Los equipos se organizan y gestionan a sí mismos, decidiendo cómo completar las tareas y ajustando los procesos mientras aprenden.
• Cascada: Los equipos típicamente reciben dirección de los gerentes, quienes deciden qué debe hacerse, por quién y cuándo. Sin embargo, el nivel de detalle en estas instrucciones puede variar según el proyecto o el estilo del gerente.

4. Cambio – Aceptado vs. Resistido:

• Ágil: Debido a que los equipos trabajan hacia objetivos amplios sin definir cada detalle por adelantado, reciben bien los cambios a medida que emergen nuevas necesidades o percepciones.
• Cascada: La gestión del cambio es burocrática y costosa porque requiere análisis exhaustivo, documentación y aprobación. Como resultado, a menudo actúa como una barrera para el cambio necesario.

5. Control basado en: Disciplina Profesional vs. Cumplimiento de Procesos

• Ágil: Depende en gran medida de la competencia, disciplina y autoorganización del equipo. Los miembros del equipo se comprometen entre sí y son propietarios colectivos de las tareas y soluciones.
• Cascada: Utiliza planificación detallada e instrucciones claras. El rol de cada persona se define por adelantado, y el gerente de proyecto coordina las actividades. El éxito depende de seguir el plan y los procesos según fueron diseñados.

Como mencioné anteriormente, depende…

En el mundo complejo de hoy, ejecutar un proyecto completamente ágil o completamente en cascada es poco probable. Con mayor frecuencia, los equipos descubren que cierta agilidad puede agregar valor a un proyecto principalmente en cascada, mientras que algunos elementos de cascada tienen sentido en un proyecto que de otra manera sería ágil. Esta mezcla se llama frecuentemente un enfoque híbrido, situándose en la zona gris entre los dos extremos.

Entonces, la pregunta real de un gerente de proyecto no es "¿Qué método puro debo elegir?" sino más bien "¿Dónde debería ubicarse mi proyecto en el espectro?" Los métodos ágiles prosperan en entornos con alta volatilidad, incertidumbre, complejidad y ambigüedad (VUCA). Por el contrario, los enfoques de cascada generalmente funcionan mejor donde las cosas son más estables, ciertas, simples y claras.

El marco Cynefin puede ayudarte a identificar dónde podría ubicarse tu proyecto en este espectro.

Cynefin, que se pronuncia kuh-nev-in, es una palabra galesa que significa los múltiples factores entrelazados en nuestro entorno y nuestra experiencia que nos influyen (en cómo pensamos, interpretamos y actuamos) de maneras que nunca podremos entender completamente.

En una simplificación excesiva reconocida del Marco Cynefin, el entorno en el que estamos trabajando – en este caso nuestro entorno de proyecto – puede situarse en un espectro caracterizado como claro, complicado, complejo o caótico.

En un entorno de proyecto que es:

• Claro, existe un camino obvio entre el problema y la solución.
• Complicado, el camino entre el problema y la solución podría no ser obvio, pero un buen análisis revelará un camino hacia una solución apropiada.
• Complejo, no es posible identificar un solo camino, incluso con análisis, porque las predicciones solo pueden hacerse basándose en teoría más que en experiencia.
• Caótico, no hay fundamento para la predicción porque hay demasiados factores cambiantes o en conflicto. La única forma de avanzar es a través de la experimentación.

En lo anterior, el dominio claro se presta al enfoque waterfall puro y el dominio caótico requiere agilidad. Los otros dos – los más comunes en la realidad – probablemente se sirven mejor con un enfoque híbrido. Entonces, pregúntate, "¿cuál de los anteriores describe mejor mi entorno de proyecto?" y deja que eso guíe tu selección de enfoque.

También necesitas considerar otras limitaciones impulsadas por las reglas y cultura de tu organización al decidir sobre el enfoque más sensato para tu proyecto. Tratar de hacer que un enfoque waterfall funcione en una cultura caracterizada por la agilidad o un enfoque ágil funcione en una cultura caracterizada por el comando y control causará problemas.

Un enfoque híbrido puede tener más probabilidades de "venderse" y tener éxito.

El Manifiesto Ágil, mejorado para ampliar su aplicabilidad más allá del software, identifica cuatro declaraciones de valor destinadas a orientar a los profesionales hacia comportamientos ágiles. Cualquier persona que aspire a trabajar de manera ágil debe valorar:

Centrándose en los elementos de la izquierda mientras se reconoce el valor de los de la derecha.

Aunque hay debate sobre si el Manifiesto original se aplica completamente en el mundo actual – particularmente en un contexto de software – las declaraciones de valor aún ofrecen orientación útil para la gobernanza de proyectos. Tiene sentido basar la gobernanza de un proyecto ágil en los elementos de la izquierda, y la gobernanza de un proyecto waterfall en los elementos de la derecha.

• Personas y trabajo en equipo: Supervisión y facilitación de la disciplina profesional y la colaboración.
• Entrega de valor empresarial: Enfoque en el valor que apoya las necesidades del negocio, en lugar de cumplir con los requisitos de procesos.
• Participación activa del negocio: Contar con representantes del negocio trabajando estrechamente con el equipo durante todo el proyecto.
• Satisfacer las necesidades actuales en el despliegue: Asegurar que la solución coincida con los requisitos reales del negocio al momento del lanzamiento, incluso si esos requisitos difieren del plan inicial.

• Seguir procesos predefinidos: Asegurar que todos cumplan con los pasos y aprobaciones establecidos.
• Producir documentación predictiva: Desarrollar especificaciones claras y verificar que la solución se alinee con ellas.
• Aprobar cambios adecuadamente: Validar todos los cambios a la documentación original.
• Adherirse a los planes: Asegurar que los planes se mantengan precisos y respondan a los cambios aprobados.

En una configuración híbrida, la gobernanza debe encontrar el equilibrio adecuado entre los elementos ágiles y de cascada. Esto implica adaptar qué partes de cada enfoque tienen más sentido para el contexto específico del proyecto.

El enfoque de entrega de proyectos más efectivo debe estar impulsado por el contexto: tanto la naturaleza del trabajo como el entorno en el que vivirá el proyecto. Desconfía de cualquiera que promueva tanto el enfoque ágil puro como el de cascada puro como una receta universalmente aplicable para el éxito.

Con una referencia final de vuelta al marco Cynefin: describe un estado de Aporía (que significa callejón sin salida) o Confusión y no es un buen lugar donde estar. Lo más probable es que te encuentres, junto con tu proyecto, sufriendo aquí si no puedes o no estás dispuesto a hacer coincidir tu enfoque de proyecto con su contexto y su entorno.

Necesitas pensar por ti mismo, analizar el contexto y actuar en consecuencia. Al hacerlo, tienes la mejor oportunidad de pasar de la Aporía/Confusión a uno de los otros estados donde un enfoque, muy probablemente híbrido, optimizará tu oportunidad de éxito del proyecto.