Are you asking? Or are you telling?

If you’re using Scrum to manage a software development system, you’re (hopefully) conducting Sprint Reviews at the end of each sprint to review the results of the iteration, and to demonstrate the new value the team has delivered. I get to see a lot of companies’ take on the Sprint Review, and I’ve observed a common anti-pattern. I often see teams demonstrate software for their customers, then spend a lot of time arguing with them about whether they built it right or not.

Demos are not for telling customers what you built, they’re for asking if what you built is right. When we only tell customers what we’ve built, we’re ignoring the uncertainty inherent in software development. If we take a defensive position when changes are (inevitably) requested, we’re engaging in contract negotiation with our customers. Typically, teams take this stance when they feel they might be punished in some way for building the wrong thing, so they use the demo to prove that they built what was asked for.

But as counterintuitive as it sounds, the goal isn’t to build what was asked for. The goal is to build what customers want and are willing to pay for. Customers can’t easily articulate what they want, unless we show them something that they don’t want. The demo is an opportunity to inspect and adapt. If we inspect but don’t adapt, we’re running the risk of building the wrong thing.

When we ask if what we built is right, however, we’re ensuring that we leave room for adaptation. If we take a position that says, “we probably got some of this wrong, but give us your feedback on what resonates with you and what needs more work”, we’re revealing an opportunity to collaborate, and pointing the product closer to something the customer is willing to buy.

This is scary territory for development teams that are used to defining success by meeting deadlines and budgets within scope constraints. To those teams, collaborating from a position of potentially being wrong is akin to declaring defeat. I think that, as important as things like budgets and deadlines are, building something that customers are willing to pay for is a more relevant measure of success.

When you ask if it’s right:

• Batches shrink, because we tend to view stories as bets, and we recognize the risk of getting big bets wrong.
• Writing stories gets easier, because team members anticipate the outcome of the demo when writing them.
• The product gets better, because we give our customers an opportunity to provide clarity over time.
• Engagement increases, because discovering the right product becomes everyone’s responsibility.
• Trust increases, because our customers begin to see that we’re working with them, not against them.

What do your sprint reviews look like? Are you giving your customers an opportunity to adapt?

Have an idea for the weekly inspection? I’d love to hear it – @johnkrewson