Trust is the Essence of Agile

A few years ago two colleagues and me were asked to help out in some project that wasn’t doing very well. They told us they needed some experts on software development. Before you can say anything, I also am still shocked they sent me. But seriously, after spending a few months there, my opinion on what they actually needed, were an airtight contract and airtight functional specification. To my surprise, they actually said that they left/wanted holes in the specs so they could argue over details with the customer. Before some might think this was to come to a mutual agreement, I have to make clear that most of the time these were last-minute discussions about who was right about a lot of functionality that was vaguely described. Resulting into a customer most certainly not trusting the company that supplied them with the software they wanted. This had been going for quite some time now, until we were brought in to rescue the project. Of course if they had brought in an army of the best developers, they would not even succeed. What I had come to learn, was that they needed an airtight functional specification, instead of the one with so many holes that all raised questions.[Countries]

You can imagine that I was very surprised to learn that Agile Software Development also drives on open documentation. (Of course this is comparing apples to oranges, but read more on Agile here and here.) But all the openness cannot be without trust! And the relationship between the customer and that employer certainly wasn’t based on trust. Trust is the melted cheese that binds everything and everyone in the project together. And as David Anderson goes says, trust is the grease that takes the friction out of the software engineering economy. An excellent example he uses are the merchants from my own country, the Netherlands, where 200 to 300 years ago the trust among each other brought us great wealth and established the Dutch Guilder as the World’s reserve currency. (And then the European Union came along and brought us the Euro and almost 100% inflation, but that’s a different story.)[Countries]

Also most excellent is what Mary Poppendieck and Tom Poppendieck had to say about trust in their book Lean Software Development.[Countries]

“Conventional wisdom holds that specifying and controlling scope in a contract is necessary to protect an organization from self-serving behavior on the part of the other party. However, the effect of this protection is a sub-optimized value stream… The bottom line? Organizations that use outsourcing as a way to save money will save more money overall if they collaborate with vendors by using some form of optional scope contract.”

 

I’d think that’s very hard to prove, as you can probably only get that proof from real life experience and measuring. Read the book or the chapter about contracts here in pdf, read more here as well. In the example chapter from Lean Software Developement you can read about Toyota and how they’ve gained trust from their suppliers, because they thought (and proved) it is more important to have a strong network of suppliers than short-term benefits that come from taking advantage of a supplier. The article compares Toyota with GM and shows where and why Toyota does much better, because of the trust. They take the parallel to IT Software, fixed-price projects and time-material. An interesting read, also for developers.[Countries]

I think in most projects I’ve been in, there is enough trust among developers. But when it comes to trust between developers and the project manager, that’s on a whole different scale. Developers don’t always trust their project manager to do what’s best for them and/or the project. I think this also has to do with the fact that project managers don’t always tell the whole story. And perhaps that’s also because of a lack of trust. And as Mary and Tom Poppendieck wrote in their book, many people think that these contracts are the substitute for this trust. Conventional wisdom says that all eventualities should be spelled out in a contract, so the parties cannot possibly take advantage of each other. Going from such a point of view, it’s a long way to trust.[Countries]

Of course there’s always some form of trust. Most of the time, I’ve noticed that a lot of our customers trust us to send competent people to help them solve problems. But I don’t meet many customers that trust their supplier enough to trust them into getting Agile, where a lot of specifications -be it contract or functional- are left open. Perhaps you have different experiences?[Countries]