This could be seen as a “dated” post as the debate about Wagile is certainly not new, but in my experience, many companies go full tilt on projects using Agile. Some come up roses and others fail miserably. If the latter is true, they disavow Agile completely and go back to the “tried and true” methodology of Waterfall. Some projects require Waterfall but companies try to gain the benefits of Agile when possible. So, I would argue there is still room for a hybrid approach. But if you are working in the IT space, the goal would be as close to Agile as you can get. But often times, Wagile is a reality in your business model. Some people refer to this as an attempt at doing agile, when it is in fact a mini waterfall. However, I think it is a bit more complex than that.
To see what you could achieve with both, you have to examine the pros and cons of each method.
Pros of the Waterfall model:
- Regulated – Waterfall has a set of clear gates which are closely monitored by project managers and others. The gates, as well as the entire project, are closely planned and budgeted usually around milestones.
- Regimented – Waterfall is usually closely controlled. This allows for teams to report effectively
Cons of the Waterfall model:
- Projects delivered using Waterfall typically won’t show any system progress until the build is complete.
- By the end of a build, the project is more than halfway complete, so viewing what has been built is incredibly risky waiting for the end of the build will not allow enough time for buy-in to the changes coming from the implementation.
Agile and its not so distant relative, Scrum offer a different approach to project management compared to Waterfall. The focus of Agile is on collaboration between self-organizing, cross-functional teams. These teams work on a time- boxed set of deliverables, which will deliver success or failure by the end of the project based on an early understanding of what should be achieved.
Pros of using the Agile model:
- Speed – Theoretically, Agile should see projects through to completion more quickly.
- Technical & Functional – Agile allows the technical and functional parts of the project to lead the development of the solution.
Cons of the Agile model:
- Scope – The project scope can spiral out of control. If a Scrum master and/or product owner is/are not strong, then the technical team may lack clear direction as to what they are delivering. As such, scope changes can create significant chance of project failure.
- Cost – Although time and cost are closely linked, the innovations that come from Agile and potential scope creep can cause costs to rise.
“Wagile” Methodology (and other Agile-Waterfall hybrids)
The Wagile approach attempts to combine the best features of both Agile and Waterfall by adopting a few Agile practices, such as short iterations, the daily stand-up or continuous integration, on top of a Waterfall model (or vice versa). That said, by leveraging the best of both practices, depending on the project, it can end up being the superior project management methodology.
When using Wagile (or Scumfall) the approach that makes more sense to me is more Waterfall that allows time for iterations and demos.
Pros of using the Wagile model:
- Iterations – Allows for iterations in design and build, even if the approach is mostly Waterfall. The benefit is that the system can be built and then changed throughout the project to ensure buy-in to the final design and a closer match with the organization’s strategy.
- Plans – Planning is done early and plans are reviewed often to ensure adherence to the timeline. Early adherence to a project plan and following it through is essential.
- The Best of Both – Wagile allows the project to take the best from both Waterfall and Agile, including but not limited to: understanding the business need, alignment of budget/scope/ time, and iterations to reduce risk of scope creep.
- Wagile also encourages continuous communication and involvement from all parts of the project to instill ownership among team members. If your PM tool has social functions, they really come into play here.
Cons of using the Wagile model:
- Clarity – As a non-traditional approach, Wagile needs to be identified early and the process agreed upon by all parties. For example if the team is expecting to have a product backlog and the project manager is expecting to test at a specific time, this method may not work. Communication regardless of the approach, is always essential, the roles just need to be clearly defined when using this method.
- The Wagile approach attempts to combine the best features of both Agile and Waterfall by adopting a few Agile practices, such as short iterations, the daily stand-up or continuous integration, on top of a Waterfall model (or vice versa). In theory it attempts to leverage the best of both practices.
When using this method, the model I prefer actually begins in Waterfall where you have discovery, but when you get to the design phase, you bring in agile methodology. By analyzing, responding and changing during the design phase, you still allow time for iterations and demos. When you reach the build phase, you build, demo and fine tune. Again time for iterations and demos are a natural build in here allowing the team to drive these essential phases. QA also gets built into this cycle. After this you move to UAT and launch.
That would be a perfect world scenario of Wagile. Often that doesn’t happen, but if you business model won’t allow for clear Agile, if you can bring in the self-functioning team and iterative approach while still keeping a handle on the timeline, it is often the best approach. Whatever the approach the decision about methodology in the project or the business model should not be taken lightly. It is the foundation upon which projects succeed or fail.