Is Your Scrum Adoption Stalling?

I often get asked what to do when a Scrum adoption begins to stall.  This is especially true to those in the earlier stages of adoption.  Whenever these conversations occur, it inevitably leads to the same answer.  I can’t help.  I just don’t understand your context or your organization.  Don’t misunderstand.  I want to help, but what can I do when I’m not beside you seeing what you see and hearing what you hear?

Today, I have an idea.  I emphasize questions over statements so it’s time to practice what I preach.  After all, it’s you who has all the answers, not me.  My role today is think through questions I’d ask myself if I were in your shoes.

• Why Scrum?  How do people feel Scrum helps the org?  What’s wrong with our previous operating model?  What’s the impetus behind the change?  Is that impetus from the trenches or from the C-suite?  Was the adoption because of some crisis that occurred in the past or that’s looming on the horizon?  Or maybe we hear it’s trending, and we’d like to claim that we’re an agile shop. Whatever it is, thoroughly exploring the why will generate many great insights.
• Who’s making decisions?  Since Scrum requires decentralized decision making, it’s an important question to dig into.  How have leaders responded to teaching instead of telling?  Are they prepared to hand over some more of their authority? How have they responded when that new Product Owner, Scrum Master, or team makes a misstep?  I like how Ed Catmull puts it:

Trust doesn’t mean that you trust that someone won’t screw up. It means you trust them even when they do.

• Where do we begin? Did we go all in and with all teams?  Or did we start smaller by adopting one new event at a time with a single team?  I’d caution against going all in.  It requires too much thought and too much guess work. Plus, it’s just too much pain all at once.  Why not start as quickly as possible, where we’re at, and with what we have?  Start with a single team.  Start by doing weekly or bi-weekly retrospectives, provide this team with the latitude to try new things, and incrementally adopt Scrum as the team finds value in exploring new Scrum events.
• Do we actually understand Scrum? Do we understand that it’s more than just rebranding our meetings?  In fact, let’s put those Scrum events aside for the moment and talk mindset.  If we were to write the mindset of where we are now and compare it to the mindset we hope to cultivate, how does it differ?  Imagine the organization is at that destination.  What behaviors would we see then?  Can we begin epitomizing at least one of these critical behaviors today?
• What’s valued? Let’s ask everyone from team member to executive about the value proposition of this Scrum adoption.  When we compare answers, what themes do we see?  What themes don’t we see that we expected? If we were to run these value props by an experienced coach, what would worry him or her?
• Where’s it going to hurt? When we’re asking about value, let’s also talk about cost.  What’s this adoption going to cost us?  For how long?  What’s going to be our biggest hurdles?  What do team members expect of their executives in terms of tackling these obstacles?  What about the other way around?  Are we going to hide the problems we find or blame Scrum for the pain?  Have we thought about how we can prepare people for this reality?  This is important because Scrum will expose a number of issues in our organization, but it solves none.  It’s up to us humans to solve those problems.
• Are we ready for the pain?  For example, I might want to lose a few pounds, but as soon as that personal trainer starts making me sweat, I might change my mind. What’s the smallest experiment we can run that would help us measure how dedicated we are to this? After all, wouldn’t it be better to kill or pivot our adoption at the lowest cost possible and in the least amount of time?
• What do we measure?   I hate this one.  After all, most of us have seen metrics used as a weapon instead of a tool.  A new Scrum adoption is especially fragile at the start so why not begin with something qualitative like the Comparative Agility survey?  Take it now and take it again in a few months.  What’s changed?  Ok so still want a quantitative metric?  You won’t like it.  Measure how often the team is delivering working software to their target environment (ideally, production).  After all, nothing will make those pesky status reports disappear like software people can muck with.  I talk more about metrics in What Metrics Will My Team Find Useful.

That’s it for today.  I realize this post is chock full of questions but few answers about our budding Scrum adoption. Unfortunately, context is king here.  Every organization is different.  Every situation requires a different approach.  The good news though?  Every problem is a people problem, and people are what makes this interesting.