Updated January 19, 2025 - changed self-organizing to self-managing and other related changes.

Scrum teams are defined as meeting specific criteria:

  1. Scrum teams should have the skills on the team to get the job done that they are going to be asked to do.

  2. The team should be no more than 12 people (before 2007, Scrum suggested that the team be between 5 and 9; then the size was changed to 3-9; in 2020, Scrum set the limit to 10 developers plus a Scrum Master and a Product Owner).

  3. The team should be self-organizing. It’s the last part I’d like to talk about in this blog post.

By the way, self-organization is a topic covered in the Advanced ScrumMastering online training program. If you're serious about understanding Scrum and how to be a great ScrumMaster, check out the course!

When I teach or coach people about Scrum, we talk about self-managing — but do we ever REALLY give it enough time? Do we ever really understand it? Sometimes I wonder…

Do These Behaviors Sound Familiar?

Case in point: a pervasive dysfunction during an organization's transformation to Scrum are teams where the developers don’t seem to know what to do next. Behaviors we tend to see from these teams include (but are not limited to):

  • waiting to be assigned to a task on the Sprint Backlog,

  • assigning themselves to a task on the Sprint Backlog and then going off to work on it by themselves,

  • delegating planning and estimation tasks to the “senior” people on the team,

  • expecting a “lead” on the team to determine a design (solution),

  • letting someone else determine how much work they can do in a Sprint,

  • doing a poor retrospective (or none at all),

  • showing no concern for how to avoid problems that occurred in a Sprint,

  • showing no concern for how to improve the team’s performance,

  • expecting management to tell the team how to improve,

  • working toward improving metrics rather than improving the team.

There are probably several more common items that could be added to the list (and I’ll do that as I think of them). They all boil down to a lack of self-organization. Let’s take a quick look at both of these attributes.

The Benefits of Self-Managing Teams

Self-management in teams refers to the capacity of the team to organize, direct, and motivate its members towards achieving common goals without relying on external authority or management. This involves the team taking initiative in decision-making, problem-solving, and accountability for their outcomes. Under suitable conditions, self-managed teams harness each member's unique skills and insights to operate effectively, fostering a sense of autonomy and ownership among individuals, which ultimately drives performance and innovation. The benefits of self-management include:

  • faster decision-making with a team lead– no matter how effective and knowledgeable the “team leader,” they still become a bottleneck to team performance,

  • individual and team performance– without a team leader, team members are required to take greater responsibility and ownership,

  • redistribution of work between team members– with team members more responsible for tracking and maintaining their work, more capacity is available for good leadership and

  • use of full human potential– people have tremendous potential, only a tiny portion of which is tapped in command-and-control situations.

The Importance of Self-Organizing Teams

The importance of self-management principles cannot be understated. Self-managing teams:

  • Spontaneously respond to external interference (changes in priority, defects, etc.) and quickly regain their balance. When the functioning of a self-organizing team is interrupted by something (e.g., a team member leaves the company, the team faces a difficult technical challenge, a new manager doesn’t know how to allow the team to make decisions), the team will tend to modify their behavior and adapt to the new circumstances.

  • They can become highly productive due, in part, to their lack of dependence on the response of a centralized coordinator (“manager”). The effectiveness of a self-organizing team lies in its ability to “attack” the work it needs to do rather than waiting on the decisions of a single coordinator. Self-organizing teams are generally allowed to “pull” work from a backlog of ready work items when they are ready. Time is not wasted waiting for instructions.

  • Work that is based on the concepts of maximizing mutual benefit rather than minimizing conflict. Instead of creating processes, practices, or policies aimed at reducing conflict (for example, to avoid two people working on the same code at the same time, John owns all work in the “A” module, while Holly owns all of the “B” module work), self-managing teams adapt to the current circumstances and identify ways to work more effectively together.

  • Create more effective coordination due to multiple elements actively participating autonomously– self-managing teams improve their coordination by getting everyone involved frequently to assess (inspect) and adapt. This is called “operational awareness,” and even though it is arguably somewhat inefficient, the resulting improvements in coordination more than offset any inefficiencies.

Self-managing teams decide how much work they can complete and how they will get it done during a Sprint. This is not just about how the team chooses to solve a particular Product Backlog Item (PBI) but also how they will leverage their skills to get the job done. The team decides things like:

  • Who’s going to work with whom?

  • Who is going to work on which tasks?

  • When is the work going to get done?

  • What tools do we use?

