Trust is Missing

Trust is a weird thing: it’s contextual, exists on a spectrum, and is very transactional. Think about your relationships. You trust some people with certain aspects of your life, but not everything. For instance, Todd and Ryan trust each other to work on this book and to co-teach a good class together—but they don’t trust each other to do each other’s laundry. And trust changes over time. It can take a long time to build up trust with someone, and then one misstep can wipe it out.

What does trust look like on a Scrum team?

• The product owner trusts the development team to create a done product increment by the end of every sprint.

• The development team trusts the product owner to provide them with a clear product vision.

• Development team members trust one another to do their best and support one another.

• Management trusts the Scrum team and removes any impediments to delivery.

Without trust, you can’t have transparency. If the members of a Scrum team don’t trust each other or an organization doesn’t trust a Scrum team, then it’s impossible to make the team’s work and progress evident to stakeholders. Instead, people play defense: they blame one another and fail to work as a truly collaborative team.

Want to quickly make your organization trust your Scrum team? Deliver. We’ve found no better way to build trust than consistently delivering increments of products every sprint.

But how do you increase the likelihood that a Scrum team can work together smoothly and deliver successfully? Well, other than solving the many anti-patterns in this book, here are a few quick ideas you can try:

• Shorten your sprint length. Instead of a four-week sprint, try a one-week sprint. The development team will have fewer product backlog items to focus on, the product owner will have stakeholders in the sprint review even more frequently, and collaboration will happen in shorter intervals.

• Focus sprint planning on setting a sprint goal that has a true impact on the customer. This helps inspire the team and gives them something real to work toward.

• Use the daily scrum as an opportunity for the development team to inspect their progress toward their sprint goal. Celebrate progress and promote opportunities for Scrum team members to support and help one another. This helps increase trust within the team.

• Create opportunities for the Scrum team to collaborate with real customers. The sprint review event is perfect for this. Who better to talk about the impact of the team’s work than the people who are actually affected by it?

• Introduce or reemphasize the importance of the Scrum values. If you and your team keep the Scrum values in mind, then empiricism will shine.

If you see that trust is lacking—either between your Scrum team and the rest of the organization or within the team itself—do everything in your power to find a way to build trust. We offer tips and exercises for doing so throughout the rest of this book. For Scrum to work to its full potential, trust is mandatory.