Over the years we have come across many proponents of various Agile systems, selling their particular Agile brand with the idea that when a system does not work, dump it for another – their version. In the case of Jeff Sutherland and Ken Schwaber (who founded Scrum) and their legions of Scrum consultants, they frequently recommend that Waterfall users switch to Scrum. In his recent blog titled „Why Waterfall Doesn’t Scale” Jeff cites examples of Waterfall failure and some successes of Scrum. Our concern here is that the title used (Why Waterfall Doesn’t Scale) and the content of the blog because it doesn’t give a complete picture and might give the wrong impression, that Waterfall must be dumped entirely in order to scale. This is just not the case but I will come back to this later.
Does Agile adoption mean to dump your entire system?
The reality of Agile adoption is rarely a case of dumping an entire system for a new one. Let’s be clear here, I’m not talking about high profile project failures here (Scrum adoption might well be a good option in such situations) but rather the vast silent majority who have a system that works to some degree or another and who just want to be better. To these businesses, switching from Waterfall to Scrum or some other specific framework is just nonsense, – totally unnecessary. The purpose of this blog is to address the unmentioned masses, those that want to transition to Agile, just adopting what works for them.
If you are in the position of looking to improve the system in your business then there is no need to switch to some other system like Scrum to make improvements.
Practices and process from any number of Agile methods may well help your business including many of those found in Scrum, but you do not need to adopt any framework in entirety to achieve huge improvements. Many Agile features are common across all Agile frameworks. Choose practices and processes that fit your needs.
Fitting your needs is the critical phrase here, since every business is different. You are the expert in how your business operates, so your first step to improvement is to understand how Agile processes and practices work, as well as how the phycology behind these methods can benefit your business. A great starting point is to read our numerous blogs on the issue. The next step is to understand how to manage and implement Agile, the most important part is how to collaborate and manage work, often referred to as application lifecycle management (ALM) (here’s where we can help), it is largely a work culture change that can be greatly assisted through the use of ALM Software to reinforces work culture change. If this gradual improvement is your path then you will be adopting your own version of hybrid Agile, specifically a pick and mix approach to improvement. Not Scrum or any other brand necessarily, but rather what’s the best fit for your business, progressively augmenting your existing practice and processes on a path to gradual improvement, – the least risky of all Agile adoption methods. If it is not broke do not fix it, just improve it.
Does the increasing number of changing requirements mean the death of your Waterfall project?
Jeff’s blog might give you the impression that an increasing number of changing requirements might mean the death of your Waterfall project. This is a danger; however, Waterfall Development can be argumented with Agile practices and processes, vastly improving how responsive to change a Waterfall development project can be. To prove it we created a Agile Waterfall template for codeBeamer ALM specifically to enable Waterfall projects to become Agile and scalable, enabling practitioners to cope with constantly changing requirements. Do not ditch Waterfall until you have tried codeBeamer ALM and our Agile Waterfall template.
No matter what version of Agile or Agile framework you choose to scale up with, codeBeamer ALM is flexible enough to manage your processes and practices effectively.