The blogosphere delights me. I think it’s wonderful, the way things can emerge as a result of different perspectives and experience and ideas acting on the same “theme”. Let’s take a simple for-example:
A short while ago I was musing over a classic problem to do with Agile: the traditional human desire for predictability, how that often influences the creation of flawed plans, how it is that the flawed plans then get funded, and the consequent militant standoff between the Plan and reality. I shared my belief that the thing we had to change was the “contract”. I referred to some work done many years ago by Alistair Cockburn, meandered towards some other stuff (on incomplete contracts) done by Erik Brynjolfsson, and suggested that the answer may lie in something we have yet to see work commercially, a software development contract based on option theory.
A reader I’ve never met (and I’ve met a goodly number), Andrew Ochsner, then commented on how he had been looking serendipitously at something similar, and referred me to a paper by Kent Beck on Optional Scope Contracts. [Thank you, Andrew]. Now I’d read the paper before, but with the blogosphere, I don’t have to go through the process of remembering it, trying to find it, checking its relevance and then publishing its availability. There’s a community that does that, focusing on subjects we care about, but, importantly, subjects we do not necessarily have the same opinions about.
I’m still working my way through Kent’s paper, but what intrigues me is the implication of making quality a constant. For quality read customer satisfaction. For contract read covenant. Suddenly I get very very interested.
A note about contract versus covenant. In a contract, at the slightest sign of trouble, you look for “recourse”. A contract tells you how to punish the other person if something goes wrong. In a covenant, at the slightest sign of trouble, you look for “repair”. A covenant tells you that the two of you will work something out, not sue each other.
The relationship between developers and “the business”, in an Agile setting, must be a covenant. Not a contract. And the common theme that binds the two parties together must be customer satisfaction.
More later.