Waterfall vs. Agile: Choosing the Right Project Management Method

Waterfall Methodology

Waterfall Methodology is used by most federal and state agencies and businesses that rely on these agencies. It is also used by the vast majority of projects that are not software-centric. It utilizes a phased and structured approach to software development. It assumes every requirement of a project can be identified before design and coding begins. It tells the team's developers everything that needs to be in the software before it is up and running. It follows a waterfall approach. Development teams only have one chance to get each aspect of a project right.

Steps in Waterfall Methodology

1. Requirements Analysis
2. Design
3. Coding
4. Integration
5. Testing
6. Deployment

Traditional "waterfall" development depends on a perfect understanding of the product requirements at the outset and minimal errors in executing each phase.

Agile Methodology

Agile Methodology provides opportunities to assess the direction throughout the development lifecycle. It uses regular cadences of work, known as Sprints, at the end of which teams must present a potentially shippable product increment. It focuses on the repetition of abbreviated work cycles as well as the functional product they yield. The team stops and re-evaluates the direction of a project every two weeks, affording time to steer it in another direction as required. In an agile paradigm, every aspect of development (requirements, design, etc.) is continually revisited.

Comparing Agile and Traditional Project Management

Agile Project Management

1. Teams are self-directed and are free to accomplish deliverables as they choose, as long as they follow agreed-upon rules.
2. Project requirements are developed within the process as needs and uses emerge. This could mean that the final outcome is different from the one envisaged at the outset.
3. User testing and customer feedback happen constantly. It's easy to learn from mistakes, implement feedback, and evolve deliverables. However, the constant testing needed for this is labor-intensive, and it can be difficult to manage if users are not engaged.
4. Teams constantly assess the scope and direction of their product or project. This means that they can change direction at any time in the process to make sure that their product will meet changing needs. Because of this, however, it can be difficult to write a business case at the outset because the final outcome is not fully known.

Traditional Project Management

1. Teams are typically tightly controlled by a project manager. They work to detailed schedules agreed upon at the outset.
2. Project requirements are identified before the project begins. This can sometimes lead to "scope creep" because stakeholders often ask for more than they need, "just in case."
3. User testing and customer feedback take place towards the end of the project when everything has been designed and implemented. This can mean that problems can emerge after the release, sometimes leading to expensive fixes and even public recalls.
4. Teams work on a final product that can be delivered some time – often months or years – after the project begins. Sometimes, the end product or project is no longer relevant because business or customer needs have changed.

Conclusion

Ultimately, traditional project management is often best in a stable environment where a defined deliverable is needed for a fixed budget. Agile is often best where the end product is uncertain or where the environment is changing fast.