It is likely that some stakeholders will fall back on old habits, and go directly to team members in an attempt to get their stuff done quickly. Team members can learn to redirect these requests with artfully diplomatic ripostes like: “This sounds important, you should bring it to our product owner!”

In scrum, no-one but the product owner is authorized to ask the team to do work or to change the priority of backlog items.

‘rugby’ approach—where a team tries to go the distance as a unit, passing the ball back and forth.”

This vision encompasses who the product is being built for, why they need it, and how they will use it. It informs all of the many decisions that must be made in order to make the product a reality.

like having their tasks, agreements, and progress charts in plain sight at all times.

“The agile movement is not anti-methodology,” Highsmith wrote, “in fact, many of us want to restore credibility to the word methodology. We want to restore a balance. We embrace modeling, but not in order to file some diagram in a dusty corporate repository.”

Test as you go, not at the end—a bug fixed now is cheaper than one that has had a chance to propagate through a system for months. Deliver product early and often, as only by demonstrating working software to your customer can you find out what they really want.

Being agile is about building a flexible process that anticipates and embraces change, allowing the team to adapt to new requirements and unexpected developments. It is a by-now-familiar refrain: inspect and adapt. Notice how that mantra surfaces in every discussion of every agile value?

Document as you go, and only as needed. When you bake the documentation into your process, you only write documentation that is relevant and useful. Build cross-functional teams to break down silos, so that no individual or department can become a process or information bottleneck.