Self-managing teams adapt through the Sprint, moving the right people to the right tasks daily. As situations change, the team adapts. Team members self-select for tasks (no one decides for anyone else which task to work on) and work together as miniature “tiger teams” to attack and complete a PBI as fast as they reasonably can.

Self-managing teams OWN their sprint backlogs and work together to build the right product right. Look at how they work and constantly find better ways to get things done. They keep their meetings short by keeping each other focused on the task. They are responsible for trying their best to get what was forecast for the Sprint. Whether they get their entire forecasted content DONE by the end of the Sprint, a self-managing team then critically looks at their productivity and performance and tries to find ways to improve.

Self-managing teams OWN their performance and productivity and take their accountability seriously. If you are on a Scrum team, ask yourself, “Do we OWN our Sprint Backlogs and make things happen?” If not, what’s happening instead, and how could you get your team and management on board to help fix it? Ask yourself, “Do we OWN our productivity and performance and seek ways to improve every Sprint?” Again, if not, what’s happening instead? How could you onboard your team and management to help fix the situation?

Scrum is not just about backlogs and prioritization. Self-organizing work teams have consistently proven that they can achieve higher performance levels (working smarter, not harder) if you’re lucky enough to be on a genuinely self-managing work team. Scrum DOES give us a way to make it happen, but the Scrum Team member bears responsibility for making a difference — not management.

Get your team to take accountability for themselves. We’re all adults here. And if you fear that your organization’s management won’t let your squad self-manager, remember that someone has to organize. If it’s not the team, management WILL do it. But I’ve worked with many managers in my day (and been one myself for almost 20 years). There are a lot of managers out there who, if they saw the teams taking ownership, those same managers would step back and say, “Go for it!”

What Do You Need to Do to Create a Self-Organizing Team?

Here are some steps you can take to create self-organizing teams in your organization:

Get Management Onboard

You can't self-organize unless the team is confident that their decisions will be supported by management. In addition, management needs to understand how to effectively coach a team (instead of "manage" the team) and precisely how to respond to mistakes appropriately.

Check Our Online FREE Training

Ready to take your team to the next level? Check out our free online courses designed specifically for building self-managing teams. These courses are packed with bold strategies, actionable insights, and hands-on tools that empower your team to thrive without micromanagement.

Don’t wait for change to happen—create it. Dive into our courses and discover how to cultivate autonomy and responsibility within your team. Transform the way you work together and unleash your team’s full potential. Get started today and redefine your approach to teamwork!

If You're a Manager...

Look at your teams as the tools you use to get work done. Keep them motivated, connect them to your customers and their purpose, and improve their skills through training and coaching. When they make a mistake, ask what can be done to 1) fix it and 2) never let it happen again -- but don't do the typical "Who did it?" unless you KNOW you have a performance problem. Hold your teams to a high and achievable standard and ensure they know it. Then, please support their efforts to perform at that standard.

Set the Guard Rails

Like people, teams need to know the boundaries and the decisions they are allowed to make, which are set and unchangeable. Ground rules and DONEness definitions can be used to define the constraints within which they must remain. For example:

  • Ground Rules may be written to ensure the team produces a weekly status report. This isn't a negotiable item - management likely requires the team to produce a weekly status report.

  • The DONEness Definition may include several artifacts (documents) that must be updated with each feature the team builds. Again, these are likely not negotiable; thus, the team must create them.

Set Clear Goals

Teams are more motivated and work most effectively when they have explicit goals. Ensure that your teams know what is expected of them and why what they are doing is essential. Repeat the message again and again and again.

Encourage Situational Leadership

Teams have no defined leaders, but team members (even new team members) should be encouraged to take leadership of, for example, a Product Backlog Item.

Keep Teams Together as Long as Possible

Regularly changing team membership causes the team to "reset" in their maturity. This translates into a loss of productivity and a loss of effectiveness. It will also result in a loss of self-organizational behavior. If teams change membership frequently, they should probably ensure that they document things like:

  • their values,

  • ground rules,

  • common procedures,

  • doneness definitions,

  • and so on.

This will make it easier for newcomers to understand the basics.

Previous
Previous

What Do Testers REALLY Do On a Scrum Team?

Next
Next

Don't Waste Time in Sprint "Capacity" Planning