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.
That is interesting.
There is a simple covenant that is very effective in our delivery world. It is about aligning the bonus payment of the IT and business lead to a common goal of successful delivery of the project. When a common goal is shared, and it is strong enough (100% of bonus), it is amazing to see how solutions to obstacles are found, compromises are made, meaningless statusing falls by the wayside, etc. etc.
The unfortunate situation about compensation and bonus structures is that in most large organizations, not enough is variable vs. fixed. It’s usually not specific enough to an individual’s tasks but rather to the shared corporate objectives and values (I have never figured this out .. why must 100,000 employees all behave like lemmings towards a single goal). Why can’t bonus structures be purely task or individual project focussed ?
OK, now you’re really scaring me!
http://tinyurl.com/2q5omp
I was interested in Kent’s concept of very short-term contracts, but wondered how realistic that was and whether rolling contracts with frequent non-adversarial reviews would be more feasible.
As to MG’s point about corporate/individual goals, there was an article in a recent Harvard Business Review that suggested that overall strategy was often way-laid by the resource allocation implications of innumerable smaller decisions.
Trust is an important enabler of covenants. Without it you are stuck with contracts.
Hello JP,
It has been a real pleasure perusing your blog.
Seeing the various references made to Agile contracts on your blog – does it mean BT is open to negotiating an Agile contract with a prospective vendor? – I understand that perhaps differents parts of the organization may have different policies – but I thought I would ask?
I am also wondering if the fact that a company uses ‘Agile’ could be a differentiator during a bidding process.
Thanks.
Imran