One, the Product Owner needs to be knowledgeable about the domain. By this I mean two things: the Product Owner should understand the process the team is executing well enough to know what can be done and, just as important, what can’t. But the Product Owner also has to understand the what well enough to know how to translate what can be done into

it’s pointless to look for evil people; look instead for evil systems.

Reflecting on my time at West Point and in Vietnam, I found myself agreeing that leadership has nothing to do with authority. Rather, it has to do with—among other things—knowledge and being a servant-leader. The Chief Engineer can’t simply say something has to be done a particular way. He has to persuade, cajole, and demonstrate that his way is

By getting constant input from whoever is getting value from what you’re doing—be it the person clicking the Buy button on Amazon, the parishioners of your church, the children in a classroom, or someone trying on a dress—you’re in a position to constantly adjust your strategy and more quickly succeed. The idea goes by the somewhat ludicrous name

The Product Owner needed to be able to deliver feedback to the team from the customer each and every Sprint. They needed to spend half their time talking to the people buying the product (getting their thoughts on the latest incremental release and how it delivered value) and half their time with the team creating the Backlog (showing them what the

All men dream: but not equally. Those who dream by night in the dusty recesses of their minds wake in the day to find that it was vanity: but the dreamers of the day are dangerous men, for they may act their dreams with open eyes, to make it possible. —T. E. Lawrence, Seven Pillars of Wisdom

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

Everyone Knows Everything. Communication saturation accelerates work.

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.