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.”
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…
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 software 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:
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 inertia. (All of this because our codebase is part of gemba.)
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.
Artefacts 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 artefacts 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.
(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.
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. Continue reading →
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:
While searching the web this morning I failed to find a clear and succinct definition or explanation of the seven types of muda (waste), as originally identified by Toyota. So for reference I’ve compiled the following using a combination of various textbooks on my bookshelf:
Producing more than necessary results in consumption of raw materials before they are needed; wasteful use of manpower and utilities; additions of machinery; increased interest burdens; increased inventory (below); increased transportation and admin costs.
Inventory or Work-in-Progress (WIP)
Final products, work in progress, parts and supplies all add to the cost of operations by consuming space, facilities, manpower and admin. Their quality also deteriorates over time, and they may even be destroyed by a fire or other disaster.
Moving materials or products adds no value. Worse, damage often occurs during transport.
Repair / Rejects
Rejects interrupt production and require expensive rework. Often the rejects must be discarded, thus wasting the resources and effort that went into their creation. The rejects themselves may also damage machinery.
Any motion of a person’s body not directly related to adding value is unproductive. Unnecessary or awkward operator motions put undue stress on the body and cause waste.
Sometimes inadequate technology or design leads to muda in the processing work itself. For example, the apparent need to wrap WIP in bubble-wrap for transportation to another machine could be eliminated by re-designing the assembly line.
Waiting occurs when the hands of the operator are idle; when an operator’s work is put on hold because of line imbalances, lack of parts or machine downtime; or when the operator is simply monitoring the machine as it adds value.