It’s becoming more and more obvious, Agile adoption is growing at an incredible rate, and it has been estimated at roughly 10% annually. Not many who have jumped into adopting Agile have asked the question “Why Choose Agile?” To answer that question we also need to look at already existing methodologies that exist, namely Waterfall. Is it to say that waterfall is bad? or inefficient? The answer is, not necessarily. Waterfall has it’s purposes, and when applied properly it provides all the benefits that are expected from a project that is using it…the key words here “applied properly.” The problem with Agile adoption is that it’s considered to be relatively new, and more often than not, applied incorrectly. So here are the key differences that can help understand and promote the transition from Waterfall to Agile.
1. Process Control
In Waterfall you have phase gates that are defined similar to milestones, and they occur at every stage of the process. For each of those stages there is a request to approve each gate before it is started, furthermore the scope is defined at the beginning and can’t be changed without major impacts. Sure, you can issue a change request, but that likely changes the entire balance of the budget, resources, and timeline. In Agile on the other hand, there is empirical process control where you are redefining the scope based on priority of the preset period of a sprint (2 – 4 weeks). In this way Agile allows the highest value, business needs, and ROI that are realigned regularly. Whereas in Waterfall, you cannot and there is little possibility to change the scope mid-course. Agile therefore allows a team or business to respond to the immediate business needs of their client, thus providing higher value consistently.
2. Triple Constraints and the Perception of Success
The main components to any project are Scope, Time (Budget), and Cost. With Waterfall the Scope is typically fixed, whereby Time and Cost are flexible. Problem though is that even with a Time and Cost change there really isn’t any easy way to determine a cutoff point, and stop teams in the middle of the project while waiting for a client to make a decision. This means that in order for a project to be successful in Waterfall, ideally all 3 constraints would typically need to stay fixed with the addition of change requests. Agile on the other hand provides a way to easily fix Time and Cost while making Scope flexible. Waterfall-minded people will right away spark the question “Will all the scope be completed though?” The answer of course is “not necessarily and that’s ok.” The reason for this is that it doesn’t matter, because in Agile you are already delivering the highest value from your Time and Cost that could ever be delivered from a Waterfall project. Hard to believe at first, but for those who have completed at lease one Agile project, they know this can be attained since the highest priority/value scope is being delivered.
3. Profitability and Customer Retention
Most Waterfall-minded companies will measure their margins from project to project with the intent that each project will need to be profitable. But what happens when a project slips through the cracks and goes into the negative? Going Agile will allow for higher customer retention, after all when you provide higher value through implementing current trends in innovation, accurate and faster delivery dates, customers are more likely to stay with you for the long run. The positive side-effect to this is higher motivation within your teams. This is an added benefit to both supplier and customer since learning curves (performance states) stay intact and will very likely improve when the same team members work together for longer periods of time.
4. Delivery Schedules
Waterfall depends on the entire project to be completed before it can be delivered. This certainly gives the impression to both the development team and the client that the project is going on without end. This of course applies to projects that last longer than a few months. But with Agile, you already built in the expectation that delivery is possible at the end of each Sprint, even though in some cases you may choose not to. The main issue that has never been resolved but almost always happens in Waterfall, is the moment there’s a change request, the client asks for more scope and although they would be willing to pay more for it, they want the delivery date to stay the same. Why not just deliver in increments the way that Agile already requires you to?
There are many more reasons why you may want to choose Agile over Waterfall, but most need to be shown rather than be told what those benefits are. The key point to consider is that Agile adoption should be concrete, and should come with a fully committed paradigm shift in management and teams that are looking to implement all the necessary mindsets and tools that are needed. The most likely and best approach to adopting Agile however, is to jump into it completely and use Agile in itself to inspect and adapt. Taking on a half waterfall and half agile approach will certainly lead to adoption failure.
[Image courtesy of Stuart Miles at FreeDigitalPhotos.net]
Share this:
This work is licensed under a Creative Commons Attribution 4.0 International License.
