carnival of the agilists, 3-aug-07

John Brothers has posted the latest edition of the Carnival, entitled I’m running late. This is a perennial topic for all software development projects, and doubly so for those of us who take a lean or TOC view of productivity and change, so props to John for bringing that focus to the carnival this time around.

Speaking of TOC, one recent post that escaped John’s attention is Multi-Tasking: Why projects take so long and still go late by Kevin Fox. Every time I work in a large organisation I find myself writing about multi-tasking – and wondering why “common sense” is so rare…

more on the muda of multi-tasking

As you’ll know by now, I can’t abide multi-tasking. This week, Johanna Rothman has been stirring the waters in an attempt to raise awareness that multi-tasking is bad. In particular, there’s a lot of great meat in the comments on that post (I particularly liked J├╝rgen Ahting’s reply). Well worth a read.

multi-tasking in the news

Over a year ago I wrote about the muda of multi-tasking and the delays it will inevitably cause. I had been prompted by the planning approach used by my client at the time, and by a rush of articles in various blogs and magazines, and this week it’s happening all over again. Kathy Sierra discusses a recent cover story in Time magazine (and there’s lots to read in the comments on her blog, too). And a quick search on Technorati suggests the article has opened another flood of blogging on the subject.

multi For me, the best explanation of the problems caused by multi-tasking still come from the Theory of Constraints world. A good straightforward description of the theory can be found in Frank Patrick’s Multi-tasking Multiplies Lead Time. ToC shows that multi-tasking slows down every task we’re working on – and that’s in addition to the psychological effects reported above.

When I adopted David Allen’s Getting Things Done, one of the first changes I made was to fix my email so that it only updated twice each day. I was addicted to intermittent variable reinforcement, and to be truthful I probably still am. It’s an invidious form of multi-tasking, because it seems as if I’m only checking email, webstats, bloglines etc during “breaks”. Unfortunately, if there’s something interesting to read the break expands and delays whatever I was supposed to be doing. Time to find a cure and remove this one source of muda from my day…

Goldratt’s Theory of Constraints shows why multi-tasking delays everything we do and everyone who needs to work with us. Over a year later, I still haven’t learned that lesson.

more on multi-tasking

The other day I noticed an interesting side-effect of multi-tasking

In the very strange organisation where I currently work everyone works on many pieces of work simultaneously. And the historical mind-set means that every task or workflow item requires many people to complete it. This week a number of times I found myself frustrated because I couldn’t progress any of the tasks on my list, and gradually I realised why: Every work item involved six or seven other people. Suppose I have a two-hour task to complete (ie. under normal circumstances it would be easy to complete it inside one day). To get it done I have to involve five or six different people at various times, but the chances of them ALL being free (not in meetings, not off sick, not on vacation) on that same day are tiny. Consequently every task takes maybe ten times longer than it should.

the muda of multi-tasking

Multi-tasking seems to be the topic of the week: Clark says it makes you stupid; Johanna has developed a new workshop simulation to demonstrate the problems it can cause; and Tony Rizzo has written about it here, here and here in the last couple of weeks alone! (I haven’t seen any case studies per se, but there’s more theory and anecdote in the links above than you can shake a stick at…)

In Lean Software Development Mary Poppendieck lists task switching as one of her seven types of muda. But in the workshops that Andy & I ran recently, our participants preferred to stick with the original Toyota muda types, and to list task switching under the muda of motion. What’s important is not the taxonomy, so much as the recognition that task switching is bad.

Unfortunately I’m currently lending my services to an organisation in which task switching is institutionalised. Absolutely everyone is expected to be working on several things at once, and I’m viewed as a dangerous heretic (and probably pathologically lazy) by insisting on having only one job at any given time. I wonder when anyone will notice that I’ve delivered everything on time…?