Algunas diferencias entre Agile y Waterfall

En este post vamos a comentar algunas diferencias entre Agile y Waterfall en tres aspectos relevantes en la gestión de proyectos, los requisitos, la documentación y los entregables.

• Los Requisitos. Los Requisitos de un proyecto como las condiciones que debe satisfacer o las tareas que se deben completar para dar por concluido un proyecto. También se pueden entender como el conjunto de criterios dentro el alcance, o la lista de especificaciones que se deben cumplir en el proyecto.
• En Waterfall, probablemente necesitarás un documento que enumerará el alcance y los requisitos del producto. Necesitarás un plan de proyecto y para ello deberás disponer de un equipo de gente que se encargará de escribir y aprobar formalmente esos planes. Además, deberás establecer un board para el control de cambios con un proceso riguroso para gestionar cualquier cambio que se solicite o se requiera. Todo esto está pensado para proteger al equipo de crear algo que el cliente o los stakeholders no quieran y para minimizar cualquier cambio que pueda poner en riesgo el proyecto. Los planes de proyecto aprobados formalmente funcionan bien cuando la definición de los productos finales deseados está bien acotada y es conocida de antemano. Por ejemplo, un proyecto que tiene unos requisitos y objetivos claros basados en regulación existente. Pero si ese no es el caso, un equipo Waterfall corre el riesgo de crear un entregable completo, para inmediatamente descubrir que el cliente no necesita lo que se ha desarrollado.
• En Agile, los requisitos se tratan de una forma dinámica y pueden cambiar a medida que el equipo recibe feedback y dispone de nueva información. Inicialmente, en el lanzamiento del proyecto, hay definido un conjunto de requisitos, y ese conjunto o lista (o backlog) de requisitos crece y cambia constantemente a lo largo del proyecto. El equipo tiene que trabajar con los stakeholders para establecer las prioridades de esos requisitos, de modo que empiecen trabajando por los más prioritarios, que pueden ser los que aportan más valor o los más urgentes. El equipo seguirá trabajando en esos requisitos bajando de forma iterativa en la lista de prioridad, a medida que los primeros se van entregando. Al final de cada iteración, el equipo recibe feedback rápida y frecuentemente, y puede llevar a cabo los ajustes necesarios en los requisitos que todavía están en la lista antes de continuar con la siguiente iteración.

• La Documentación. Todos los proyectos necesitan documentación: planes de proyecto, mapas de stakeholders, planificaciones, contratos, etc.
• Los proyectos Waterfall requieren muchísima documentación, porque hay muchos traspasos (handovers) entre fases y entre los diferentes equipos de trabajo del proyecto. Además, como el trabajo se entrega en lotes muy grandes, es necesario crear mucha documentación en cada etapa del proyecto.
• En Agile también se requiere documentación. Sin embargo, en Agile se da prioridad a las conversaciones entre personas en tiempo real, lo que implica que la documentación tiene un propósito diferente. Además, como el trabajo se va realizando en pequeñas partes, se necesita menos documentación en cada una de las etapas del proyecto. En lugar de laboriosos documentos formales con una gestión de cambios y un proceso de aprobación rigurosos, los documentos son más cortos y solo necesitan el nivel de detalle suficiente para su propósito. Estos documentos solo incluyen la información necesaria para que el lector conozca qué es lo que tiene que hacer para completar su trabajo, y solo se escriben si son necesarios.

• Los Entregables (Deliverables) configuran el tercer elemento. Los deliverables son los resultados tangibles de un proyecto.
• En los proyectos Waterfall los deliverables se entregan al final del proyecto. La release final del proyecto es un gran evento.
• En cambio, en Agile hay releases más frecuentes y de menor envergadura. Cuando hay mucha incertidumbre en un proyecto, como por ejemplo, en un nuevo mercado o sector Agile permite recibir feedback e ir tuneando el proyecto a medida que se va avanzando. Si se carece de ese feedback es posible entregar al final de un proyecto waterfall algo que el cliente realmente no quiere.

Estas "simples" diferencias marcan un abismo entre la gestión de proyectos Waterfall y Agile

Agile en entornos VUCA

Debemos recordar que Agile se centra en entregar valor en un mundo con altos niveles de incertidumbre, riesgo y competencia. Prepara a los equipos para reaccionar rápidamente cuando cuentan con nueva información, oportunidades de negocio o nuevas tecnologías.

Agile, tal como ya comentamos en otros posts, se adapta mejor para proyectos y sectores que se ven afectados por numerosos cambios o incluso los fomentan ellos mismos. Pero incluso en algunos sectores que podríamos pensar que son bastante estables y que no están sujetos a tantos cambios, podemos encontrarnos con que no son tan fijos y que se ven sometidos a modificaciones, por ejemplo, en regulación, legislación, desastres naturales y otros imprevistos.

Una cosa que nos han enseñado los 2020 y 2021 y concretamente la pandemia de COVID-19, es que ningún sector, industria, empresa, ni persona es inmune al cambio y a la incertidumbre.

 

Y aquí quiero introducir el concepto de VUCA. VUCA es el acrónimo de Volatility (volatilidad), Uncertainty (incertidumbre), Complexity (complejidad) y Ambiguity (ambigüedad). VUCA define las condiciones que afectan a una organización en un mundo complejo y cambiante.

 

Qué significa cada uno de estos conceptos:

• Volatilidad. La velocidad de cambio y rotación en un negocio o situación. En un proyecto de alta volatilidad es importante estar atento a las próximas disrupciones que se puedan producir y cuándo se podrían dar.
• Incertidumbre. La falta de predictibilidad. En un entorno de gran incertidumbre es muy difícil crear planes de futuro que no estén basado en muchas hipótesis que pueden, al final, ser incorrectas.
• Complejidad. El número de fuerzas, problemas, cuestiones, organizaciones y factores que están interrelacionados y que pueden influir en el proyecto.
• Ambigüedad. La posibilidad de malinterpretar las condiciones y las causas de determinados eventos o circunstancias.

Adoptar una metodología Agile incrementa las posibilidades de éxito en los proyectos y los negocios a pesar de la incertidumbre. Para poder hacer una gestión eficiente de los proyectos es necesario entender correctamente el entorno. Cuando iniciamos un proyecto es muy útil examinar el entorno y las condiciones que existen alrededor, antes de decidir cuál es la mejor aproximación para abordar el proyecto.

Si el entorno se puede enmarcar como VUCA entonces es un buen candidato para aplicar Agile, y aunque no es la solución perfecta para solventar la volatilidad, la incertidumbre, la complejidad y la ambigüedad, te ayudará a conseguir los mejores resultados mitigando los riesgos que se presentan, ya que Agile te proporciona herramientas y sistemas para enfrentarte y adaptarte a VUCA.