The Scrum Team
The Scrum Team is made up of the people who actually work on Product Backlog Items during a Sprint. In a software context, this group is most often called the Development Team. In other contexts, the simple term Team is often used. The Scrum Master and the Product Owner, while part of the overall Scrum Team, may or may not be members of the Team working on PBIs. There is no Project Manager or Team Lead in Scrum. Everyone is simply an equal member of the Team.
Estimated time for this course: 30 minutes
Suggested Prerequisites: Scrum Framework
Upon completion you will:
The Scrum Team Overview
In the original Harvard Business Review paper that inspired the creation of Scrum, “The New New Product Development Game,” Professors Hirotaka Takeuchi and Ikujiro Nonaka observed great teams were:
1. Transcendent: They have a sense of purpose beyond the ordinary. This self-realized goal allows them to move beyond the ordinary into the extraordinary. In a very real way the very decision to not be average, but to be great, changes the way they view themselves and what they’re capable of.
2. Autonomous: The teams are self-organizing and self-managing, they have the power to make their own decisions about how they do their jobs, and are empowered to make those decisions stick.
3. Cross-Functional: The teams have all the skills needed to complete the project. Planning, design, production, sales, distribution. And those skills feed and reinforce each other. As one team member that designed a revolutionary new camera for Canon described it: “When all the team members are located in one large room, someone’s information becomes yours, without even trying. You then start thinking in terms of what’s best or second best for the group at large and not only where you stand.”
People sometimes struggle with the idea of transcendence. Transcendence is the spirit of the team. The first Scrum team watched a video at the beginning of each Daily Meeting of New Zealand's All Blacks rugby team. The energy from that team is palpable. They are united in purpose. The first Scrum team wanted to capture that spirit: the determination to crush any impediment; the spirit to celebrate every success; the goal of victory. That is team transcendence, whether on a sports team or delivering great products or services.
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.)
View and Download Class Slides
Cross-functionality & Pairing
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.
Papers & Patterns
Explore ScrumLab Prime
Are you ready to advance your Scrum knowledge? Prime members enjoy unrestricted access to all our webinars and advanced Scrum topics.