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.

If the Product Owner isn’t available to the team, the whole process can fall apart. 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.

Four, the Product Owner needs to be accountable for value. In a business context what matters is revenue. I measure a Product Owner by how much revenue they deliver per “point” of effort.

After the first Sprint, once you’ve completed the OODA loop and delivered some product to customers, you’ll change that order, realizing that another arrangement is actually better. And then you keep doing it, continually updating and reprioritizing the Backlog each Sprint, tacking toward the order that delivers value the fastest. You’ll probably never reach the absolute perfect order, but you want to move toward it step by step, Sprint by Sprint. The key thing to remember is that the order is always in flux. The right order one week won’t be the same the next. Your environment will have changed. You’ll have learned new things. You’ll have discovered that some things are easier and some harder.

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. You want to do this even before you make 20 percent of the features.

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

This will get you the feedback you need to power your decision loop and prioritization. This is Version 0.5. This is a camera that can take a picture but can’t focus.

But what it gets you is feedback. The camera’s body is really awkward to hold because the shutter button is in a weird place.

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. From a cost point of view, it makes sense. Limit the number of changes, and you’ll limit the cost associated with them. What the bean counters don’t realize is that they’re setting up a system that is designed to deny people what they actually want. They’re trying to limit cost, but in doing so, they’re limiting learning, innovation, and creativity.

Management of risk is at the heart of any successful venture.

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?

Technical risk is interesting. The question of whether it’s actually possible to build what the customer wants is a tricky one, especially if you’re making something that is physical, which requires plants and tooling and up-front investment.

“set-based concurrent engineering.” What that means in English is “building a few different prototypes to see which one works best before going into full production.”

Financial risk is what causes most companies to fail. They’ve built something cool, but they can’t sell it for enough to actually make a profit. A classic example of this is online journalism and the death of the newspaper.

This idea of providing content or a service for free, and then making money on the advertising, is still prevalent in tech start-ups to this day.

Know that as the Product Owner you’re going to be evaluated on revenue and cost.

Whatever your experience, once the teacher began talking about covalent bonds or some other abstruse concept, there was likely a near-audible click as you and your fellow students gazed out the window, doodled pictures, or thought about the cute boy or girl in the second row.

it’s pointless to look for evil people; look instead for evil systems. Let’s ask a question that has a chance to actually change things: “What is the set of incentives that drives bad behavior?”