Some of the best agile software teams I ever worked with communicated well, would push hard to meet deadlines, supported each other when struggling with issues, and went above and beyond to maintain quality. But why?

The key element was trustworthiness. In this article, I’ll provide a self­assessment tool that will allow you and your team members to assess and demonstrate trustworthiness over time.

Building Connection Was Not Enough

When first learning agile over 15 years ago, many experts emphasized “values” to strengthen agile teams. Yet, not many approaches were provided to help a team adopt values like courage, communication and respect (especially if this was not part of the organization’s values). I strongly desired these for my teams, but they still seemed out of reach to me as a new agile coach. An even greater challenge: almost all of my teams were distributed.

I looked for what could work. First, I focused on “connection” with my distributed agile teams. I built this connection by improving my facilitation and one-­to-­one coaching skills. I also developed distributed retrospectives that would help teams get to the heart of their connection issues. My teams started to improve and became more effective. But there

A 2013 TED talk by Onora O’Neill helped clarify what I was seeing with my teams. In this 10­minute talk, she challenged current thinking on trust-building in organizations. This matched my struggles in trying to build values on distributed agile teams. She claimed it is better to demonstrate “trustworthiness” over building trust, and this consists of giving evidence of:

  • Competence
  • Honesty
  • Reliability

These were the elements I was seeing in the “connections” within my more successful distributed teams. Specifically, this talk reminded me of past questions and conversations I’ve had with my distributed teams on how to communicate more clearly about their work. These questions can be categorized into competence, honesty and reliability.


Most people assume competency is only about skills, but it is much more than that. Competence on a distributed agile team has specific implications. As a competent team member on a distributed agile team, can I answer “yes” to the following questions:

  • Do I have the skills I need to complete the work?
  • Do I have the information I need to complete the work? Do I have the time to complete the work?
  • Can I easily and quickly connect with people I need to help me complete my work?

Beyond skills, it is critical for distributed team members to have access to information, or to other people who can help them complete their work. If they don’t have access to the right information on how to plan, create and deploy our work product, this can lead to wasteful delays. For software teams, examples of this type of information could include requirements, data sources, logins or current architecture overviews.

Distributed teams have similar challenges in connecting to the right people. We can’t just turn to our nearest co­worker or walk down the hall. We have to be more intentional in building connections with others inside and outside our team. If we don’t have connections to other critical team members that might have information to complete our work, we risk introducing waste and churn into our distributed agile work.

In some instances, the answers to the questions above might be, “No, I don’t have everything I need to complete the work.” In these situations, we can pair with another member on our agile time with the complementary skills and still feel a level of confidence in getting the work done. This is where the next element of our trustworthiness comes in.


Honesty on a distributed agile team can also be checked through several important questions:

  • Will I say when I can or cannot get planned work done?
  • Will I be honest about my competence and what I need to get the work done?
  • Will I provide accurate and useful updates on my work in progress?
  • Will I let others know when I discover additional work and that my original commitments may be at risk?
  • Will I let others know when I need help?

Answering these questions with a “yes” requires developing a level of safety and understanding within the team that can be addressed by understanding cultural differences, work preferences and the team’s work history. I find one-­to­-one coaching and discussing team working agreements can help with understanding cultural and personal biases in answering these questions.

Another element of honesty is making sure you communicate through multiple channels to guarantee your teammates see these critical updates about your work. Most distributed agile teams rely on a task board for these updates, but sometimes more timely updates are needed. When you’re stuck on a problem, why just signal the task is blocked on the task board? Why not ask for ideas in a team chat channel? Perhaps you may be in over your head and asking someone to pair with you on completing the task in chat will get you on a faster path to completing the task.

This kind of honesty does not have to wait for a discussion of impediments in a daily standup. A key concept in agile and lean is that any form of waiting is waste. Why not call attention to the problem right away so the particular task can move forward?

This kind of honesty can be difficult for those new to a successful agile team. Again, one­-to-­one coaching, encouragement and teammates leading by example can help tremendously. An agile coach may even model this behavior for the entire team after a short tutorial on how and why this type of honest communication can benefit the team and the individual.


Finally, reliability can be addressed by answering the following questions:

  • Will I get the work done when I say I will?
  • Will I communicate updates on my progress in a timely and frequent manner? Will I say “no” when I have too much work in progress?
  • Will I provide help when others ask?

For reliability, most people just think about the first question. But just like competence and honesty, there is far more to reliability. The second question, on updating your progress to others, helps support the first question and is sometimes overlooked. The third question, being able to say “no,” needs to be understood by the team as valuable communication and not a shortcoming.

The last question (“Will I provide help when others ask?”) is about reliability as a fellow team member. Can you be there to support your team members? This is not about looking good. It is about making progress on the team’s work and not just your own. As a distributed agile team, there is time to focus on the individual’s work, but being aware of the progress of others and providing help to your team is part of your team work.

The Challenge

Some of you may be thinking you should ask these questions of your teammates immediately. That will likely backfire. If these questions are asked of another team member, they may feel their competence, honesty and reliability is being challenged.

Instead, why not give all team members this article to read and review in private and suggest a retrospective (with some working agreements around safe conversation). Discuss trustworthiness and team members’ abilities to judge trustworthiness in others based on what they’ve learned from answering the questions themselves and hearing the answers of others on the team.

The benefits to demonstrating trustworthiness—team members pushing hard to meet deadlines, supporting each other through struggles and meeting or exceeding quality requirements, to name a few—do not happen overnight.

What have you tried to show trustworthiness on your distributed teams? I welcome hearing what has worked and not worked for you.

A previous version was published on April 28, 2016 by Mark Kilby.