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

by Jeff Sutherland

I first created Scrum, with Ken Schwaber, twenty years ago, as a faster, more reliable, more effective way to create software in the tech industry. Up to that point—and even as late as 2005—most software development projects were created using the Waterfall method, where a project was completed in distinct stages and moved step by step toward ultimate release to consumers or software users. The process was slow, unpredictable, and often never resulted in a product that people wanted or would pay to buy. Delays of months or even years were endemic to the process. The early step-by-step plans, laid out in comforting detail in Gantt charts, reassured management that we were in control of the development process—but almost without fail, we would fall quickly behind schedule and disastrously over budget.

I discuss how we organize projects around small teams—and why that is such an effective way to work. I explain how we prioritize projects, how we set up one-week to one-month “sprints” to gain momentum and hold everyone on the team accountable, how we conduct brief daily stand-ups to keep tabs on what has been done and on the challenges that have inevitably cropped up. And how Scrum incorporates the concepts of continuous improvement and minimum viable products to get immediate feedback from consumers, rather than waiting until a project is finished.

Why a World War I artifact has become the de facto tool used in twenty-first-century project management has never been quite clear to me.

And I’d remember that Eisenhower once observed that planning for combat is important, but as soon as the first shot is fired, your plans go up in smoke.

Yet when Jeff and his boss, CIO Chief Chad Fulgham, looked at the plan in the spring of 2010, they knew it for what it was, what such charts all are, really: a complete fabrication. When the two men started to look at actual development and actual deliverables, they realized the problem was beyond fixing. New defects in the software were being discovered faster than old ones were being fixed.

they’d deliver the most challenging half of the project in less than a fifth of the time with less than a tenth of the amount budgeted.

“In sum, we have significant concerns and questions about the ability of this new approach to complete the Sentinel project within budget, in a timely fashion, and with similar functionality.

One of her tests of whether a team is on the right path comes when she asks, say, a network engineer, “What team are you on?” If he or she responds by mentioning the product they’re working on (say automation or integration) rather than their specialty (such as network engineering), she nods approvingly. When a specialist identifies with their specialty more than with the product they’re actually making, Dourambeis knows she still has work to do.

The transparency and sharing of a truly fantastic team threatens structures rooted in secrets and obfuscation.

What Kind of Dog Is It? Don’t estimate in absolute terms like hours—it’s been proven that humans are terrible at that. Size things relatively, by what breed of dog the problem is, or T-shirt size (S, M, L, XL, XXL), or, more commonly, the Fibonacci sequence.

He’s the founder of OpenView Venture Partners, and he’s the one who figured out that working longer hours creates more work than it accomplishes.

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.

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

There are only three roles in Scrum. Either you’re part of the team, and you’re doing the work, or you’re a Scrum Master, helping the team figure out how to do the work better, or you’re a Product Owner. This is all laid out in the appendix. The Product Owner decides what the work should be. He or she owns the Backlog, what’s on it, and, most important, what order it’s in.

The problem was, after the second Sprint we introduced the Daily Stand-up meeting.

They don’t give anyone performance appraisals or promotions or raises. But they do decide on the vision of the car, and how the car will be made—by persuasion, not coercion.

Rather, it has to do with—among other things—knowledge and being a servant-leader.

So I split the role in two, giving the Scrum Master the how and the Product Owner the what.

The battle was decided not by what the machine could do, but by how fast observation was translated into action.

And it’s exactly what I designed Scrum for—to allow a Product Owner to make decisions quickly, based on real-time feedback.

As Boyd put it in a briefing he gave to other officers, “He who can handle the quickest rate of change survives.”

Then, based on that information, she can change what the team will do in the next Sprint.

When you’re thinking about building something, don’t assume you can’t deliver something of value until the very end. Instead, try to think about the minimum viable product. What is the absolute least I can build and still deliver some value to a customer?

This allows them to see how people actually react, rather than guess how they will react.

A fallback, if you can’t put something before an external customer, is to identify an internal customer—for example, the Product Owner—who can act in lieu of the public.

A nice tight little world where there’s no change … [creatures who live in such a world are] dinosaurs; they’re going to die. The name of the game is not to become a dinosaur. If you’re in an equilibrium condition, you’re dead.… The underlying message is simple: there is no way out.… That’s the way it is, guys.4

The adage to keep in mind comes from Frederick II of Prussia, later to be called “the Great”: “He who will defend everything defends nothing.

Whenever you’re making something, you want to put it in the hands of those who are actually going to use it as fast as possible.

I call this a “Minimum Viable Product,” or MVP.

With this incremental-release process, in the time it would’ve taken you to create half of the features of your initial product or project, you’ve now released 200 percent of the value, in half the time.

One of the big sources of the cost overruns there—and in just about any contract, be it to build computer software, airplanes, or buildings—is change fees.

Racking up change fees is actually the business model of a bunch of government contractors. They’ll underbid a project, knowing that they’ll make a profit because of change orders. When a contract is written on a years-long project with all the requirements spelled out in those pretty-looking charts, it’s tempting to say, “Well, that covers it.” Then the contractor says, “I’m agreeing to do this and only this. If you want any changes, it will cost you.” This after-the-fact billing has become the center of so much cost that companies and agencies have set up Change Control Boards.

Then every Sprint, the customer, who in this scenario is contractually obligated to work closely with the Product Owner, can change priorities completely.

Any item or feature in the Backlog can be moved anywhere else. And new features? No problem: just drop equivalently sized features from the deliverables. Oh, you want a laser-guided system now? Well, that’s 50 points of work—to compensate for that addition, let’s drop 50 points of low-priority features from the bottom of the Backlog.

If the construction firm wanted to terminate at any time, they could—they’d just have to pay 20 percent of the value of the remaining contract. Basically, if the software worked the way the construction firm wanted, they could stop the Scrum shop from building any more.

Let’s do a little math here to see how everyone won. In the first three months of the contract the customer paid out $1.5 million to the Scrum firm. Terminating the contract early required them to pay 20 percent of the remaining $8.5 million—that’s $1.7 million. They paid out $3.2 million for a piece of software they thought would cost $10 million, and they got it seventeen months early.

In this way Scrum aligns everyone’s interests: those of the team, the Scrum Master, the Product Owner, the customer, and the company. Everyone works toward the same goal and with the same vision: deliver real value as fast as possible.

Management of risk is at the heart of any successful venture. What Scrum allows you to do is reduce the risks of failure. The three most common types are market risk, technical risk, and financial risk. Or, to put it another way: Do people want what we’re building? Can we actually build it? Can we really sell what we’ve built?

It’s often what the customer said they wanted at the beginning of the process, but in reality people don’t know what they really want until they can try something out.

Apple famously does this with all their products, often building a dozen fully functioning prototypes before organizing a shoot-out to see which one is the best. This allows different ideas to be expressed quickly without a massive investment.

By putting incremental releases in front of customers quickly, you’ll find out what your customers value and what they’re willing to pay for.

Okay, what do you do tomorrow to implement Scrum where you work? The first step is just putting together a Backlog and a team. Think about the vision you have for your product or service or whatever, and start breaking down the things you need to do to execute that vision. You don’t need a whole lot—just a week’s worth of Backlog. And while the team members are holding their Daily Stand-up meetings and running their first Sprint, you’ll be able to build up enough Backlog to keep the team busy for the next two Sprints.

They can see the stories move across the Scrum board to Done. They can graph story points against time on a Burndown Chart and watch a nice, steady line move toward zero, or burn down.

Or even better use the Fibonacci sequence and estimate the point value for each item: