Waterfall is the project management equivalent of a unicorn! An ideal that doesn’t really exist. I’m talking about waterfall as specified by Winston W. Royce back in 1970. No one really makes software using the waterfall approach even if that’s what they’re telling you. We already explored why Agile and mobile development are such an awesome fit, and today we’re exploring agile v’s waterfall.
In a waterfall approach the team move between the development stages of Analysis, Requirements specification, Design, Implementation, Testing and integration then finally Release flowing from one stage to another from top to bottom, hence the name. In theory all the requirements are specified perfectly up front and detail the complete scope of the project. Everything is designed perfectly based on the requirements, everything implemented and tested without changes. The result is delivered and, according to theory, is exactly what the customer asked for.
Software projects just don’t work like that! So why are we still trying to use waterfall to manage our software projects?
Project managers are responsible for controlling the cost of a project. Fixing the time and scope of a project gives the impression of cost control and risk reduction, but it’s just the illusion of cost certainty and the salesman know it! Why?
Everyone learns about their project as it is built. What you really need comes into focus as you get nearer the end of a project just like driving towards an object in the distance. Requirements are specified in natural languages and are ambiguous, they can’t be made perfect. Even if the language is right it could be read wrongly. Internal and external factors such as market forces can change what you need from your project and are completely out of your control.
In waterfall, you only get a delivery use at the Test and Integration stage. That’s when you really learn about how good your requirements were. By the time you realise that what you asked for isn’t what you really need it will be too late to save your release date. Adding and changing scope increases your costs as extending the date is the only option left as you try to incorporate the for newly discovered value. Project delays and cancellations are rife in the software industry!
That’s when the Change Control Process (CCP) hidden in the small print of the contract kicks in! The CCP lays out the process the contractor is going to use to let you make a changes to your project scope. The CCP sets up the rules of engagement with the project team. Every change will have to be estimated, and it’s impact to the schedule estimated then a decision made whether to move the date will have to be made.
In some organisations moving the date is the last thing that anyone wants to do.The change control process is a huge source of conflict for everyone as you try to get as much of your learning incorporated into the project as possible, pushing the release date in small increments or reducing your test phase and final product quality as you do so.
Each delay increases your costs. The contractor is going to get paid for delivering the original scope and for all the changes you requested. They are effectively getting paid twice, once for the originally specified product and once for the product you really need and doing this far later than you originally expected.
“Wait a minute! There has to be a better way?!” I hear you ask and there is.
The answer is to approach a project in a way that lets learn about what you need before the end of a project and provide a way to incorporate that learning into what your building as you build it. That’s exactly what happens in an agile project.
In agile, you control the scope and regularly get the opportunity to review what is delivered throughout the project. You can control what is built letting you remove or change scope to add newly learned value and protect the delivery date from the very start of the project.
In an agile project, you get to drive the project to the best place possible rather than be an unwilling passenger on a project.
An agile CCP is the backlog. The backlog and the regular planning meetings to review it give you, the client, another two levers to manage your project with. You can choose to add time as you have to do in waterfall but you also get to change and/or remove features. You also control the build order. This does four things for your project:
Increases visibility – An agile project regularly delivers a useable product increment you can learn from. You get to see for yourself how the project is doing and don’t have to wait till the Test phase start using the project. You’ll know how it’s progressing by using the result.
Promotes adaptability – By only selecting the stories for the next product increment at the planning meeting you get to incorporate what you’ve learnt and to change what you need as internal and external factors change. This is usually every 2 weeks.
Delivers useable value early – Start to realise the most important value from your project at the earliest possible moment by ordering the stories with the highest business value to be done and delivered first. Start using the product for the core business stories before the less valuable flows are finished.
Tackles risk early– concentrating on the most risky stories early on in a project means these are done first and which reduces the total risk of the project or you get to cancel a project with the least sunk cost.
By being upfront and encouraging you to manage your learning agile project management promotes an atmosphere of collaboration which is in stark contrast to the waterfall CCP.
That’s part of the reason why, in a recent survey by Scott Ambler on Agile Adoption 86% responded that they have tried the agile approach.
Agile has crossed the chasm and is now the preferred approach in the majority of software projects.
Definitely something to think about when negotiating your next software contract. Do you really want another unicorn or are you ready to take control and adopt agile in your organisation?