So people keep talking about the Agile – Waterfall dichotomy. About agile and un-agile practices. I decided to have an unscientific look at what Agile isn’t. If there is a true dichotomy between Agile and Waterfall, then things opposite of Agile should be either entirely out of scope for projects and software development or they should be characteristic of Waterfall methods. And since anyone would bother to mention them in the context of Agile, one would assume that this would be because they are distinguishing between Agile and Waterfall.
Method
[bibshow file=http://www.citeulike.org/bibtex/user/greger/]
I searched Google Scholar for that phrase. I scanned the first four pages for useful results. I excluded results which had nothing to do with projects or software development. I also excluded results where it was clear that the authors had not meant to say what agile is not, e.g. double negations.
Results – Agile is not …
Here are the on-topic, top results:
- Agile is not adopted simultaneously by all teams [bibcite key=”citeulike:12798206″]
- Agile is not code and fix [bibcite key=”citeulike:12798229″]
- Agile is not a choice for cost leaders [bibcite key=”citeulike:5931196″]
- Agile is not new [bibcite key=”citeulike:12798341″]
- Agile is not ad hoc link
- Agile is not a distinct, well-defined process [bibcite key=”citeulike:6930173″]
- Agile is not appropriate [bibcite key=”citeulike:12798375″]
- Agile is not enough [bibcite key=”citeulike:12798346,citeulike:9338314″]
- Agile is not consciously created but instead just emerges [bibcite key=”citeulike:9337598″]
- Agile is not a silver bullet [bibcite key=”citeulike:12798347,citeulike:12798350″]
- Agile is not an excuse for unilateral behaviour [bibcite key=”citeulike:7373711″]
- Agile is not about perfectionism [bibcite key=”citeulike:12798351″]
- Agile is not about small-scale continuous improvements [bibcite key=”citeulike:12798353″]
- Agile is not optimised for resource-constrained environments (such as that represented by the DySCAS middleware) [bibcite key=”citeulike:12798356″]
- Agile is not the absence of process [bibcite key=”citeulike:12798357″]
Agile is …
Source: Wikimedia | CC BY SA 3.0Agile Software Development methodology. CC BY-SA 3.0
If something is not something it follows that it might be the opposite of that which it is not. So if the above list of what “Agile isn’t” is largely correct, what then are the opposites which might describe what Agile is?
Agile is a set of practices and processes which are adopted incrementally in an organization. Agile is disciplined, but not to the point of perfectionism. That means that Agile is far removed from ad hoc, code and fix, unilateral behavior and other symptoms of cowboy coding. Agile is based on older methods, it does not reinvent the wheel — it refines it. Agile will not solve all problems and while it may be introduced incrementally, a full agile implementation might be a step-change away from where you are now.
Waterfall is …
Are these other things characteristic of Waterfall? Would anyone agree that “waterfall is adopted simultaneously be all teams” or that “waterfall is code and fix”? I tried negating all of the “agile is not” sentences above and as far as I can see, only one of them can possibly be negated to achieve something that at least some people may agree is true of waterfall: “waterfall is for cost leaders”. Research shows that this is not true, still I know that many people believe that it is correct.
Conclusion
This short and simple investigation into what Agile is and isn’t clearly indicates that whatever the opposite of agile is, it certainly isn’t waterfall.
References
[/bibshow]
Image sources
- Agile Software Development methodology: Wikimedia | CC BY SA 3.0
- Agile_Software_Development_methodology: Wikimedia Commons | CC BY SA 3.0
Pingback: Key Agile Practices You Need - Greger Wikstrand
Great work. We’re starting a major agile transition at a 1st tier defense firm. I’ll include this blog post in our “read ahead reference package.” I’ll give some thought about how the current acquisition model in DODI 5000.02 matches up against this paradigm and were programs get in trouble and where the myth of “if we just used agile our problems would be solved,” is a fallacy.
Thanks for the stimulating contribution to the multi-billion problem of SWDev in Space and Defense
Thanks for sharing. I’m very happy you found this useful and will share it with your colleagues. I would appreciate any comment they might have as well.
Of course, our domain is large architecture centric IT and embedded system of systems. Conference in June will include reference to this material.
As well all the references added to the growing list being used by US DOD for our new Agile+EVM guidebook coming in late summer.
This is what make me smile and cry at the same time for the utter nonsense of #NoEstimates