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

by Jeff Sutherland

The Scrum Master, the person in charge of running the process, asks each team member three questions: 1. What did you do yesterday to help the team finish the Sprint? 2. What will you do today to help the team finish the Sprint? 3. What obstacles are getting in the team’s way?

What he did was map all the communication flows within the team—who was talking to whom, where information was flowing, and where it wasn’t. This type of mapping is a 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.

Getting everyone together in a room was key, because it gave the team the opportunity to self-organize around challenges. 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.

This is the reason such a meeting is often called the Daily Stand-up or Daily Scrum. It doesn’t really matter what you call it. It has to be at the same time every day, with the same three questions, with everyone standing up, and last no more than fifteen minutes.

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

What the Daily Stand-up meeting did was get all these people into a room where they quickly figured out how they could work together as a team. They were no longer simply individuals with separate skills but, rather, a team trying to move a house to Done.

Think about your job. How much of your time is wasted while you’re waiting for someone else to finish their work, or for information to be delivered, or because you’re trying to do too many things at once? Maybe you would rather be at work all day—me, I’d rather be surfing.

What Scrum does is create a different kind of pattern. It accepts that we’re habit-driven creatures, seekers of rhythm, somewhat predictable, but also somewhat magical and capable of greatness. When I created Scrum, I thought, What if I can take human patterns and make them positive rather than negative? What if I can design a virtuous, self-reinforcing cycle that encourages the best parts of ourselves and diminishes the worst? In giving Scrum a daily and weekly rhythm, I guess what I was striving for was to offer people the chance to like the person they see in the mirror.

If you’re working with something complicated—for example, writing a report, creating a presentation, developing a piece of software, or crafting a book, you’re holding an incredibly complex object in your mind. You must take into account dozens of factors, remember what you’ve done, where you want to go, and what the impediments might be. That’s a pretty tricky thing to do. And what happens if you’re interrupted or have to switch quickly to another project, even just for a moment? You guessed it: that carefully built mental architecture collapses. It can take hours of work just to get back to the same state of awareness.

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.

Let me put some actual numbers to that. In December of 2012, General Motors started laying off people in some of its auto plants in America. Why? The company had built too many cars. At the end of November that year they had 245,853 full-size pickups sitting in car lots across the country.

He started telling people that working late wasn’t a sign of commitment; it was a sign of failure. “It’s not because I want you to have a balanced life,” he told people. “It’s because you’ll get more stuff done.” So no more nights, no more weekends. When people go on vacation, they are expected to go on vacation, not check e-mail, not check in with the office. If you can’t actually take time off without having to make sure everything is going right at the office, the thinking goes, you aren’t managing your teams well.

It seems fairly straightforward, right? These are esteemed judges using their years of experience and wisdom to make critical decisions affecting not only the lives of the prisoners and their victims but the well-being of the community as a whole. Each day they heard between fourteen and thirty-five cases. So if you were a prisoner, what was the biggest factor in whether you’d go free or not? True remorse, perhaps? Your reformation and behavior in prison? The severity of your crime? None of those, actually. It turns out what really mattered was how long it had been since the judge had had a sandwich. The researchers

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.

What Scrum does is focus us on trying to eliminate the pointless waste that seems part and parcel of work. I’ve tried to make it so that the process itself is the least disturbing framework you can have and still keep people focused.

Let’s talk about that wedding. The first thing to do is create a list of all the things that make up a successful wedding. It might look something like this: • Bride and Groom • Flowers • Invitations • Church • Reception Hall • Food • Officiant • Dress • Wedding Rings • Music (DJ or Band)

As I’ve already pointed out, we humans are absolutely terrible at this, but what we are good at, it turns out, is relative sizing—comparing one size to another. Picking out the difference between small, medium, and large T-shirts, for example.

In the literature this effect has been explained as an “informational cascade.” As Sushil Bikhchandani, David Hirshleifer, and Ivo Welch, the authors of the paper “A Theory of Fads, Fashion, Custom, and Cultural Change as Informational Cascades” put it: “An informational cascade occurs when it is optimal for an individual, having observed the actions of those ahead of him, to follow the behavior of the preceding individual without regard to his own information.”2

A great example the authors use is the submission of a paper to a journal. Let’s say the first journal’s editor rejects it. Then the writer submits the same article to a second journal. That journal’s editor, learning of the first rejection, is more likely to reject it. And if there’s a third journal, that editor, knowing of the two previous rejections, is even more likely to reject it. People assume other people are making sound judgments, even if those judgments contradict their own. This is bad. When you’re making a judgment about when you’ll likely deliver a multibillion-dollar project—or whether you’ll get everything done on time for your wedding day—it’s critical to apply your own judgment, and use other estimates to improve your own, not replace it.

The other well-known problem is what’s called the “halo effect.” This is when one characteristic of something influences how people perc...

