The Scrum Team

In the early 1990s, Jim Coplien was invited to assess a project at the Borland Software Corporation. They were making a new spreadsheet program called Quattro Pro for Windows. The software had more than one million lines of code, took thirty-one months, and a team of eight people. That means each team member produced one thousand lines of code every week. That’s more code in less time than any team on record. (See Coplien's paper in the Papers and Patterns tab.)

To figure out why the Borland team was so fast, Coplien mapped all the communication flows within the team—who was talking to whom, where information was flowing, and where it was not. This type of mapping is a classic tool that can be used to spot bottlenecks or information hoarders. The greater the communication saturation—the more everyone knows everything—the faster the team. Basically, the metric spun off by this type of analysis measures how well everyone knows what they need to know to get their work done. The Borland team still has the highest rating ever: 90 percent. Most companies hover around 20 percent.

What cripples communication saturation is specialization—the number of roles and titles in a group. If people have a specific title, they tend to do only tasks that match for that title. And to protect the power of that role, they tend to hold on to specialized knowledge. That is why Scrum only has three roles: a person is either a member of the Team, the Scrum Master, or the Product Owner. This can be difficult for traditional organizations, but it is critical to get the kind of productivity increases that Scrum can deliver.

Just as the number of roles impacts performance, the sheer number of people on a Team also has a dramatic effect. The Team dynamic only works well in small teams. The classic formulation is seven people, plus or minus two, though the fastest teams usually hover around five. What’s fascinating is that the data shows that if there are more than nine people on a team Velocity actually slows down. Surprisingly, more resources actually make Teams slower.

In software development, there’s a term called Brooks’ Law. Fred Brooks first coined it in his seminal 1975 book The Mythical Man-Month. Put simply, Brooks’ Law states “adding manpower to a late software project makes it later.” This has been borne out in study after study. Lawrence Putnam, a legendary figure in software development, made it his life’s work to study how long things take to make and why. His work kept showing that projects with twenty or more people on them used more effort than those with five or fewer. Not just a little bit, but a lot. A large team would take about five times the number of hours that a small team would. He saw this again and again, and in the mid-1990s he decided to do a broad-based study to determine what the right team size is. So he looked at 491 medium-size projects at hundreds of different companies. These were all projects that required new products or features to be created, not a repurposing of old versions. He divided the projects by team size and noticed something right away. Once the teams grew larger than eight, they took dramatically longer to get things done. Groups made up of three to seven people required about 25 percent of the effort of groups of nine to twenty to get the same amount of work done. This result recurred over hundreds and hundreds of projects. That large teams accomplish less than small teams do seems to be an ironclad rule of human nature. (See Slides tab.)

Too often there are tasks that only one person on the Team can do. This is common among beginning Scrum Teams. It needs to be addressed as quickly as possible. The reason is that if only one person can do the work, and that person is unavailable, the whole team grinds to a halt. People get sick, people change jobs; you can't afford to have your organization held hostage by one skill set.

Good Scrum teams make sure that at least two people, and ideally more, can do any one job. The teams that solve this problem tend to increase their Velocity. The reason is that collective knowledge, not individual skill, is what improves team speed. Individuals can falter, yet if the rest of the team can carry on, their productivity doesn’t suffer.

Perhaps the best way to make sure your team isn’t limited is through pairing and cross-training. If there is only one person that can do a task, make sure the next time that task comes up they pair with someone while doing it so that person can learn. Encourage all of your people to cross-train in various skill sets, not only will you reap the benefits, but they will be more engaged and excited as they learn new skills.

Paper: Borland Paper on Teams

Pattern: Autonomous Team

Pattern: Stable Team

The Scrum Pattern Language of Programing : The PLoP movement codifies well know Agile practices that have been successfully implemented many times.