The Case For Agile Over Waterfall

This article came about as the result of a recent trip I made to a customer. I was presenting on TFS and made the, oft repeated, statement that Agile is better than Waterfall. Now I have to admit that I have never really had anyone challenge me on this assumption since most of the people I know just accept this as truth. On this particular day there were a couple of project managers in the audience and they were none too pleased about my assertion. For the rest of the hour, we went back and forth on the issue. Following are a few of exchanges to the best of my recollection:

 

Exchange 1

Project managers: “You can’t say that agile is better than waterfall, it simply isn’t true.”

Me: “I have twenty years of evidence backing up my claim and I have personally seen it work this way.”

 

Exchange 2

Project managers: “Well, we have government regulations we deal with and you just don’t understand what we do here.”

Me: “I have [another customer] that has to deal with HIPPA requirements and they use Agile so I don’t think your requirements are that strict, are they?”

 

Exchange 3

Project managers: “We don’t use pure Waterfall we use a modified version.”

Me: “So..you’ve already modified your methodology because it’s inadequate. Why not finish the job?”

 

 

Essentially the arguments went on from there but were just variations on these three exchanges. To be fair, I tried to explain that I believe Waterfall has it’s place in many, many areas just not in software development but this argument fell on deaf ears. So it got me to thinking: “Am I right?” I had looked at some evidence years ago and had proven it out myself on countless occasions but was that still the case all these years later? Did Agile methodologies still hold sway over Waterfall? Did the evidence prove it? To that end I have assembled evidence for myself and for anyone else who has to fight the Agile battle. Please feel free to add your own evidence (pro or con) in the comments.

 

Please note that I deal in empirical data. Period. I can find any number of people (including myself) who have had good/bad experiences with Waterfall and good/bad experiences with Agile. On the main, I’ve found Agile to be better in the situations I have dealt with but I have seen plenty of people swear to Waterfall the same way. To even the playing field I have to go to objective data as the measure rather than feelings. The data I found shows many data points but there are two that I think are vital for people to understand:

1. Overall, Agile methodologies are better for software development projects than traditional project management (Waterfall).
2. Even Agile projects fail; having a superior methodology is no substitute for a good team and solid project discipline.

 

Waterfall Over Agile

I looked for any empirical data that would show traditional project management (Waterfall) beating Agile methodologies for software development. After several hours I gave up. I don’t know if it exists but if it does the data showing Waterfall beating Agile is very hard to find.

 

Agile Over Waterfall

The exact opposite is true for Agile being better for software development than traditional project management. There were too many studies to include so i decided to focus on one of the key studies that would be most appealing to management. To that end, I found an excellent article written by Dr. David F. Rico, PMP, ACP, CSM entitled “The Business Value of Using Agile Project Management for New Products and Services” (https://davidfrico.com/rico-apm-roi.pdf). It is an extremely concise and well documented survey of data in support of Agile and is a “study of studies” that really summarizes the Agile impact. I suggest you read the entire article but below are the most compelling pieces of data showing improvement of Agile over traditional project management within several studies:

https://davidfrico.com/rico-apm-roi.pdf

 

 

In the same article Dr. Rico also mentions the 2008 Maryland study that “[…]developed a database with over 153 data points on the costs and benefits of agile project management from 72 studies.” [Rico, D. F. (2008). What is the ROI of agile vs. traditional methods? An analysis of extreme programming, testdriven development, pair programming, and scrum (using real options). TickIT International, 10(4), 9-18]:

https://davidfrico.com/rico-apm-roi.pdf

 

 

Additionally, in 2009 there was another study that examined the “[c]ost and benefit metrics, models, and measures were developed based on 52 data points from 32 studies.” [Rico, D. F., Sayani, H. H., & Sone, S. (2009). The business value of agile software methods: Maximizing ROI with just-in-time processes and documentation. Ft. Lauderdale, FL: J. Ross Publishing.]:

https://davidfrico.com/rico-apm-roi.pdf

 

 

Naturally there are many, many more articles on the benefits of Agile. One other one that springs to mind is Ben Linder’s article entitled, “Evidence of Success of Agile Projects”. (https://www.infoq.com/news/2012/11/success-agile-projects). Linders cites references to other studies that have shown Agile project success as well as guidance for implementation. Feel free to add you own favorite study in the comments section and, if you have a study that shows Waterfall beating Agile I will gladly add it to the main article for balance.

Comments

• Anonymous
  November 06, 2013
  I'm just a regular dev and don't get into a lot of these discussions. But I did find the Agile Adoption and Transformation Survival Guide a very interesting read:  www.infoq.com/.../agile-adoption-transformation It's not entirely objective (the author makes a lot of subjective arguments) and he doesn't mention Waterfall specifically, but the author's position is that whether Agile really works well in a company is mainly due to the company culture.

• Anonymous
  November 06, 2013
  Hey Stephen :) I would say that is absolutely the case in software development and, basically, in life. I believe your attitude toward something will determine your success or failure in that effort. Z

• Anonymous
  November 06, 2013
  All the literature that I've seen has referred to waterfall as the WORST development methodology. As far as I know, the first paper on waterfall was in 1970 by Royce, and it was about how it doesn't work very well.

• Anonymous
  November 07, 2013
  Hey Mike :) Do you happen to know the citation for that study? I would be a good one to add to the mix. Z

