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?

9 thoughts on “Where Agile meets Planning”

  1. Waterfall and its in-concrete relations make dangerous and unrealistic assumptions that:
    1. the customer knows exactly and unchangeably what they want
    2. the customer is able to clearly and unambiguously describe those needs
    3. the developer completely comprehends that description, and
    4. the developer can translate that understanding into a system that works in time and on budget.

    Now I KNOW I’m always going to have some trouble with 3 and 4 (as a developer), and I’m pretty sure that 1 and 2 are shaky too. I think Cockburn also points out that the people on the project are first-order variables in its success – this to me means that the methodology we choose should fit the people available rather than the other way around – especially if we have smart people. While I’m aware that there are project managers around that can successfully build space shuttles, the likelihood that they are available and affordable to most software projects is slim. So rather than try to change the way the people you DO have work, why not cut the methodology to fit? In my experience this will USUALLY result in some aspect of Agile being most effective.

  2. Agile is all about unknows and change (kind of). To that end, I can’t see how you can effectively capture that in a formal written contract; especially when you consider that corporate lawyers will be involved ;-)

    Most of the Agile work that I am involved in is done using one of two vehicles;

    1 – Fixed Price / Fixed Scope
    2 – Time and Materials

    I would love to see our clients move to something like a price per user story point, with collaboration. Remember, as you move through the cycles you re-estimate and the value of stories changes. How you capture this in a formal contract that all parties are happy with is something that I will leave to the lawyers, and good luck to them.

    I guess the solution is, the contract can only take you so far. What is key is the relationship, trust and level of collaboration between all parties to ensure the right outcome; business value for the client and their customers and profit for the supplier. Perhaps I am too naive?

Let me know what you think

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