Too much counting, not enough trust

The title and inspiration of this blog comes from Chapter 4 of John Bogle’s book “Enough: True Measures of Money, Business and Life”. Bogle asserts here that in the world of business and finance “Statistics – in charts, graphs and tables – can be used to prove almost anything, but unquantifiable values have a way of holding steady as a rock”.

The bottom line for Bogle is that we can’t count and prove absolutely everything, so ultimately we always have to rely on trust to some degree. And it is better to trust in values like integrity than what are sometimes characterised as “lies, damn lies and statistics”.

At first the call to rely on trust rather than measures sounds somewhat alarming. But in IT, as in any other form of business, we do ultimately have to face the fact that in the end we have no other choice. No matter how many plans have been drawn up, there is only one way in which value is ever going to be delivered, and that is by “the team”. In this sense we have no choice but to trust the team to deliver. The principle underlying the Agile Manifesto that we should: “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.” has fundamentally got to be right.

But we do need to be careful how we communicate these facts of life. A demand to simply “trust the team” is somewhat prone to being interpreted with alarm and mistrust in some management and customer circles, who understandably interpret it in the light of past experience, often bad old IT practice which repeatedly played the mantra “IT is different. Trust us. Send more money!”

Trust Me, I'm Lying

There is clearly a difference between building mutual trust and unilateral demands for “blind faith”. The key missing ingredients in the latter, which agile rightly insists on also being present, are collaboration, communication and frequent delivery of value through working software. In any calls for trust we forget these additional ingredients at our peril.

So there is a very real sense in which we should not be asking the customer to simply “trust the team”, but rather to “work with the team in a spirit of mutual respect and trust”. Active engagement and collaboration needs to be further supplemented with “openness and visibility in all things”.  The team’s artefacts are clearly visible to anyone and everyone as “information radiators” that anyone can see at any time. And in Scrum, for example, anyone can come along and listen in to the teams daily stand-up meetings, and the team should aim to invite the world and his wife to see the product demonstrations of the working software that results from each and every Sprint.

Of course, again, it is all a question of balance – as Bogle puts it “No business can trust everything and count nothing. Nor can any business count everything and trust nothing”.

So the other key to success becomes finding the few good simple measures that enable us to count the things that really matter.

The things that really matter are outcomes. So, assuming the required outcome is frequent deliver of valuable, working software, that is fit for purpose and acceptable to the customer, these key measures are clearly based on how much production quality software has been produced and accepted and what value is represented by this. Hence key measures such as a requirements progress chart, also known as Release Burndown or Burnup, depending upon your terminology and presentation preferences.

But even these few very relatively hard and objective measures require human integrity in the compilation and human judgement in the interpretation. I have been involved in very successful projects that would have been cancelled if the velocity of the first 2 or 3 sprints had simply been projected outwards – no way would a viable product be produced in time. But human reason suggested continuing and was right, given for example the firm architectural foundation that had been built and tested and the amount of effort that had been put into establishing the test framework.

So, in summary, we must, should and do value professional judgement and integrity over mechanistic counting. We can’t measure everything and trust nothing, but we can and should measure the things that really count. In the end the answer is not “you must trust us”, but to dissolve the “you” and “us” into a single collaborative partnership built on mutual respect and trust.

Related content