A new kind of limited WIP: Card duration limits

Here are my notes from my "99 second presentation" from the Limited WIP Society Melbourne meetup today:

Today I want to talk about another kind of limited WIP: a card duration limit, or if you will a dynamic batch size limit: 

I'd like to propose that we could make more use of duration limits on our software development processes,  basically by pulling a card out of our Kanban process if it exceed a pre-determined system duration limit and putting it back into the backlog, probably with an indicator that it had used up the allowed capacity.

We would then have an opportunity to re-prioritise the task based on knowing it has hit the limit and if appropriate re-queue the task. A bit like an operating systems does, it would prevent one task from consuming excessive system capacity and by freeing up system capacity we allow other, possibly higher value cards to flow through our process.

I would imagine this might allow us to control the upper cycle time of our system, preventing late and surprising high lead times. Instead of having to wait for cycle time to be measured to indicate we had a problem, this duration limit would act as a leading indicator for early intervention while the card was still in process.

One consideration to balance would be the costs of re-work and task switching when we decided to re-start that task at a later time. 

However, having this duration limit would allow us to safely take on very risky, unknown size and unknown complexity cards while limiting the effect on flow. I wonder if this would then allow us to more safely exploit the variation in tasks sizes in software development for maximum economic return. 

So I propose we experiment with limiting card durations and observe the economic tradeoffs that result, I'd be interested in hearing your thoughts.

PS. You can probably tell I've been reading Don Reinertsen recently. 

PPS. I'm running an Introduction to Kanban 2-day course in Melbourne.