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.

By the time Adam Smith wrote The Wealth of Nations in 1776, pin-making had become specialized to the point where it could involve eighteen different specialists. Smith wrote that, “One man draws out the wire, another straights it, a third cuts it, a fourth points it, a fifth grinds it at the top for receiving the head…”

Not only has this trend continued through the present day, it is likely accelerating. A recent article in Harvard Business Review, “The Age of Hyperspecialization“, claims that as work becomes more knowledge-based and as communication technology improves, it is easier to split work into smaller and smaller pieces.

The article talks about about a number of companies and business models. But, in particular, presents a site called TopCoder, which allows companies to present development work that needs to be done. The work is then bid on and completed by hyperspecialists all over the world: a designer in the US, an analyst in Kiev, an architect in Bangalore, a programmer in Beijing, and so on.

These individuals do not work together as a team. Rather they have very specific artifacts to produce. The artifacts are defined in a very sequential (“waterfall”) process.

It is interesting to think about a grand, sweeping trend like the one toward hyperspecialization in contrast to agile development. Agile does not at all require individuals to be generalists, but individuals are expected to work together as a team. The handoff-driven model created by hyperspecialization and used on sites like TopCoder are anything but agile.

So where does this go? Is agile at odds with a 300-year trend? It could be. Or, perhaps teams will evolve more agile ways of working within the trend toward hyperspcialization.

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.

Project Success Sliders were initially created and devised by Rob Thomsett in his book, Radical Project Management. Sliders are a way for a product owner (or collectively all key stakeholders) to convey expectations to the team. By default there are six sliders, each of which reflects some dimension by which project success can be determined—for example, delivery of all planned features, quality, meeting an agreed upon schedule. This can be seen in this figure:

Each slider starts at a value of three along a continuum from one to five. The product owner or key stakeholders then moves sliders up or down to reflect the appropriate mix of factors in determining the success of the project. Stakeholders are prevented from simply moving all sliders to five by a rule that that every movement up must be offset by a corresponding move down.

If sliders are out of balance (e.g., too many have been moved to higher numbers), the green checkmark in the upper right is replaced by a red circle and number showing how far out of balance the sliders are as you can see in this figure:

Sliders are brought back into balance when the product owner or stakeholders made additional adjustments to the sliders as shown in this example:

Project success sliders can be a useful way to create an appropriate dialogue between stakeholders and team members about how success will be defined on the project.

Be sure to check out our Project Success Sliders tool and let me know what you think

1. Does the structure accentuate the strengths, shore up the weaknesses, and support the motivations of the team members? People don’t enjoy being on a team where they are not able to make use of their strengths or are constantly required to do things they are bad at. Good team members are willing to do whatever is necessary for the success of the project, but that doesn’t relieve us from the goal of trying to find a team structure that accentuates the strengths of as many team members as possible.
2. Does the structure minimize the number of people required to be on two teams (and avoid having anyone on three)? A well-conceived team structure for an organization that is not attempting to do too many concurrent projects will reduce multitasking to a tolerable level. If more than 20% of all team members belong to more than one team, consider an alternative team design or deferring some projects.
3. Does the structure maximize the amount of time that teams will remain together?
   If other factors are equal, you should favor a design that allows team membership to persist over a longer period. It takes time for individuals to learn to work well together. Amortize the cost of that learning over a longer period by trying to leave teams together as long as possible.
4. Are component teams used only in limited and easily justifiable cases? Most teams should be created around the end-to-end delivery of working features. In some cases, it is acceptable to have a component team developing reusable user interface components, providing access to a database, or similar functionality. But these should be exceptions.
5. Will you be able to feed most teams with two pizzas? Given the compelling productivity and quality advantages of small teams, the majority of teams in a good design should have five to nine members.
6. Does the structure minimize the number of communication paths between teams? A poor team structure design will result in a seemingly infinite number of communication paths between teams. Teams will find themselves unable to complete any work without coordinating first with too many other teams. Some inter-team coordination will always be required. But, if a team that wants to add a new field on a form is required to coordinate that effort with three other teams, as I’ve seen, then the communication overhead is too high.
7. Does the structure encourage teams to communicate who wouldn’t otherwise do so? Some teams will just naturally communicate with each other. An effective team design encourages communication among teams or individuals who should communicate but may not do so on their own accord. In fact, one valid reason to put someone on two teams is that doing so will increase the communication between those teams. If lack of communication between two teams is a concern, splitting a person’s time between those two teams is easily justified.
8. Does the design support a clear understanding of accountability? A well-designed team structure will reinforce the concept of a shared, all-teams accountability for the overall success of the project while providing each team with clear indicators of their unique accountabilities.
9. Did team members have input into the design of the team? During the early stages of your transition to Scrum, this may not be possible. Individuals may not yet have enough experience delivering working, tested, ready-to-use products by the end of each sprint. Similarly, some individuals may be initially too resistant to Scrum to contribute to team structure discussions in constructive ways. In these cases, it is acceptable for managers outside the team to design an initial team structure.

