We explain some techniques for building trust on agile teams in our Agile Coaching book. However, I continue to explore this topic, as I believe it's essential for agile coaches to master.
As an agile coach, you want to build trust with the people on the team you are coaching. You also want to improve trust between individuals on the team (which is hard to do if the team doesn't trust you yet). This blog shares my latest thinking on how you can help encourage trust to grow in different situations.
Since our book was published, I ran two workshops on "Trust & Project Culture" at XPDay and XP2010 conferences with Sallyann Freudenberg. Our focus in these workshops is how can we boost factors that improve trust and dampen those forces working against trust. Here are a couple of force-field charts from our workshops so you can get an idea of what those factors might be.
The Trust Equation
In preparing for our workshops on trust, I dug out a copy of "The Trusted Advisor" from my bookshelf. This is an excellent book by David Maister, Charles Green, and Robert Galford. It contains a useful formula that neatly captures aspects of our interactions relating to whether we are seen as Trustworthy:
The letters in this formula stands for,
- Credibility relates to expertise. An essential element in trust is having faith that the person I am placing my trust in has the skills and knowledge to meet their commitments. We lose credibility when we stretch the truth and claim to be capable in areas that we don’t have experience.
- Reliability relates to organizational skill to get the work done. I need to be confident that I can depend on a person doing what they say in a timely fashion to a proper standard. Essentially, we lose damage trust if we don’t meet our promises.
- Intimacy seems to be an odd factor to weave into an equation. Clearly, this doesn’t refer to physical intimacy, it represents the degree to which another person cares about the others needs. Where we appear aloof and detached from the situation and our team mates, we find a lack of openness and trust.
- Self-orientation detracts from trust because we’re more cautious about people who put themselves first. We fear they may not be committed to shared goals and may sabotage our efforts in favor of their hidden agenda.
Remember these, when you're introduced to a new team. Take care to build credibility by relating your experience with other teams without exaggerating. Make commitments that you can keep and follow up on them. And take time to get to know the team and their goals, explaining that you are there to support them.
We can also help the teams that we coach to improve trust by working on these same aspects. First, let's look at how these factors relate to teamwork.
Factors Blocking Trust
As an agile coach, you already know agile software development is a co-operative game, teamwork is essential. But when thrown together, people often hang back from working closely together as a team; they're reluctant to depend on their team mates and to allow time to share work with others. In this situation, if we try to apply the trust equation, we have low C, R, and I with high S, no trust exists between team mates or managers. People actively minimise interactions preferring to follow the adage "If you want a job doing then do it yourself!"
Watch an team of amateurs playing soccer and you'll see something similar. Players won't pass the ball to those who they don't believe have the skill to handle it. You'll also notice players who hog the ball, retaining possession rather than pass to a team mate who's better placed to score. The team may win a game because of their star player but if he gets injured then the team struggle to play their usual game. What's going on here? Simple, where there are mixed abilities on the team that affects how they collaborate. People also like recognition for their unique skills. The same is true with software teams.
What's going on when people avoid close team work? Well, I'm sure you notice that developers often find it natural to divide up the work to suit each persons skills and then work independently. As we each develop deeper knowledge of our chosen specialist area, we become comfortable with that kind of work and tend to look for more of the same. Why? We like this because we feel safe when we know what we are doing. We also don't have the overhead of explaining what we are doing to anyone else working on the same thing, which feels more efficient. We may even kid ourselves that it would compromise the team's chance of success by allowing team members with less experience to try their hand at something new. And we nicely side-step the risk of exposing our competence at the task in hand to anyone else.
However, there's a downside to specialising in this way. Work does not arrive at an even rate for each skill area and this causes bottlenecks. I'm sure you'll have seen teams where the UI guy is overloaded while the DBA is waiting around for work. The Agile antidote to this situation is the "cross-functional" team. Basically, we have to step outside our comfort zones and expand our skills so we can handle whatever is thrown at our team. Of course, it's unlikely that everyone can become an expert in all the different types of work the team takes on, some specialisation will continue. What's usually required is each team member expands the range of tasks that they can complete proficiently enough to ease skill bottlenecks.
There's a big wrench to let go and pitch into other types of work, to allow team members with less experience to try their hand at something new. People tend to be nervous, as doing so can slow the whole team down while people learn new skills (the team may lose trust from management as their 'R' factor appears to drop). To speed up this learning, everyone must be ready to ask for help. Often, reluctance to admit that we don't have all the answers (as we might lose face) is what blocks this is lack of trust in teams.
In his book "Overcoming The Five Dysfunctions Of A Team" Patrick Lencioni explains that trust is all about vulnerability, 'Team members need to be comfortable being exposed to one another, so that they will be unafraid to honestly say things like “I was wrong,” “I made a mistake,” “I need help,” “I’m not sure,” “you’re better than I am at that,” and “I’m sorry."'
Getting over this may be difficult in low-safety situations, such as where people risk losing their jobs or have individual performance targets rather than shared team goals. One way you can coach teams in this is to be the first to ask the dumb questions. You act as a role model, demonstrating that it is safe to expose your ignorance in order to learn better. You can also support the team's learning by organising study sessions, such as Coding Dojos.
Techniques for Building Trust
So, as agile coaches, what other techniques can we use to build trust on software development teams? Do physical exercises where we practice falling backwards into the arm's of the team or put on a blindfold help? Can we really develop trust though exercises of forced reliance where we let go and trust the team will take care that we don't get hurt? I don't know but Lencioni suggests that the answer lies in taking time to get to know each other better (improving the 'I' factor in the Trust Equation). This can be accelerated by exercises, such as sharing personal histories and comparing personality profiles (like MBTI, Belbin, etc). You can also work on this by creating more opportunities for team members to get to know each other more naturally through regular social time, such as team lunch on Wednesdays.
We can also work on the 'R' factor from the Trust Equation. Early steps in building a relationship of trust with new suppliers is drawing up contracts to make explicit the responsibilities of each party. You can try the same approach on software teams. Facilitate the creation of team working agreements or a team charter to make team norms and values explicit. If you create team working agreements in a workshop near the start of the project take time to document them somewhere (on a wiki page or flipchart in the team workspace) so that the team keeps them in mind. Notice where working agreements are broken and revise them through retrospectives, as the project goes along.
More on Building Trust
Sallyann and I will be running our "Building a Culture of Trust" workshop again at Agile Business Conference in October. We hope to see you there. I'll also be giving a keynote on "Building Trust in Agile Teams" at Agile Cambridge the following week. If you can't come to those events, you can listen to a talk I gave "Improve Collaboration, Build Trust" via video from Skills Matter and look out for my upcoming article on building trust for Cutter Consortium.
I'd say that the factor which is most often underrated is intimacy. We tend to keep it professional and professional only and we lose a chance to build trust relationship within a team. This is a pity since basing on trust you can skip a lot of formal procedures making work efficient, yet still fairly pleasurable for the people.
On the other hand, while I agree that work shouldn't be always done by experts, in some cases I find it hard to have done any job by any member of the team. Sure, we employ collective code ownership to share knowledge about whole code base among developers, but I don't expect they would take product management from me or would become expert system administrators. And that's what cross-functional teams are about too.
We try to help each other whenever we see bottlenecks but on a typical situation I prefer our developers not to start functional testing as that's not very effective way of using their time. Besides, odds are they won't become star testers no matter how hard they try.
But then we come back to trust again. We trust that a tester would do his job perfectly. We trust a developer would fix bugs using he mind and not knees to proposed best solution, etc. If the trust is the problem we start shooting at each other using bug tracker as a gun and wasting time writing lengthy comments just to show we right and the other side is not. Then, it's time to come back to "I" factor.
Posted by: Pawel Brodzinski | 04 August 2010 at 01:55 PM