Twenty years ago, an agile rebellion started among a small pocket of besieged software developers. Today, the benefits of agile methodologies have improved stock trading, federal bureaucracies, celebrity chef-led humanitarian efforts. Yet Agile has started to lose favor. This has prompted us to get back to basics and start a series focusing on the Principles of Agile.

We covered the first principle recently. Now let’s turn our attention to the second principle:

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

It may not sound like much in the “move fast and break things” world of 2021, but in 2001, that was a shot across the bow for enterprise IT project management. At the time, IT project management was primarily change management.

Fixed Requirements

In 2001, the success of a project was primarily measured by how closely the plan was followed. And that is certainly one form of success: delivering a system that meets the specs on time and within budget.

There are some problems with it though. The first problem was that it rarely happened. The other, more fundamental problem was that even when projects were “successful”, users were rarely happy with the system.

We hit the spec, but everybody is complaining about the system! What is happening?

There were some common scapegoats:

• The development team just didn’t work hard enough to interpret the specs correctly. They’re always asking annoying questions instead of working!
• Those darn stakeholders were wrong about the features of the system. Why can’t they just tell us what they actually need!
• We just didn’t capture enough detail in the requirements. We need to use more tools and processes to capture every possible edge case!

The result was often to try to add more controls: manage the dev team even tighter, gather even more detailed requirements, get even more sign offs, add even more review process, etc.

It wasn’t working.

Fixing Requirements

When you rarely hit your metrics for success and even hitting them has bad results, it’s time start rethinking how we work.

Agile asked a simple question: What if the problem is actually the process, not the people? What if trying to gather all of the requirements up front is inherently impossible? What if all humans, even genius visionaries, sometimes change their minds after seeing a first version?

Instead of change being dangerous, what if we started our reasoning from the opposite supposition? What if we assume that change is inevitable and even valuable! What would software development look like?

I sometimes feel like the rest of Agile is really just an implementation detail once you fully grok that simple idea.

Change is inevitable and valuable. Now what?

Well, we’d probably need to have a timebox where we limit change, maybe a couple of weeks. That’s enough time for devs and designers to dig into meaty problems but not so long to go down deadends.

We’d need to make sure we were getting frequent feedback from the expert users to make sure they still like the idea as originally envisioned. Maybe we could do that at the end of that timebox? Make sure we’re demo’ing at least that often.

We’d probably want some time for the team to contemplate how the project’s going and provide feedback too. Could we do that after each timebox? And so on. I don’t need to belabor the point. You get it. And I’m not belittling anything about Agile. Like many good ideas, it only feels obvious in retrospect.

Software is Still Messy

As much as I like Agile, it’s not a silver bullet. The reality of building complex systems is still messy. We still need a process for managing change. We still have contracts and deadlines. We still have cross-team workstreams to plan. We still have stakeholder expectations to manage.

Agile does not magically fix any of that mess. Agile acknowledges it.

Instead of pretending that we have a complete and perfect plan, let’s acknowledge that our plan will need to change. We still need to understand the impact of a change. What lower priority items might fall out of the backlog? Will it jeopardize a meaningful deadline? Will it change our integration with another team? And so on.

But Agile helps us understand change is not the enemy. Instead of trying to minimize change and constantly pushing back, we strive to welcome change, understand its impact, and then collaborate with our stakeholders to determine if the change is worth it.

Change is Learning

There’s a scene from The Office (US) where Michael drives into a lake, because he’s following the GPS navigation directions. It’s obviously the wrong decision, but he trusts the machine more than his eyes.

Large projects sometimes feel that way. Some piece of functionality no longer makes sense. The users don’t even want it. But it’s in the project plan that procurement approved 18 months ago. So we have to build it, right?

No. That’s insane.

This is a large reason why Agile says that planning is useful but responding to change is more useful. Change represents learning. If a feature is no longer valuable, let’s not build it. If prioritizing a new feature will help the business capture a strategic advantage, let’s build it or at least explore the feasibility. I don’t care what the original scope was when the project was planned – if the plan is now wrong. This stuff should be obvious, but it’s easy to get so focused on the plan that you lose sight of the business value we’re actually trying to deliver.

Least Worst

It can definitely be risky to welcome change, especially late in development. It requires trust between the dev team and the business stakeholders. Trust can leave you vulnerable, but if your plan has no room for change, that means you have no room to adapt to new information. I’ve never worked on a large, complex project where we weren’t constantly learning and adapting. I wouldn’t want to.

To paraphrase Churchill, Agile is not perfect and doesn’t solve all problems. Indeed it has been said that Agile is the worst methodology except for all of those other forms our industry has tried from time to time.

Building great software is hard, even in ideal conditions.

Welcoming change acknowledges that truth and helps engage everyone in creating the best possible solution using the most up-to-date thinking. That’s the only hope our industry has to deliver projects that are truly successful.