BROADCASTS.com

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\u201d?

In this final episode about the major changes in the new Scrum Guide, I\u2019m 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 \u201cself-organizing\u201d to saying that they must be \u201cself-managing.\u201d

At first, I didn\u2019t 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\u2019d often thought that self-organizing was chosen to keep managers from freaking out: \u201cWhat do you mean the team is self-managing? Then what am I going to do\u201d? 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, \u201cself-managing\u201d is going to be a big shock to organizations that haven\u2019t allowed teams to be self-organizing or self-managing at all.

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

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

One frequent complaint about Scrum is that, \u201cThere are too many meetings\u201d. 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\u2019re going to do this. They don\u2019t change anything about the way they work. So, all those other meetings that are on your calendar don\u2019t go away, and here\u2019s four more you need to do. Often, organizations that dictate Scrum as a veneer atop their existing processes don\u2019t 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\u2019t retain talent, but you can\u2019t attract talent. Because word gets out and people hear that yeah, you don\u2019t want to work there because that\u2019s a horrible place to work. Self-managing teams create a healthier workplace that people want to join and stay in.

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\u2019t being rewarded with money. The three factors that motivate knowledge workers are autonomy, mastery, and purpose.\xa0\xa0

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\u2019s 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\u2019s 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\u2019s autonomy.

Another way that Scrum gives teams autonomy is that they set their own Sprint Goal. No one says, \u201cThis is what you\u2019re going to be doing this Sprint.\u201d Instead, the Scrum Team talks about what would be valuable to do based on the feedback they\u2019ve 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\u2019re responsible for coming up with that plan, nobody else.

Scrum encourages mastery. The Scrum team is accountable as a whole for delivery, so there\u2019s no idea that, \u201cThis is my area and I don\u2019t have to do anything else\u201d. 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\u2019re building and why. And it should be exciting for us.\xa0

A benefit of self-managing teams is that there\u2019s less overhead for managers. They don\u2019t 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\u2019t have to chase us down for status reports, that he didn\u2019t have to be telling people what to do. He could just say, \u201cHere\u2019s what we need to accomplish.\u201d And we figured it out on our own. His management activities became about helping us grow in our careers. He would ask, \u201cWhat do you need to know? What do you need to learn? How can I help with that?\u201d 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 \u2014 especially in the face of uncertainty. We can pretend that we can predict the future, but we can\u2019t. And in complex product development, something new is always going to come up. There\u2019s 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.

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\u2019d 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\u2019s try to leverage Scrum for this, and he said, \u201cAs long as everyone does what I say, we\u2019ll succeed.\u201d As a result, people didn\u2019t 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.\xa0

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\u2019ll 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\u2019s effectiveness, the processes they work with, and the objectives they\u2019re being asked to work on.

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

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

• Register for our\xa0upcoming web meetings
• See available\xa0training courses

\xa0