I was talking with my friend Clarke Ching today about Kanban and pull systems in general. I came up with a metaphor that we both liked and thought I would share it.
Problem : Imagine you want to get a ball of string ( your features ) through to the other side of a funnel ( your development team ).
Traditional methods involved pushing REALLY, REALLY HARD until it goes through.
Agile and other iterative methods realise that trying to force a whole ball of string through a funnel at once is madness, so they chop the string up into smaller pieces which are easier to push through.
Pull systems, such as Kanban, change the dynamic, rather than pushing the string through, they feed the tip of the string through and then pull it as fast as they can.
Which of these is best?
Well, traditional methods often cheat by mashing some subset of the string through and declaring victory. Or by making the team ( the funnel ) enormous so that you can fit a fairly large ball of string through the hole without effort. Or by minimising the features so that they’re dealing with a tiny ball of string. Or some combination of the above. I’m not sure this is ever a good idea.
Agile works pretty well, but the chopping takes effort ( iteration planning ) and consumes time. But it does break down into nice, neat iterations which provide clear points for releases, milestones, measurement and feedback.
Kanban works pretty well too, it might be slightly more efficient than an iterative Agile approach, but the milestone and release points need to be superimposed onto it since there are no natural break points.
Lean and ToC have their place here too - tools, techniques and strategies to make the hole in the funnel wider and to make sure that the string that gets through is the right string, used as efficiently as possible. Stretching the funnel as far as possible, just as I have stretched this metaphor.
June 4th, 2009 at 7:42 pm
Rob,
I like this metaphor. It works on so many levels as you describe, and even if you take the agile vs traditional aspects, and ignore the kanban/pull version, you can still use it. Not sure that I’d agree with the notion that agile chops the string up. I think it’d be better if you said that ‘agile unpicks one feature/story at a time to feed through the funnel’. Also, would TOC emphasise how to make the hole bigger without necessarily increasing your team size, in contrast to the notion of throwing more people at the problem, which then only works to a certain extent as you end up with size vs communication issues I guess. Anyways, enough rambling and thanks for the metaphor.
Bruce
June 24th, 2009 at 7:48 pm
I dislike this metaphor, and all metaphors that make programming something like assembly line work. If all we did was repeatedly attach do-hickeys onto widgets I might agree. But good programming would be to construct a do-hickey attaching function and add it to the widget. Too much software engineering is focused on attaching the do-hickey and too little on the paradigm changing process modifications that would produce software better and faster.
June 29th, 2009 at 7:25 pm
I think you’re missing the point Veri. The metaphor isn’t about programming it is about scheduling and managing programmers and their efforts.
However you break it down, the work of developers needs to be scheduled, planned and controlled. That the work of programmers is creative and unpredictable in nature is certain, this doesn’t mean that you can’t or shouldn’t try to track, understand, guide and control it as a project manager. It makes it harder that the programmers aren’t churning out widgets, but that’s the nature of the game.
In a sense, is like the life of a production-line widget assembler. Requirements come, you create the solution, you release it, more requirements come…