It is likely that if you are involved in modern software development you will be using an agile approach, most likely Scrum or Kanban, but it’s also likely that the executive team that have requested the software will want to know in some detail what they are buying up front. This can lead to “Wagile”, a hybrid project management approach that often combines the worst elements of both Waterfall and Agile methodologies, and should be avoided, if not, at the very least, managed with caution.

In traditional Waterfall methodologies, the project is divided into distinct phases, and each phase must be completed before moving on to the next. Agile, on the other hand, is an iterative approach that focuses on collaboration and flexibility, allowing for changes and adaptations as the project progresses.

In a Wagile approach, the structured planning and requirements definition stages of Waterfall are generally conducted first, laying down the fundamental framework of the project. This is then followed by iterative cycles of development, testing, and feedback, much like Agile. This hybrid method aims to take advantage of the strengths of both Waterfall (e.g., thorough planning, clear milestones) and Agile (e.g., flexibility, adaptability).

Wagile is often seen as a compromise solution for organizations transitioning from a Waterfall approach to Agile or for projects where neither pure Waterfall nor pure Agile would be entirely appropriate due to various constraints or requirements. However, critics argue that Wagile can sometimes lead to the worst of both worlds—lacking both the rigid structure of Waterfall and the flexibility of Agile—if not implemented carefully.