silk and spinach

The New York Times recently ran an interview with Ed Reilly (American Management Association) on the distractions that can result from technology. Email, for example:

“Companies go to great lengths to set up lists of authorized approvals, meaning who can approve what size of purchase. But you will find that people who are not authorized to spend $100 on their own are authorized to send e-mails to people and waste hundreds of thousands of dollars’ worth of company time.”

(Link via Merlin Mann at 43folders.)

For me, this is not just about the distraction caused by receiving email (although re-acquiring the flow state does definitely cost). In Ed’s comment I see the muda of working on the wrong stuff - of spending time on conversations, research, or even whole projects, that aren’t on the value stream.

This isn’t about finding the right balance between creative freedom and strict customer pull. It’s about making sure that everyone can always identify the business value of the things they spend their time on. Is this project right for our strategy and markets? Is this feature ever going to be used? I’ve spent time in three very large (>20,000 people) organisations at various times in my career, totalling sixteen years in various roles in software development. And only twice did I work on projects that were actually delivered into the hands of users. The remainder all seemed to be great ideas to someone, I’m sure. But the waste incurred was huge. This is the muda of working on the wrong stuff, and very often it begins with an email…

Brent Strange reports that some major companies - notably Microsoft, Mozilla and VeriSign - have begun rewarding their testers with cash for finding serious defects prior to release. It seems to me that this approach is seriously flawed, in at least two respects.

First, it further promotes the traditional antagonism between developers and testers. There’s now a clear reward for testers to find the developers’ work wanting. How does that help to build trust or teamwork?

And second, it rewards the testers for not helping the developers get it right sooner. Sure, the cash will be less than the cost of releasing with a serious defect, but it will also be less than the cost of rework due to finding the defect late in the value stream.

The solution? Both developers and testers should be rewarded when the pre-release testing finds no defects.* Instead of rewarding antagonism, reward collaboration. And reward the reduction in rework. Have the testers engaged at the front of the value stream, creating automated self-checking tests that will help the developers get it right - and complete - first time.

* (Footnote: this needs to be balanced by penalties of some kind if the pre-release tests are skimped in any way!)

One of the central tenets of lean (and TOC, for that matter) is that inventory is not an asset, but is waste. In particular, carrying inventory incurs storage costs. David Carlton is reading up on lean manufacturing, particularly in relation to applying its techniques to softare development. This week David asks a deceptively simple question about inventory:

“… it’s not clear to me exactly what lesson [the carrying cost of inventory] has for software development”

While neither David nor I would claim that software development is similar to manufacturing, it can be edifying to map the themes, principles and practices of the one onto the other. I think the answer to this particular question lies in looking at the various kinds of inventory we have in software development, and examining the carrying costs of each in turn. Off the top of my head:

unreachable code

Still gets built, thus contributing to slower build times, and hence to reduction of flow and feedback during coding. It may also need to be read (or worse - understood) whenever we’re debugging or designing an extension in that area. We have to keep it compiling successfully, which means it could actually prevent design changes and cause inertia. And if it has tests, we have to keep them building successfully and passing - another potential cause of reduced speed, frustration and ultimately design intertia. (All of this because our codebase is part of gemba.)

unused features

Same as unreachable code, plus: Features we ship get in the way of our users, which will either confuse them, slow them down, or otherwise generally leave them feeling slightly uneasy about our product. And presumably our testers still have to ensure that the features do work as intended, so there’s extra pointless work to do for each release. And if these features have bugs, we have to carry the support cost when a user stumbles upon one.

items in the product backlog

Have to be reviewed whenever stories are prioritised. And if we have too many, they may contribute to a sense that the product is a Death March.

artifacts that don’t ship

By which I mean documents, plans and models that must be kept up-to-date as the fuzzy future comes into focus, and as the product evolves. None of these artifacts is directly a part of the product, and yet we spend time and money fiddling with them (while Rome burns).

(And we haven’t even mentioned the time and money invested in creating these things in the first place!)

What other inventory and carrying costs does your project have?

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.

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.

In case you missed them, or can’t find stuff in the archives, here’s a recap on the posts I’ve written about waste in large organisations…

the muda of walking about

Co-location, co-location, co-location

your eyes are too high, sir

A salutary tale of bureaucracy without lean thinking

more on multi-tasking

Multi-tasking delays everyone

local optimisation

In which cost accounting at the department level leads to false positives in the search for productivity improvements

the taxi business

When per-project cost accounting dominates, the first project that needs an infrastructure feature pays for it; everyone else then gets a free ride. Local optimisation prevents progress

tidy gemba

House-keeping is never a waste of time

i only want a pencil

In a dysfunctional organisation, even pencils can be exorbitantly expensive

(During my New Year clear-out today I found the notes for this post. So I dusted them off and here’s the result. Over a year late, but timeless.)

I’m currently working in a vast building, filled with thousands of people on two enormous floors. I’m part of a team, and our desks are all over the place (albeit on the same floor). I’m the type who gets much more out of face-to-face meetings than I do over the telephone, so I spend much of my time walking around the building from desk to desk. But I’m convinced that I waste less time walking than I would if I chose to work alone and then rework in response to review comments.

Our desk locations are allocated centrally, and in fact the task of desk allocation employs one person full-time because personnel changes and department reorganisations seem to be in fashion this year. And today there’s good news! Someone has seen sense, and my team is being moved together, to a set of adjacent desks. Adjacent to my current desk, in fact. Which is a shame, because in the same shuffle I’ve been allocated a desk right across the building, on the other floor. Still, only one place to go now when I need to talk to someone.

Update 9-jan-06
After three months of spending hours each day walking the stairs and corridors to talk with my team-mates, I was finally moved to a desk in their group. By an amazing coincidence, I left the following week.

Applications for UK passports must be accompanied by two photographs of just the right size, shape, brightness, contrast etc. There’s a double-sided A4 sheet with the application form, giving a dozen examples of acceptable and unacceptable photos, so that you have every opportunity to supply them correctly first time. And as if that’s not helpful enough, our Post Office provides a “check and send” service (for the mere consideration of £7), whereby an expert will go through your form and check that your photos conform to the required standards. If you’ve messed up, there’s always a photo booth right there, so you can rectify any problems immediately. And hence the Passport Office will receive a greater number of correct applications, improving their turnaround time and everyone’s satisfaction. Until now.
Read the rest of this entry »

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.

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…?

Andy Lawrence and I ran our workshop on muda in software development processes yesterday at the Agile Business Conference. We had twenty-two participants and the workshop finished with a very interesting and lively discussion. Andy and I certainly enjoyed it, and I think most of the group did too.

A couple of the groups also made a very interesting discovery. As we’re running the same workshop at XPday Benelux, I won’t share the results just yet. Suffice to say that all of the groups decided that ‘learning to see’ muda is something they plan to try when they get back to work!

Here are a couple of photos taken by Andy during the workshop: