Different take on Agile – Kanban and iteration free development

I came across this interesting article.


It is an Agile process but seems to be missing the iterations.  Instead people just set their capacity and continuously work through stories.  Its a bit mean though, because we have been training up all these iteration managers … and now what would they do?

The article also mentions that you can do away with estimates if you have “expected time to delivery, or wait time”.  And most controversially of all the concepts … it has an example of a developer who volunteers to help with testing, rather than just ramming more stories into testing when the testers are already at a point where they can’t keep up.

I was looking through the process and feeling quite impressed, when I realised – we are finally using Agile to turn projects into production support.


About James King

I coach organisations in how to better make use of the untapped talent they have in their people and to explore new ways of understanding and solving new and old problems I live in Sydney with my wife and daughter and have no real hobbies beyond the usual boring ones of reading, writing and watching tv.
This entry was posted in Agile, Organisational change. Bookmark the permalink.

5 Responses to Different take on Agile – Kanban and iteration free development

  1. Since I didn’t blog (http://agile-commentary.blogspot.com/) about it, I’ll point you in some other directions.

    If you are interested in learning more about dropping estimation from your process, I know it’s been talked about on InfoQ.

    If you are interested in learning more about KFC (Kanban, Flow, Cadence), look up the recent Lean / Kanban 2009 conference in Miami (Twitterdom and Mike Cottmeyer covered it well) or search for Karl Scotland’s blog!

    I’m finding value in both concepts and have been learning/incorporating them for almost a year.

  2. James King says:

    Thanks Kevin

    I will definitely follow those links up

  3. James King says:

    Apparently not everyone thinks Kanban is a good idea though. So here is a reply from the opposition:


  4. I saw that article also, and it has some interesting points.

    In my last environment, I found that as my scrum team matured, we started treating iteration boundaries as a checkpoint and we loosened up the “scope must not change” rule within the sprint. We slowly drifted from Scrum and towards parts of Kanban. Learning about Kanban helped me understand why.

    In my current environment, scrum (by the book) won’t be accepted/attempted.

    I had a great discussion over lunch with a peer along these same lines (Kanban vs. Scrum). We ended up agreeing. We stated that both can be implemented badly. We agreed that only a person whose been through both can see the positives and negatives of both. And we agreed that they are conducive to different agile starting points and company cultures. You could start with either and end up in the other (as shown by this link you shared).

  5. James King says:

    I had a very similar discussion on Friday. We came to the agreement that the team can make almost any approach work and can also make any fail.

    The key we found was to have a team who keep trying to improve locally, while also listening to what their customers and suppliers are telling them and also continually assessing new ideas.

    But the most important component seemed to be that the team accepted that they were somewhere between doomed and perfect, and deliberately chose to move closer to perfection and further from doomed with the actions they were taking this week.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s