It’s sort of a chicken and egg problem in many agile teams—that is the notion of trust.
- Do you give the team your trust as an organization? Or do they have to earn it over time?
- And if they make a mistake or miss a commitment, do they immediately lose your trust? And then have to start earning it again?
- And is trust reciprocal, i.e., does the organization need to gain the trust of the team? And if so, how does that work?
I want to explore trust in this article. I’ve done it before, but an interview by Jeff Nielsen inspired me to revisit it. I’ve also been hearing quite a few leaders who are “going Agile” talk about earning it lately. Their reaction is more along the lines of:
I’ll try this agile stuff and see how it goes. If “it” and the “teams” earn my trust, then I’ll support it. But essentially, I don’t believe in this stuff and you have to “show me” that it works…
Here is an interview snippet between Cameron Phillip-Edmonds and Jeff Nielsen on AgileConnections. You can read the full interview here.
Cameron Philipp-Edmonds: Okay you talk about that broken promise, and that missed commitment. Once trust is really lost in an agile team, what is a good way to reestablish it, and can you reestablish it?
Jeff Nielsen: You mean trust within the team, or trust between a team, and it's larger project community?
Cameron Philipp-Edmonds: Let's go with both.
Jeff Nielsen: Okay, somehow I thought you would say that. Well let me start with the latter. If you run into a situation where the stakeholders call it a product owner or whatever you would, starts to believe that the team is not good at keeping it's promises. That's a very toxic situation, and difficult to regain. They say it takes years to build trust and on the moments to break it. That is trust, if I've seen teams that failed to deliver what they promise to do in iteration or two, and then for the next six months that's the story that gets told, and that's the belief that's going around the project ecosystem is this team just doesn't deliver.
That said, what I tell teams and the way I coach teams is the best thing you can do is make a promise and keep it, and once you do that, several times in a row, that becomes the new story. This doesn't have to be a promise about we'll get this match work done by the end of the iteration. Although that's a very effective promise to make at an iteration level or sprint level in agile team.
We'll do this six stories come, heck or high water, and if we finish these, then well these three more will treat as stretch stories, delivering on that commitment for a couple of iterations certainly goes a long way in building trust. It can be smaller things, it can be ... We're going to show up to this meeting in time, we'll commit to a certain often when you're in an environment when the requirements really are changing fast, and you keep up with.
One thing I encourage team to commit to is a certain level of output, a certain velocity. You say no matter what, we will produce twenty points worth this iteration. That's a promise you can work on. At the individual level, within the team, it's no different. You think about what the people that you trust, and the people that you don't trust. The people that you trust are those that do what they say, they're going to do most of the time.
When they don't, they let you know, right away when something comes up. We've all been in this situation where we find we're unable to keep a promise we've made. Sometimes that's lack of ability, sometimes it's our own foibles and weaknesses that get in the way. As soon as something changes, and you realize you're not going to be able to keep a promise, communicate that right away.
That goes a long way towards building a trust. The other key aspect of trust is trusting that someone else is considering your interest. It’s great to have someone that always does what they say they will do, and it's easy to trust that kind of person. It's even better if you trust at that person will do what they say they're going to do and keep your interest in mind as they do that.
Think about a relationship or a marriage relationship for example, that you have to have that.
I’m not sure if I agree with or even understand Jeff’s ramblings around trust. To be fair, it’s often hard to be coherent in a live interview.
A lot of what Jeff talks about seems to revolve around commitment as well. As in, I committed to you that I will deliver 10 stories in this sprint and then I only deliver 5. It seems as if doing that breaks the entire “trust circle” in his experience. Think in terms of the Circle of Trust from the movie Meet the Fockers.
Anyway, I want to explore some notions around trust that were inspired by the interview. Whether you consider them right or wrong, these are aspects of my leadership-based trust system.
Consider them my Circle of Trust :-)
From a leadership perspective in agile teams I most often coach leaders (managers, directors, senior leadership) that they need to extend trust in the beginning of their agile journey. That is the have the posture of the teams earning it and that they verify it, that it will significantly undermine the teams performance.
Do you extend trust indefinitely without results or reciprocal actions? No. But you extend it long enough so that your teams understand that things have changed, you’re trying, and that they indeed have your trust. In other words, that they’re empowered to be self-directed and need to take ownership and be held accountable for the results.
In the example, Jeff speaks to a team losing it. There’s a general quote around – “it takes time to build trust, but only a moment to lose it”. Sometimes there’s the reference to deposits in a bank account.
I’d like to change the word to faith in some instances. If a team is going through difficulty, then I might lose faith in their ability to deliver on their commitments. I still trust that they’re professionals and doing the best they can. They’re just hitting a rough patch. I also trust that they’re self-aware enough to reflect on their difficulties and to work hard on improving.
Trust, but Verify?
We all need to simply stop either saying this or even thinking it. If you need to verify, then you haven’t let go and you don’t trust your team. Period.
Sure, you may think this is a positive, trusting posture, but in the end, it’s not. You also have to keep in mind that agility, almost by definition, is “self verifying”. As a leader you can attend daily stand-ups, grooming meetings, planning meetings, and most certainly the sprint demo. By definition and based on your sprint length, you’ll be gaining a tremendous amount of “verification information” surrounding your team.
Trust, When the “going is tough”?
Want a measure of how far you’ve come in the trust department? Well don’t measure it when things are going well. Instead measure it under the worst of conditions, when your projects are failing and you’re under personal pressure from above.
Under these circumstances do you maintain your “trusting patterns” with your teams? If you do, it says quite a lot about your trust culture and how far you’ve come as an agile leader. Your teams will also pay attention to and appreciate the consistency under pressure.
Instead, worry more about gaining the Teams’ Trust!
As leaders we often have the false view that the team is there to “serve” us. That the very act of paying team members divorces us from treating the team with respect, engaging them as partners and serving them. In today’s complex marketplace of knowledge workers, this attitude is particularly archaic and harmful.
Instead, we leaders should be as concerned about gaining and maintaining our teams’ trust in us as we are in trusting our teams. Having a mindset of 360-degree trust is probably the “right” view. Do they trust our vision and goal setting? Do they trust our business sense and value-based prioritization? Do they trust our general decision-making and balanced view? Do they trust that we are fair and reasoned? Do they trust that we are trustworthy and have strength of character—do we do what we say and say what we do?
I actually wish that most leaders would focus 80:20 on trust. Focus 80% of their attention on gaining their teams’ trust and 20% on trusting their teams. I think that trust juxtaposition would serve all of us well.
I don’t think we explore trust often enough in our discussions surrounding the keys to solid agile performance. I don’t necessarily understand why beyond the fact that it’s an uncomfortable topic.
Clearly nobody will admit that they don’t trust another party in their working relationships. Often we look at it as a binary thing, either we trust (good) or we don’t trust (bad). When I actually think there are many degrees of trust, with many of us leaning towards not trusting.
And if we say that we trust, do our words, actions, and even body language affirm that we trust? Far too often the answer is no, with a lack of self-awareness often preventing us from recognizing the behavior.
I’ve blogged about trust and commitment in two other blog posts. You might want to check them out to see if I’ve staid consistent in my thinking or not:
I think my key takeaway is that I believe, truly believe that –
One of the critical agile success factors is the degree to which leadership extends trust in the early phases of agile adoption. It’s very much a leap of faith…that is “paid back” with the potential for phenomenal results.
Stay agile my friends,