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

by Jeff Sutherland

What look like virtuous patterns can end up being nothing but folly—nothing but waste. That’s what I’m going to spend this chapter talking about: the waste that infects our work, the cancer that eats at our productivity, our organizations, our lives, and our society.

Ohno talked about three different types of waste. He used the Japanese words: Muri, waste through unreasonableness; Mura, waste through inconsistency; and Muda, waste through outcomes. These ideas are highly aligned with Deming’s PDCA cycle, which I wrote about earlier: Plan, Do, Check, Act. Plan means avoid Muri. Do means avoid Mura. Check means avoid Muda. Act means the will, motivation, and determination to do all that.

“People don’t multitask because they’re good at it. They do it because they are more distracted. They have trouble inhibiting the impulse to do another activity.” In other words, the people who multitask the most just can’t focus. They can’t help themselves.

The “Loss to Context Switching” column is pure waste. That’s right: if you have five projects, a full 75 percent of your work goes nowhere—three-quarters of your day is flushed down the toilet. It’s why you couldn’t write the rows and columns at the same speed. It’s a result of the physical limitations of your brain.

One idea I want to address here is called “Work in Process,” or sometimes just “inventory.” The idea is that it’s wasteful to have a bunch of stuff lying around that isn’t being used to build something. That stuff, whether it be car doors or widgets, actually costs money, and if it’s sitting around on the factory floor, it means that huge amounts of money are bound up in inventory that isn’t actually needed right then. This changes how you look at things that are in process.

Imagine (or, if you’re unfortunate, remember) having five tasks partially done. You’ve painted one wall of the bathroom, the dog food is still in the trunk, the mortgage check has been written but not mailed, and the leaves are piled up but not bagged. You’ve expended effort but haven’t created any value.

As I’ve said, in Scrum there is a rhythm to the work. Every iteration, or Sprint, the team tries to get a number of things done. But that “Done” implies a complete, deliverable product that can be used by a customer. If something is half done at the end of the Sprint, you’re worse off than if you hadn’t started at all. You’ve expended resources, effort, and time and gotten nothing to a deliverable state. You have a half-constructed car. It might have been better to create something smaller—something that really works.

It took twenty-four times longer. If a bug was addressed on the day it was created, it would take an hour to fix; three weeks later, it would take twenty-four hours. It didn’t even matter if the bug was big or small, complicated or simple—it always took twenty-four times longer three weeks later. As you can imagine, every software developer in the company was soon required to test and fix their code on the same day.

This phenomenon has been labeled “ego depletion.” The idea is that making any choice involves an energy cost. It’s an odd sort of exhaustion—you don’t feel physically tired, but your capacity to make good decisions diminishes. What really changes is your self-control—your ability to be disciplined, thoughtful, and prescient.

Whatever resource is burned up by making decisions is also used up in self-regulation. The students who’d made all the product decisions simply couldn’t hold their hands in the icy water as long as the control group that had been spared the decisions. So there’s a limited number of sound decisions you can make in any one day, and as you make more and more, you erode your ability to regulate your own behavior. You start making mistakes—eventually, serious ones.

A team that depends on regular heroic actions to make its deadlines is not working the way it’s supposed to work.

While Ohno didn’t mention a fourth type of waste, one comes to mind—i.e., “Emotional Waste.” That type of waste is generated when a company has an asshole in its midst—someone who likes spinning up other people and putting them in a tizzy. Assholes often justify their behavior by claiming they’re simply trying to make people work better. But they’re merely indulging the negative aspects of their personality, and nothing is more undermining of a team’s ability to excel.

It was because they made a very basic mistake. They thought they could plan everything ahead of time. They spent months of effort making the sort of detailed plans that seem plausible—that are laid out on pretty charts and include carefully precise steps and almost always describe a fictional reality.

“How many of you have actually read all this?” I asked. Silence. “But look,” I said to one of the managers, “you signed off on this. There’s your signature. Didn’t you actually read it?” More awkward silence. I didn’t want to pick on him, but the fact is, in project after project, people cut and paste and throw in boilerplate, but no one actually reads all those thousands of pages. They can’t. That’s the point. They’ve set up a system that forces them to endorse a fantasy.

Then I said to the teams, “Now we need to estimate how much work each one of these sticky notes will take.” Not how long, but how much work.

They actually were excited. An unreadable stack of paper had become understandable pieces of work. It’s like that old saw, “How do you eat an elephant? One bite at a time.”

