Sunday, June 26, 2011

Agile belongs in a Kanban, not Tables

Alistair Cockburn put together a fine article on using various tables to track value, risk, and quality in a agile project.

I countered on twitter that a Kanban board would be a better a way to visualize this information. Alistair didn't quite grok what i was getting at and asked for a picture, now being such a boig fan of Alistair, I couldn't refuse...



  1. Unfortunately the image (url) is broken.

  2. Hi Jeff,

    Read Alistairs article, and like you I like the thinking, even though it is nothing new. To summarise, get the biggest bang for you buck, by doing the most important things first and forgeting the tail!

    This is a simple message that most people can grasp. Adding more resolution to this message doesn't always help IMHO. The people who could benefit from the higher resolution are the types the get the basic message anyway.

    The type of people who need to grasp the basic message normally have a bunch of other basic problems too. Like poor collaboration between devs and business people, a lack of trust, top down command and control, etc.

    Adding resolution to these people can lead to them focusing on one aspect whilst ignoring everything else. I've experienced elaborate business value analysis whilst the engine that was meant to realise the value was totally jammed. A much simpler priority scheme for these people would have been a better bet. Freeing up time to focus on the basics and get their engine working.

    Back to basics is a less attractive message I know. Well because it offers nothing new and shiny. But often this is the most fruitful message. This alongside with the unpopular message about basic trade offs, a reminder that there is no such thing as a free lunch.

    Until these messages are received, everything else can turn into an expensive distraction. I'm sure you would agree.


  3. Paul,

    Yes back to basics is nothing new. Still, not enough IT shops help their clients to think in these incremental terms, we ( IT) have the modeling expertise to know why this is good for the business, but often don't have the will.

    Spending somemtime partitioning this problem is a good exercise IMHO, it really helped us on a project to focus on what matters, Alistair used tables, I prefer color and a flow based table.

    I would never underestimate how easy it is for fog of war to set in on a project, simple visualizations like the above can really help remove it...

  4. Hi Jeff,

    Yes I see the utility. For me, most of my clients would benefit from getting better at delivery. Although I could see them jumping on this stuff as one more good excuse not to tackle the harder problem of actually delivering working software.

    For those who are already good at delivery, then I agree, this is a way of getting even better. For the poor, it is perhaps yet another distraction and excuse for remaining poor. This type of analysis has definitely got it's place though, table or kanban.

    Thanks for sharing.


  5. Paul,

    Your focus I on getting people to be better at delivery, all the power to you.

    I don't think that's better than getting people to be better at judging what they should be delivering and when they should stop delivering.

    The importance of either depends on your perspective, certainly I have been to plenty of place where delivery was good, but alignment not so much, so why was that organization poor? Maybe they were distracted by spending to much time on delivery practices.

  6. Hi Jeff,

    Agreed. If you can deliver, but the business are getting you to deliver the wrong things, then yes. I don't think that this particular scenario is at the root of the IT crisis however.

    Most business people would be glad if they got something for their money, as long as it worked and was timely. Allowing them to inspect and adapt as they go.

    You've got me blogging. Well a tongue-in-cheek rant actually :)

    Let me know what you think.