Where Agile meets Planning

One has to be careful with the word “agile”. If you were an accountant, how would you feel if someone described you as agile? Other than in the pure physical sense, I guess.

I digress.

I’ve experienced a lot of pushback whenever I’ve seen agile techniques being used, perhaps even more pushback than I’ve seen for social software as a whole. When I’ve tried to analyse the sources of the pushback, the Conscientious Objectors can be classified as follows:

• The In-Concrete Setter: I need robust reliable plans, not all this mumbo-jumbo. I’ll give you use-case.
• The Futurologist: I have a long-term business to run, with long-term plans. You’re just not helping me. Get real.
• The Educated Dinosaur: Just tell me what I am going to get, when and for how much. Is that too much to ask?
• The Legless Ostrich:  You’ve known about this for at least a year now, how can you say this is new?
• The Mad-Hatter-In-Reverse: (A close relative of the In-Concrete Setter) You’re late, you’re late, for a very important date [with apologies to Lewis Carroll and, if memory serves me right, Danny Kaye]

Much of Agile is about the most effective way of discovering amorphous requirements. Agile does this in many ways: use of user stories, fast iteration models, pair programming, collocation in general, better in-team communications, more bite-sized chunks of work, test-driven design, natural selection, whatever.

All these techniques are designed to make the software meet the user’s expectations in terms of function and look and feel and even performance.

Where Agile is sometimes oversold is in the context of estimation. To me, software estimation is a bit like growing ear hair. It takes time to do it well. There aren’t that many short cuts.

And when you look at the conscientious objector list above, you will find that most of them have the core of their objection rooted in the lack of predictability of planning. For some reason they seem to forget that they never had real predictability with the waterfall model, especially not when requirements were amorphous or tacit.

I’ve been wondering about how to fix this for a while, and many years ago this drove me down an odd road, looking at Erik Brynjolfsson’s work on Incomplete Contracts. I kept on feeling that until and unless we managed to capture the value of Agile (although it wasn’t called that then, we just used terms like Fast Iteration) in a comprehensible contract, we would always face an uphill task.

So it looked like we would be stuck with Predictably Wrong rather than Provisionally Right.

Which is why I found this piece on Agile Contracts by Alistair Cockburn a timely reminder to delve deeper into the Agile contracting process. Alistair lists 10 contract types:

• Fixed-price fixed-scope (and possibly fixed-time)
• Fixed-price fixed-scope (and possibly fixed-time) but collaborate with the customer to alter scope anyway
• Time and materials
• Not-to-exceed with fixed fee
• Fixed price per story point
• Bob Martin’s idea, an updated version of shared-risk shared-reward model
• Venture-capital financing model
• Incremental delivery with payment on incremental acceptance
• Jonathan House’s idea, fixed-base-price with success/failure ratchets
• Time and materials variant

I tend to think the answer is in none of these, but in option theory. I’m not the first to think that way, but what Alistair has done is reawaken in me the need to complete that analysis. So thank you Mr Cockburn.
I’d love to hear from readers about their experiences in this regard. Any takers? What works? What doesn’t? Why?