Staring at all those sticky notes on the wall, everyone had a feeling of accomplishment. They could now see what they had to do.

Okay, Sutherland, I can hear you saying, we’re bad at estimating, but I’ve got to do something, right? I have to have some sort of plan. And you’re right: you do. But the key is to refine the plan throughout the project rather than do it all up front.

Unsurprisingly, this is not a new problem. People have struggled for decades with exactly this. One issue is that different members of the team know different things, but another is sometimes called the “bandwagon” effect. You’ve been in meetings like that. That’s when someone comes up with an idea, and everyone starts talking about it. And even if you disagreed with it initially, you go along because the group is going along. And everyone agrees on a path forward that seems like a really good idea at the time but turns out to be a complete failure. And when you probe people about the decision, it’s almost always the case that each had some reservations, but they didn’t voice them because they figured everyone else was excited. People assume that if everyone else is going along with something, their own reservation is silly or misinformed, and they don’t want to look stupid in front of the group. Remember, this groupthink isn’t an individual failure; this is a human failure.

The other well-known problem is what’s called the “halo effect.” This is when one characteristic of something influences how people perceive other, unrelated characteristics. This was first empirically studied in 1920 by Edward Lee Thorndike. In his classic paper “A Constant Error in Psychological Ratings,” Thorndike asked military officers to rank their soldiers by various qualities—physical, intellectual, leadership, personality, and so on. He then looked at how one set of qualities affected the rating of another. He found that they correlated too closely. If someone’s physique was rated highly, so were his leadership skills. And his intelligence. And his character. This research has been supported in follow-up studies over the years, confirming that, for example, if someone is good-looking, everyone assumes that they’re also smart and trustworthy.

The problem is that you’re not getting, or giving, enough information to actually do the job right. People think in narratives, in stories. That’s how we understand the world.

So before you prioritize what needs to be done for your business, you need to define the character, the user, the customer—the person who’s going to use what you’re going to do. You need to know their likes, dislikes, passions, enthusiasms, frustrations, and joys. And then you need to understand their motivations.

Imagine the story about Amazon.com: As a customer, I want the world’s biggest online bookseller so that I can buy any book I want at any time I want. Now, that certainly encapsulates Amazon, but it’s really too big to actually do anything with. You need to break it down. Really down.

that for any story to be ready it needs to meet the INVEST criteria: Independent. The story must be actionable and “completable” on its own. It shouldn’t be inherently dependent on another story. Negotiable. Until it’s actually being done, it needs to be able to be rewritten. Allowance for change is built in. Valuable. It actually delivers value to a customer or user or stakeholder. Estimable. You have to be able to size it. Small. The story needs to be small enough to be able to estimate and plan for easily. If it is too big, rewrite it or break it down into smaller stories. Testable. The story must have a test it is supposed to pass in order to be complete. Write the test before you do the story.

For each story pursued there should be both a “definition of Ready” (as in “Does it meet the INVEST criteria?”) and finally “a definition of Done” (as in “What conditions need to be met, what tests need to be passed, to call it a wrap?”).

Also once you have your velocity, you can figure out the most important thing in Scrum: what is keeping you from going faster? What is keeping you from accelerating? In the last chapter I talked about waste, about the things that will slow you down. This is how you see if you really are getting rid of waste.

Then I handed them a memo with a list of twelve impediments on it. They ranged from not empowering people to make decisions to onerous technical requirements, from people not showing up for meetings to simple things such as not having everybody on a team work in the same room. There were process, personality, and procedure problems—the type of things that are endemic to any corporation.

And that, he says, is the most important part of Scrum: it changes the culture people work in, which can be scary for some. Indeed, the company had to get rid of employees who couldn’t make the switch, he says—not because they were incompetent, but because they were hoarding information and knowledge for their own benefit, to ensure their own indispensability rather than helping the team and the company. Changing that culture, though, is what allows true excellence to emerge.

In his book Happier, Ben-Shahar writes: “We are not rewarded for enjoying the journey itself but for the successful completion of a journey. Society rewards results, not processes; arrivals, not journeys.” But our day-to-day life is mostly made up of journeys.

In a company, the goal may be to deliver that next great product, or make people’s lives a little better with it, or solve some problem that vexes the world. But if we get rewarded only for results, not processes, we’re going to be pretty miserable.

