It was one of those discussions that start as something else. We were not more than a couple of weeks into our initial rollout of a new web app to the company’s sales team. “They’re sales people”, said our Customer Proxy, “if they don’t trust the numbers from the system, they won’t use it”. This was a problem for us, because rapid adoption is essential to our process: without it we can’t get the feedback we need to develop the right thing.
So the discussion turned to what we could do to get the users to trust the software, and from there drifted into the question of what it means to trust a computer system. This piqued my interest, as I was aware of the importance of trust within a team, and between a team and its customer, but had never thought about the idea of trust in the product itself.
Thinking that the collective wisdom of the Agile community might be able to shed some light on this idea, I started with a quick web search, and found Rachel Davies’s excellent post on Building Trust on Agile Teams.
Rachel’s post reminded me of something I hadn’t thought about since Uni, The Trust Equation, as described by David Maister, Charles Green and Robert Galford, in their famous book The Trusted Advisor.
The Trust Equation
The Trust Equation tells us that the factors involved in Trustworthiness are Credibility, Reliability, Intimacy and Self-orientation.
Now this certainly seemed relevant to my interests. It’s easy to think of the credibility of a software system, and we talk all the time about how reliable a system is, but then we dip into less clear-cut territory. While there might be occasions when people feel intimacy for a computer system, it didn’t seem tremendously work-related. And I’m quite happy that our product doesn’t have a sense of self-orientation yet, because I’m not quite ready for that level of responsibility (Just ask my husband, there’s a reason that this book has sat unopened on our coffee table for over a year).
So, if the trust equation doesn’t help me to understand how our users will come to trust our system, is it any use to me? Well, here’s where it gets interesting. We’re a full Extreme Programming (XP) team, with on-site customers, and XP tells us that if our customers trust our process, and engage in it, this will allow us to produce higher-quality software. So perhaps in XP, we have to see trust in the process, and trust in the product as being tightly coupled.
How do we get our users to trust the process? I got to thinking that maybe the trust equation could help me here, and decided to look at each of the components in turn.
Credibility means the quality of being believable: worthy of trust. For our salespeople to trust the numbers coming from our system, the numbers had to be credible. For our customers to trust our process, and us as a development team, they have to be able to believe that we are a team capable of delivering what they need.
The surest way that we’ve found to help our customers believe that we are capable has been to open up our process to them. By enabling them to see the ways that we work, they can better understand the logic behind the things that we do. Involving the customer in the process is of course a key tenet of XP.
In XP, we make a real effort to break work down into manageable, achievable chunks, and define clear success criteria for each. When we let the customer see this process, they come to associate our team with an ongoing chain of successful deliveries, rather than seeing us as working on huge project with a delivery date far in the future.
How did we tackle the problem of getting salespeople to trust the numbers from the system? Well, we showed our work! The system does a number of calculations, and we decided to display more of the values from intermediate steps, so that salespeople could check our working.
The common element here is openness: both openness in the process by showing the customer how we work, as well as openness in the software by exposing information to help build trust. I also think that it shows us that the value in stories may not always be pure monetary value, but that some stories may be valuable because they help to build trust in the process, or trust in the product.
Reliability in a software system is easy to define - a reliable system produces consistent results, and is not prone to failure. It doesn’t crash all the time!
The safety-first approach of XP makes this much easier to achieve. By focusing on eliminating all known defects before proceeding with new functionality, we have found that we’ve dramatically improved the reliability of our software.
The perception of reliability is significantly helped by close communication with the customers, and keeping the feedback cycle short. This gives them the confidence that when they do find a problem, it will be fixed quickly.
For the team, reliability means the customers need to trust that we will consistently deliver what we promise to. This means that it is extremely important to be seen to be delivering in a timely fashion, in line with our estimates. XP helps us again here, as using velocity means we can be very confident that our estimates will be accurate in the short term. Customers come to realise that when we tell them a feature will be delivered in the next sprint, they can rely on it being delivered.
As a side note, one of the important things I’ve noticed is that this effect will be maximised if the Agile process is seen as the way to get things done. This means that there have to be no ways to “cheat” and win by going around the process. One of the ways we helped to stop people going around the process was to remove the phones from the developers' desks. If I had to pick the single change that has made the biggest impact on my daily life, that would be it!
Intimacy might seem like a strange concept to be talking about in this context, but it means the degree to which the customer feels secure in sharing with us. An important factor in this is the customer’s belief that we understand and care about their needs and requirements.
Our planning process helps us a great deal to build this intimacy. Customers take an active role in building the stories, defining the goals and acceptance criteria, and prioritising the work. This allows them to feel, correctly, that they are an important part of what guides the project.
Another way that we’ve attempted to build common understanding is by developers shadowing salespeople on an ordinary working day. The developer sits next to salesperson, observes their work, interacts, and asks questions. This is in addition to the regular cycle of demos and planning, and it has proved to be well worth the time spent. By doing this, we have not only gained the confidence of the customers, but we’ve also had several valuable “Aha!” moments, which wouldn’t otherwise have happened.
I think this shows us how important it is to involve developers closely in customer communication, rather than delegating this task solely to a product owner or customer proxy.
Self-Orientation is the only one of the components of the equation that we aim to minimise, rather than maximise. If customers perceive us as seeking our own goals, rather than having common goals with them, this will diminish trust.
A very useful tool in our Agile toolkit is the prioritised backlog. In this, we attempt to prioritise higher the work which will deliver the most value. When we involve our customers in the prioritisation process, we help to build trust that we share common goals. Of course, when we have many stakeholders, managing the conflicting priorities can be a challenge, which is why it’s vital that the process be transparent. It’s much better that a customer understands why their requirement isn’t a high priority, rather than thinking “The developers never give me what I want”.
Something that has hindered us in the past is that some of our customers were disengaged from the development process because they felt that their needs were always a low priority. To tackle this, one thing we’ve tried is for developers to have informal chats with various customers, outside of the regular prioritisation process. This is something that our CTO likes to do quite often. He finds that having an overview of the ideas that our customers have can often give us an opportunity to find the “quick wins” that will enable us to deliver value without a lot of development work.
The thing to remember here, is that it’s not always clear to users what is easy to implement, and what is hard. They often won’t suggest features that would be useful because they think they will be too difficult. By regularly talking to them and trying to spot these hidden ideas, we gain a lot of insight for very little effort.
When these ideas are identified, it can be worth doing some development work to explore them. We try to set aside some time in each sprint for these spikes. Development work on a spike is time-boxed, and doesn’t have to be done by Test-driven or Behaviour-driven development (TDD or BDD). The output of a spike might be nothing, or might be new stories which can be better prioritised given our better understanding of the problem. Sometimes a spike will be done using TDD, and the output will be a new feature in trunk or a standalone piece of software.
Trust Me, I’m Agile
What did I discover in my little foray into the world of trust? I discovered that trust between customers and the development team is critical for XP to work. I also found that XP gives us many tools that help us to increase this level of trust.
We can build our Credibility by making our process as open and transparent as possible, and helping our customers to understand what we do. The Reliability of both our software, and our team, is improved by XP’s safety-first approach. By building a common understanding with our customers, via techniques like work shadowing by developers, we can improve Intimacy. Lastly, we can reduce the trust-diminishing effects of Self-Orientation by communicating well with our customers to help them understand the common goals that we share.