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.