When you list things that need to be done, it’s tempting just to put together a list as I did earlier about Alex’s wedding: church, flowers, officiant, food, etc. The problem is, if you give any of those items to a separate team that isn’t intimately invested in the results of the decisions between white roses and daisies, you might not get the results you’re looking for.

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. We have an intimate grasp of characters, desires, and motivations. Where we get into trouble is when we try to abstract out of the main through-line discrete parts and deal with them out of context.

So the first thing you want to think about when you’re considering a task is character or role—for example, a customer, a bride, a reader, an employee. Who is this task being done for? Whose lens on the world is the one we need to gaze through when we’re building this thing, making that decision, or delivering this piece? Then you need to think of the what—what we want

It’s simply a picture of Captain Jean-Luc Picard of the USS Enterprise, under which the text reads: “As a starship captain, I’d like the log function to automatically use today’s stardate.… ” It makes sense when you think about it. Haven’t you wondered why in the far future a starship captain would have to state the date when he makes a log entry? “Captain’s Log. Stardate 4671.7. The planet Mars is lovely from orbit.…” We don’t have to do that now when we make a blog entry. Why does he?

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. How do those character types feed what they want? Why do they need a car? What are they going to do with that captain’s log?

The whole collection of stories that might make up that idea of an online bookstore is often referred to as an “Epic”—a story too big to do by itself but that includes a number of smaller stories that add up to a single idea.

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?”). We find in real projects that if stories are really Ready, the team will double the speed of implementation. And if the stories are really Done at the end of a Sprint, teams can double speed again. This is one of the tricks needed to get twice as much work done in half the time.

In Scrum this kind of planning happens with each and every Sprint at what is called the “Sprint Planning” meeting. Everyone gets together and looks at the list of stories that have to be done and says, “Okay, what can we accomplish at this Sprint?

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

“I can’t tell you that today. We have to get the teams moving to see how fast they are. I’ll tell you what: in six weeks I’ll give you our delivery date, and it isn’t going to be one you’ll like. But,” I said quickly before he could interrupt, “I’ll give you a list of the things that are getting in your teams’ way, that are stopping them from meeting that July date you promised Wall Street. A list of impediments. And your job will be to remove them as fast as possible.”

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.

By the end of the next Sprint, the teams’ velocity had gone up 50 percent. The new date for delivery was September 1. Still three months late even though they had accelerated from 20 points to 90 points per Sprint, over 400 percent! And still not good enough. So Brent and I gathered everyone together, from engineering to marketing to business analysts to compliance folks to management.

It was amazing to watch the stock price of Medco that summer. When we started building the infrastructure, the stock started going up, and when we delivered, it continued to rise. How much? Well, many billions of dollars’ worth, from a price of 25 to over 50 within the year. Wall Street had decided the company would continue to grow, would attract new customers, and would maintain its leadership in the field. In retrospect, I should have asked for a percentage-of-market-cap increase rather than a simple fee.

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

THE TAKEAWAY

These take aways seem contradictory.

The Map Is Not the Terrain. Don’t fall in love with your plan. It’s almost certainly wrong.

This sounds like a contradiction. What's the point of a plan if it's going to be wrong?

Only Plan What You Need To. Don’t try to project everything out years in advance. Just plan enough to keep your teams busy.

Plan with Poker. Use Planning Poker to quickly estimate work that needs to be done.

Know Your Velocity. Every team should know exactly how much work they can get done in each Sprint. And they should know how much they can improve that velocity by working smarter and removing barriers that are slowing them down.

Set Audacious Goals. With Scrum it is not that hard to double production or cut delivery time in half. If you do it in the right way, your revenue and stock price should double as well.

But our day-to-day life is mostly made up of journeys. We don’t summit peaks every day, or make the big score, or get a big bonus. Most of our days are taken up with striving toward our goals, whatever they may be. 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.

Empowering people would never work in their worldview. Of course, these days I’m a senior consultant to venture firms and I’m often treated like an oracle. When people have a hard problem, they ask the oracle for the solution. They don’t necessarily expect the answer to make sense. They just try it, and, to their surprise, it almost always works.

In this chapter I’m going to lay out just how important happiness is to your bottom line, and how to capture, measure, and apply it. This is happiness with rigor. 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.

Happy people sell more stuff, make more money, cost less, are less likely to leave their jobs, are healthier, and live longer. Or as a 2005 paper that did a meta-analysis of some 225 papers with over 275,000 participants put it:

“Study after study shows that happiness precedes important outcomes and indicators of thriving.”

I want you to take away from this is simple: even small gestures can have great impact. What Scrum is focused on is taking those small things and systematically building them up into a scaffolding for success. Just one thing at a time, and you can actually change the world.

Forget trust-building exercises, and instead build trust every single day. And I want you to measure it. It’s not enough to think people are happy. 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. And it does.

In Japanese the word used is kaizen, or “improvement.” 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.”