Five Ways To Build Team Trust

Posted by Mike Bria on Apr 15, 2009

Sections

Process & Practices

Topics

Collaboration ,

Agile

Tags

Agile Manifesto

Many people have noted that the presence of trust in your agile team is a fundamental component in successfully implementing the Agile Manifesto value of "Individuals & Interactions". Esther Derby offers five concrete suggestions to help build this trust.

The first and often most cited item of the Agile Manifesto stresses that we value "Individuals & Interactions" (over "processes & tools") as a foundation to our development process. Taking this further, any agile methodology specifies that creating a tight, collaborative team is a primary linchpin to implementing this value. Going even further yet, many will agree that the success of such a team begins with the true presence of trust between the members.

But, in a professional environment, what does it really look like when this trust is present? How does a team actually build it?

Esther Derby recently offered a few answers to these questions. For the first one, she says this:

What we need in the workplace is professional trust. Professional trust says, I trust that you are competent to do the work, that you'll share relevant information, and that you have good intentions towards the team. Taken broadly, that's trust about communication, commitment, and competence.

Esther then goes on to present five concrete suggestions people can act on to help trust form within their team.

1. Address Issues Directly.
   Working closely together as a agile good team will, personal differences are inevitable to crop up. Building trust depends on team members having the courage to speak directly to the person "bugging them", rather than going through a manager to communicate these concerns or even not raising them at all. As Esther says:

   When people don't know how to have difficult conversations...or think it's not their job to navigate working relationship, trust erodes. And that's why people need a framework to talk about interpersonal feedback.

   Ola Ellnestam recently posted a good report on experiences applying such a "feedback framework" learned from a workshop with Esther and Diana Larsen.


2. Share Relevant Information.
   In other words, have the courage to speak your mind. If you don't agree, say so. Of course, doing so in a constructive way is important to doing this effectively, so find out how to do this well, but either way do it. As Esther concludes:

   When someone on the team withholds and opinion or concern when a topic is under discussion and then comes back later to say "I thought it was a bad idea from the start," other team members feel blindsided. That breaks trust.



3. Follow Through on Commitments or Give Early Notice When You Can't.
   Quite simply, do your best to be transparent and proactive when things aren't going as planned for you. That said, in order to reduce the frequency of such occurrences, see #4.


4. Say No When You Mean No.
   Get over the not-uncommon anti-pattern of thinking you have to say "yes" to every request in order to look like a "team player". Esther advises:

   Saying Yes without follow-through leads others to doubt your word. If you can't say No, your Yes won't mean anything.
   
   It may seem paradoxical, but building competence trust sometimes means admitting that you don't have all the answers.



5. Show What You Know and What You Don't Know.
   In a nutshell, be generous with the information you do possess, but also be aware and open about the things that you do not know.

Trust is something commonly talked about, but not so commonly effectively built. Take a moment to read Esther's full article to get a more complete sense of the good suggestions she has.

1. Back to top

   Doing a Feedback Workshop

   by Anand Vishwanath

   As rightly pointed out in this article, feedback is the key to building trust within the team. Inculcating this feedback culture within the team is a challenge in itself.
   
   Here is a take on it from a Feedback Workshop point of view, if anyone wants to try
   
   blog.anandvishwanath.in/2008/11/feedback-worksh...

   Reply

2. Back to top

   The "Life cycle" is not fully convered.

   by Liu Xia

   OK, I should appologize that this might have nothing to do with this article. However, don't you think the donzens of "Agile" article is focused on how to "DEVELOP" rather than how to deal with the product we produced with "Agile" method in maintaining cycle.
   The "DEVELOPMENT" cycle cannot resolve all the problems and I still doubt that the storyboard can provide enough information while code can analysed quickly, if we encountered a problem. You know, the team is changing all the time while the maintaining cycle will last for a long time (great cost).
   
   P.S. (I am not expert:-), Just curious~~)

   Reply

• Older >