With a nod to the guys at Freakonomics, what do birds, soccer, and Agile Teams have in common? They are all examples of spontaneous order, or self-organization.

Flocking behavior is a form of self-organization found in nature. Flocks have three simple rules: separation, alignment, and cohesion. With just those rules, the flock is able to move as if it were a single complex organism. Consider: hundreds of birds taking off and flying in a tight group, wind swirling — this should be total chaos.
In soccer, players are assigned positions (roles) and are told their responsibilities. Once the game starts, the players have to adjust to the other team’s moves. Players have to trust that their teammates will move to the right places, pass the ball at the right time, and shoot on net when appropriate. The coach has very little control during the run of play, and the referee just observes for compliance purposes. The team is responsible for the results.
An agile team operates under the Agile Manifesto and the supporting principles, one of which is this: “The best architectures, requirements, and designs emerge from self-organizing teams.”

That’s easy to say, but what are self-organizing teams? How can you create a container in which teams are more likely to self-organize? What do we mean by “team” anyway?

Four main attributes of a real team

Teams have a common purpose

Ask yourself: does my team know the mission and vision of the project? Do they know how that vision fits with the strategic direction of the company? Can they see a direct line between the stories and tasks in each iteration with the Project Charter and Business Case? Does each iteration begin with a review of the goals for the next release?

If your answer to any of the questions is “no”, why not? What makes you think the team can self-organize and deliver good results if they don’t know why they are doing it? What is their motivation?

Teams have clear boundaries

We can’t expect teams to self-organize without knowing what the limits are. The team knows the extent of their authority in terms of information flow, alignment with other organizational units, resources or decision-making policies. In a regulated environment, some boundaries are very clear and necessary. However, some limits are arbitrary or are there because “that’s the way it’s always been”. Teams should be encouraged to question every limitation. A team that knows the limits, and the reasons they exist, will be better able to operate effectively within them.

Consider whether your teams ask questions or simply follow your lead. What are some techniques you can use to encourage questions? One possibility is to use a POWER (Purpose, Outcomes, WIIFM, Evaluate, Results) agenda for meetings allowing your team to prepare questions ahead of meetings. Try statying quiet for longer than you normally would. Use the WAIT acronym to always ask yourself: Why Am I Talking?

Teams stay together

The third feature of real teams is stability over some reasonable period of time. What happens if I remove any of the rocks in this structure? Any change in the structure forces rebuilding from the beginning. Even though (with each change in the team) they might become more efficient at Forming, Storming, and Norming, on the way to Performing, they still have to go through every stage. A team in constant turmoil, with frequent turnover, is unlikely to perform at a high level. The team almost definitely will not reach a predictable velocity, and so cannot really improve in a methodical way.

Teams have authority

The authority to self-manage within the given boundaries allows the team to use all of its experience and expertise and creates an environment in which emergent design can thrive. This type of freedom leads to the simplest solutions to the business problems.

How do you “grant” authority to the team? Ask more questions, instead of giving answers. Believe me when I say that Agile Coaches have opinions about technical decisions made by teams. I think one of the hardest parts of our job is staying silent when we disagree with a team decision. The Scrum Master’s role is also to let the team make decisions. You can’t let them make disastrous choices, but you should let them choose options with which you disagree. There are multiple feedback loops built into Scrum that will let you and the team examine whether the choice works out. Even though you might have some technical expertise, giving technical advice is not the role of the Scrum Master. If “technical expert” is a secondary role for you, make it clear when you are taking off your Scrum Master hat and putting on your technical hat. Some Scrum Masters literally use a hat to indicate the role change.

When deciding the limits of the team’s authority, you need to consider who is best able to handle the functions of the unit.

Four main functions of an organization

Setting direction

Teams need someone to set the directions for the team, i.e. specifying the organizational objectives, the core purpose or mission that requires the tasks so that they are all pulling on the same direction. Typically, that is the Product Owner, but that role is a Scrum construct and doesn’t necessarily exist on every team. In any case, your company might have Product Owners, Chief Product Owners, Application Owners, Executive Sponsors, and other stakeholders who probably have part of the mission, vision, and direction. The team needs to know who the single voice is on the subject of direction.

Organizational design

The second function of an organization is for someone to be responsible for designing the performing unit and arrange for needed organizational support for the work i.e. structuring tasks, deciding who will be involved in performing them, establishing norms of conduct for work behavior, and making sure teams members have the resources and assistance they need to carry out their work. Some of this might be the Scrum Master’s job, but some can be performed by the team. The more that the team handles on its own, the more likely they are to be committed to the work.

Monitoring performance