The importance of happiness really hit me when I was setting up my first Scrum team. I realized that I had to address the team’s emotional state as well as its mental state. For a West Point–trained fighter pilot, this was something of an adjustment. I was used to things being cut-and-dried. Being clinical and scientific, it took me some time to figure out that to empower people, to change their lives for the better, I had to change myself. Over the course of that first Scrum effort I realized that true greatness is deeply rooted in joy. And that to be joyful is to take the first step toward success.

I may have become a better person through developing Scrum, which makes my family and me happier. But as a businessman and a scientist, I like hard data.

That’s right. People aren’t happy because they’re successful; they’re successful because they’re happy. Happiness is a predictive measure.

I want you to be a scientist about it: quantify it and equate it with performance. If something doesn’t match up, there’s a problem. It’s great to go to the pub with your team and bond. But it doesn’t do the company a lot of good if that bonding doesn’t actually translate into better performance. There are a lot of people I hang with just for fun. With my team I want that social aspect to move directly into performance.

What is the little improvement that can be done right away that will make things better? In Scrum this is captured at the end of each Sprint in what I call the “Sprint Retrospective.”

What are the things that actually make people happy? They’re the same things that make great teams: autonomy, mastery, and purpose. Or to say it more expansively, it’s the ability to control your own destiny, it’s the feeling that you’re getting better at something, and it’s knowing that you’re serving something bigger than yourself.

One element of Scrum that’s often a prelude to achieving autonomy, mastery, and purpose is transparency. The idea is that there should be no secret cabal, no hidden agendas, nothing behind the curtain. Far too often in a company it isn’t really clear what everyone is working on, or how each person’s daily activity advances the goals of the company.

That’s why in Scrum anyone can go to any meeting. Any stakeholder can observe a Daily Stand-up or attend a Review.

… that the only route to employee happiness that also benefits shareholders is through a sense of fulfillment resulting from an important job done well.

What these “thrivers” share is what I’ve been writing about throughout this chapter—each thriver is vital and passionate, and each is trying to perfect their craft, whether they belong to an airplane crew or are a busboy in a restaurant. What can companies do to create an atmosphere in which people thrive? Managers can encourage autonomy by letting people make their own decisions about their job. And they can make sure that employees know everything that’s going on,

This usually happens after a team has achieved some big success or increased their productivity greatly by using Scrum. They’ve self-organized, and they feel proud of their progress.

The first step is being aware of the problem, which is why I want teams to measure their velocity every Sprint. I want to know what their rate of change is. If there isn’t positive growth, I know we’ve got to bear down. And the person I depend on to do this is the Scrum Master. He or she needs to be able to see the problem and bring it up with the team. It’s crucial that someone ask the hard questions.

It’s not enough just to be happy. Happiness needs to be harnessed to produce results.

But Scrum isn’t just about making teams go faster. It’s about boosting impact,

The idea behind the Backlog is that it should have everything that could possibly be included in the product. You’re never going to actually build it all, but you want a list of everything that could be included in that product vision. The key, though, is what you decide to do first. The questions you need to ask are: what are the items that have the biggest business impact, that are most important to the customer, that can make the most money, and are the easiest to do? You have to realize that there are a whole bunch of things on that list that you will never get to, but you want to get to the things that deliver the most value with the lowest risk first. With Scrum’s incremental development and delivery, you want to begin with the things that will immediately create revenue, effectively “de-risking” the project.

As Scott Maxwell says, the difficult part isn’t figuring out what you want to accomplish; it’s figuring out what you can accomplish.

The key is prioritizing the work. How do you do that? Well, first you need someone who can figure out both what the vision is, and where the value lies. In Scrum we call that person the Product Owner.

Reflecting on my time at West Point and in Vietnam, I found myself agreeing that leadership has nothing to do with authority. Rather, it has to do with—among other things—knowledge and being a servant-leader. The Chief Engineer can’t simply say something has to be done a particular way. He has to persuade, cajole, and demonstrate that his way is the right way, the best way.

The Product Owner needed to be able to deliver feedback to the team from the customer each and every Sprint. They needed to spend half their time talking to the people buying the product (getting their thoughts on the latest incremental release and how it delivered value) and half their time with the team creating the Backlog (showing them what the customers valued and what they didn’t).

The Scrum Master and the team are responsible for how fast they’re going and how much faster they can get. The Product Owner is accountable for translating the team’s productivity into value.