There are several ways to answer the question “is agile cheaper than waterfall?” Here are two of my favorites:
“It depends. Agile done well is cheaper, as long as you measure correctly.”
“You’re asking the wrong question. The right question is: is agile better?”
How Agile Is NOT Cheaper
The fun thing about relative terms is that you have to do a comparison. There was a joke that really resonated with me as a little kid (synapses and memory are funny things).
Which weighs more, a ton of feathers, or a ton of bricks?
Kenneth Grant explores this question as a process comparison, and identifies it as a poorly formed question because comparing agile and waterfall is comparing apples and oranges. Agile delivers to-be-determined stuff incrementally and waterfall delivers predetermined stuff all at once. The question is poorly formed at a higher level too.
“Is agile cheaper than waterfall?” is a grown-up version of the same question. If I have 7 developers and someone organizing their efforts, it costs a fixed amount per year, $X. If I have them developing with waterfall, I will spend $X for the year. If I have them developing with agile, I will spend $X per year. If I have them watching Bob Ross videos and painting landscapes, I will spend $X per year. No matter what that team does, I will spend the same amount to employ them.
But agile lets you build more efficiently, therefore you build more in the same amount of time – therefore it costs less per unit of delivered software. OK, that’s true – but agile, as applied to a process (and yes, I know – agile is a philosophy, not a process; application of agile philosophy results in changes to process), does not mean you build the right product. Comparing cost in terms of output is just as wrong as comparing it per unit time. If an agile team builds me a better dresser faster than a waterfall team builds me a not-as-nice dresser, I’m not better off if what I actually needed was a coffee table.
In terms of coffee-tables-delivered, which is what I actually care about*, both agile and waterfall cost the same. I guess you could argue that I have wasted less money efficiently building the dresser with the agile team, therefore it is “cheaper.” But if I don’t have my coffee table, I don’t care about cost, primarily. I care that my remote control was sitting on the floor and the dog chewed it up. [*Note: I actually care about the remote control, and about having a place to put my popcorn when watching a movie, for my sharp-eyed long term readers. The lack-of-coffee table is just a problem manifestation, not the actual problem.]
Whether agile is cheaper or not should be measured in terms of the cost of solving the problem, not the cost per unit time spent, nor the cost of output generated.
Agile Done Well IS Cheaper
When we assess that agile is being done well, we are not only measuring that the team creating the product (design, development and testing, to simplify) is being efficient. We are measuring the efficiency of the larger team (the company) at solving the larger problem (success in the market). This definition of scope encompasses both development agility and business agility. It requires that the product team (product manager, product owner, business analyst, etc) also be agile. That they effectively identify the important problems, for the right customers, in the right markets. This requires both up-front deterministic insights (to get the team started in the right direction) and emergent insights (to course-correct as the team gets smarter about market needs).
When a development team is not informed about what is important to customers, the process looks like this:
- The team is given a charter – go create a solution for “this problem.” [Note: there is insufficient validation that “this problem” is “the right problem.”]
- The team efficiently builds an awesome solution for “this problem” and takes it to customers (for feedback, or an attempt to sell it).
- Because, in my biased example, the team solves the “wrong problem,” the team now fails. Props to their development agility, they fail fast.
- The team then comes up with an idea to try something else that might not fail. Unfortunately, the feedback is more likely to be about the suitability of what they created, instead of feedback about the initial problem selection. If that ratio is 80/20, then 20% of the teams now have “this other problem” as their charter. That lucky 20% goes back to step 2. The unlucky 80% also go back to step 2, but they are looking for a better solution to the wrong problem.
- I’m cheating with my list here. The lucky 20% actually have a shot at escaping the infinite loop in step 3. Let’s say 50% of them “get it right” – they focused on the right problem, thanks to the feedback they got and they created a solution that is effective for customers trying to solve that problem. They escape this viscous cycle and get to now focus on improving the solution. The rest of the teams get more feedback and try again.
The overall inefficiency of efficiently failing over and over again may or may not be “cheaper” than using a waterfall approach.
The waterfall version of the process above is simpler:
- The team is given a charter – go create a solution for “this problem.” [Note: there is insufficient validation that “this problem” is “the right problem.”]
- The team rigorously clarifies exactly how they will solve the (wrong) problem, then elegantly designs a comprehensive solution to the (wrong) problem, then extensively builds their solution to the (wrong) problem.
- The team releases their solution to the market. It fails, because it did not solve the right problems.
100% of the waterfall teams that focused on the wrong problem will fail. 100% of the agile teams that stay focused on the wrong problem will fail. Only the teams that change their focus from the wrong problem to the right problem can succeed.
Is Agile Better?
The important question to ask is if following a process that is defined by agile principles is better than one that is not. The primary goal is not to save money, or to deliver faster. The primary goal is to deliver a solution that succeeds in the market. Anything you do that helps you better define the problems, and validate the solutions is “better.” Getting faster is nice, as long as you’re getting faster at building the right product.
If you’re building the wrong product, investing in your ability to build more cost effectively is a waste of energy.
Conclusion
A team that does agile well is a team that maximizes the likelihood that they are solving the right problems. They avoid – or minimize – inefficient failed attempts from focusing on the wrong problem. Instead, their iterations focus on improving the suitability of their product in helping customers solve the right problem. Incremental improvements solve the problem better, or solve it for more people. Iterative opportunities for feedback are ruthlessly exploited, maximizing the efficiency of problem selection and solution, and not just the efficiency of building stuff.
You had me at Bob Ross videos. Bob Ross and Martin Yan (Yan Can Cook) are timeless classics.
Oh yeah, Martin Yan is awesome too! I think I’d have better luck getting developers to paint landscapes than to cook, but he’s another great example. Thanks!
I agree in general with the statements, but something to think about… Agile also helps you identify that you should be building a coffee table instead of a dresser much, much faster than waterfall. The dresser / coffee table conversation is more of a business problem than an agile problem.
Hey Zac, thanks for joining in the discussion and welcome to Tyner Blain!
I agree that “agile (done right)” helps you discover the need for remote-control protection, and helps you validate that a coffee table is a good solution (if it is). Unfortunately, I’ve seen two many “agile” teams that aren’t agile.
The worst case scenarios are “agile in name only” – where people are going through the motions.. Slightly less bad is the situation where the product-creation team (developers, QA, doc, services, etc) is being incremental and iterative about how they deliver, but the problem-discovery team (product management, strategy, business analysis, etc) is not.
I’d agree with your last sentence if you were to say “The dresser / coffee table conversation is more of a business problem than a development problem.” Agile can apply (and should apply to both teams. Unfortunately, it is almost universally only practiced by the product-creation teams.
Well said, I have nothing to add but a few “harrumphs” and “hear, hear.”
Ouch. Doesn’t solving a business problem pay our salaries?
There are some other things to say.
Hypothetically, if both agile and waterfall have the right project target (ideal solution for the client with no errors), waterfall can deliver with less effort and money.
The average agile process is slower than the waterfall one: you need to consider communication (meetings, replan, retask, refactor).
The real thing is that waterfall is hardly retroactive and it is pretty difficult to correct a plan if the target is failed. So agile delivers something which has more quality and value for the client and it delivers better.
Hey J_Zar, thanks for chiming in and welcome to Tyner Blain!
I’d like to address your three points separately.
Thank you for your answer and congratulations for the really nice post series!
Scott – Great article and great insights, one of the few articles that makes me wish I had written it myself. I have been arguing for years that Agile is great – on the right project for the right organization and with the right people. The same, however, is true for Waterfall and for Spiral/Iterative methodologies. It should never be a question of which approach is right for your organization, but which is right for your specific situation. Agile is great if there is a high degree of uncertainty or high volatility in the product. Waterfall is cheaper if the stakeholders actually know what they want up front and change is manageable.
I respectfully disagree with Zac that “Agile also helps you identify that you should be building a coffee table instead of a dresser much, much faster than waterfall”. Groups that rush to Agile without a clear definition of the problem can spend much more money in the rush to build something, anything, than a group who spends time analyzing the situation before developing anything – one of the hallmarks of effective Waterfall (i.e., one in which course corrections are possible). If the requirements definition phase of Waterfall does not recognize that a dresser is what is really needed, that is a failure of the analysis skills of the people involved, not the Waterfall process per se and if the requirements definition phase of Waterfall costs more than the first release of an Agile project, that again is a deficit of analysis skills, not an indictment against the methodology.
Regardless, there are much cheaper and faster ways of figuring out whether you need a coffee table or a dresser before you ever get into the decision to follow an Agile or Waterfall Software Development Methodology (SDM), and that is through effective business analysis (for truly critical projects in a Requirements Discovery and Analysis Workshop). Whether you are an Agile enthusiast or a Waterfall fan, knowing whether your customer wants a dresser or a coffee table before you rush to deliver it is always the cheapest solution, but ultimately, defining the business problem should not be IT’s responsibility.
Thanks Tom, and welcome to Tyner Blain!
“Specific Situation” is absolutely right. It’s why consultants (myself included) often answer “it depends” or with a series of clarifying questions before expressing a concrete point of view.
On knowing up-front I really like how Frederick Brooks describes the debate between empiricism and rationalism in his book The Design of Design. My take-away, both points of view have truth: knowing which direction to run before you start running is better than not knowing, and being able to change direction as you get smarter about where you want to go is better than marching forward based on your original orders. My experience has been that waterfall (even done well) biases a team towards achieving predicted outcomes, and against making changes. Waterfall that doesn’t allow for change is flat-out broken, but even good waterfall adds burdens to the process of making changes, and causes organizational / expectation problems. I haven’t seen a project yet where it didn’t.
On that last bit about “should it be IT’s responsibility?” – I agree that it is a business problem. However, as someone who’s worked in multiple organizations, both inside IT and inside other areas (reporting to CMO, strategy groups, engineering that reports to COO, line-of-business units, etc), I believe that any IT department that self-defines as a “job shop” or “cost center” is making itself irrelevant. By taking a “we do what we’re told, right or wrong” approach, an IT department makes itself into a commodity, and not a partner. I’ve seen those IT-department employees (a) have their positions re-located to “lower cost labor environments” and (b) miss out on projects that were outsourced to external vendors. Both situations lead to layoffs for those folks.
For many people it is comforting to have less ambiguity in your role (do what you’re asked to do, vs. figure out what needs to be done). Personally, having been the victim, beneficiary, and observer of outsourcing, I believe it is a false-comfort. For my personality, I find much more comfort in knowing that by making a difference (e.g. solving the business problem, not just delivering what I’m asked to deliver), I make it harder for someone to choose to replace me.
Hi Todd,
This is a question that most project managers who think about switching to Agile ask all the time – this is the first post I read addressing this.
I would like to republish your post on PM Hut, where many project managers benefit from it. Please either email me or contact me through the contact us form on the PM Hut website in case you’re OK with this.
Of course. Email sent. Thanks for asking!
Thanks, Jeremy!
“Is agile cheaper than waterfall?†is a grown-up version of the same question. If I have 7 developers and someone organizing their efforts, it costs a fixed amount per year, $X. If I have them developing with waterfall, I will spend $X for the year. If I have them developing with agile, I will spend $X per year. If I have them watching Bob Ross videos and painting landscapes, I will spend $X per year. No matter what that team does, I will spend the same amount to employ them.”
Scott, if i were a supplier to your company engaging those 7 developers, i would charge you probably 40% more per year and certainly not at same cost as for Waterfall. Agile is intensive, cannot be compared with Waterfall. It would cause team burnout over a period of one long year, and i would extract a price for that as well as for speed.
The very fact that you are able to compare Agile and Waterfall (which in ideal cases cannot be compared) means you are trying to force Agile where waterfall (because you cannot have both pre-determined and to-be-determined requirements at the same time) would have sufficed, probably because business wants an early view. In such cases, then i believe my cost is justified because you demand speed.
My argument is based on personal experience.
Let me know your thoughts.
Regards,
Vijay