If you’re not prepared for change, you’re not prepared for Agile
We all know that Agile is not a silver bullet. Many teams claim to be Agile but resist the very thing Agile is built for: change. If your organization implements Agile ceremonies without embracing a change-ready mindset, you’re setting yourself up for failure.
Change is inevitable – but knowing this and designing for it are two different things.
I’ve worked with many teams that label themselves Agile and weren’t. I’ve also worked with teams that didn’t label themselves as Agile (or anything else for that matter) but really were. That’s because being truly Agile is very much about accepting, adapting to, and managing change.
Where to Start
Let’s explore how to effectively alter our mindset and make Agile, or at least acceptance to change, a reality.
Accept and Adapt to Change
We all know change is coming, whether in the form of shifting requirements, new technology, or evolving team structures. And yet, change almost always triggers stress. Why? Because change disrupts predictability, and predictability gives us a sense of control.
This response isn’t weakness – it’s pure human nature.
In fact, change often triggers a progression of emotions that resemble what’s described in the Kübler-Ross model: Denial, Anger, Bargaining, Depression, and finally Acceptance. We may not experience all five stages in a dramatic way, but even small changes can spark micro-versions of this process.
The key takeaway is this: Acceptance doesn’t happen instantly, and that’s okay. But the sooner the team recognizes change as a natural, expected part of the process, the faster it can move past resistance and into solutioning.
Agile isn’t just about adapting to change, it’s about learning to expect it, normalize it, and design for it.
Make Change Part of Your Process
Here’s where Agile methodologies come into play. Building change into processes is one of the foundations of Agile. It is one of the reasons why Agile stresses to:
- Work in short intervals (sprints)
- Limit the amount of work in process (WIP)
- Scope upcoming work through sprint planning
- Track and measure sprint velocity
These practices help us to adapt to change quickly and reduce the amount of change that teams encounter. Building change into processes reduces stress because everyone knows what to expect when change arises.
Change Should Be Negotiable, Not Dictated
With that said, if “what is expected” when change occurs is that the team always ends up just “dealing with it” and working overtime, then we must examine our change process. If this is the case with your team, then it is likely that change is unidirectional with management.
In a “functional” Agile environment, change is bidirectional and most importantly, negotiable. The main purpose of getting a good feel for sprint velocity and capacity is to establish a realistic understanding of a team’s ability to complete work. If a change is “additive” to the current workload, then its scope, impact, and priority must be considered with the existing work. If it is determined that the change is urgent enough to supersede work items already in the queue, then an equal measure of queued work must be returned to the Backlog.
I imagine that some of you are saying, “That sounds great in theory, but I live in the real world.” I freely admit that in the real world sometimes we just have to suck it up and work harder and longer, but this should be the exception, not the rule. If this is the norm for your team, then you need to work this out with your management and business owners, otherwise your team will suffer burnout, low morale, and high attrition. So, if your team is on this “one-way street”, then consider implementing and strengthening your process with:
• Backlog grooming
• Mid-sprint reviews and
• Stakeholder prioritization
The bottom line is, if change always means overtime, then your Agile process is broken.
Make Your Customers Part of the Team
Perhaps the biggest source of change comes from the people we do work for: Our customers.
Another foundation of Agile is constant customer engagement. Make your customers part of the team, not just part of the process. Your customers have a direct and vested interest in the end product when they are part of the team and thus have equal ownership and responsibility for the impact of the changes they impose. When the customer is part of the team, it is “we” rather than “us vs them”.
In addition, if the customer is truly part of the team, they are more likely to be empathetic and understand the impact of change on the team and are therefore less likely to demand that low-priority/low-value changes be made immediately.
Conclusion
If you are frustrated by constant changes, ask yourself this: Is it the change that’s frustrating, or the way we respond to it?
Agile isn’t about controlling change. It’s about preparing for it, embracing it, and collaborating through it.
When we treat change as standard operating procedure – not as an exception or disruption – we’re no longer just going through the motions of Agile, we’re living it!
Additional Resources
Take advantage of these free resources to dive deeper into key topics covered in this article.
Accept and Adapt to Change
- Agile Change Management: Overview, Principles, Best Practices
- 5 Tips for Adapting Change Management to Agile CRM Projects
The Technical Manager 
Leave a reply to Ed Russell Cancel reply