Monday, May 6, 2013

Help us crowd-fund an amazing Lean Kanban conference in Melbourne this September 2013



I'm really excited to announce the Lean Kanban Australia/New Zealand conference 12-13th September this year! We're using a crowd-funding campaign to validate the concept in a lean way :-)



Checkout http://www.pozible.com/lkanz and pledge to buy a discounted ticket. There are only 40 discount tickets available so get in fast to secure a really cheap price and to show your good taste, and your support for the conference.

Also, talk to your company about the opportunity to sponsor the conference, they can sponsor direct from the pozible campaign or contact any of the organisers.

Finally, please put the word out via twitter or your own blog. Help us bring the world's best Lean and Kanban speakers to Australia. Let me know if you have any questions!

Ben


Tuesday, January 22, 2013

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.