Scrum teams are defined as meeting certain 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 between 3 and 9 people (prior to 2007, Scrum suggested that the team be between 5 and 9; more recently, that size was changed to 3-9).
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 new Advanced Certified ScrumMaster program. We offer this program both as a classroom event as well as in the new OnDemand format that allows students to take the class at their pace and practice REAL skills as they are ready. If you’re really serious about understanding Scrum and how to be a great ScrumMaster, go check out the course information.

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

Do These Behaviors Sound Familiar?

Case in point: a very common dysfunction during an organization’s transformation to Scrum from whatever they were doing are teams that don’t really seem to know what to do next. Behaviors we tend to see from these teams include (but are DEFINITELY 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 teams performance,
• expecting management to tell the team how to improve,
• working toward improving metrics rather than actually improving the team.

There’s 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-Organizing Teams

Self-organization is defined as “the ability of a system to spontaneously arrange its components or elements in a purposeful (non-random) manner, under appropriate conditions but without the help of an external agency.”[1]

The benefits of self-organization include:

• faster decision-making– 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 leaders and team members– with team members more responsible for tracking and maintaining their own work, more capacity is available for good leadership, and
• use of full human potential– people have amazing potential, only a small portion of which is tapped in command-and-control situations.

The Importance of Self-Organizing Teams

The importance of self-organizational principles cannot be understated. Self-organizing 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.
• Are able to become extremely 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 based on the concepts of maximizing mutual benefit rather than minimizing conflict– Instead of creating processes, practices, or policies aimed at minimizing conflict (for example, in order 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-organizing 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-organizing teams improve their own coordination by getting everyone involved on a frequent basis 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-Organizing teams decide how much work they can complete and how they are going to get that work done during a Sprint. This is not just about how the team decides to solve a particular Product Backlog Item (PBI), but also how they are going to leverage their skills to get the job done. The team decides things like:

• Who’s going to work with whom?
• Who’s is going to work on which tasks?
• When is the work going to get done?
• What tools do we use?

Self-organizing teams adapt as they go through the Sprint, moving the right people to the right tasks on a daily basis. As situations change, the team adapts. Team members self-select for tasks (no one decides for them 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-Organizing teams OWN their Sprint Backlogs and work together to build the right product right.

Look at how they are working and are constantly finding better ways to get things done. They keep their meetings short by keeping each other focused on the task at hand. They OWN responsibility for trying as best they can to get done what was forecasted for the Sprint. Whether they get their entire forecasted content DONE by the end of the Sprint, a self-managing team then takes a critical look at their productivity and their 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 get your team and your management onboard to help fix the situation?

Scrum is not just about backlogs and prioritization. Self-organizing work teams have always proven that they can achieve higher levels of performance (working smarter, not harder) — that’s if you’re lucky enough to be on a truly self-organizing work team. Scrum DOES give us a way to make it happen, but it’s the Scrum Team member that 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 team self-organize, keep in mind that someone has to organize. If it’s not the team, management WILL do it. But I’ve worked with a lot of managers in my day (and been one myself for almost 20 years). There’s a lot of managers out there that, 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 (as opposed to “manage” the team) and specifically how to properly respond to mistakes.

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 keep improving 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 make sure they know what the standard is. Then, support their efforts to perform at that standard.

Set the Guard Rails.

Like people, teams need to know what the boundaries are — what decisions are they 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 that the team produces a status report every week. This isn’t a negotiable item – the team is likely required by management to produce a weekly status report.
• The DONEness Definition may be written to include several artifacts (documents) that must be updated with each feature that the team builds. Again, these are likely not negotiable and thus the team is required to create them.

Set Clear Goals.

Teams are more motivated and work most effectively when they have clear goals. Make sure that your teams know what is expected of them and why what they are doing is important. 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.

Changing team membership on a regular basis causes the team to have 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.