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.

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.

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.

This can be a very alluring approach. Not only does it seemingly solve the problem of how to overlap work but it also allows each type of specialist to work mostly with others of their own kind, which many may prefer until they become used to the close collaboration of a Scrum team. Unfortunately, the same disadvantages apply to activity-specific sprints as apply to activity-specific teams: too many hand-offs and a lack of whole-team responsibility.

One of the biggest problems with activity-specific sprints is that they create what are known as finish-to-start relationships. In a finish-to-start relationship, one task must finish before the next can start. For example, a Gantt chart on a sequential project may show that analysis must finish before coding can start and that coding must finish before testing can start. Good Scrum teams learn that this is not true; many activities can be overlapped. What is important is not when tasks start but when they finish. Coding cannot finish until analysis finishes and testing cannot finish until coding finishes. These are known as finish-to-finish relationships and are reinforced by Scrum’s sprint mechanism. All work is done at the end of the sprint, or it is returned to the product backlog.

With a little experience, most teams are able to see how to overlap some types of work and create finish-to-finish relationships between them. Teams easily find ways to overlap discussions of what users need and programming. They also soon find ways to overlap programming and testing. These activities lend themselves to iterative and incremental approaches: Get a few details from the users about what they need and then build a little of it; build a little and then test what you’ve built. Other activities, though, do not appear at first to be as amenable to an iterative, incremental approach. User experience design, database design, and architecture are often cited as work that needs to be done up front because the work must be viewed holistically. I argue that we should think holistically but work iteratively toward solutions. All sprint activities can and should overlap.

For specific guidance on how to overlap work in a sprint, see Chapter 14, “Sprints,” in Succeeding with Agile.

Remove Finish-to-Start Activities on Agile Projects by Mike Cohn is licensed under a Creative Commons Attribution-No Derivative Works 3.0 United States License.
Based on a work at Remove Finish-to-Start Activities on Agile Projects.

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.

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.

Most of our teams complete 10 or more user stories per sprint. When answering the 3 questions in the daily Scrum, it was clear what each person was working on, but it wasn’t as clear how each story was doing or when a story was in trouble. For example, if no one worked on a story, problems with that story aren’t visible because no one mentions that story during the standup. What we’ve started doing is conducting the daily standup story-by-story rather than person-by-person. Now it’s very clear how each story is progressing, but difficult to figure out what each person is doing. Some people work on multiple stories and others may not even speak up in a daily Scrum.

One possible solution to this common problem is that these teams are doing too many product backlog items per sprint. Based on data I analyzed on successfully finished sprints, I determined that a team should average around 1 to 1-1/2 user stories (product backlog items of any sort, really) per person per sprint. So, a six-person team should get somewhere around 6-9 user stories done per sprint. Teams doing shorter sprints (one or two weeks) should be at the low end of the range; teams doing three- or four-week sprints should be at the upper end. This means that coincidentally teams with longer sprints do slightly larger user stories in their sprints.

I hate that the answer I got was around one user story per person in a sprint because that makes it sound like each person grabs one user story and works on it alone for the duration of the sprint. Nothing could be further from the truth. Expressing the number of items in terms of the number of people on the team is just an obvious way to state the result: more people, more user stories. I want to reiterate though that the result is not for each person to do one user story per sprint alone.

Another solution to the problem above is to conduct the daily standup in front of a physical task board and have people point to whatever they are working on. I always prefer to do this whenever possible. I frequently ask the speaker to “Point to what you’re working on.” Assuming a well setup task board this will show me the user story that the task relates to.

Another solution is to designate a “point person” for each user story the team plans to work on in the sprint. This person is responsible for knowing if the user story is moving along appropriately. The person is essentially a “story owner” but we’re talking about 2-5 minutes a day of extra work. This isn’t a heavyweight new responsibility. The person may or may not be the primary contributor on the story; it doesn’t seem to matter.

Another possible solution could be to look at the sizes of the teams involved. I find the ideal team size is 5-7 people. Standard agile advice seems to be 5-9 is the right size. When possible I try to stay on the low end of the range. If the team is more than 9, it is easy to lose track of what people are doing.

Finally, most teams do the daily standup per-person, but some encounter the problem described here and discuss things story-by-story. Not all teams need to do it the same. If you’re in an organization with even a handful of teams, I would randomly split them and tell some to try person-by-person and others to try story-by-story for a full sprint. I’d get everyone together afterwards for a short cross-team retrospective and let people say how it went. Hopefully teams could hear the results of other teams and then make a good decision about what to do next.

Suppose a tester and I are working on the story about auto-incrementing the next check number in a checkbook management system. We would talk before getting started and agree that I’m going to go code the simple scenario where the user enters one check after another and that we’ll force the session to start with check 100. So entering five checks will give 101, 102,…105. The tester goes and writes an automated test for that while I code it. We check that in tomorrow morning and it becomes part of the nightly build. We’ve just exchanged work at a level smaller than the individual user story / product backlog item. Let’s do it again.

Next the tester and I talk and agree that we want to read the last check number from the file storage part of our product. So now our check numbers have to start at the right place rather than always starting with 100. The tester writes the automated tests while I code. We both check in our work and add it to the nightly build.

Next we decide to tackle the situation where the user doesn’t enter one check after another. Instead of check, check, check, check we want to handle sequences like check, check, deposit, EFT, check, deposit, check and make sure the check numbers are incrementing correctly.

Then we decide to handle the case where the user manually types in a check number, overriding the default. Perhaps an analyst figures out what to do in some edge cases around this part of the user story (do we warn the user they’re missing a check? does the sequence start to go off the last entered check number or the highest check number?). While the analyst figures that out the tester is automating and I’m coding. And so it goes….