Teams need to determine who is in the best position for monitoring and managing the work process, i.e. collecting and interpreting data about how the work is proceeding and initiating corrective action as needed. Scrum provides some standard tools for measuring progress, some that will automatically generate useful information when used correctly. However, none of that matters if the team isn’t looking at the data and taking action. The theory behind Scrum is empirical process control, and the pillars that support that theory are transparency, inspection, and adaptation. To be blunt, teams that aren’t using the data to improve their processes are not doing Scrum. Teams that don’t know how to use the data can’t do Scrum. Make sure your teams know what information is important, how to interpret it, and what actions are appropriate based on what they are seeing. Either your iteration review or retrospective are a perfect setting for examining the data and discussing trends.

Oh yeah, getting stuff done

Of course, the fourth function of an organization is someone to execute the work, i.e. apply physical or mental energy to accomplish task. That should be almost everyone on the team, but it is worth noting who is involved in the work each iteration. A team will find it difficult to self-organize if they aren’t clear about what each person is willing and able to do.

Motivation

Nothing motivates a team as much as accepting the responsibility for fulfilling commitments that it made itself. – Ken Schwaber

If we accept Ken Schwaber’s words as true, then how do we create a context in which team responsibility for commitments is more likely to emerge?

Give them the information

More and more, I see teams trying to shorten the iteration planning. They don’t find the time valuable because they are given a set of stories and are not encouraged to ask questions unless there is a technical concern. A high-functioning team loves the planning process because it is the best time to ask powerful, probing questions. Technical expertise comes from curiosity, but we stifle curiosity when we don’t examine why a customer needs a certain feature or function, and we stifle creativity when we don’t examine alternatives to developing a minimally viable product. More information = more motivation.

Give them resources

Teams will find it difficult to self-organize around the work if infrastructure is an impediment. Applying some variation of Maslow’s Hierarchy of Needs, organizations should be examining the basic items teams need to continue to exist in a healthy way.

Give them education

Teams need training, coaching and technical assistance. In the hierarchy of needs, this is a level above the basics, but it is critical to project success. We talk a lot about cross-functional teams, but we don’t mean that everyone on the team is interchangeable. We mean that a Scrum team has all the capability to produce working software without depending on outside support. This is not always possible, but teams should be striving to move closer to independence with every iteration.

Give them rewards

The idea of economic, or even symbolic, rewards has been shown to be demotivating according to studies conducted in the past decade. Daniel Pink wrote about another way to motivate employees in his book Drive.

Autonomy – Employees desire autonomy over the main areas of their work. The want some control over time (when they do it), technique (how they do it), and task (what they do).

Mastery – Employees want to become better at something that matters to them.

Purpose – Employees desire to contribute to a cause greater and more enduring than themselves.

Keep in mind that increasing employee satisfaction through self-determination has an effect on traditional compensation models. I’m not suggesting that your organization must immediately change its financial reward system. I am suggesting that that system may not have the intended effect and that supplementing it with modern ideas about motivation is worth considering.

So if we:

Give our teams a compelling mission and describe the product vision;
Surround our teams with the appropriate sub-systems:
- Reward and Information to motivate and propel them,
- Education and Infrastructure to enable them;
And create a container in which the team:
- Develops goals, guidelines and policies,
- Takes advantage of the broad range of knowledge, experience, education, age, gender, and cultural backgrounds,
- And freely exchanges information;

we are more likely to have a team that can easily respond to change. What’s stopping us?

Change is hard

Many factors highlight the need to change how organizations are run. To become more agile, we need the power and authority to be with the people closer to the customer. We have to trust them with information and give them time to think, learn and improve. At the same time, bureaucracy needs to be reduced if not eliminated. We need to be Lean.

The only way to achieve these goals is to empower our teams. We have to allow them to use their expertise, not just to execute their work but to monitor and control themselves, make their own decisions and design their processes.

Situational Leadership model

As the organization and teams mature, we need to change our leadership behaviors from highly directive (lower right on this chart) to coaching, supporting, and eventually delegating responsibility.

High Directive

Set goals
Organizing
Define time boxes
Give directions
Check up (control)

Low Directive

Supply support
Communication
Collaboration improving
Active listening
Give relational feedback

First steps toward self-organization

Overcoming inertia, i.e. taking the first step, is always the hardest part. It is especially difficult when you don’t know what the first step should be, so I’ve drafted a list of some first steps you might consider in your organizations.

Make sure teams understand the mission and vision and their part in making it happen
Talk about boundaries in terms of information flow, alignment with other organizational units, resources or decision-making policies
Do whatever possible to stabilize the team structure and maintain it
Decide, with the team, who has the authority to:

Set the directions for the team
Design the team and get organizational support for the work
Establish norms for work behavior
Make sure teams have the resources they need to do their work
Collect and interpret data about how the work is proceeding
Initiate corrective action as needed
Execute the work

I hope you find this article useful on your path to self-organized teams. It is important to note that self-organization can’t happen overnight: The Neuroscience of Agile Leadership.

Please subscribe and share this blog using the widgets below and Follow me @QuietAgilist or Connect with me on LinkedIn to get updated when I post a new entry. It's free with no obligation!