• Anonymous
  November 09, 2013
  I've seen both methodologies succeed and fail. People are the most critical factor. But there's more to it than that. First, which definition of Agile are we discussing? It seems that the pro-Agile community cannot agree on a single definition for Agile. That makes endorsements of Agile less substantive and more about personal opinions and biases. Second, different projects require different methodologies to be successful. One size does not fit all. Third, Agile has 3 glaring problems:

1. It's sprints do not lead to highly scalable designs and implementations. It's a fact.
2. Each sprint can cause re-implementation of code. Recoding introduces bugs, an undesirable and expensive side effect.
3. Recoding is expensive and costs employers more time and money. Re-doing any work is wasteful. Fourth, Waterfall can take so long to define that the delivered product is obsolete upon completion. There are no substitutes for good product/project definitions to define the full scope of a product/project. From what I have seen of the various "versions" of Agile I've been exposed to, it does this poorly. For Agile to be considered viable, it must meet this standard., especially for large projects. To become a legitimate methodology, it must be well-defined, which it currently is not. For success, a rationally chosen, middle ground methodology for product development needs to be chosen and executed. There is one last problem, the reason I think the Agile "methodology" is so in vogue: Planning, designing, and documenting are hard work. Some people simply cannot do it. I think most developers would rather code than plan, design, and document. In my 30+ years in I.T., I estimate that approximately 50% of the people in I.T., particularly development, lack essential skills and/or the proper mindset, to be effective. For them, coding incessantly is the easy way out.

• Anonymous
  November 09, 2013
  Agile is a way of thinking about software development, not a fixed set of techniques or tools. Agile refers to being able to change quickly when it advances the project. There are techniques and tools that help keep a project flexible and help keep communications between the development team and the other stake holders effective, but don't be afraid to change tools, or even procedures, if you are not getting the results you want. Some Agile folks may insist that they don't need no stinkin requirements, but they are wrong. Agile doesn't do away with requirements, it manages changing requirements by making change management central to the development effort. You still need to have enough original requirements to create something to change.

• Anonymous
  December 06, 2013
  @Lee First: The definition of agile is found in the Agile Manifesto. Anything else is just a specific attempt to implement those principles. Second: Of course. That is where there are different implementations of the principles outlined in the Agile Manifesto. Third:

1. No, it isn't. See, I can make declarative statements as well.
2. Each day, irregardless of methodology, can cause re-implementation of code. What is your point?
3. Obviously. Again, what is your point? This doesn't have anything to do with agile in particular. Fourth: Ok. So what exactly are you advocating here? In my 94,365,747 hours of experience (see how I've made myself sound really authoritative now?) in IT, I estimate that approximately 73.67% of developers are pretty average, and write pretty average code. Do you really care that (a) I've got experience or (b) that I've made an entirely biased and completely unfounded estimation? Last: It isn't in "vogue". It isn't a "fad". It is the way most major successful software companies are delivering software. Yes, documentation and requirements are hard, and agile doesn't make that magically go away. That is why there are a myriad of books on the subject. Agile is a mindset that permeates the way your company approaches software development.

• Anonymous
  January 07, 2014
  Did the customer actually buy anything from you after that argument? I think if you're trying to sell something it's probably best to avoid humiliating your prospective customer.

• Anonymous
  January 07, 2014
  Expr, Yeah they did actually. The CIO was in the room and came up to me after the session and thanked me. It was meant to help the people get out of a single mode of thinking and create a dialog about new approaches. They later told me that there was a great internal discussion as a result and they were looking at new ways of doing development. All I can do is present the evidence and let them decide. Z