Join Kelley O'Connell for an in-depth discussion in this video Agile vs. waterfall, part of Transitioning from Waterfall to Agile Project Management.
- View Offline
- Adoption of Agile practices in project management is growing at an astonishing rate- roughly 10% per year. Why is that? What does everyone think they're going to gain? Waterfall project management has served us well for many years. Why change now? Well, Waterfall project management is effective. There's absolutely nothing wrong with it, and many companies continue to use it. The key difference between Agile and Waterfall is the type of process control in use.
In Waterfall, you're using defined process controls also known as phase gates. There are phase gates at every stage of the process. What this means is that at each step you're asking for approval to move to the next phase. The scope is defined at the beginning and can't be changed once development starts. The difference with Agile is you're re-setting scope and priority every two to four weeks. You're doing this to ensure that your work is aligned to the highest value business needs all the time.
Let's look at an example. Let's say your company, the best bank around, is going to implement a mobile app for customers to view their account balances. Rumor has it that your main competitor, the bank across town, is going to release their own mobile app. Time is of the essence. Using Waterfall, you would write a project charter, define the mobile app exactly, get approval, set the schedule precisely, get approval again, set up a project team, start development.
These phase gates alone have likely used up at least 30 days� time. This is the Waterfall defined process control for getting started. In Agile, it would look like this. Work with a business sponsor, define the mobile app vision, set up a team, and start developing. Can you see the difference between these lists? The project overhead in Agile is much lower, saving time getting from idea to execution. This is empirical process control.
Your commitment here is merely to say this is what we think will deliver value. We'll inspect and adapt as we go along to ensure that what we deliver really is valuable. Let's take our example a little further. What if the bank across town released their mobile app and it has the ability for customers to transfer funds from one account to another? Is it still okay to release an app that allows only viewing balances? Probably not. So how would each methodology handle this? Well in Waterfall, you're going to complete a project change request form, pull your development team off their work to estimate it exactly, figure out how much more it will cost, estimate how much longer it will take, present your change request for approval, re-baseline your schedule, cost, and scope, and of course, have your business partner sign off that they won't ask for anything else.
This phase gate will add another two to four weeks before your team can begin working on transferring money between accounts. Okay, so what would that look like in Agile? Well, when you learned what the bank across town was doing, you'd decide with your business partner how high a priority this changes and add the work to the backlog. Then you'd continue developing. You have the freedom to adapt to changing business priorities right away in agile. This is empirical process control.
Instead of using defined processes for every possible situation, you're frequently inspecting the work and the business needs so that you can focus on what is truly valuable right now. The number one key difference then between Waterfall and Agile is the ability to respond to the evolving business needs immediately. This is the big deal. This is why so many companies are adopting Agile.
Lynda.com is a PMI Registered Education Provider. This course qualifies for professional development units (PDUs). To view the activity and PDU details for this course, click here.
The PMI Registered Education Provider logo is a registered mark of the Project Management Institute, Inc.
- Making the agile paradigm shift
- Testing agile practices
- Obtaining support
- Building the team
- Planning basics
- Sprint planning and execution
- Expanding the pilot