Waterfall and agile project management styles have strengths and weaknesses. Both are suitable in specific situations. Know the strengths and weaknesses, and when to use one style over another for successful project management.
Many project management professionals inquire about “agile project management”. Since Agile is a bit difficult to describe by itself, it is better to outline the more traditional Waterfall approach, then contrast Agile’s approach to highlight the distinctions, focusing on the reasons certain aspects are different from Waterfall.
A premise for any methodology: To accomplish work in the form of a project, it’s important for the team to agree on how they’re going to work together and sequence the work that must be completed to realize the project’s goals.
In project management, there are two primary approaches to accomplishing work: Waterfall and Agile. Currently, both approaches are used to solve problems and produce deliverables (artifacts / work products). Each approach has its strengths and weaknesses and is suited to certain types of projects. Understanding each method is essential for a successful delivery, since using the right (or wrong) approach can affect the nature of interaction with the team, and the actual project’s results.
The Waterfall methodology has its roots in the construction industry. In this style, project work is broken into sequences of activities, with coordinated collections of activities grouped into phases. Each phase is completed before the project team moves to the next phase.
For example, the project requirements are defined, the team designs and builds to those requirements, the solution is tested and then released to the customer. One phase is completed before flowing into and starting the next phase, hence the title waterfall.
In construction, this sequence makes sense. The customers and architect decide the type and shape of the building. The planning is completed before the team starts construction. Once the building is completed, the customer and construction foreman perform a walk-through of the building, and test all the various sub-systems (e.g., electrical switches, kitchens, elevators, alarm systems, sinks, etc.). After receiving approval from everyone, the building is released to the customer.
A waterfall approach is a great way to manage projects when the requirements generally are well known at the beginning of the project. Thinking back to our construction example, planning in the beginning is highly recommended, since making changes once construction has begun can become very expensive. Imagine planning for a 2-floor building, then when halfway through construction, the customer decides to change the height to 10 floors. Most likely, the existing construction will need to be demolished before construction can start on the 10-floor building.
Software development is different:
As software development became more commonplace, the natural tendency was to apply waterfall approaches to software development. This method worked in the beginning but was awkward at best. As software projects became larger and more complex, problems with a waterfall approach become more apparent and obvious.
In February 2001, a group of seventeen software developers wanted to improve the software development process and solve the problems listed below, among other issues they were experiencing. They believed using a waterfall approach was adding a lot of overhead, time, cost and general waste to the process. The waste was slowing down development and causing a misalignment between the requirements and delivered products. Software bugs and defects had begun to grow, further consuming additional new development time. The group wrote a Manifesto for Agile Software Development, describing four values and twelve driving principles to help improve software development. The output of their meeting and work became the foundation of the Agile project management methodology. More details can be found at their site http://agilemanifesto.org.
For construction projects, the cost of rework is very high, so the more advance planning, the less chance for costly changes due to poor planning.
By contrast, changes to software can be significantly less expensive than construction projects. In addition, many software changes can be made after a product is released. Think of all the various app updates that are sent daily to smartphones. These enhancements come after customers use the software and add their own ideas to future enhancements.
Agile takes the approach that software should be built in small pieces, periodically reviewed and adjusted, based on the periodic feedback. The final result will align more closely with the customer’s needs and increase customers’ satisfaction.
Following are four main issues of using waterfall to manage software development projects, and an explanation of how Agile attempts to solve these issues.
- Timely Feedback: Teams do not receive timely feedback from customers
- Rapid Change: Teams have difficulty incorporating changes quickly
- Elaborative Design: Teams do not have enough information to fully design a solution up front
- Team Structure and Dynamics: Teams struggle communicating quickly and efficiently
In waterfall, customers do not see the deliverable until nearly the end of the project. For example, in a two-year waterfall project, customers may not see any meaningful demonstrations until 18 months into the project. Any feedback they give many not be included in the final product, which can lead to customer frustration. Even worse, if the customers’ requirements change over those 18 months, it becomes difficult for those new and/or adjusted requirements to be incorporated. The risk is the final product will not align to what the customers now want.
In Agile, these customer demonstrations typically occur every two weeks, although some teams use three or four-week intervals, sometimes called Sprints. As customers see these periodic presentations, they provide feedback regularly in the process, keeping the team from spending long periods of time creating something that is no longer relevant. The timely feedback helps shape the final results.
With a much more rapid feedback cycle, there are more changes that come in continually. In waterfall, a formal change management process is created to handle any changes. The team identifies the change and estimates the impact to cost, schedule and resources. The team presents the change to a Change Board and asks the customers about the change. The tendency is to treat changes as an exception instead of a necessary benefit. Yet, if the changes are closer to what the customer wants, or if customers change their mind, the changes are an important factor that affects overall customers’ satisfaction. Additionally, since changes and feedback come back much sooner in Agile versus waterfall, the traditional Change Management process must be simplified to keep up with the changes.
With Agile projects, the traditional Change Management process is too cumbersome to manage a lot of changes. Therefore, Agile embraces change as part of the on-going process instead of treating change as an exception process. The overall scope of an Agile project may go through a formal change management process, but nearly all the design and implementation details are addressed directly within the team. As ideas are exchanged, discussions about changes occur rapidly as well, allowing the team to adjust to new ideas quickly, hence the idea of being Agile.
With all this feedback and rapid change occurring, the importance and value of upfront planning is diminished. Since ideas and changes come throughout the project, there is less value in initial planning. Instead, the design is elaborated over time. This move to reduced planning can be unsettling for people who are used to reviewing a design document to get the big picture. Upon reflection, the Waterfall method’s initial design document is probably less accurate than most people realize. In waterfall, even with change management, the design document can become outdated. If the team attempts to keep the design document current, development can slow due to possible issues between developer and business analyst, reducing productivity.
With Agile, developers create code and related documentation at the same time, minimizing the amount of time needed for documentation maintenance. Therefore, the developer can produce more value for the business, especially if the business analyst has been trained in Agile methods.
Team Structure and Dynamics:
An Agile team structure is typically different than a waterfall project. To be successful, Agile team members must become more accountable with their own work as well as become invested in the entire team’s success. The entire team is now responsible for delivery, which can be a very different mindset from Waterfall. In Waterfall, typically the Project Manager is held accountable for delivery and team members are held accountable only for their individual work.
Agile teams add two new roles, Product Owner and Scrum Master. The Product Owner is the business person responsible to describe the systems functionality from a user perspective. The Product Owner is embedded into the team as much as possible. In many cases, they interact with the team on a daily basis, which allows the rapid feedback and adjustments to occur quickly, as described above.
The other new role, Scrum Master, is responsible to help the team develop its working processes and ensure they align to the Agile Manifesto as much as possible. The goal is to help people form a high performing and highly motivated team. A Waterfall Project Manager typically focuses up from the team, where the Scrum Master focuses more on the team’s maturity.
To be clear, there is still a need for waterfall. Projects that have somewhat, or well-defined, requirements are better suited for waterfall. Some Agile project management trainers use the waterfall method to plan Agile classes. Since they know all the various pieces to prepare for a class, they hold a short planning session and build the waterfall plan initially for each class.
The Project Management industry has been going through a transition with the addition of Agile as an approach to projects. Agile is showing itself to be better suited to handle the flexibility and rapid change needed for software development. As Agile continues to become more common, those who work with, in or around projects, will need to learn about these changes and adapt. Be aware of the methodology used for projects and realize the approach and team dynamics may be very different.