However, there are some occasions when you may want to rotate. The most common is when you want to create learning opportunities. For example, if team members are struggling to understand the duties of the ScrumMaster, they may want to consider rotating each team member through the role. This may allow each to develop an understanding of what it means to be a ScrumMaster. Similarly, if a team identifies four or five good ScrumMaster candidates among their ranks, it may want to rotate among them, giving each a chance to try the role. Then by considering the performance of each, the team will hopefully be able to choose the most appropriate ScrumMaster.

Bob Schatz and Ibrahim Abdelshafi of Primavera Systems point out another reason why rotating might be useful.

With time the team can begin to treat this position as their manager. And the person in that position typically detects and dutifully fills the apparent need. The result is a breakdown in the team’s self-management practice. By rotating the responsibility at the start of each sprint, it diffuses the role and makes it a shared team responsibility and establishes a balance of power. (The Agile Marathon in the Proceedings of Agile 2006)

So, although it is possible to rotate the job of ScrumMaster, I recommend doing it only for specific reasons, such as those just given, and only temporarily. Rotating should not be a permanent practice. There are simply too many problems with it, including the following:

• Someone who has rotated into the role usually has other, non-ScrumMaster tasks to perform during the sprint, and these often take priority.
• It’s hard to train enough people to do the role well.
• Some people will use their time as ScrumMaster to try to push through changes to the process.
• Designating someone as ScrumMaster for a sprint or two does not automatically make someone value the job, which can lead to ScrumMasters who think Scrum is a mistake.

After achieving some easy, early improvement from Scrum, some teams become self-satisfied. They stop seeking further improvements. It is up to the ScrumMasters of those teams to protect them from this complacency.

So, a good ScrumMaster will occasionally have to stand up to an aggressive product owner and say, “Now is not the time to push this team any harder. They’re working as hard as they can and if pushed more, they’re likely to get sloppy.” But my advice to good ScrumMasters is that for each time they say this, they should later tell the product owner something like, “Now’s the time. The team is rested. They’re ready. Let’s see what they can do. It’s time to push them for more.”

If you’re a ScrumMaster, be sure to protect your team from both types of problem.

In a recent issue of the Harvard Business Review (October 2010), Professor Hayagreeva Rao wrote about the results of asking his MBA students to design the job of a 17th century pirate ship captain. His MBA students designed a job that lumped together two areas of responsibility:

1. star tasks–the strategic work of deciding which ships to attack, commanding the crew during battle, negotiating with other captains, and so on
2. guardian tasks–the operational work of distributing their pirate booty, settling conflict, punishing crew members, and organizing care for the wounded

The problem with this job description is that it mixes star and guardian tasks. As Professor Rao points out, there are very few individuals who excel at both types of task. Star tasks require risk-taking and entrepreneurship whereas guardian tasks require conscientiousness and consistency. A pirate captain good at identifying ships to attack and at leading his crew into battle would likely be bored by the administrative minutiae of the guardian tasks.

Professor Rao claims that people tend to spend most of their effort on the tasks they are good at (and presumably enjoy). My experience certainly bears this out.

Pirates avoided this problem by having a captain responsible for the star tasks and a quartermaster general responsible for the guardian tasks.

So what does the decidedly non-collaborative, non-agile environment of a pirate ship have to do with agile project management? Well, it turns out that the product owner is largely performing star tasks and the ScrumMaster is largely performing guardian tasks. And so, for the same reason that pirate ships had separate individuals as captain and quartermaster general, our agile software development projects should have separate ScrumMasters and product owners.

Self-organization does not mean that workers instead of managers engineer an organization design. It does not mean letting people do whatever they want to do. It means that management commits to guiding the evolution of behaviors that emerge from the interaction of independent agents instead of specifying in advance what effective behavior is.

Self-organizing teams are not free from management control. Management chooses for them what product to build or often chooses who will work on their project, but they are nonetheless self-organizing. Neither are they free from influence. Early references to Scrum were clear about this. In “The New New Product Development Game” from 1986, Takeuchi and Nonaka write that “subtle control is also consistent with the self-organizing character of project teams.”

An agile or Scrum team’s job is to self-organize around the challenges, and within the boundaries and constraints, put in place by management. Management’s job is to come up with appropriate challenges and remove impediments to self-organization. That being said, the fewer constraints or controls put on a team, the better. If leaders overly constrain how an agile team solves the challenge given to it, self-organization will not occur. The team will shut down; because it has already been told so much about the challenge and how to solve it, it will wait to hear the rest. So how does an agile leader achieve the subtle balance between command and influence?

Suppose you are a ScrumMaster for a team. You’ve noticed that one team member, Jeff, is domineering and no one is willing to stand up to him. This team has self-organized—it has chosen to let Jeff make all key decisions. As the ScrumMaster for this team, though, you recognize that if Jeff continues to make all the decisions on his own it will impede the team’s efforts to improve. You consider having a private conversation with Jeff, but that is unlikely to change much. You contemplate stepping in and overruling some decisions he makes, but if you do it once the team will expect you to continue to do so, which won’t be good.

Then you begin thinking about the agile principles of subtle control and influence. Perhaps you decide to change the team’s dynamics by asking management to add someone new to the agile team, someone who is likely to stand up to Jeff. Or maybe you suggest to the enterprise architecture team that someone from its group attend key meetings—someone with the experience and background to challenge Jeff. No matter the specific problem, if you see that the team has self-organized in a way that impedes it, it is your responsibility to find a way to agitate, stir up, or otherwise disturb the status quo, so that the team adjusts, hopefully reorganizing in a more productive way.

There is more to leading a self-organizing team than buying pizza and getting out of the way. Leaders influence teams in subtle and indirect ways. It is impossible for a leader to accurately predict how a team will respond to a change, whether that change is a different team composition, new standards of performance, a vicarious selection system, or so on. Leaders do not have all the answers. What they do have is the ability to agitate teams (and the organization itself) toward becoming more agile.

For more details on how leaders can help teams and their organizations grow more agile, see Chapter 12 of Succeeding with Agile.

The Role of Leaders on a Self-Organizing Team by Mike Cohn is licensed under a Creative Commons Attribution-No Derivative Works 3.0 United States License.
Based on a work at blog.mountaingoatsoftware.com.

As a Mac user, I’ve been paying a bit of extra attention today (and over the past few weeks) to what shakeups might be in store at Apple during Jobs’ absence. I read this today and want to share it as a great example of a ScrumMaster removing an impediment. It’s about Tim Cook, Apple’s current COO, who is likely to replace Jobs:

Tim Cook arrived at Apple (AAPL, Fortune 500) in 1998 from Compaq Computer. He was a 16-year computer-industry veteran – he’d worked for IBM (IBM, Fortune 500) for 12 of those years – with a mandate to clean up the atrocious state of Apple’s manufacturing, distribution, and supply apparatus. One day back then, he convened a meeting with his team, and the discussion turned to a particular problem in Asia.

“This is really bad,” Cook told the group. “Someone should be in China driving this.” Thirty minutes into that meeting Cook looked at Sabih Khan, a key operations executive, and abruptly asked, without a trace of emotion, “Why are you still here?”

Khan, who remains one of Cook’s top lieutenants to this day, immediately stood up, drove to San Francisco International Airport, and, without a change of clothes, booked a flight to China with no return date.

Khan sounds like a perfect ScrumMaster to me. He heard about the impediment and within thirty minutes was on a plane to resolve the problem.

Let’s hope, Steve Jobs’ doctors are able to remove all impediments in the way of his return to good health.

For the full article reference above, see http://money.cnn.com/2009/01/15/technology/cook_apple.fortune/index.htm