Learn more about Velocity Partners offshore software development company
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.
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 neither saying this nor 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.
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.
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. But at the same time, do their words, actions, and even body language affirm that they 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 or not:
Stay agile my friends,