Is agile really all about being able to change?
The myths about agile and change
We all know the stories: “if you do agile, you can change!”. Isn’t that great? Those poor fools doing Waterfall can’t change. They bolt themselves to this big plan, and stick to it even when it goes to hell.
But on an agile project, we can do whatever you like. Change direction, change product, change focus. Change your scope, change your timelines, change your priorities, whatever you like!”
These are myths and misconceptions. In this article I am going to challenge:
- the idea that waterfall projects cannot change
- the idea that change is always a good thing
- and the idea that being able to change is a good thing.
Let’s get started!
Any project can change
I’ve worked on many agile projects and many waterfall projects. Many of them (both types) have involved changes. Waterfall projects certainly can definitely change: they institute a change control process.
Remember, Waterfall projects tend to fix scope up front, base their time and cost constraints on that scope, then try and hold those things fast in the Iron Triangle. If scope goes up, time goes up and if time goes up, the cost goes up. So Waterfall project managers often spend a lot of time trying to avoid scope changes by a Change Control Process.
You make someone fill out a bunch of forms and do a bunch of impact analysis and cost and risk estimation (all of which are a waste of time or money). And hopefully, they give up and go away or can’t get the seventeen approvals required for their change.
Micro-changes
This describes big scope changes. There are also the little “micro” changes: a new button here, and different heading there, an extra set of form validation there. Waterfall people are (rightly) worried about these too, so they try and prevent them by specifying all of the system up-front in big “specification” documents. You don’t start building anything until everything is “specified” in the big document. If someone wants to change something, they have to change the specification first, which is covered by guess what? A slow and painful change control process! Thus, even if someone has a better idea on how to do something, they probably won’t get their idea in.
So Waterfall projects CAN and DO change. So Agile doesn’t differ from Waterfall in that “Agile projects can change, Waterfall projects cannot change”. Both can change and can not change, depending on the decisions made by people working on the projects. The difference is that Waterfall projects tend to resist and fight change; they discourage change by putting wasteful processes around it that make it difficult. Agile projects tend not to (though there is no law saying they can’t… maybe you’ve worked on an agile project that has? If so, I’d love to hear about it in the comments).
There are different types of change
Change is complex. Some change is good, some change is bad. Some change is easy, some change is hard. I’ll start off by dividing change into three types:
- changing something that hasn’t been built yet
- changing something that is in the process of being built
- or changing something that has already been built.
The first type has the lowest cost and risk since you’re just changing an idea or a scope item. The second one has higher cost and risk because you might break the thing as you change it. The third type has the highest cost and risk, because you might break it, and you might break other things that this thing is connected to, and if it does break, you’re impacting real users or customers, instead of just something in a test environment.
So it seems like the first is the best type and the third is the worst type. That’s roughly correct though is a simplistic view. The third type often has the most value.
For example, if you have a website that customers don’t like or can’t use or isn’t converting, fixing it and improving it could yield huge results. But rearranging items buried in a product backlog probably won’t make much difference to anything. As always, it’s not just about the costs and risks, it’s also about the benefits.
Change can be bad
If “being able to change” is good, that means change is good, right? We know that some changes are more costly and risky than others, but change is a good thing, right? Otherwise “being able to change (easily)” wouldn’t be an advantage, right?
It’s about the why
Change can be good or it can be bad. The important question is not the what (what are we changing? Has it been built yet?) or the how (do we just let it happen or do we wrap wasteful control processes around it?), but the why. Change can be done for a variety of reasons, some of them are good and some are bad. Here is a rough list:
- Because a stakeholder feels like it (bad)
- Because a UX designer / visual designer / brand person / marketing person feels like it (bad)
- or because it has to be done for legal / security / privacy / compliance reasons (annoying, but fundamentally good, nobody wants to go to jail)
- Because otherwise our infrastructure will fall over and melt (annoying, but good)
- Because our stakeholders came up with some feedback in our sprint review after seeing the latest product increment (good)
- or because our user testing tells us that we should (good)
- Because the market / business environment is shifting and has made this change desirable (good)
- Because our analytics (real customers in a real environment, not UX testing in a lab) tells us that we should (really good)
So if you have a product owner or stakeholders or marketing people who like to change their mind for no particular reason about what they want to build (urgh), or are in the middle of building (double urgh) or have already built (triple urgh), “being able to change” is not an advantage, it’s actually a disadvantage.
Agile isn’t about being able to change, it’s about making informed changes
Agile lets you make informed changes for the right reasons
You want to be making the right changes for the right reasons.
The worst reason for change is because “the boss says so”. They will actually have their own reasons, probably based on some line of thinking. But if it’s not based on inspecting the product (in an agile sprint review), or actual data, then the reasons are probably invalid.
The next worst reasons are “we saw the product in a sprint review and we don’t like it and we want something else”. At least the stakeholders have seen the product; but unless the feedback is from actual customers, it’s not very relevant. Remember, you’re building something to make customers happy, not stakeholders happy. Stakeholders can hate the product, but that doesn’t matter if customers love it and pay for it.
The next best reason to change something is that you did some user testing, and the testing showed that the product needs to change. This is important feedback and is a good reason to change. Obviously, you should be testing things you haven’t built yet or are just starting to build (via Rapid Prototyping), rather than things you have already built.
The problem with user testing though is that it is not a realistic environment. Eric Ries has some interesting things to say about this in his book The Lean Startup.
Agile (with Continuous Delivery) gives you the ability to make frequent changes
The best reason to change something is that you have gotten real data from real customers in a real production environment. That is, you have built analytics into your product (you HAVE built analytics into your product, haven’t you?), and it is telling you that customers don’t like it, don’t understand it, or can’t use it properly.
Of course, this will mean changing something you have already built, which is expensive and risky. So you have to invest in automated testing and continuous delivery, to reduce the cost and risk of these changes.
