How to Build Trust to Enable Agility
How much can your team get accomplished without trust? If you're looking over your shoulder, try BRAVING it for better results.
Join the DZone community and get the full member experience.Join For Free
One of the most common questions I am asked in my Professional Scrum Master (PSM) courses and in coaching engagements is:
"How do we build trust?"
This is a complex topic. And there are no simple or quick processes or techniques that will guarantee an outcome. Nor can you know how long it will take to build trust.Trust is fluid and constantly evolving.There is no "end goal." Because trust is a feeling.
Trust is a characteristic of a relationship, of many interconnected and overlapping relationships.
It may be challenging and complex, but trust is essential to enable agility. So let's define what trust is and the elements required to build trust.
What Is Trust?
Trust is a willingness to be vulnerable. When I trust, I am essentially making something important to me vulnerable to the actions of someone else.
Distrust is when I don't feel that something I have made vulnerable to you is actually safe with you.
What are things we make vulnerable? It could be position, reputation, ideas, work or creation, opportunity, or feelings. It could be a paycheck.
Anatomy of Trust
Brené Brown uses the acronym BRAVING to talk about the elements required to build trust. Brené says that when we trust, "...we are BRAVING connection with someone." Let's explore each element related to enabling agility.
"I establish clear boundaries, and I stick to my boundaries. You establish boundaries, and you hold your boundaries. We both respect each other's boundaries."
The Scrum framework is an example of boundaries that help a Scrum Team focus and self-organize around a goal to deliver shippable product by the end of a Sprint. Team members stick to this boundary by not accepting additional work during the Sprint that would endanger that goal. Others in the organization respect this boundary by not forcing or pressuring them to break this boundary.
People may also set individual boundaries in the context of the workplace. I may set a boundary that I leave my work at the office. Or perhaps I don't check email on the weekend. Maybe I don't take on any new projects or activities unless I remove something equivalent.
"I do what I say I will do. You do what you say you will do. Over and over and over again."
Reliability is important when you need to collaborate in order to solve challenging problems and innovate. Reliability is important when success is measured by team outcomes, not solely by individual activities. You can't just be reliable once. Consistency matters. There are two things you must consider in order to be reliable.
1. Establish Clear Expectations.
A Scrum Team creates a clear Sprint Goal and a transparent plan for achieving it. These expectations are revisited at least on a daily basis in the Daily Scrum. A Scrum Team also sets a clear expectation of quality and completeness in their definition of "Done."
2. Don't Overcommit.
When we have too many plates spinning in the air, we can have problems focusing, we may cut corners or forget things, and we can experience burnout. Learn to say "no" or "not now."
Of course, we cannot predict exactly how long things will take. So we may be wrong.
Improving my reliability has been an intentional focus this past year. Specifically, I never say "yes" to new opportunities or requests immediately. I take some time to consider if it is something I really want to do in the greater context of my life. And if I do, I then consider what I am removing to make space and outline some expectations (outcomes, time commitment, working agreements, etc.). More often than not, I end up saying "no" or "not now."
"I hold you to account for doing the things you said you would do. You can hold me to account for doing the things I said I would do."
"Calling someone out" is not a bad thing. It's a thing you do when you deeply respect and care for someone. And if you are on the receiving end of it, you appreciate that this person had the courage to help you see something maybe you were unable to see and to help you do better.
And since we are human beings, we are going to screw up.
When you do, own it. Apologize and make amends.
When you are on the receiving end of it, you allow the other person to own it, apologize, and make amends.
"What you share with me, I will hold in confidence. And I expect you to do the same with me, and with others."
When we gossip or collude with others, we are demonstrating that we will not hold information in confidence. This erodes trust.
I often find coaching opportunities around this topic. As a Scrum Master, a team member may come to me about issues with another team member. Ultimately, I will coach this team member on addressing the issues with that person directly.
If you put yourself in the other person's shoes, how would you feel if a team member was complaining about you to someone else?
The Sprint Retrospective is an example of where we honor the "vault" as a team. Only Scrum Team members participate, and the specifics of what happens in the room stays in the room. A Scrum Master helps keep a positive, continuous improvement focus rather than just dwelling on the negative and complaining.
"This is about choosing courage over comfort. This is about choosing what is right over what is simply fun, fast, or easy. Practice your values rather than just professing them."
Product Owners show integrity by saying no to stakeholders who want something that is not in alignment with the product vision or is of low value. They don't just put it at the bottom of the Product Backlog to make the stakeholder happy.
Scrum Teams show integrity by not showing partially done software in the Sprint Review.
When our leaders profess their values, we expect their actions and decisions to reflect them. People don't trust leaders who say one thing but then do another. If a leader says he values learning and innovation, but he measures individuals on a strict "billable hours" policy or by "lines of code", this inconsistency breaks down integrity.
"You can be struggling and ask for help, and I will not judge you. I can be struggling and ask for help, and you will not judge me."
Practicing non-judgment honors vulnerability. It must be okay to need help. In fact, we should place value on being willing to ask for help. We cannot think less of someone when we offer them help.
I may think that the quality of your work has been suffering and does not meet our standards, but I am not going to assume you intentionally did poor quality work or that you don't have the same level of commitment as I do. I can hold you accountable from a place of non-judgment.
Truly believing that we learn from failure is another way that teams and organizations practice non-judgment.
"You can assume the most generous things about my words, actions, and intentions. And I will do the same for you."
Generosity means recognizing that we are all human. We make mistakes. We go through difficult times. Generosity means we are willing to forgive, offer an opportunity to make amends, and hold space for the inevitable learning and growth that is part of being human and being part of a team.
I may feel disrespected by something you said in our planning session, but I know you would not intentionally hurt me. I will have a direct and honest conversation about how I feel, but I will not label you as a disrespectful person.
Make It Real
Set aside 10 minutes and reflect on these questions. Pick one or two relationships where you want to build trust.
Step 1: How can the acronym BRAVING help you think about and talk about trust differently?
Step 3: Where do you have an opportunity to improve each of the 7 elements of BRAVING?
Bonus: And if you have 25 minutes, check out Brene Brown's talk on the Anatomy of Trust. Then ask yourself who is filling up your marble jar, and how are you filling up the marble jar? (Yes, you have to watch the video to know what that means.)
Published at DZone with permission of , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.