Scrum: The Art of Doing Twice the Work in Half the Time

by Jeff Sutherland

In software development there is a rule, borne out by decades of research, that 80 percent of the value in any piece of software is in 20 percent of the features.

“Agile Manifesto.” It declared the following values: people over processes; products that actually work over documenting what that product is supposed to do; collaborating with customers over negotiating with them; and responding to change over following a plan. Scrum is the framework I built to put those values into practice. There is no methodology.

An “impediment” is an idea that comes from the company that first formed a lot of the ideas Scrum is based on: Toyota. And, more specifically, Taiichi Ohno’s Toyota Production System.

It is not an exaggeration that in a low-growth period such waste is a crime against society more than a business loss. Eliminating waste must be a business’s first objective.4

For Scrum to really take off, someone in senior management needs to understand in his bones that impediments are nearly criminal.

Suffice it to say here that the effect of eliminating waste is dramatic, but people often don’t do it, because it requires being honest with themselves and with others.

There’s a poster-size copy of the “Agile” principles on the wall—principles I helped write and have devoted my life to implementing around the world.

the danger almost settled me. I credit this to the training I got from the Air Force on how to control risk. That training taught me to do four things: Observe, Orient, Decide, and Act.

Scrum teams that work well are able to achieve what we call “hyperproductivity.”

Work doesn’t have to suck. It can flow; it can be an expression of joy, an alignment toward a higher purpose.

Think of performance bonuses or promotions or hiring. Everything is focused on the individual actor, rather than the team. And that, it turns out, is a big mistake.

So how do you create a team that aims for a higher goal, organizes itself, and constantly feeds off each member’s skills? I spent a lot of time pondering that. After all, you can’t just yell at people to be more self-organized and transcendent; the motivation has to come from within. Imposing it will kill what you’re trying to do.

All twenty-four companies marched, but L2, because of our position in the alphabet, marched twenty-third. After the ceremony my future father-in-law asked me, “That company. The second to last one. They were different than all the rest. The others were marching; they seemed to be floating. Who were they?” “That was my company,” I told him. “Those men buried General MacArthur.” My company had achieved transcendence.

as de facto Scrum Master, was to make sure that those things getting in the team’s way at one meeting were gone by the next.

But just because cross-functionality can achieve great results, you shouldn’t play Noah and throw two of everything into a team. The team dynamic only works well in small teams. The classic formulation is seven people, plus or minus two, though I’ve seen teams as small as three function at a high level. What’s fascinating is that the data shows that if you have more than nine people on a team, their velocity actually slows down. That’s right. More resources make the team go slower.

Brooks first coined back in 1975 in his seminal book The Mythical Man-Month. Put simply, Brooks’s Law says “adding manpower to a late software project makes it later.”8 This has been borne out in study after study.

A large team would take about five times the number of hours that a small team would.

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 hundre...

In 2001, Nelson Cowan of the University of Missouri wondered whether that magic rule of seven was really true and conducted a wide survey of all the new research on the topic. It turns out that the number of items one can retain in short-term memory isn’t seven. It’s four.

If you can link things in your short-term memory to long-term memory associations, you can hold more. But the part of the mind that focuses—the conscious part—can only hold about four distinct items at once.

When he tried to figure out why adding more people to a project made it take longer, he discovered two reasons. The first is the time it takes to bring people up to speed. As you’d expect, bringing a new person up to speed slows down everyone else.

The second reason has to do not only with how we think but, quite literally, with what our brains are capable of thinking. The number of communication channels increases dramatically with the number of people, and our brains just can’t handle it.

if you have five people, you have ten channels. Six people, fifteen channels. Seven, twenty-one. Eight, twenty-eight. Nine, thirty-six. Ten, forty-five. Our brains simply can’t keep up with that many people at once. We don’t know what everyone is doing. And we slow down as we try to figure it out.

When talking about others, though, you’re making one of the most common—and destructive—human errors in judging other people’s actions. It even has a name: “Fundamental Attribution Error.”

We all perceive ourselves as responding to a situation, while we see others as motivated by their character.

One amusing side effect is that when we’re asked to report on our personality traits and those of our friends, we always paint ourselves as far more boring. We say we have dramatically fewer character traits than our friends.

An intuitive physicist might explain why a rock falls by saying the rock itself has the intrinsic quality of gravity, rather than saying that gravity is part of a system of forces acting on the rock. In the same way, when we talk about others, we talk about their inherent properties, rather than see those properties in relation to the external environment.

What Scrum is designed to do is change that system. Instead of looking for blame and fault, it rewards positive behavior by focusing people on working together and getting things done.

“The Perils of Obedience”: Ordinary people, simply doing their jobs, and without any particular hostility on their part, can become agents in a terrible destructive process. Moreover, even

The Fundamental Attribution Error appeals to our sense of justice.

And that’s a place I want to help people reach with Scrum. It’s not impossible. It’s not only the elites and athletes and special people who can do this. It’s about setting up the right framework with the right incentives and giving people the freedom, respect, and authority to do things themselves. Greatness can’t be imposed; it has to come from within. But it does live within all of us.

Right before the first real Scrum at Easel in 1993 I was working at a company just blocks from the MIT Media Lab, and I stole an idea from the lab that has become the core of Scrum: the Sprint.

Every three weeks each team had to demonstrate to their colleagues what it was working on.

An important point: nothing gets moved to Done unless it can be used by the customer.

One crucial element of an individual Sprint, though, is that once the team commits to what they’re going to accomplish, the tasks are locked in. Nothing else can be added by anyone outside the team.

interfering and distracting the team slows its speed dramatically.

What did you do yesterday to help the team finish the Sprint? What will you do today to help the team finish the Sprint? What obstacles are getting in the team’s way?

That’s the whole meeting. If it takes more than fifteen minutes, you’re doing it wrong.

In the early 1990s he was invited to look at a project at Borland Software Corporation that was making a new spreadsheet product called “Quattro Pro for Windows.” For the project, one million lines of software code had been created. They took thirty-one months to produce and were the output of eight people. That means each team member produced one thousand lines of code each week. That’s the fastest of any team on record, and Jim wanted to know how they did it.

The greater the communication saturation—the more everyone knows everything—the faster the team.

The thing that cripples communication saturation is specialization—the number of roles and titles in a group. If people have a special title, they tend to do only things that seem a match for that title. And to protect the power of that role, they tend to hold on to specific knowledge.

If someone was stuck with a problem—if the accelerometer wasn’t talking to the altimeter—everyone saw that the impediment could block the whole Sprint, and they swarmed on it, making sure it got fixed pronto.

The point was to give the team a regular heartbeat.

The second rule was that the meeting couldn’t last more than fifteen minutes.

The idea was to get the most actionable and valuable information in the least amount of time.

I want aggressive teams—ones that come out of the daily meeting knowing the most important thing they need to accomplish that day.

But he said the main thing the Stand-ups did was remove dependencies.

Demo or Die. At the end of each Sprint, have something that’s done—something that can be used (to fly, drive, whatever).