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.

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.

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.

On more traditional, corporate projects, we see equivalent problems when teams organize around the layers of an application, including

• Reduced communication across the layers
• A feeling that design by contract is sufficient
• Ending sprints without a potentially shippable product increment

If structuring teams around the layers of an architecture is the wrong approach, what’s better? Rather than organizing around components, each team on a project can ideally be responsible for end-to-end delivery of working (tested) features. There are many advantages to organizing multiteam projects into feature teams:

• Feature teams are better able to evaluate the impact of design decisions. At the end of a sprint, a feature team will have built end-to-end functionality, traversing all levels of the technology stack of the application. This maximizes members’ learning about the product design decisions they made (Do users like the functionality as developed?) and about technical design decisions (How well did this implementation approach work for us?)
• Feature teams reduce waste created by hand-offs. Handing work from one group or individual to another is wasteful. In the case of a component team, there is the risk that too much or too little functionality will have been developed, that the wrong functionality has been developed, that some of the functionality is no longer needed, and so on.
• It ensures that the right people are talking. Because a feature team includes all skills needed to go from idea to running, tested feature, it ensures that the individuals with those skills communicate at least daily.
• Component teams create risk to the schedule. The work of a component team is valuable only after it has been integrated into the product by a feature team. The effort to integrate the component team’s work must be estimated by the feature team, whether it will occur in the same sprint during which it is developed (as is best) or in a later sprint. Estimating this type of effort is difficult because it requires the feature team to estimate the integration work without knowing the quality of the component.
• It keeps the focus on delivering features. It can be tempting for a team to fall back into its pre-Scrum habits. Organizing teams around the delivery of features, rather than around architectural elements or technologies, serves as a constant reminder of Scrum’s focus on delivering features in each sprint.

Of course, there will be occasions when creating a component team is still appropriate, for example when a new capability will be used by multiple teams or when the risk of multiple solutions being developed for the same problem is high. Overall, however, the vast majority of teams on a large project should be feature teams.

Additional advice on feature and component teams can be found in Chapter 10, “Team Structure,” of Succeeding with Agile.

• The daily scrum is about micro-managing the team’s daily work plans and making sure that everyone is doing what they say they’ll do.
• Continuous integration is put in place so that the minute some developer screws up and breaks a build, it becomes known.
• Pair programming is about making sure that programmers don’t lose focus, don’t goldplate, don’t work on only the fun stuff, and that they clean things up.

Ah, but who is it that is doing this micromanagement?

It’s the team.

Yes, agile is about micromanagment, but it’s about the team micromanaging themselves and for their own benefit.

My first answer is always: Try to get the one person to move to where the rest of the team is. I don’t expect to see any moving trucks roll out when I ask this, but I have to ask. I figured if I keep asking, some team somewhere will eventually have the person move. Having one remote is a cost that must be borne by the full team. For the right person, it’s easily worth it. But sometimes, the person who is remote has not special skills, knowledge or experience to justify the added hassle.

So, assuming that we’ve tried the “move here” solution and it didn’t work, what can a team do that likes the physical task board but that has one remote member?

My recommendation is to continue to use the physical task board–it is simply too beneficial to the collocated team members to give it up in favor of a product backlog tool, especially if team members are already used to it and like it. How the team conveys information on the task board to the remote team member depends on what that person does.

Sometimes the remote person works remotely because they have a very specialized skill that couldn’t be filled in the office where the rest of the team is. This would be the case, for example, if our remote person is an expert in Windows internals and is writing boot-time code in C++. It would also be the case if our remote person has twenty years of experience in the domain and with some of our really old code. In these cases, the remote person usually (not always) works for a day or two relatively alone. The remote person in this case could identify during the daily Scrum what he or she will work on and not need further interaction with the task board until selecting the next task. Here, the remote person doesn’t really interact with the task board at all and interacts only with the team. Not ideal as I’d like the person to see the tasks, but this can work in some situations.

What is more common is for the ScrumMaster to take on the responsibility of updating an electronic version that mirrors the physical task board. A shared spreadsheet is normally sufficient for this, but some teams opt for a more specialized tool, which is fine. Many tools offer 5-10 user free licenses and since the tool is only needed by the ScrumMaster and one remote employees, the free license is adequate.

Normally the ScrumMaster updates the electronic task board once a day, usually right after the daily scrum meeting. Of course, reading the physical task board and updating the electronic one can be quite time-consuming because the ScrumMaster has to look at each task in both places to see if that item needs to be updated.

One good way of minimizing the time the ScrumMaster spends doing this is to mark the cards on the physical task board. The mark indicates “I’ve updated this task. Please update it in the online task board.” I like to use Post-It flags for this. As team members do their daily scrum, they stick one of these flags (of any color) on the card. If the estimate changes, if the task is done, if a new task is added, those cards are tagged with a flag. When the meeting is over, the ScrumMaster can very easily see which items need to be updated. The ScrumMaster removes the flags once the online task board is updated. This approach also works in situations where the ScrumMaster updates the board more than once a day. Any time someone changes the board, flag the task.

