TL;DR
- Change is often the thing we’re most afraid of in traditional PMO.
- Scrum done well turns change into opportunity, it's part of the process.
- To handle change, Scrum can't be half-baked into a waterfall process.
- Planning is good, rigid planning is painful.
- Only say yes to the changes that add value.
We’ve all experienced it. The thing we’re most afraid of in projects is change. Change to requirements, customer expectations, quality standards, budgets, to the market, and even changes to our product relevance while we’re building it. Typically, change means a higher burden on the dev team and management. It means extra work to rebalance expectations and baselines, change boards, and dev team overtime (on top of the OT they’re already working). It’s no wonder that change is what we typically try to prevent on a traditional project.
What if I told you that Scrum handles change quite well. Have you been working in Scrum for a while, and yet change is still killing your teams? Is it still an overall demotivating aspect to your projects? If change is something your teams fear, then you’re probably using a half-baked version of Scrum. I recently wrote about the systemic factors that disrupt the essence of Scrum. Basically it’s a combination of the contracts, timelines, and requirements structure. These are the main issues that prevent a true implementation of Scrum. When setup properly, Scrum handles change as a bend in the river, rather than becoming a steep drop-off in productivity.
How Does Scrum Handle Change?
Once your organization is setup to use Scrum, change will be handled as a flow. Here are ways Scrum supports change as a flow.When Done is Truly Done
One of the key concepts in Scrum is that your Sprint features are in a complete state by the end of a Sprint. Product Backlog refinement is key to this concept. The Product Owner and Dev Team must refine and prioritize your backlog in a way that prevents features from being spread across multiple Sprints. This supports the ability to create a done, releasable product. This has several positive knock-on effects to handle change.When you release a truly done increment...
- Change isn’t as big an issue when you release stable, done increments, there are no loose ends to tie up.
- Sprints can be made short enough to allow feedback and movement in another direction.
- Product Backlog refinement ensures features are broken up in a way to reduce dependencies.
Every Sprint is an Opportunity for Change
Whoah, wait, opportunity for change? But change is such a baaaaad thing! With done increments being delivered, there are no loose ends to tie up, so a change in direction isn’t as painful to the teams. It reduces resistance, and allows unexpected changes to be handled more like just another feature in the Product Backlog.Flexible Planning is Good, Rigidity is Bad
Flexible Routes
There’s a difference between planning for an outcome, and following a pre-planned path to a specific output. Let’s say I need to drive to my friend Ned’s house. Before I start, Google maps says the best route is to take the main highway route. While driving, traffic gets backed up, and Google tells me there’s a better route to take. Do you stay on the path you’re on, just because it’s what you chose when you started your journey? Heck no, you take those side streets, and arrive with less stress, and on-time. This is what Scrum is like compared to traditional project management. Scrum is veering off in the other direction when you need to, and still achieving the same goal (or getting there even faster).Flexible Destination
Another flexible aspect of Scrum is allowing changes to an outcome, rather than hitting a specific output. Let’s say I call Ned when I see traffic is backed up. He says, “We can meet at the restaurant instead of meeting at my place, since we were going out to eat anyway.” Scrum would respond with an emphatic “Yes! Let me shift this old route to the new one, and I’ll see you soon.”Traditional project management might say, “That’s not what we agreed upon before I left. I’ll consider it, but since it’s not the original agreement, let me document what you’re suggesting, estimate this traffic backup, call my parents for advisement, plot a new course on Google maps, compare it to my current path, write down the differences between the two, text it to you, and then have you and my parents text me back in agreement on this new plan. If there’s a difference in cost between these paths, I’ll bill you.”
I don’t know about you, but one definitely sounds like a better approach than the other.
