[bibshow]
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:
Honesty/trust seems to be a prerequisite for prosperity.
Img by @EricBeinhocker pic.twitter.com/63fvnBG1tM
thx for reminding @aggielanddnug
— 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
Source: Improve IT on Flickr | CC BY SA 2.0What are these two young men doing? If you don’t even know what they are doing, how can you trust them?
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.
Trust noestimates?
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
No estimates is being proposed by some people such as Neil Killick, Vasco Duarte and Woody Zuill. Bascially, their argument boils down to that noestimates increases client intimacy.
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.
Update
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
@GregerWikstrand some language missing, no action verb @PeterKretzman pic.twitter.com/j14e29Gzmy
— 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
Source: Visualpunch on Flickr | CC BY SA 2.0The Agile Manifesto
Let’s start by looking at the agile manifesto and how each of its tenents score on the trust equation:
- Individuals and interactions over processes and tools. This goes to increasing client intimacy but might have a negative effect on credibility and relaibility.
- Working software over comprehensive documentation. This goes a long way to improving relaibility but also credibility.
- Customer collaboration over contract negotiation. This goes directly to improving client intimacy and will possibly also reduce the impression of self-orientation as in “We’re in this together!”
- Responding to change over following a plan. This might be the real gem from a trust perspective. You would think that presenting a plan would speak strongly for your credibility and then when you deliver according to plan you would prove your reliability. But think a bit more. Change is the only constant. And there goes your predictability and with it your reliability.
Source: Owned by the authorA summary table of trust and the agile manifesto.
Conclusion
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.
References
[/bibshow]
Image sources
- Two young men working in front of the computer: Improve IT on Flickr | CC BY SA 2.0
- The Agile Manifesto: Visualpunch on Flickr | CC BY SA 2.0
- trust agile manifesto: Owned by the author
- A trust game: Gosrkiya on Wikimedia Commons | CC BY SA 3.0
Greger,
I enjoyed the way you put the Trust Equation to use and moved it into development. You created some additional insight for me.
Thanks for the mention.
When you use “deliver on time” as part of the reliability, all schedules for delivery require “margin,” since the irreducible uncertainty of all work is always in place – aleatory uncertainty. As well reducible uncertainty – epistemic – is also there and requires spending money to address it.
Both the irreducible uncertainty and its margin, and the reducible uncertainty and its “buy down” cost require estimates.
When there are no estimates, these two uncertainties are not “handled” and the reliability of the trust equation no longer exists.
Credibility is then eroded since the known and knowable uncertainties are not being addressed.
Of the myriad of reasons #NoEstimates make little sense on any project of substantial cost, effort, and value – these are two more reasons. Which me back to
http://herdingcats.typepad.com/my_weblog/2014/10/should-i-be-estimating-my-work.html
Without recognition of the decision making of when “not estimating” is appropriate, there can be no real conversation about it’s applicability.
The word impossible is not actually what I used. With knowing something about the future performance of the projects variables the confidence in any decisions made about the project have no basis for that confidence.
Pingback: Should you distrust agile? - Greger Wikstrand
I think #NoEstimates is a relatively new idea. Those that don’t understand it are naturally fearful and skeptical. I’m sure early Neanderthals were wary as the mastery of fire was introduced.
Margin is just another word for padding, a way to accommodate inaccurate estimates. This is part of what No Estimates addresses.
I believe the first clause of the Manifesto covers credibility, reliability, intimacy, and self orientation to some degree, not just intimacy. By putting individuals first, all four areas see a trust benefit.
There needs to be some clarity of the words used by Aaron
Margin is protection for irreducible (aleatory uncertainty) http://goo.gl/3gUEC6 It is not padding. The estimate to complete or the estimate for a cost is derived from a probabilistic model, a parametric model, or a monte carlo model. This margin results from this modeling processes. The estimates in the models are not inaccurate, they are probabilistic – and require assessment of the needed (or acceptable) levels of confidence.
I’d suggest Aaron read http://goo.gl/tA0pjF and http://goo.gl/E88H5 for further backgrund on the creration and use of margin.
In any nontrivial work effort, trust comes from “saying what you’re going to do and doing what you said.” But first come “saying what you’re going to do.”
Putting individual first in the absence of contractual deliverables on non-trivial projects appears to be a lack of understanding of the core tenant of business – the exchange of money for value. It’s crticital that people be able to continue to the success of the projects in ways meanigful to them. While at the same time it is critical that those paying for this contribution get what rthey are paying for. Any disconnects between those two needs are resolved by a Statement of Work, Concept of Operation, Requirements and other vehicles describing what “done” looks like
Statements like “Those that don’t understand it are naturally fearful and skeptical. I’m sure early Neanderthals were wary as the mastery of fire was introduced” – fail to recognize – possibly with willful ignorance – the microeconomics of decision making require estimating to impact of the decision or the opportunity cost of choosing one outcome over the other.
To suggest that business decision can be made – again on non-trivial projects – in the absence of assessing probabilistic outcomes driven by probabilistic uncertainty would seem to demonstrate lack of understanding of basic business probability and statistics for managerial finance.
Greger,
The chart from World Bank is interesting. Our daughter is a teacher and graduate student in education. When some asks why can’t the US have an education system like Norway or Sweden, her answer is based on the homogeneity and uniformity of the culture and economics.
Trust in the US usually starts – in business – with a contract. The notion of individual and collaboration OVER contracts ignoire the cultural aspects of enterprise in the US. That naive notion seems to extend to some of the ideas of trust in the post as well.
In the US trusted suppliers are those that show up on time, provide products and services at the agreed prices, and those products and services fulfill the stated need of those paying – and likely “over perform” to those needs.
Discussion based on the Agile Manifesto without consideration of the 12 Agile Principles tend to be “naive” at best of the actual business environment in which SW Development takes place.
So when we hear “trust” in the absence of a domain, consider those as personal opinion, uninformed by actual business processes build on the governance of spending other peoples money.
What you state about “In the US […]” is not really different anywhere else and I think both Scrum and the trust equation captures that.
Why didn’t I cover the agile principles as well in the discussion? The point of the examples is to apply the trust equation to a few well known examples, not to do a thorough discussion of trust as it applies to software business.