Other teams do something similar using color-coded dots. Anything touched on Monday is blue, Tuesday is red, and so on. Two problems occur though: First, the dot packs usually come with four colors to a pack so you have to buy a fifth color. Second, it’s a hassle to make sure we have the right color on hand.

• Big Visible Charts. Alistair Cockburn coined the term “Big Visible Charts” to describe the charts that agile teams like to hang on their walls. One of the most common of these is the sprint burndown chart, showing the number of hours remaining as of each day of the current sprint. Charts like these provide a strong visual reminder of the current state of the project. What is shown on these charts will get the attention of team members so display charts showing the most important information for that sprint. Ron Jeffries suggests considering big visible charts showing the number of passing customer acceptance tests, the pass/fail status of tests by day, sprint and release burndown charts, number of new stories introduced to the product backlog per sprint, and more.
• Additional feedback devices. In addition to big, visible charts, it is common for an agile team to use additional visual feedback devices in their workspace. One of the most common is a lava lamp that is turned on whenever the automated build is broken. I’ve also worked with teams that use flashing red traffic lights to indicate exceptional conditions such as an issue on a production server. Also popular are ambient orbs and Nabaztag rabbits, which are wireless programmable devices that can also be configured to change colors, speak messages, or wiggle their ears as a team desires. Devices like these make a workspace more dynamic, unobtrusively bringing into it information the team may find helpful.
• Everyone on your team. Each person on the team should ideally be able to see each other person on the team. This absolutely includes the ScrumMaster and ideally includes the product owner. I do understand, however, that product owners often have responsibilities to other groups outside the development team and so may sit near them instead. Still, in an ideal world the product owner would be visible to everyone in the team workspace.
• The sprint backlog. One of the best ways to ensure that everything necessary is completed in the sprint is to make the sprint backlog visible. The best way to do that is by displaying the sprint backlog on a wall, ideally in the form of a task board A task board is usually oriented in rows and columns with each row containing a particular user story and one index card or sticky note for each task involved in that story. Task cards are organized in columns, minimally including “To Do” “In Process,” and “Done.” In this way, team members are able to see work progressing across the task board during the sprint and all work to be done is visible at all times.
• The product backlog. One problem with running an endless series of sprints is that each can feel disconnected or isolated from the whole of a planned released or related set of new capabilities. A good way to reduce the impact of this problem is by displaying the product backlog somewhere clearly visible. This can be as simple as keeping the shoebox full of user stories written on index cards on a table in the middle of the team’s space. Even better, tack the index cards with those upcoming user stories on a wall where all can see them. This allows team members to see how the user stories they are working on in the current sprint relate to others that are coming soon.
• At least one big white board. Every team needs at least one big whiteboard. Locating this in the team’s common workspace encourages spontaneous meetings. One developer may start using the board to think through a problem; others may notice and offer to help.
• Someplace quiet and private. As important as open communication is, there are times when someone needs some peace and quiet. Sometimes this is for something as simple as a private phone call. Other times it can be to think through a particularly challenging problem without being interrupted.
• Food and drink. It’s always a good idea to have food and drink available. These don’t need to be fancy, and they don’t even need to be provided by the organization. I’ve worked with plenty of teams that buy a small under-desk refrigerator and share the expense of buying water bottles or soda for it. Other teams buy a coffee machine, depending on team preferences. Some teams rotate bringing in snacks, both healthful and not.
• A window. Windows are often a scarce commodity and are doled out to an organization’s favored employees. One of the nice things about an open workspace is that windows are shared. Even if the view is only of our parking lot and can only be seen across three messy desks, at least I can see the window and some natural light.

It’s unlikely that every one of these will be visible from your workspace, but the more of them visible, the better. Let me know what else you think should be visible from within the ideal agile workspace.

In general, a team should feel comfortable working on multiple product backlog items at the same time during an iteration. A typical seven person team will plan between five and ten items into an iteration. They’ll usually be closer to the low end of that range with a one- or two-week iteration and closer to the high end with a four-week iteration. Perhaps surprisingly, though, iteration length has less influence on the number of product backlog items selected than you might think. It seems that teams with longer sprints simply have larger product backlog items.

A seven-person team will rarely be at its most efficient when all team members swarm onto a single product backlog item. There’s too much opportunity for them to get in each other’s way for this to be a good long-term strategy. However, an entire team swarming onto a single product backlog item can be a very effective learning technique and one that I often encourage. If you are part of a team that hasn’t yet learned how all disciplines can work well together, limiting the entire team to one product backlog item in progress at a time is something you might want to try. This forces people to quickly learn ways to work in small batches so that work can, for example, be transferred from programming to testing in multiple tiny increments.

Similarly, if you are on a team where each developer grabs a product backlog item and works independently on it throughout an iteration, a rule of “only one item in progress at a time” is a good way to experience the benefits of working in smaller batches.

So, while I think swarming in this way is an excellent technique to use sometimes, I don’t think it should be the default way of working for very many teams. Some may benefit from it over the long term, but most will find that it introduces too many opportunities to be in someone else’s way as they try to make progress. I consider it equivalent to a drill that a team may do to improve a skill–good to use for practice but not the way to do something forever.