Change at the Speed of Sprints: Embedding Change Management Into Agile Delivery
Bart has been in ecommerce for over 20 years, and can't imagine a better job to have. He is interested in all things agile, or anything new to learn.
Agile delivery is built for speed.
Teams iterate quickly, respond to real-time feedback, and adjust priorities on the fly. But change management often lags behind, stuck in outdated models built for waterfall environments, slow, sequential, and heavily centralized.
The result is tension.
Product and engineering teams are expected to move fast, while organizational change is still framed as a one-time push, led from the top, and layered on after the fact. This disconnect slows down adoption, creates resistance, and makes change feel like an external burden rather than a shared responsibility.
Traditional change management assumes predictability and control. Agile assumes complexity and evolution. Trying to bolt one onto the other creates more friction than clarity.
The solution isn’t to abandon change management; it’s to redesign it to fit the way agile teams already operate. Change needs to be iterative, just like the work. It needs to be visible, collaborative, and flexible enough to shift based on what’s working (and what’s not). It can’t live in a separate team or a side plan. It has to be part of the sprint.
When change is embedded directly into agile delivery—into planning, standups, reviews, and retros—it becomes manageable, measurable, and less disruptive. It’s no longer a competing force; it becomes part …
Please log in or sign up below to read the rest of the article.
|
"The radical of one century is the conservative of the next. The radical invents the views. When he has worn them out, the conservative adopts them." - Mark Twain |
