When Trust Goes AWOL

Some time ago, I had to take an early morning flight to get to a meeting in a distant city. It was an important meeting for me professionally, and I needed to get a good night's sleep beforehand.

I went to bed earlier than normal, and I even managed to doze off earlier. Yet, despite my early bed time, I slept poorly and only managed about three hours of sleep that night. Why? Because I was using a new alarm clock and I didn't trust it.

Since I wanted to minimize as much as possible any interruption to my wife, I used the alarm clock on my mobile phone rather than our noisier main alarm. It also meant that I didn't have to fiddle around in the middle of the night to reset the main alarm for my wife. Since this was a new mobile phone and I had no track record with it, I didn't trust that it was set correctly or that it would go off on schedule.

Instead of having a restful night's sleep, I found myself waking every twenty minutes or so just to check that it wasn't yet after 4:45 a.m. and that the alarm clock hadn't failed me. I literally lost sleep due to a lack of trust.

Ironically, the intention of the meeting I was flying to was to rebuild trust between my client and one of their key customers. My client had made a significant sale to their customer a few years earlier but had made a mess of their implementation. Their software could be described fairly as "bug ridden," both parties' budgets had been blown due to the rework required, and the product was late. From rosy beginnings, the relationship between the two companies had become hostile. Our discussions started with a very low level of mutual trust.

I was at the meeting partly as a "hired gun" and partly as an "expert witness." My client recently had adopted an agile approach internally and was convinced that if they used just a few of the agile techniques with their external customers then they could recover much of the trust they had lost in earlier projects. They recognized that they could share the benefits of their improved quality, productivity, and predictability with their customers, if only they could convince them to work collaboratively throughout the duration of the project-something which they expected their customers to resist. I was there to explain how and why agile works and to sell the approach by explaining how the considerable benefits could only be achieved at a small cost to the customer.

The meeting started with a friendly tone. Participants from both sides of the table were fully aware that their futures were bound together, even though their mutual past had often been unpleasant. We presented a quick overview of the agile approach, explaining how by working together collaboratively my client could deliver working software each month for six months. We explained how we would collaboratively define the success criteria for each iteration and how we could automate many of these criteria as tests. We explained how they didn't have to get everything right up front-that they could change their mind as they learned. But they had to be careful with how they prioritized their work because once the budget ran out that was it. We explained not only how each iteration would be extensively tested as part of our development process, but that they could start their own acceptance testing at the end of month one, rather than at the end of month six (assuming