Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
What Does It Mean?
Let’s be honest—no one really likes change when it shows up uninvited. Change usually means rework, replanning, and maybe a few uncomfortable conversations. But this principle reminds us that change isn’t failure. In fact, change is opportunity. It means we’ve learned something. It means the customer’s needs have shifted – or OUR needs have shifted – and we have a chance to respond.
Organizations that resist change usually pay the price. They deliver something shiny, new, and already irrelevant. Worse, they frustrate their customers, who wonder why they’re paying for something that doesn’t solve their actual problem.
Agile doesn’t promise stability; it promises adaptability. And adaptability is how we deliver competitive advantage.
My Experience: Dependency “Contracts”
A recent experience brought this principle home for me. I’ve been working (with varying degrees of success) to get teams to better track their dependencies with one another. I’ve tried everything—fields in Jira, slick dashboards, automation rules—you name it. But many folks in the company insisted on writing what they called “Dependency Contracts.”
On the surface, these contracts were actually quite good. They were detailed, thorough, and well-documented. The problem? They lived in Confluence and just sat there. Static. Out of date as soon as they were published. And since teams weren’t actually putting the dependent work into their backlogs, the dependencies were missed altogether.
Guess what? I was right. Work slipped, dependencies got overlooked, and suddenly those carefully-crafted contracts didn’t look so helpful. Now, we’re back at the drawing board—but here’s the positive: there’s far more openness to change. I have a team of agile coaches working on a more dynamic approach to dependency management right now. Hopefully, we’ll see fruit soon.
Why This Matters
The “Dependency Contract” story is a perfect example of what happens when we cling to rigid documents instead of embracing change. Contracts gave the illusion of certainty, but the reality was much messier. Requirements shifted, priorities shifted, and the teams needed a way to adapt—not a static agreement filed away in Confluence.
By welcoming change—acknowledging that dependencies evolve, just like requirements do—we set ourselves up to respond faster and more effectively. And in today’s environment, the ability to respond is the real competitive advantage.
Embracing Change = Embracing Reality
Here’s the truth: change is going to happen whether we like it or not. We can either treat it as a disruption or harness it as fuel. Agile calls us to do the latter.
To wrap it up, this principle is not giving us permission to move the goalposts endlessly. It’s reminding us that adaptability is the point. Embracing change is not weakness—it’s resilience. It’s how we keep delivering value, even when the world refuses to stand still.
Take It to Your Team
In your next retrospective, try this:
- Ask the team to recall the last time a change came in late—new requirement, shifting dependency, or customer feedback.
- Discuss: Did we treat it as a disruption or as an opportunity? What was the impact?
- Brainstorm: What lightweight practice could we try to spot and adapt to change faster next time? (e.g., dependency huddles, backlog refinement tweaks, or simply surfacing assumptions earlier.)
The goal isn’t to prevent change—it’s to build muscle for responding to it.
Scrum Bubbles 