From Self-Organizing to Self-Managing Scrum Teams – What’s The Difference?

What is the difference between Self-Organizing and Self-Managing Scrum Teams

The Scrum Guide 2020 introduced several changes. Most of them are well understandable, and their sense and benefit is clearly recognizable. However, one adaptation is not so easy to explain and the benefit is not necessarily obvious. Self-organizing has been replaced by self-managing. Do you know the difference between these two forms of organization? This article will show you what the difference is and how it affects the way the Scrum team works. Have I made you curious? Then read on quickly!

Scrum Teams Are Now Self-Managing

Of all the changes in the new Scrum Guide 2020, the change from a self-organizing team to a self-managing team probably raises the most questions in the agile community. Self-organizing teams have been around since the 1960s. In my article: What are self-organizing teams in agile projects, I have already written in detail about this way of organization.

In the Scrum Guide 2017 you can read:

Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team.

In the Scrum Guide 2020 you can read:

Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how.

What self-managing for a Scrum Team exactly means is then described as follows:

The Scrum Team is responsible for all product-related activities from stakeholder collaboration, verification, maintenance, operation, experimentation, research and development, and anything else that might be required. They are structured and empowered by the organization to manage their own work. Working in Sprints at a sustainable pace improves the Scrum Team’s focus and consistency.

Only One Word Has Changed but Not How the Team Works

Even before the new Scrum Guide, team members coordinated: who does what, when, and how. Nothing has changed in the “work organization” in the team. There is probably only an attempt to make it clearer to the outside world how the team acts and to what degree the Scrum Team is responsible.

The term “self-organization” was probably too “fuzzy” for Ken Schwaber and Jeff Sutherland, because every system is self-organized to a certain degree. People basically self-organize, whether they do so directionally or chaotically. But another clue how the two gentlemen came to “self-managing” is, they probably looked into Richard Hickman’s Authority Matrix. What’s behind it? Read on to find out more.

The Authority Matrix by Richard Hackman

John Richard Hackman, PhD (1940-2013) was a leading expert on teams and performance-based groups in organizations. In his 2012 book, “Leading Teams: Setting the Stage for Great Performances”, he outlined his Authority Matrix and described four levels of giving authority to teams. Let’s look at Hackman’s four levels of team authority, starting with teams with the least authority:

  • Manager-led teams that leave team members only the authority for task execution while managers monitor and manage work processes, design the context, and set the direction. From our point of view, many expert groups in functional silos and traditional project management “teams” are practical examples of this set-up.
  • Self-managing teams put members not just in charge for task execution but also for managing their progress. Within IT, we see a lot of Kanban teams applying this approach, either focusing on team tasks or on team-bridging value streams.
  • Self-designing teams give members the authority to change the design of their team and/or aspects of the organizational context in which they operate. Most real management teams are in this position and some Scrum teams, especially when Lean/Agile is scaled.
  • Self-governing teams have responsibility for all four core functions as shown by corporate boards of directors, worker cooperatives, or start-ups.
The Authority-Matrix by Hackman describes self-managing teams
The Authority Matrix by Richard Hackman

So Where Does Self-Organization Fit In?

In Hackman’s hierarchy of authority, self-organizing agile teams would be classified as self-managing teams. Agile teams self-manage their work (which team member should do what, when, and how). However, Agile teams are not self-designing or self-governing. In other words, a self-organizing agile team has authority over its work and the process it uses, but not over who is on the team or what the team’s goal is, for example.

Is It Now Self-Organizing or Self-Managing?

In the introductory text, I asked you: Do you know the difference? From my point of view, you can call it either way. For me, it makes no difference. I prefer self-organizing because:

Self-organizing was described that way in the first published article on Scrum (1986 Harvard Business Review: The New New Product Development Game). The authors of that article, Takeuchi and Nonaka, considered self-organizing as one of the six characteristics necessary to create a “fast, flexible process.” Also, Self-organizing or Self-directed Work Team (SDWTs) have been around since the 1960s – so have a long history.

Wouldn’t Self-Designing Also Be Possible?

No one prevents a team from growing and taking on more responsibility. The company management naturally asks itself: How much self-organization do we want to have in our company at all? Should a team even be allowed to determine its own team members or dismiss members? Wouldn’t that already be a self-desgining team? I think a Scrum team should be able to do this, or at least have a relevant say in it.

So, now we are at the end of this article and you might ask yourself: “So much text, just because of two words”? Yes, that amazed me too! Self-organization is a central element in Scrum and in agile project management. Therefore, this text was probably useful after all.

Literature for this article:

Here Is Even More Knowledge

This was an overview about self-organizing and self-managing Scrum Teams. What is your experience with such teams? Do you agree with my statements in this article or do you have a different opinion? Share your experience with the readers in the comment box below so we can all get a broader view. Thank you!
Would you like to learn more about how to make your projects more successful with Scrum and Agile Project Management? My book Scrum – How to Successfully Apply Agile Project Management and Scrum takes you an important step further!

Do you know somebody who might be interested in this article? Then forward it or share it. Thank you!

SharePoint Online for Project Management

Posted in Agile Project Management.

Leave a Reply

Your email address will not be published.