An effective team structure is one of the most critical factors in the success of any agile endeavor. Poorly structured teams will lead to inefficient teamwork, excessive integration challenges, multitasking, low morale and other problems. By using these nine questions to carefully consider how teams are organized you can avoid these problems.


Nine Questions to Assess Team Structure 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.

]]> http://blog.mountaingoatsoftware.com/nine-questions-to-assess-team-structure/feed 11 http://blog.mountaingoatsoftware.com/distributed-teams-build-trust-through-early-progress http://blog.mountaingoatsoftware.com/distributed-teams-build-trust-through-early-progress#comments Mon, 22 Feb 2010 17:48:42 +0000 Mike Cohn http://blog.mountaingoatsoftware.com/?p=655 Critical to creating a coherent team is building trust among team members. This is much more difficult on a distributed team. Unable to rely on repeated, frequent face-to-face communication, distributed teams need to take other measures to build trust. Traveling ambassadors, starting meetings with casual conversations, occasional in-person meetings of the full team, working agreements, and similar activities all help. What also helps is early pressure for the team to produce working software by the end of each sprint, even the earliest ones.

Unfortunately, many projects schedule too much time for teambuilding exercises and discussions too early in the project. This is a common and dangerous agile project management mistake, as shown by research from Professor Lynda Gratton and her coauthors, as published in the MIT Sloan Management Review.

Guiding these diverse teams to success requires some counterintuitive management practices. In particular, team leaders should focus on tasks at the early stages, rather than on interpersonal relationships, and then switch to relationship building when the time is right. (Gratton, Voigt, and Erickson. “Bridging faultlines in diverse teams.” MIT Sloan Management Review, Summer 2007, 22–29.)

Though this research suggests that the early focus should be on tasks, I do not mean to suggest that product owners or ScrumMasters should be assigning tasks to developers. Rather, I mean that these leaders should emphasize the need for the team to make demonstrable progress even in the early sprints. The problem with an early emphasis on relationship building is that it encourages less-than-ideal subgroups to form. Any large group will inevitably split into subgroups. If these subgroups are allowed to form too early they will form around surface-level attributes—Americans, Swedes, C++ programmers, Java programmers, female database engineers, male programmers, and so on. As Gratton and her coauthors write, “Simply put, in a team’s early going, the more people interact with one another, the more likely they are to make snap judgments and to emphasize their differences” (26).

What we’d like to do is defer relationship building until team members have learned more significant things about each other, such as specific skills, competencies, approaches to work, and so on. This is done through early emphasis on progress rather than relationship building. The subgroups that form at that time will be based on the mutual need to work together to develop the product. To develop a particular user story from the product backlog, you and I need to work together. In doing so we learn each other’s skills and specific competencies. I come to know you not just as a Java programmer but as a Java programmer with a real passion and strength for automated unit testing. You find that I am not just a DBA, but one who is strong at optimizing SQL statements.

Teams with subgroups formed around compatible skills, attitudes, approaches to work, and so on are less likely to lead to a later breakdown in trust than subgroups formed on superficial attributes (such as American, Swede, programmer, tester, and so on). Think back to one or more troubled teams you were a member of. Odds are that conflict on those teams was of an us-versus-them nature based on superficial attributes: this office versus that office, programmer versus DBA, Linux fanatics versus Windows fanatics. When teams feel an immediate need to make progress, those types of subgroups do not have time to form.

After a team has worked together for a few sprints, shift the emphasis toward relationship building by incorporating more social activities and shared downtime into the sprints. A team needs to have a sufficient amount of shared experience before social activities and relationship building can be useful. But when that has been achieved, “instilling confidence in the team and creating opportunities to socialize at that point helps the development of new abilities and allows the team to grow” (29).

I want to be clear that I am not saying that no time for socialization should be included at the start of a project. Seeding visits and whole-team, in-person get-togethers at the start of a project for its initial release planning can be very useful. Three points are key here:

• First, the project should start with intensity and a focus on early demonstrations of progress.
• Second, the entire “budget” for socialization should not be spent in the first couple of sprints.
• Third, early social activities should tie into the work of the project, such as bringing a team together for release planning.
]]> http://blog.mountaingoatsoftware.com/distributed-teams-build-trust-through-early-progress/feed 12 http://blog.mountaingoatsoftware.com/removing-team-members http://blog.mountaingoatsoftware.com/removing-team-members#comments Tue, 26 Jan 2010 17:50:40 +0000 Mike Cohn http://blog.mountaingoatsoftware.com/?p=662 People often ask me whether teams should have the right to vote members off. To help answer that question, let me share a story with you.

