Trust is the grease that keeps a team running smoothly. One of the most effective and low-cost ways to improve the delivery, performance, and morale is to gain the team’s trust. As a Scrum Master, it’s your responsibility to build trust with your team. A team that trusts their Scrum Master has an advantage over others. Broadly speaking, teams perform better when they feel they’re in good hands.
Scrum Masters can seem like outsiders, as you tend to interact with the team, not with their work. The dynamic is exacerbated during Agile transformations: Scrum Masters who are brought in to work with a team that is used to a waterfall approach can struggle to gain the team’s trust.
Here are 5 ways to connect with your team, and demonstrate that you are here to help and support them:
1. Ask questions and remember the answers.
Scrum Masters are rarely domain experts in all areas of the project they’re working on. You can easily get lost juggling department dynamics, rapidly changing requirements, and company jargon. Teams can confuse their Scrum Master unintentionally, and they notice when their Scrum Master doesn’t catch up. If you fall into this sand pit, you can quickly get stuck, unable to convince the team that you understand what they are going through.
Luckily, one of the most valuable tools for building trust is also an excellent and simple solution to this problem. Just ask questions and remember the answers.
Team members are proud of their skills and knowledge; showing your interest in their work is a simple way to demonstrate that you value them. By asking questions when you aren’t entirely sure of the answers, you’re telling the team you care about what they do and want to learn more. On a basic level, this will also improve your knowledge and understanding of the project you’re working on, which will pay dividends for you on its own; the bonus is the growing trust from your team!
Asking questions can sometimes feel a little awkward. It can be uncomfortable to feel like we don’t know what we’re doing. But it’s important that we make ourselves vulnerable so the team feels empowered to ask their own questions, of you and of each other.
It’s paramount to remember the answers the team gives you. All your trust-building and question-asking will come to naught if—when the subject of your previous question comes up—you’re still confused. Of course, you’ll sometimes forget things (you’re not a computer after all), but you do have to be careful to remember far more than you forget. This closes the loop for the team; you cared enough to ask about their work, you asked them, you paid attention to their answers, and then you cared enough to remember and learn from their experiences.
2. Take the blame.
Mistakes happen; we’re only human, and that’s ok. When they do happen, it’s your job to step in to take responsibility. You might be explaining what happened to people outside the team, but you should do the same when discussing the situation with the team too.
Casting blame ultimately does no one any good, and by taking the blame, you’re helping move the conversation forward to something more useful and productive. You want the team to talk about how they’re going to fix the problem, not whose fault it was. Be sincere when you take the blame, then move the discussion to more fruitful ground. It’s valuable to get used to taking the blame early and often; in all projects, mistakes are inevitable. Thankfully, in Agile, mistakes allow for quick course corrections, preventing the issue from snowballing the way it would in a waterfall project. Mistakes made early in a project provide a perfect opportunity to step in and take the blame, especially when the team is just learning to work within Agile.
Taking the blame also means the team trusts you to own up to your own mistakes, to take ownership of the team’s struggles. This doesn’t mean that the team itself may not have made mistakes. Such missteps should be discussed and addressed, such as at a Sprint Retro. But it moves the dialogue to a productive and valuable place.
3. Be honest and transparent.
In every organization, there’s a certain amount of information that people want to hold close to the chest. This is entirely natural and is by no means a problem in and of itself. Problems occur when people become so concerned about preventing things from being talked about, they discourage people from talking entirely or hide things from those who most need to know.
Your job as Scrum Master is to stop this from happening, especially within your team. Teams will follow your example, so you must model the behavior you want to see. Ultimately, you must be a little more honest and transparent than you might be comfortable with at first. Push as much information out to the team as your project sponsors are ok with; then convince your sponsors to tell the team even more.
Curiosity is a natural thing; sating that curiosity brings a level of satisfaction and understanding from your team that is invaluable. Frankly, it’s better for your team to know too much than too little. Teams with a high degree of transparency are better able to identify issues and propose solutions to each other—usually dealing with a problem more effectively than one could on their own. Honesty and transparency show the team you’re committed to them and their work, not the strictures of the job.
4. Let the team lead.
Often, as a team is learning Agile, they’ll turn to their Scrum Master with a question about how something should run. This is totally normal, and a big part of a Scrum Master’s job is to reinforce Agile and Scrum principles. However, as a team matures, it will naturally move away from “pure” Scrum.
Teams operate differently, and out-of-the-box Scrum works perfectly for very few teams. When your team has questions about the best way to handle some part of the process, turn the question back on them. When they ask, “Should we do, X or Y?” reply, “That depends. What works better for you and the rest of the team?” Let them lead themselves to the answer; you just need to give them the space to find it. Often, they have the answer already, they’re looking for someone to validate their answer, or they don’t trust themselves enough to come up with it.
By turning their question back to them, you’re enabling them to lead themselves. Within Agile, the team should be self-organizing, and this a big shove along that path.
When you give the team leeway to learn to lead themselves, you are demonstrating that you trust them, and this is naturally reciprocated.
5. Trust the team.
Here’s the deal: if you don’t trust the team, they won’t trust you. There are no two ways around it. People can sense doubt. When you think what they’re saying or doing is untrustworthy, your team will know, and they will project that mistrust back on you.
What can you do? Easy. Trust your team. Not only when you know absolutely, for-sure, 100%, that they’re trustworthy. Trust them as soon as they’re assembled, and then trust them more as you understand them! Trusting doesn’t mean ignoring or glossing over mistakes; it means you trust them to do the right thing, and to fix it when they slip up. Trust means holding each other accountable, being honest, being on their side, genuinely caring, and helping them to be better.
A Scrum Master who practices asking questions and remembering the answers, taking the blame, being honest and transparent, letting the team lead, and trusting the team will enjoy higher productivity, less friction, and better quality outcomes.
