For those of you interested in kanban scheduling in sw dev you might wanna check out some of David Andersons work:
Kanban in Action
A Kanban System for Sustaining Engineering

Like Martin I also find and have experience that some kind of kanban system for limiting the work-in-progress can be a beneficial addition to Scrum.

The basic idea is based on the heijunka principle of load levelling. As long as you have work flowing steadily through the process at a predictable rate and all steps have approximately the same capacity planning is very simple: you know that when you add a work item to be done it will take approximately the average cycle time to get through the system (you have to adjust for the relative size of the work).

This way your planning will be like this:

“OK here is 5 points of work I need done when will it be ready?

The you look at your kanban - the visualisation of your process - and say - we 20 points of work in progress before it and we are delivering 5 points per day, so you can expect to have it in five days (four days of backlog/lead time to deliver the WIP and on the fifth day the new 5-point item will have made it through the process).

It quite simple and probably “good enough” for most people since it takes away a lot of planning effort. It requires a very stable process with limited variation to be useful (ie. predictable). This is one of the reasons that Kanbans should be used carefully and you should react promptly to problems when you see causes of variation such as queues building up in the constrained intermediate process steps.

Which in turn explains why the ScrumMaster role is so important…

Give me a mail at (mj at ative.dk) if you are interested in hearing more and I will write some more about it.

@Kennie: I remeber Kanban as interesting notion, but I didn’t catch the concept very well in my notes, and now I can’t seem to recall what is was all about?

@Hans: I’m afraid these questions are not direct MP quotes. MP really just asked “Why?”, and the questions are my attempt to clarify what MP was asking - and I might be wrong.

“Why is software development so hard to manage?” Shouldn’t the question have been something like “Why are BIG software projects so hard to manage!”? I know that answer to that would have been a dead give away! “BIG” (time, people, problem domain, et al) = “complex” = “a conceptual whole made up of complicated and related parts” and that’s difficult to grasp by nature! So we, the agile heads, break the structure down into manageable bits and make big projects small and manageable. At least that’s what I do!
Maybe the question should have been “Is there another way of managing BIG projects? - other than by breaking it down into smaller bits” because breaking a project down have some obvious risks –like missing whole…?!? Hmm I almost made that sound lean BTW.. Her “what makes agile fail points” those points would make just about anything fail! Maybe I should have expiated less from a free lecture, so Bent next time force my arm and make pay to experience the two day show