I was at a conference when I saw Derek walking toward me. I had first met him a year earlier when I taught a class at his company. I had been back a handful of times, and always enjoyed talking with him. We hadn’t talked in three months and I thought this would be a good chance to catch up. As we said hello, I could tell something was really bothering him, so we sat down to talk. Derek told me during his team’s sprint review the week before, they asked him to resign as their ScrumMaster and leave the team. He did and was looking around within his company to find another Scrum team to join.

Although rare, Derek’s situation is not unheard of. The question of whether the team has the authority to remove a member is a common topic. Commonly referred to as “voting someone off the island,” removing a team member is not an action to be considered lightly. Every effort should be made to address problems that might lead some or all project team members to feel they will be better off without a particular member.

An agile or Scrum team alone should not have the right to remove someone from the team. As I detailed in Chapter 12 of Succeeding with Agile, self-organization does not occur in a vacuum. The right preconditions must be in place for self-organization to occur. Individuals then self-organize within boundaries established by the organization. This is referred to as the CDE model, which says that for self-organization to occur there must be a container that bounds the individuals, some differences among them, and transforming exchanges.

Chapter 12 in Succeeding with Agile also makes the point that leaders within the organization exert influence on the self-organizing team by adjusting its containers, differences, and exchanges. For example, over time and through attrition a team might become too homogeneous. An astute scrum product owner, functional manager, or even ScrumMaster might counter by adding two new team members with radically different backgrounds, skills, decision-making styles, or so on. Doesn’t it seem possible—likely even, in this example—that a team might have a knee-jerk reaction and vote the new, nonconforming individuals off the team, negating the work of the leader who deliberately added them? Ultimate authority for team composition, therefore, must reside with the leadership of the organization. Those leaders should listen, of course, when team members say they think they’d be more productive without a member. But, team members should not be allowed on their own to remove someone from the team.

]]> http://blog.mountaingoatsoftware.com/removing-team-members/feed 18 http://blog.mountaingoatsoftware.com/the-role-of-leaders-on-a-self-organizing-team http://blog.mountaingoatsoftware.com/the-role-of-leaders-on-a-self-organizing-team#comments Thu, 07 Jan 2010 15:51:21 +0000 Mike Cohn http://blog.mountaingoatsoftware.com/?p=483 Self-organization is a fundamental concept in agile project management. The Agile Manifesto includes the principle, “The best architectures, requirements, and designs emerge from self-organizing teams.” Yet a common misconception about agile project management approaches is that because of this reliance on self-organizing teams, there is little or no role for leaders of agile teams. Nothing could be further from the truth. In The Biology of Business, Philip Anderson refutes this mistaken assumption.

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.

]]> http://blog.mountaingoatsoftware.com/the-role-of-leaders-on-a-self-organizing-team/feed 23 http://blog.mountaingoatsoftware.com/the-fallacy-of-one-throat-to-choke http://blog.mountaingoatsoftware.com/the-fallacy-of-one-throat-to-choke#comments Thu, 10 Dec 2009 15:43:21 +0000 Mike Cohn http://blog.mountaingoatsoftware.com/?p=467 In speaking with some agile teams and agile project management consultants I occasionally hear two statements that I strongly disagree with. These statements are that “the product owner is the single wringable neck on the project” or that the “product owner is the one throat to choke.” These each mean the same thing, that in an agile project, the product owner is the person ultimately responsible for the success of the project.

This is wrong, however. On an agile project—as well as in many other cases—there is no single, wringable neck. To say there is a way of releasing the rest of the team from responsibility. And this is clearly wrong.

From a manager’s perspective it can be nice to always be able to point to one person and say, “That’s who I’ll blame if things go wrong.” Howerver in agile project management the “one throat to choke” argument is false. Historically, there may be one person who takes the blame for things when they go wrong, but that doesn’t mean that person was responsible for the failure.

Take the case of a sports team. At the start of a new season, who on a sports team do we say we’ll hold responsible for winning the championship? The coach? The owner? The star player? Teams that win championships find a way to win games, no matter the circumstances. If the game plan isn’t working, the coach and players adapt. If the star player is having a bad day, someone else steps up. The whole team feels responsible for winning somehow, some way. If the team loses, it may be tempting to blame one person or another, but the team knows that each one of them is accountable for the loss. It’s never just one person’s fault. In reality, there is no single, wringable neck.

Consider a nonsports analogy. If both parents were involved in raising a child (and assuming one of them isn’t abusive or obviously negligent), which parent is the one throat to choke if a child grows up to be a convicted felon? There is a reason we call it a parental unit. Raising a child is a team effort.

The only way to ever create an environment of shared ownership and responsibility is to let go of the notion of having one throat to choke. That doesn’t mean no one is responsible. That means that on a successful team, the team members must do their part, or even go beyond a perceived role, to ensure that the team reaches its goals.

]]> http://blog.mountaingoatsoftware.com/the-fallacy-of-one-throat-to-choke/feed 73