 |
Software Testing & QA Online Community > Detail: When Trust Goes AWOL
| A StickyMinds.com Original |
|  | |
When Trust Goes AWOL
By Clarke Ching
   
Summary: Trust is invisible, but the symptoms of its absence are not. That is the theme of this week's column, in which Clarke Ching recounts the difficulty one of his clients went through to rebuild trust with a customer. The customer had long ago lost faith in the quality of the products provided by this client since every piece of software delivered seemed buggy. But both were determined to make the relationship work. That's when Clarke Ching stepped in and took an agile approach to relationship therapy. | | |
|
|
 |
 Hear more about this topic in the StickyMinds SoundByte podcast interview with Clarke Ching.
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 we delivered on time). We also hoped that at the end of month six they would be in a position of "proving" the software works rather than trying to prove that it doesn't.
It was an offer we thought too good to refuse, and the new approach seemed to appeal to them—in principle. One of the biggest problems with the relationship was that my client had released product upgrades before all of the bugs were ironed out. Accordingly, the customer, which ran billions of dollars worth of financial transactions on the system, spent a small fortune and many months on acceptance testing each software upgrade before trusting it enough to be used. The saddest thing was that the situation turned nice people, with a mutual objective, into enemies. Each release had an unpleasant "them and us" feel about it, with each side focusing less on the mutual goal of delivering high-quality software, and more on shielding themselves from blame and proving the other side was wrong. The senior stakeholders on both sides lost a lot of sleep as the relationship continued to sour.
I'd like to report that we saw an instant transformation in the relationship—that our sturdy logic pushed the trust lever up to full strength—but it didn't. At best we saw a slight thaw, but we still had several years of broken promises behind us. All they had was yet another promise that things would get much better, much like the promises they had heard before from my client.
The thaw sped up a little once we stopped explaining ourselves and started listening to their questions and concerns. How would things work in practice? How would they know that we were keeping our promises? How would they know that the quality was as good as we said? Could they see the tests? Could they really start testing so soon? What if there were problems?
As a result of these questions we promised to give detailed, written reports daily and to have daily progress teleconferences. Although we were happy to give report daily, we would have preferred less detail. We also would have preferred to have several daily conversations rather than one formal teleconference. But both of these requests stemmed from starting with low levels of trust and also from having to rebuild trust.
Perhaps the best thing we did that day in terms of building trust was to insist that we got similar commitments from our customers regarding the levels of collaboration we needed from them in order to deliver to schedule. It was clear to both parties that we shared a mutual purpose—to deliver the project—and that the most cost-effective way of doing this was by working together. We also made it absolutely clear that without continuous collaboration we would have to re-plan the project and extend its schedule by several weeks by adding a "rework" phase at the end of the project. Most important was that working collaboratively would mean that we got to know each other better.
The best way to build—or rebuild—trust is to act in a trustworthy way. I only needed to see my mobile’s alarm clock work properly once before I trusted it and thereafter I slept soundly, but it takes longer to build trust in people. Trust grew on my project as soon as our customers saw the automated acceptance-level tests, which we had created together as a team, running. They got as much of a thrill when they saw the pages of green tests as we did.
Trust grew more when we shipped working software—software that came complete with the output from running several hundreds automated acceptance-level tests. As trust grew, the strict management reporting and formal meetings became more pragmatic and less time consuming. But, most importantly, by working collaboratively we learned each other's concerns and worries, and we started to care for each other rather than framing our thoughts in terms of "them and us." Above all else, with the stress levels reduced, we all slept more soundly.
About the Author
Clarke Ching is a New Zealander living in Scotland. In addition to being an independent consultant and a regular columnist on StickyMinds.com, he's a passionate advocate of agile software development and a chairman of the AgileScotland special interest group, which meets monthly in Edinburgh. Clarke currently is writing a book titled Rolling Rocks Downhill, in which he explains why working with software projects often feel like pushing rocks uphill. He also demonstrates how to use lean, quality, and agile techniques to make your projects progress easier and be more productive and predictable. Read more about his book and other articles and listen to his podcasts at www.clarkeching.com.
Back to Top
StickyMinds.com Weekly Column From 7/16/2007
|
