I was catching up with Chris Murman* and out of nowhere he said something that’s stuck with me. He said this more kindly than I’m summing up here, but this is what I took away:
Change fatigue with Scrum is what someone says when they don’t want to do something.
It caught me off guard, and the more I considered it, the more I agreed. Change fatigue isn’t real. It’s camouflage. But it’s also a gift, and we should be thankful for their generosity and get curious. Here are some questions to ask:
- What changes do we currently have in progress? Which are working and which aren’t?
- Who decided these were the right changes to make and why now?
- Is there another change you believe we should make instead?
- What competing priorities are we having to balance?
- When does something stop being a “change” and start just being how we operate in a Scrum environment?
Avoid the temptation to persuade them to your point of view. (Especially don’t tell them that Tanner says change fatigue is a myth.) This is an opportunity to learn and, more importantly, for the person to be heard. What we’re likely to hear is that the person has been robbed of a choice. Someone else is deciding that this is the right time for change or the right change to make, and while I’ve written about this before in Invitation over Imposition, it’s worth revisiting.
If decentralized decision making is a tenet of agility then it follows that Scrum teams should decide how they change their operating model.
Let me be careful here. I’m not advocating for chaos and total autonomy. Too much choice has consequences. Take a study done in 2000 by Sheena Iyengar and Mark Lepper. Shoppers were offered 24 varieties of jam while shoppers on a subsequent day were offered only six varieties. The study found that those who saw the larger display were one-tenth as likely to buy as those who saw the smaller display. The point is that choice overload is real.
Is choice fatigue real though? I’m not sure. As a coach, I’m an advocate of choice since I feel we make so many of our choices by default instead of by design. Worse yet, we often don’t notice. I like how Barry Schwartz puts it in The Paradox of Choice: Why Less Is More:
Freedom to choose has what might be called expressive value. Choice is what enables us to tell the world who we are and what we care about.
So what do we do? How do we invite teams to change within constraints and without inundating them in choice? Try the MoSCoW prioritization technique when it comes to how Scrum teams adapt their operating model:
- Must Do: These are the things all Scrum teams must have in common. Tooling is a common item. The less in this bucket, the more autonomy a team can employ.
- Should Do: These are ways of working that we’ve seen with great success across the organization. As the team matures, adopt from this bucket first.
- Could Do: Have you adopted everything from Should Do? Here are some interesting experiments to run. Be the pointy end of the spear and try one. Tell us what you learn.
- Won’t Do: Many of our Scrum teams have tried these, and they’ve failed in every circumstance. Let us tell you why they should be avoided.
* Oh. So you want to know what Chris actually said that day? Fine: 😉
If it’s something you want to do, it’s a choice. If it’s something you don’t want to do, it’s a change.
Do you want to get notified when new posts are published? Leave your email below.
