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

by Jeff Sutherland

Three, the Product Owner has to be available to the team, to explain what needs to be done and why. While the Product Owner is ultimately accountable for the Backlog, there needs to be a constant dialogue with the team.

This is one of the reasons I rarely recommend that CEOs or other senior executives be Product Owners. They just don’t have the time the team needs.

Now, that’s a lot to ask of one person, and it’s the reason why in big projects there’s usually a team of Product Owners to address all the needs.

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

This insight has become fundamental to how wars are fought. And it’s exactly what I designed Scrum for—to allow a Product Owner to make decisions quickly, based on real-time feedback.

A few years ago I heard about a Scrum developer that got a $10 million contract to deliver software for a big construction company. The two parties agreed on a twenty-month time frame. But the Scrum company inserted a clause into the contract. 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.

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.

Then, as the Product Owner, put together a road map of where you think things are going. What do you think you can get done this quarter? Where do you want to be this year? It’s important to remember that this is just a snapshot in time, so don’t overplan, just estimate.

It’s the system that has failed them, and us. But how do we change it? How do we encourage transparency, priorities, and accountability? You know the answer: Scrum.

The office of the Chief Information Officer of the State of Washington is responsible not only for what technology is purchased, but how it’s made. The CIO’s office is made up of twenty people who are supposed to make sure massive IT failures, costing tens of millions of dollars, don’t happen. Meanwhile, the department handles IT upgrades for the parts of the government that do everything from issue driver’s licenses, to distribute unemployment benefits, to regulate fish and wildlife. In 2012 they oversaw eighty requests totaling more than $400 million. And they issue standards and guidance to various agencies on how to implement state policy. To do that, they use Scrum.

But there are some roadblocks. DeAngelo says that one thing they’ve realized is that in some cases the Waterfall method is actually written into state law. Changing that can be tough. The State of Washington funds things in two-year cycles. “You have to ask for big chunks. You can’t say we’ll add value until you tell us to stop,”

Part of the problem is that in the United States, both at the federal and state level, legislatures are broken into committees. One group of lawmakers looks at education, another at crime, another at the budget, and yet another at social services. “They are fractured. They never look at the whole picture,” says Rick Anderson.

In a revamped, Scrum-driven world, instead of approving a specific plan to build a bridge across a river, a legislative body would say to the highway department, “We want X number of people to be able to travel over this waterway in Y amount of time with Z cost. How you do that is up to you.” That would allow for discovery and innovation. Instead, the norm these days is construction projects that run hundreds of millions of dollars over budget. The reason? As crews work on the project, they discover new problems and new ways of solving them. Instead of stifling that kind of innovation with Change Control Boards and massive reporting, we should be encouraging it.

As they say on Wall Street, if you don’t know who the sucker in the room is, you’re the sucker.

One company that has learned how to set its employees free and optimize innovation is Valve. To look at the firm is to behold how we all may

The company has over fifty million customers, and it makes hundreds of millions of dollars a year. And no one is really in charge.

Here’s how a project starts at Valve. Someone decides to start it. That’s it. They figure out what they think is the best use of their time and energy, what will serve the company and the customer the best, and they do it. How do they get other people to work with them on it? They convince them. If that other person thinks it’s a good idea, they’ll join that team, or “cabal,” as it’s called at Valve. All the hundreds of desks at Valve have wheels. As people start to work together on a project, they literally vote with their desks, moving them into a new configuration.

“When a company has optimized itself around innovation, they usually change in a fundamental way by eliminating internal structures and hierarchies, any internal structure,” says Greg. Valve operates that way all the time. They don’t wait to be forced into change by a crisis; they are constantly changing. It’s the day-to-day way they run the company.

Valve is not averse to all organizational structure—it crops up in many forms all the time, temporarily. But problems show up when hierarchy or codified divisions of labor either haven’t been created by the group’s members or when those structures persist for long periods of time. We believe those structures inevitably begin to serve their own needs rather than those of Valve’s customers. The hierarchy will begin to reinforce its own structure by hiring people who fit its shape, adding people to fill subordinate support roles. Its members are also incented to engage in rent-seeking behaviors that take advantage of the power structure rather than focusing on simply delivering value to customers.

It may seem that Valve would be vulnerable to freeloaders—to people who want to take advantage of the system—but peer review is constant. Sure, people get to decide what to work on, but if they can’t convince anyone else it’s a good idea, maybe it really isn’t. Greg says that instead of having the luxury of having someone tell you what to do, you have a group of peers telling you what they think of what you’ve decided to do.

“So a group of the core Valve people who have been around for a while took action to protect the Valve ethos. Even though they had to act outside of the ethos to do it,”

That’s what Scrum does. It sets goals and systematically, step by step, works out how to get there. And even more important, it identifies what is stopping us from getting there.

That’s what I hope you’ll take away from this book: the knowledge that it is possible—that you can change things, that you don’t have to accept the way things are.

By the end of the meeting the team and the Scrum Master should agree on one process improvement that they will implement in the next Sprint. That process improvement, sometimes called the kaizen, should be put into the next Sprint’s backlog, with acceptance tests.