As a consultant [bibcite key=”citeulike:13415391″] and as an agilist [bibcite key=”citeulike:9846510″] I have a vested interest in trust. Trust might be seen as one of the top two factors for success in software development projects [bibcite key=”citeulike:2824986″]. Most of us have a vague idea of what is needed to create trust. Charles H Green of The Trusted Advisor has come up with “the trust equation“. I first learned about the trust equation in one of Joe Dager‘s excellent podcasts.
But trust has always been an important topic for me. This tweet is a good example:
— Greger Wikstrand PhD (@GregerWikstrand) 14 november 2014
The trust equation
The trust equation states that:
For a full explanation, you should probably read “The trust equation, a primer” but here is my brief summary:
- Credibility = This your expertise, your diplomas and your experience. There is a limit to how high you can score on this in the eyes of your client. There are not really any expertier experts than an expert.
- Reliability = This is your consistency. Do you keep promises? Do you deliver on time?
- Intimacy = How low are the barriers that the client perceives towards us? Are we approachable, emphatic, interested?
- Self-orientation = Is this about us or about the client?
Another way to put this is that the client will trust us if we are able to do it, likely to do it, benevolent as in acting in the interest of our client and not for our own benefit.
Trust in software development
Software development has trust issues. If we are talking about large scale software development we know that: (these references are only examples and do not constitute a full literature review)
- It is highly complex, especially when off-shoring is involved [bibcite key=”citeulike:13415423″].
- It requires a high level of expertise, but that is seldom lacking [bibcite key=”citeulike:13415426″].
- It requires extensive coordination, especially with large teams or offshoring [bibcite key=”citeulike:4386425″].
- It is likely to not fully meet expectations with an emphasis on project related expectations [bibcite key=”citeulike:9679100″].
- Even in the best products, there will still be problems [bibcite key=”citeulike:13415429″].
Agile and the trust equation
So how does trust come in to play in agile software development? Trust is what allows us to move from an adversearial relationship [bibcite key=”citeulike:13415437″] based on control and contracts to a more open and productive relationship [bibcite key=”citeulike:13415442″].
An important element of trust is reliablity. That includes keeping your promises and delivering what you committed to on the day you committed to deliver. Some large corporations use this as their sole metric on the software teams. Delivering on commitments and even making clear commitments falls on the team as a whole as well as on individual contributors [bibcite key=”citeulike:9338285″]. But some of the basic mechanisms of reliability are expressed in having sprints of a fixed length. If you deliver something, every two (or three) weeks, you’re pretty reliable.
Intimacy in agile software development is expressed not least in the way we focus on customer priorities and nothing else but also through frequent demos. Working together with the customer (or the so called business) in joint teams might be the ultimate in intimacy.
The ongoing noestimates debate is an interesting example of different viewpoints on how to maximize client trust. Naturally, you cannot say that noestimates is only a discussion about trust. The issue is more nuanced than that, but trust is an interesting way to examine this issue.
Noestimates advocacy and trust
Noestimates skeptics on trust
Noestimates skeptics, such as Glen B Alleman, on the other hand argue that noestimates will make delivery commitments and predictions impossible and thus have an adverse impact on reliability. While other noestimates skeptics argue that noestimates does indeed reduce client intimacy:
Those reasons for rejection boiled down to:
- estimates are flat-out natural, ubiquitous, and unavoidable in practical life and in business;
- expressing general reluctance to do them unfortunately reinforces the often negative perception of IT people as aloof, uncooperative, and unsavvy about business imperatives.
The above section was updated 2014-11-03 based on feedback I received on Twitter, including the following tweets:
@GregerWikstrand It's difficult, if not impossible, to trust people who actively push anything which runs so counter to business needs.
— Peter Kretzman (@PeterKretzman) 3 november 2014
— Glen B. Alleman (@galleman) 3 november 2014
So is that how we should judge agile practices, on how they affect our customer relationship and trust? If one practice tends to increase trust, can we then introduce another practice that reduces trust as long as the result is the same? At least for software development effort estimation there is some data that shows that trust can improve estimation accuracy [bibcite key=”citeulike:13415952″].
The Agile Manifesto and Trust
In this post I have introduced the trust equation. I have shown why trust is important in Agile Software Development. I have shown that trust and the trust equation are useful tools for better understanding the agile manifesto and specific agile practices.