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.

 

Historia de Agile

Las metodologías Agile aparecen durante la década de los 90. En aquellos años, muchas empresas buscaban una metodología que les permitiese ofrecer al mercado sus productos de forma más rápida y eficiente, adaptándose continuamente a las necesidades de los clientes. En un entorno muy competitivo las empresas además de crear nuevos productos innovadores también deben incorporar la innovación en los procesos, metodologías y formas de trabajo (Ways of Working, WoW) que utilizan para desarrollar sus nuevos productos.

En 2001 los líderes y creadores de algunos de esas nuevas metodologías o procesos se juntaron para establecer unas bases comunes para dichos métodos y de ese modo resolver el problema que muchas de esas empresas tenían para poder desarrollar sus nuevos productos. Ese problema estaba basado en que las empresas estaban tan enfocadas en planificar y documentar sus proyectos, que perdían la visión de lo que realmente importaba, satisfacer las necesidades de los clientes.

Basándose en este insight, los mencionados líderes definieron el Manifiesto Agile para guiar a otros en lo que ellos consideraban que era realmente importante cuando se desarrollaba software, disponer de un proceso flexible y enfocado en las personas (tanto los usuarios de sus productos, como las propias personas que formaban los equipos que creaban esos productos), por encima de los productos finales o los entregables.

Es importante destacar que aunque Agile se definió originalmente para el desarrollo de software, no solo se aplica en proyectos software, sino que sus valores, principios y marcos de trabajo son aplicados y utilizados con éxito en otras muchas industrias. Agile se aplica también en aeronáutica, salud, educación, finanzas, etc. Además, hay que tener en cuenta que los métodos Agile están muy cercanos a los principios de Lean Manufacturing (ideado en 1930 en la factoría de coches de Toyota).

El término Agile hace referencia a moverse de forma rápida y fácil, a flexibilidad y la voluntad y la capacidad de adaptarse rápidamente al cambio. Los proyectos que adoptan una gestión de proyecto Agile utilizan una aproximación iterativa para el desarrollo de los mismos, que implica que los procesos dentro del proyecto se repiten sucesivamente durante el ciclo de vida del proyecto.

Si consideramos Agile en la gestión de proyectos, tenemos Agile Project Management, una forma de llevar a cabo la gestión de proyectos y equipos basada en el Manifiesto Agile, un conjunto de 4 valores y 12 principios que definen la forma de pensar (mindset) que todos los equipos Agile deberían seguir.

Para conseguir esto, el equipo opera en múltiples bloques de tiempo reducido, que se denominan iteraciones. Cada una de esas iteraciones se repite en función del feedback recibido, y en cada una de ellas el equipo aborda un subconjunto de todas las actividades del proyecto y lleva a cabo todo el trabajo requerido para completar ese entregable.

El mundo, los mercados y los usuarios son inciertos, y por tanto impredecibles, y eso implica que en cualquier momento debemos poder adaptarnos a esos cambios que se van produciendo (leer también Agile en entornos VUCA). Esta aproximación iterativa permite al proyecto avanzar rápidamente y a su vez adaptarse a los posibles cambios que puedan aparecer como fruto de esas variaciones y del feedback recibido.

De este modo, el término “Agile” significa flexibilidad, repetición y apertura al cambio durante el proceso, cuando este es necesario. Agile se encarga de recibir feedback del mercado y los clientes con frecuencia de modo que se eviten situaciones habituales con metodologías Waterfall donde la empresa está trabajando en una funcionalidad determinada y cuando la pone en el mercado ha pasado tanto tiempo desde que se definió el producto los cambios que se han producido (en el entorno, en las necesidades del cliente, etc) hacen que la funcionalidad finalmente entregada no es la que el cliente realmente quiere o necesita en el momento actual. Si hay un diálogo más constante y fluido con los clientes es más fácil y rápido reorientar el desarrollo hacia la funcionalidad que realmente es esperada por los clientes, a medida que van viendo el avance.

El mindset Agile también incluye buscar las formas de trabajo más eficientes, adaptando los procesos sin reducir la calidad o el valor del producto desarrollado y para ello la clave es reducir o eliminar todo aquello que no es necesario, tal como aboga Lean. Por tanto, volvemos a ver la sincronía entre Lean y Agile.