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

by Jeff Sutherland

There are studies going back to World War II that lay out some of the better ways that people work. But for some reason people never really put together all the pieces. Over the past two decades I’ve tried to do just that, and now this methodology has become ubiquitous in the first field I applied it to, software development. At giants such as Google, Amazon, and Salesforce.com, and at small start-ups you haven’t heard of yet, this framework has radically shifted how people get things done.

At its root, Scrum is based on a simple idea: whenever you start a project, why not regularly check in, see if what you’re doing is heading in the right direction, and if it’s actually what people want? And question whether there are any ways to improve how you’re doing what you’re doing, any ways of doing it better and faster, and what might be keeping you from doing that. That’s what’s called an “Inspect and Adapt” cycle.

The term “Agile” dates back to a 2001 conclave where I and sixteen other leaders in software development wrote up what has become known as the “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.

What Scrum does is bring teams together to create great things, and that requires everyone not only to see the end goal, but to deliver incrementally toward that goal.

Working product in short cycles allows early user feedback and you can immediately eliminate what is obviously wasteful effort.

One of the key concepts in Scrum is that the team members decide themselves how they’re going to do the work. It’s management’s responsibility to set the strategic goals, but it’s the team’s job to decide how to reach those goals.

The transparency and sharing of a truly fantastic team threatens structures rooted in secrets and obfuscation. Managers often don’t want other managers, their own teams, or other people within the power structure to know exactly what they’re doing or what is being accomplished and how fast.

In software development there’s a term called “Brooks’s Law” that Fred 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.

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 very large groups do less seems to be an ironclad rule of human nature.

Sprints are what are often called “time boxes.” They’re of a set duration.

You don’t do a one-week Sprint and then a three-week Sprint. You have to be consistent. You want to establish a work rhythm where people know how much they can get done in a set period of time.

There’s no assigning of tasks from above—the team is autonomous; they do that. There’s no detailed reporting to management. Anyone in management or on another team can walk by and look at the avionics Scrum board and know exactly where everything stands.

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

What Scrum does is alter the very way you think about time. After engaging for a while in Sprints and Stand-ups, you stop seeing time as a linear arrow into the future but, rather, as something that is fundamentally cyclical. Each Sprint is an opportunity to do something totally new; each day, a chance to improve. Scrum encourages a holistic worldview. The person who commits to it will value each moment as a returning cycle of breath and life.

The heart of Scrum is rhythm. Rhythm is deeply important to human beings. Its beat is heard in the thrumming of our blood and rooted in some of the deepest recesses of our brains. We’re pattern seekers, driven to seek out rhythm in all aspects of our lives.

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.

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.

Plan in just enough detail to deliver the next increment of value, and estimate the remainder of the project in larger chunks.

What using the Fibonacci sequence to calculate task size permits is estimates that don’t have to be 100 percent accurate. Nothing will be exactly a five or an eight or a thirteen, but using those numbers gives us a way to collect opinions on the size of a task where everyone is using roughly the same measuring stick, and in that way a consensus is formed. Estimating as a group in this manner gives us a far more accurate estimate than we could come up with alone.

There is a mnemonic I always use to tell whether a story is ready. It was created by Bill Wake, who’s a deep thinker on software design. Bill says 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.

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.

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

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, because, as they put it, “Doing your job in an information vacuum is tedious and uninspiring.” Managers should also have zero tolerance for incivility and never allow an employee to poison corporate culture through abuse or disrespect. And, finally, they should give quick and direct feedback.

The “Wise Fool” is the person who asks uncomfortable questions or raises uncomfortable truths. These workers aren’t always easy to have around, since they can be seen as troublemakers or not part of the team, but they need to be cultivated and used.

Complacency is the enemy of success.

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.

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.

When you’re picking a Product Owner, get someone who can put themselves in the mind of whoever is getting value from what you’re doing. As a friend of mine says, “My wife is the perfect Product Owner; she knows exactly what she wants. I just implement it.”

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.

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?

Every hour spent polishing the apple is lost opportunity for value.

A lot of business advice revolves around failing quickly. I prefer to think about delivering fast.

Make a List. Check It Twice. Create a list of everything that could possibly be done on a project. Then prioritize it. Put the items with the highest value and lowest risk at the top of that Backlog, then the next, and then the next.

Create new things only as long as those new things deliver value. Be willing to swap them out for things that require equal effort. What in the beginning you thought you needed is never what is actually needed.

Scrum accelerates human effort—it doesn’t matter what that effort is.

Scrum is the code of the anti-cynic. Scrum is not wishing for a better world, or surrendering to the one that exists. Rather, it is a practical, actionable way to implement change.

Make Work Visible. The most common way to do this in Scrum is to create a Scrum Board with three columns: To Do, Doing, Done. Sticky notes represent the items to be completed and the team moves them across the Scrum board as they are completed, one by one.