Why Has Self-Organizing Changed to Self-Managing in the New Scrum Guide?

In this episode, part three of a three part series on the new Scrum Guide, Professional Scrum Trainer Sam Falco answers the question: "Why has self-organizing changed to self-managing in the new Scrum Guide”?

From Self-Organizing to Self-Managing

In this final episode about the major changes in the new Scrum Guide, I’m going to talk about what may be the most significant change in the Scrum Guide update. And that is the change from saying that teams must be “self-organizing” to saying that they must be “self-managing.”

At first, I didn’t think much of it. I thought it was sort of a search-and-replace type of thing. To me self-organizing and self-managing seemed like the same thing. I’d often thought that self-organizing was chosen to keep managers from freaking out: “What do you mean the team is self-managing? Then what am I going to do”? That might be a cynical take on my part.

But even if the change is merely semantic, the significance is that organizations will look at Scrum in a new light. That phrase, “self-managing” is going to be a big shock to organizations that haven’t allowed teams to be self-organizing or self-managing at all.

A lot of organizations sort of gloss over this concept. Teams aren’t really selecting what they’ll work on except in the very shallowest sense of selecting the items that are at the top of the Product Backlog. Product Owners aren’t really Product Owners except in the shallowest sense of they’re allowed to decide what gets worked on first, but they’re still just taking orders from stakeholders. Teams don’t contribute to their goals; goals are handed to them. Teams are allowed to decide how to do what they’re told to do. Maybe we let them decide who sits where, what their core hours are, and that sort of thing. But there’s a lot more to self-managing than just allowing people to decide where they’ll sit and what they’re going to work on, specifically today.

When Teams Aren’t Allowed to Self-Manage

What happens when we’re using Scrum but we’re not allowing teams to be self-managing?

One frequent complaint about Scrum is that, “There are too many meetings”. I talked about this in a Trainer Talk episode last year. This complaint is common when an organization imposes Scrum from the top down. Here, you’re going to do this. They don’t change anything about the way they work. So, all those other meetings that are on your calendar don’t go away, and here’s four more you need to do. Often, organizations that dictate Scrum as a veneer atop their existing processes don’t see any better delivery than they were before. Sometimes things get worse. Because now they have the added overhead of the events of Scrum and all the things that go with that.

And this leads to a lack of engagement, lack of ownership, it destroys morale, it causes turnover. You not only can’t retain talent, but you can’t attract talent. Because word gets out and people hear that yeah, you don’t want to work there because that’s a horrible place to work. Self-managing teams create a healthier workplace that people want to join and stay in.

Scrum and Autonomy

In his book, Drive, Daniel Pink examined what really motivates people in complex knowledge work domains, which includes product development. What he found was that what motivated people wasn’t being rewarded with money. The three factors that motivate knowledge workers are autonomy, mastery, and purpose.  

Autonomy is the ability to decide what I am going to work on and how I am going to work on it. Mastery is the ability to continually improve your skills. And purpose means doing something that’s meaningful. Self-managing teams leverage all three of those things. And Scrum done well has all three built-in.

A Scrum Team decides what it’s going to work on. A Product Goal is more than just a statement handed out. The Product Owner who creates it also collaborates with the Scrum Team on it and on what the Scrum Team needs to do to get there. The entire team gets involved in that emergent product backlog management. That’s autonomy.

Another way that Scrum gives teams autonomy is that they set their own Sprint Goal. No one says, “This is what you’re going to be doing this Sprint.” Instead, the Scrum Team talks about what would be valuable to do based on the feedback they’ve gotten so far and creates its own goal and plan. And then of course, every day in the daily Scrum, the Developers meet and figure out how they are going to move a little closer to the Sprint Goal that day. They’re responsible for coming up with that plan, nobody else.

Scrum and Mastery

Scrum encourages mastery. The Scrum team is accountable as a whole for delivery, so there’s no idea that, “This is my area and I don’t have to do anything else”. We all expand our knowledge together and work together.

And then of course, purpose is built into Scrum. We have that important Product Goal that tells us what we’re building and why. And it should be exciting for us. 

A benefit of self-managing teams is that there’s less overhead for managers. They don’t have to spend time directing people and telling them what to do. The manager who introduced Scrum to our team and asked me to be the Scrum Master was so relieved that he didn’t have to chase us down for status reports, that he didn’t have to be telling people what to do. He could just say, “Here’s what we need to accomplish.” And we figured it out on our own. His management activities became about helping us grow in our careers. He would ask, “What do you need to know? What do you need to learn? How can I help with that?” Both for technical skills and for navigating our organization. That was a much more fulfilling experience for him and for us.

Another benefit of self-managing is serendipity in development. Hand people a problem to solve and then get out of their way. They will solve it in ways that you never imagined. Maybe solve it better than you would have if you had told them what to do.

Using Scrum to manage a project instead of driving product development misses out on creating valuable products and valuable outcomes — especially in the face of uncertainty. We can pretend that we can predict the future, but we can’t. And in complex product development, something new is always going to come up. There’s an enormous amount of uncertainty. Scrum allows us to adapt to that uncertainty as it arises. Every Sprint we have a chance to change direction.

Getting to Self-Managing Teams

So how do you get there? First, I would say abandon the illusion of control. I had a manager once who really struggled with that. He had a deliverable that he had been told must be completed by a certain date. He’d been told the scope, an immovable target date, a fixed budget. And he was obsessed with making sure that everyone knew what he wanted them to do. And I said, let’s try to leverage Scrum for this, and he said, “As long as everyone does what I say, we’ll succeed.” As a result, people didn’t take initiative when they needed to, for fear of getting slapped down. The project ran late, and there was hell to pay as a result.

This is a bad pattern. We need to let go of the idea that we can control everything, that we can predict everything up front. 

Feed your teams with objectives, not tasks. Set the boundaries within which they can make their own decisions and steer their own course.

Empower your Product Owners to make decisions and shepherd their products. Certainly, they’ll need to take into consideration what stakeholders need and want, but allow Product Owners the latitude to make decision about what is most valuable to do and give them the resources they need to make those decisions. Things like access to market data, access to customers, etc.

Encourage the Scrum team as a whole to be accountable toward each other and toward achieving positive outcomes. Encourage teams to do small experiments until the goal is achieved or the goal becomes obsolete. And then create a new goal or a new objective. We can manage risk with small Sprints where we constantly inspect and adapt not only the product and our progress toward the product goal but also the team’s effectiveness, the processes they work with, and the objectives they’re being asked to work on.

As one of the principles behind the agile manifesto states, “Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done. And they will. That’s the promise Scrum offers.

I hope you benefited from this exploration of the changes in the new Scrum Guide. I’d love to hear your feedback. If you have a question or a comment, please email us at podcast@agilethought.com.

Want to Learn More or Get in Touch?

• Register for our upcoming web meetings
• See available training courses