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]

You may also like...

10 Responses

  1. Marco says:

    I trust you Dennis! (except in BF2 when you are on the other team;-))

  2. Even then, you can trust I’ll blown you from the face of the … map… 🙂

  3. Rutger says:

    To keep it simple: GOED VERHAAL!

  4. Ramon Smits says:

    Vertrouwen is helaas vaak weinig te vinden en contracten worden vaak ook op basis van de knikkers opgesteld zodat beide partijen het zo min mogelijk euries gaat kosten.

    Maar vertrouwen moet je ook winnen. Begin klein en in een stevig fundament c.q. kader en zorg dat dit kleine brokje gewoon slaagd! Niemand investeerd ergens miljoenen in om het vervolgens niet in de gaten houden als je niet weet of je die partij kan vertrouwen.

    Maar wederom een sterke post Dennis.. straks ga ik je dev blog nog elke dag raadplegen 😉

  5. There _are_ RSS Aggregators/Readers, Ramon.

    You could subscribe to the RSS Feed here! 🙂

  6. Ramon Smits says:

    Yes I could.. but unfortunately not at the project that I am currently at 🙂

    Those webbased readers just suck…

  7. John Rusk says:

    Hi Dennis,

    It’s great to see another blogger talking about this stuff. I think it’s importance has been underestimated for a long time.

    Interesting point about trust between developers and project managers.

    One of my current projects is an interesting blend of formality and trust – perhaps I should blog about it sometime. It does have deliberately open specs. It’s the trust (and not the formality) that keeps the project working.

  8. You definitly should! I’m very, very interested in real life experiences of people that know what they’re talking about.

    It’s a little bit like the SOA hype that so very many dutch bloggers are writing about, now that TechEd is running. It still seems like a lot of theory there, but so little implementation discussions.

    As with Agile software development, although I believe the theoratical examples are better and easier to understand. That’s possibly because of the long time (several decades) Agile is being used now, and because everyone knows the domain people are talking about. Everyone has done projects and know where lots of them fail. SOA is another discussion, because it’s a whole new way of thinking, although a lot of the implementation stays the same. And people want to know where the differences are.

    That’s the same with me and Agile. I want to know what the differences are between (for example) RUP and Agile, and where Agile is best used. After that, it’s just doing my best to convince people to do projects the Agile way. Which will be very hard when RUP is currently almost the holy grale for projects at my company.

  9. John Rusk says:

    Have you read Alistair Cockburn’s "Crystal Clear" book? If not, I’d recommend it. I think you’d like it because his whole approach to agile development is based on studying real-world projects. The book includes examples from real projects, and even has a whole chapter devoted to a case study of his methodology in action.

    You can find a page about the book on my web site.

  10. I’ll try to give it a shot. Got a lot on my hands currently, .NET 2.0, VSTS, Agile and also BattleField 2! 😉

    But I’ll have a look, thanks for the suggestion.

Click on a tab to select how you'd like to leave your comment

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.