Myths of agile: Agile means fast and cheap
I thought I was finished with my “myths of Agile” series. But I’ve come across another one that still rears its ugly head from time to time. The idea is that everybody should all do Agile because it means you can do the same work, but “faster” and “cheaper”. Which is everyone wants. Right?
Agile means fast and cheap, right?
The myth goes like this. “I’m a project manager. And the ‘business’ has given me a big project to deliver. I could do it in the Waterfall way, as per normal. But all the cool kids are doing Agile these days. And Agile means faster and cheaper, instead of the slow expensive Waterfall way. And the stakeholders want faster and cheaper. So I’m going to take my big project and do it in an Agile way instead!”
There are a number of problems going on here. I’ll address them one by one.
Agile rejects big clunky projects in the first place
There is a problem in the very premise here. “I’ll take my existing big project and do my big project in this agile way. Instead of the waterfall way”. Agile software development rejects doing big clunky projects in the first place. Agile development doesn’t like projects. And Agile development doesn’t like big. In contrast to all that:
Agile encourages moving from a project to a product mindset. It encourages moving from large to small batch size. It encourages incremental and iterative development.
That doesn’t just mean breaking a big project with pre-defined scope into half a dozen steps. It means starting with just one small step, then defining and planning another small step. Then defining and planning and doing another small step. Learning and changing scope as you go.
Trying to “apply” Agile to your big project that some “business stakeholders” have pre-defined the scope for is missing the point. It is trying to jam a square peg into a round hole. And there’s more.
Agile focuses on customers not stakeholders
This “agile is faster and cheaper” mindset comes from the wrong place for Agile thinking. It comes from the traditional project manager mindset: deliver what the stakeholders want. Which sounds reasonable, and is the fundamental metric by which project managers are usually judged. (For my criticism of the traditional measure of project success, see here). But there’s something fundamentally wrong here.
The agile mindset instead tries to view things from the point of view of the customer. What software do the customers want? What software would the customers find valuable? How can we get something (not the whole thing) to them quickly? And how can we quickly learn from the software that we have built and delivered? How can improve ourselves so we can deliver more valuable software to the customer?
There is definitely a focus on speed here. But did you notice? The language is different. The Agile Manifesto doesn’t actually use the word “fast” or “quick”. Instead, it talks about “early” and “frequently”. So rather than delivering a big project in a smaller amount of time than we would otherwise, we’re talking about early and frequent delivery of a series of smaller features and changes.
Agile uses a different iron triangle
The traditional iron triangle of project management is scope, cost, time. And cost is usually a function of time (we usually pay people based on how long they work, i.e. time and materials, unless we’re doing a fixed-bid project). And time is usually a function of scope (the more things you have to build, the longer it will take to build all those things).
So poor project managers tend to spend a lot of time frantically trying to control the scope of the project. No wonder they are excited by the sound of a method to reduce the time and cost of their project!
But trying to control that triangle is a bad position for everyone, since we don’t usually know all the things we need to build up-front. We often find surprises as we go, or come up with new ideas after we’ve started. Or we get feedback from customers that direct us to build new features. So fixing scope up-front is a terrible way to control the triangle. And in fact, it’s the wrong triangle in the first place. Want to know the about the other triangle?
In his landmark book “Agile Project Management”, Jim Highsmith talked about a second, different triangle. The Agile iron triangle has three points: Value, Quality and Constraints. And the constraints point on the triangle is itself another triangle: the original iron triangle of project management (scope, time, cost). So how does this new triangle relate to the first one?
The other iron triangle
So the entire set of project “constraints” is just one of three factors you can trade against. And often in Agile, conformance to constraints is often not as important as value or quality. If you think that sounds crazy, think about this. If you discovered a new feature while building your product that your customers were frantically demanding, and would pay you vast sums of money for, would you build it? Even if it put your project over its original budget?
Any sane person would. Any sensible business would. Then you are trading off your Constraints for Value. Or if you discovered a defect in your product that would potentially harm or kill customers, would you put effort into fixing it? Even if it meant you shipped late or had to drop a feature? Of course, you would. Then you are trading Constraints for Quality.
So the Agile focus on value and quality over constraints isn’t just defensible, it’s the most honest and reasonable position. Waterfall project management proudly emphasises cost and time control because they are telling a story to the project stakeholders, not the software customers.
Agile can actually be a bit slow and that’s ok
Agile software development (done well) prioritises quality software and technical craftsmanship. It emphasises continual refactoring and paying down technical debt. What does this mean? It means that Agile can actually be quite slow in delivering individual features. Which puts pay to the lie that it means “fast and cheap”. Those words imply something shoddy rushed out the door, riddled with bugs.
Poor quality and undiscovered bugs are usually the domain of big over-scoped Waterfall projects, however. At least in my experience. Which is no surprise, considering those projects generally suffer from late and infrequent integration, silo testing departments, and tired teams put on death marches.
However, even if Agile might be slower to build each individual feature, it offers an enormous advantage over Waterfall projects: early delivery. Would you rather a project that takes five months and delivers six features, or takes six months and delivers six features one per month, starting with the first one delivered after the first month?
The latter might take longer but will start delivering value earlier. It will also start learning earlier, discover customer value propositions earlier, and reduce risk earlier. These are all the advantages of small batch size, continuous integration and continuous delivery.
Agile means small and early, not fast and cheap
Maybe a better set of words to use to describe Agile is “small and early” rather than “fast and cheap”, as opposed to the “big and late” approach of Waterfall. I think this phrase captures the philosophy and advantages of Agile much better. What do you think?
