Why IKEA makes me question LEAN

We happen to live in a mid century styled house, and IKEA’s style often fits quite well into that design. While we own many vintage pieces, there’s something to be said for rounding out the collection with some newer stuff that can be bought cost effectively. IKEA is an interesting business in that they figured out that shipping air was wasteful. By flat packing their items and having customers assemble it themselves, everyone wins.

Now, if you’ve ever assembled your own furniture, you know it can be quite a project depending on what it is. IKEA uses all kinds of interesting fasteners, all designed such that you ought to be able to assemble it with a manual screwdriver, an included allen wrench and perhaps a small hammer. The thing is, I own a battery powered drill, and I use that (with interchangeable bits) in place of the Allen wrench and screwdriver. In theory, if I eliminated all the waste from the assembly process (say everything was packed such that the pieces came out in the exact order needed), that there wouldn’t be much advantage from using power tools. That is, when I was first taught about LEAN, we were warned against optimizing the value added parts of the process and to focus on eliminating the non value add.

So, if you buy from IKEA, then assembling it yourself is part of the value add. You specifically bought the product for this reason, to trade your time for less money. Therefore, optimizing it shouldn’t make much sense, and yet, using a power tool to do the value added work drastically cuts down on the time to assemble a piece.

In fact, power tools make many value added tasks much better (or even possible at all). And so it confuses me, if you are doing a value added task manually, why you wouldn’t focus on doing it as fast or efficiently as possible. Perhaps it’s just a miscommunication from the teachers to the students, and it is certainly true that there is many a wasteful step in many processes, but it strikes me that if technology can make a value added process better, than why would you not do that right now as well as eliminate waste?

Is variability in software development good?

I myself wrote an article not too long ago on the subject of variability in process. Under some circumstances I think variability might be desirable, although I wasn’t particularly referring to software development. Last week I attended a webinar hosted by ITMPI and given by one of the employees at QSM. His talk was about the measurement of productivity in IT, specifically focused on how to account for variations in productivity when estimating. The talk was pretty good, but one of his early slides bothered me.

On that one slide he argued that software development wasn’t like manufacturing and therefore productivity couldn’t be measured like manufacturing does. Unfortunately, he offered no alternative during the talk. Instead he focused on how to measure unexplained variations in project outcomes and to aggregate this into some sort of vague productivity calculation. On the whole, useful for estimating if you just want to know the odds of a certain effort outcome, but not so useful if you want to learn about what factors impact productivity.

It’s true that software development doesn’t have a lot in common with manufacturing and the analogies drawn are often strained. That’s not so concerning to me, as the spirit of what management is often asking is right – what choices can I make to do this faster, better or cheaper. In that context, productivity isn’t just something you find out about after the fact, it’s something you want to understand.

With my own research, we’ve found measurable evidence that certain activities do make a difference in productivity. Colocation is worn about 5% better productivity. Committing resources to projects is worth about 0.4% for every 1% more committed on average your team is to a project. Which gets back to the question I posed in the title: is variability good?

In short, no. But the longer answer is, just like any process, you have to know what to control. With a highly thought intensive process, there are things you can and should seek to control to produce more predictable outcomes. It is true that software development is a more like the design of a product than the manufacture of one, but that doesn’t mean that anything goes.

The downside of delaying commitment

The Poppendieck’s helped push the idea of delayed commitment in software development. The idea is relatively straightforward and on the surface seems good. If you don’t need to make a choice, don’t. In terms of LEAN thinking, if you consider a decision in software development to be akin to creating inventory in manufacturing, then this makes perfect sense. Any decision made too early has the potential of becoming invalid with time. In the same manner, a part made in a factory too soon runs the risk of becoming useless.

We’re in the process of buying a home, and one of the very often delayed commitments is to an insurer. In the USA, and presumably elsewhere, if you want to get a mortgage, the lien holder wants you to insure your property. After all, without the collateral of your property, the lien isn’t worth very much. So, it’s very much in their interest to assure that if something bad happens that it will get repaired. You don’t need the binder from your insurer until within days of closing. You’ve probably already done the inspection, paid for the appraisal, perhaps paid money to lock the interest rate, etc. The seller will have turned away other buyers. After a month and a half, everyone is pretty well locked into this transaction. Tens of thousands of dollars may be at risk.

But that’s not my personality. If I can get the data to make a choice and make one, I will. And getting a quote on insurance was something I could easily do well in advance of closing. Delayed commitment? No, far from it. It’s usually just a formality to request the quote and lock in the insurance, but things have changed. Higher losses due to delayed maintenance and more extreme weather have made insurers more cautious. When I called, the first insurer refused to underwrite the risk because of the age of the roof. So did the second insurer. Had I waited to get these quotes then I would have found this out within days of the closing. No insurance, no closing. We’d be heavily committed to this house with a strong possibility that I would have lost all the money I put down.

At this stage, all I’m risking is the cost of the inspection. Sure, I don’t want to lose $500, but I’d far rather lose that than 5% of the purchase price. At this stage my goal is to renegotiate with the seller regarding the roof. My negotiating position is strong – I’m only into it for a few hundred while the seller now faces the possibility of being completely unable to sell without replacing the roof. Any buyer who isn’t paying cash faces the same problem. They won’t be able to get a mortgage without insurance and insurers won’t underwrite the house in the current condition.

Had I waited, my negotiating position would have been incredibly weak. I’d have put out perhaps $30,000 between inspection, appraisal, legal fees and earnest money. I’d be forced to pay for the roof myself or lose all that money. Delaying commitment isn’t always the safest choice. No matter how routine the delayed decision has been in the past, if you don’t understand the risks of not knowing the answer, you put yourself in a precarious position.

I’d argue that for anything you can know, don’t delay knowing it. Some minor rework costs are more predictable and preferable to the occasional complete blowout loss. There is value in predictability, even if the costs are slightly predictably higher.

Update: Interestingly, the seller chose not to negotiate over the replacement of the roof. We went on to buy another house, since we were unwilling to assume all the risk. The seller did eventually sell, and not terribly long thereafter, but at $15-20,000 less than our offer. In the sellers case, delaying the decision to negotiate cost them as well. Sometimes what you have right before you is as good as it is going to get.

How long to make a change permanent

A couple years ago when I was doing my Lean training, my mentor assigned me to read Womack and Jones’ book, “Lean Thinking.” The book is full of interesting ideas. If I ever loaned you my copy, you would find it filled with comments and post it notes about all the things I was considering as I read it. One particular quote that stuck with me was that it takes about five years of concerted effort to make a change permanent.

Five years seems like a really long time, and for some reason I was thinking about it today. So, I happened over to the bureau of labor statistics to get some data in median employee tenure. Interestingly, the median employee tenure is just under five years. That got me to wondering. Is it a grim reality that to make change permanent that we simply have to wait for most employees to turn over? After all, any new employees that come in are probably willing to try something new. Maybe the not so secret answer is that if you want to make change, simply wait for things to change. In the mean time, you’ll simply have to fight against the tide.

Never have an attic

We are selling our house, and I realized this evening that having an attic is about the worst thing you can have in a house. Sure, everyone wants storage space, the reality is, after ten years, it isn’t really storage. It’s clutter. It turns out over time you just put more and more and more stuff up in the attic that you should’ve gotten rid of. It gets there because you think either ‘oh, I might need this later’ or ‘this has value, I can’t just throw it away!’

Both things might seem true, but the reality is, ten years on, neither is true for us. I haven’t the energy to sell all this stuff, even at a yard sale, so I’m willing to give it away. It might have value to someone else, but to me it has so little value that I will give it to anyone who will take it. And, in turn, I realize that if I’m willing to give it away that I never was going to need it again. The attic is just a holding area for stuff that is headed either to the garbage or to someone else who can find value. If someone else can find value in these items, then I should have happily given them away 5 or 10 years ago, when I first put them up there.

The only difference is, instead of getting rid of it in a timely manner, I’ve made my own life difficult by delaying the choice to discard it. If you want to achieve a clean workspace, you’ve got to get rid of things when you no longer need them, not just store them away on the off chance you’ll need them again.

As an aside, I did want one thing from up in the attic some time ago, but of course I couldn’t find it because there was so much other ‘valuable’ stuff up there. Clutter makes life difficult not just getting rid of it, but also obscuring what is of value. In my next house, I’m going for less storage space, thus forcing myself to make those decisions right away.

Good at heart attacks, bad at cancer

I was watching a video today from IBM that included insights from many world leaders, famous figures, and so on. A lot of times someone passes a long a video and I like it. Most of the time it doesn’t resonate for me, and sometimes there’s a single quote that sticks with you.

In this case, Fareed Zakaria said “we are very good at heart attacks. We are very bad at cancer.” He wasn’t referring to the medicine, however. He was talking about companies. His point was that companies react well to sudden traumatic events and very, very poorly to things that eat away at us slowly over time. It resonated with me not because I didn’t know the concept, but because it so elegantly states the difference between sporadic and chronic loss.

Sporadic loss is a heart attack. In software it’s the production outage. It’s all hands on deck. Everyone comes together for a few minutes or hours and rescues the system. Then we go back to the projects we were working on – crisis averted.

Chronic loss is a cancer. It starts developing and you don’t even notice it. By the time cancer has become a lump you can feel, it’s frequently too late to do anything about it. The prognosis for many late stage cancers is not good. It is very similar for chronic loss in organizations. At first, it’s a defect which generates a bunch of calls to the call center, but there’s a workaround and you deem it too expensive a fix to cost justify. So, you live with the workaround. And then there’s another, and another, and another. Over time, you allow hundreds or thousands of small failures to erode the quality of your product. Individually, none of them is an issue. Collectively, you have a mountain of a problem and a few hours of heroism won’t help you. The problem got there over years of deferred maintenance and it isn’t going to go away easily.

Chronic loss looks like a bloated production support organization. Chronic loss is when you have so many production incidents you can’t even fathom taking the time to attribute them to the projects that introduced the issues. Chronic loss is when you only talk about critical, high and medium severity defects because there are so many low defects they drown out the others. Chronic loss is when you justify that measurement system as ‘focusing on the big issues’ – the heart attacks are all you look at. Chronic loss is when you pay someone to look over the shoulder of someone else doing the work to make sure it’s done right, rather than figuring out how to error proof it. Chronic loss is batch abends that you just restart every month, or week, or night, or several times a day and never figure out why it failed.

Being good at heart attacks isn’t going to save you from cancer. But preventative care of your software will protect you against both risks.

Eating your own dog food?

Someone said to me yesterday “we need to eat our own dog food.”  I’ve heard the phrase a hundred times before, but for some reason this time I thought to myself “Ew.  I don’t like the smell of dog food; I’m sure not going to like the taste.”  The origins of “eat your own dog food” are pretty well known.  Alpo food company once advertised that their food was, logically, the food they fed to their own beloved pets.  Somehow that has translated into using our own product or service, while a more appropriate translation might be that we apply our product or service on those close to us.

Symantics you say?  I think not.  Would you crack open a can of dog food and actually (be honest now) eat it yourself?  No, of course not.  It really isn’t human food, but it’s certainly of good enough quality to feed to our pets.  It’s not a bad product, for its purpose.  But software process isn’t something we do to our employees like we serve dog food to our pets.  Or, at least, it shouldn’t be.

A process can’t be just good enough for those who work for us, even if they are the only ones who would use it.  Would we, as leaders of the organization, do it ourselves?  If the answer isn’t resoundingly yes, then the process is just that – dog food.  Meant to be served to someone who we care about, but not quite enough to serve them the exact same thing we want for ourselves.

I understand the sentiment of using the tools and processes that we propose others use.  After all, do as I do is great leadership by example.  But serving your own employees a process you wouldn’t reasonably do yourself day in and day out is not good enough.

Who doesn’t like fresh bread?

I’ve never heard anyone say “I’ll have a sandwich on day-old stale bread, please.”  So, it’s not surprising that a lot of restaurants you visit offer their sandwiches on freshly baked bread.  But, from a LEAN perspective, this creates another issue – making fresh bread before the customer wants it is waste.  First off, if you make the bread fresh in the morning, by the end of the day (without preservatives) it’s not all that fresh anymore.  Bread goes stale pretty quickly.  Second, you never know how many customers you’re going to have that day, so you have to make too much bread so that you don’t run out.  But that leads to overproduction.  Then you have to throw away bread at the end of the day.

I only bring this up because I ran into an interesting experience the other day with a restaurant who solved this problem.  They actually baked the bread for my sandwich on demand!  Yes, I’m serious.  The bread that I had was made immediately before they assembled my sandwich.

Now, this particular place was in an interesting position.  They’re a pizza shop, but they also sell sandwiches.  So, they could have piles of bread going stale, or… they figured out that they could make a very tasty sandwich on freshly baked pizza dough.  Instead of stretching it into a round and placing sauce and cheese on it, they simply stretched it into an oblong shape, baked it with nothing on it, took it out, sliced it open and built my sandwich on it.  It’s not much of a stretch to imagine modifying the recipe slightly to make all kinds of different breads on demand. 

If you’ve ever baked, you’ll know that the basic structure of a bread recipe is pretty much the same.  Sure, instead of bread pre-made they now had pre-made dough, but this has a couple advantages.  One, it was an interchangeable part now – they could use it for pizza and for sandwiches.  Two, dough doesn’t go stale like bread does.

I’m not saying its the perfect solution for every place that sells a sandwich – it works well for this place because of the nature of their business.  But it is a really creative solution to reducing waste, and that’s why I bring it up.  Things like this are hopefully moments of inspiration to find a unique way of making your own processes better – that’s why I love them.

Why 5S matters at 3:00AM

At 3:00AM a recent morning ago, my son woke up with a diaper that needed to be changed.  As go most nighttime childcare events between my wife and me, whoever says “you do it” first wins.  And, in this case, it was my wife that noticed his fussing and, half asleep, mumbled “your turn.”

Reluctantly, I rolled out of bed, staggered down the hallway and made my way to my son.  One thing that has forever irked my wife is that I can usually do all of this, crawl back into bed, fall back asleep, and by 7:00AM not even remember it happened.  But not this night.

I carried my son to the changing table and there were clothes all over it!  I’m half asleep, so I grab handfuls of neatly folded clothes and throw them on the floor.  My son, now full awake, is crying loudly and I’m hoping it won’t wake up my daughter. 

Next, the diaper?  Where’s the diapers?  Usually there’s a neat pile of them right there, but not this time.  I see them in a box, just out of reach.  I can’t both make sure my son doesn’t roll off the table and grab a diaper, so I have to pick him back up.

With a new diaper in hand, I undo the existing diaper to expose the disaster within.  I reach for a wipe, and… the container is empty!!!  I toss the empty container on the floor, cursing under my breath.  There’s another container, with a measly two wipes remaining in it under the empty one.  I’m sure my son got a less than stellar cleaning that night.

Were it mid-day when I had to do this, I’d probably not even remembered to write this down for you, but at 3:00AM, what could be a quick diaper change turned into a memorable ordeal.  5S matters because you shouldn’t have to think about these things.

One, sort out what you don’t need.  What were clothes doing on the changing table anyway?  We don’t dress our son there, and so using it as a temporary holding space for clean clothes resulted in the purpose of the workstation being ruined.  A changing table needs:  diapers, wipes, a garbage can, maybe a rash cream, that’s about it.

Two, straighten.  Things should have a place.  The diapers usually did have a place.  The wipes usually did have a place.  But in this case those places weren’t rendered sacred.  There were clothes where those things should have been, and the things I needed were somewhere else.

Three, sweep.  Clean up.  Empty packages of wipes should be thrown away.

Four, standardize.  We don’t have multiple changing stations, but if we did, they should all be the same.  That way, no matter which one I go to, I’d know where the diapers and wipes were.

Fifth, sustain.  Keep it that way.  Particularly at 3AM is not the time to find out that what once was a nice clean changing station is now a mess.

Now, you won’t be doing whatever job you do at 3AM, but there are going to be times when there are other things on your mind than the activity at hand.  Little distractions surround us, particularly in software development.  The last thing you want to do is lose flow while you hunt around for something which you should know exactly where it is.  5S matters at 3AM, but it matters every other hour of the day as well.

Velocity and standard work

LEAN has a concept called standard work times which is an expectation of how long some task should take.  For example, it should take you 1 minute to mill part X from a block of steel.  Having expectations of how long something should take is important in manufacturing, because it helps you assess whether an individual or team is meeting those goals.  The measure for standard work shouldn’t come from some desire for a certain output, it should be based on how long those things really take.

In software, lots of measures of standard work have been generated over time, but we don’t seem to use them much.  I recall, from my earliest days of programming, that a programmer was expected to create about 5000 lines of code per year.  I’ve also heard estimates for debugged lines of code per day (10-25 or so, if I recall correctly).  Capers Jones’ expressed measures of productivity in FP delivered per day.  We seem to have some understanding of what a typical productivity expectation is.

And then we ignore it.  For some crazy reason we decide that the “laws of physics” don’t apply to us and we need a measurement that is unique just to us.  In Agile, they call it velocity.  It’s a measure of the team’s productivity based on story points per day.  What’s a story point?  Well, that’s a relative sizing mechanism the team determined.

The problems with velocity are numerous:

  1. It’s only good for the exact team you’re currently on.  Sadly, team members come and go.  As anyone can tell you, people are not protect-able resources.  Even if you don’t want them to quit, they will.  And when they do quit, your measure of productivity walks out the door with them.  The new person will need ramp up time.  The new person may be more or less productive.  The new person might not gel with the team.  And until then, your expectations of productivity are gone.
  2. It’s only good within the team.  You can’t compare cross team productivity if everyone’s got their own way to measure it.  I’m positive that I’ve argued before that comparing yourself to other companies isn’t necessarily a worthwhile activity, but being able to compare yourself to yourself is.  How do you know you’re getting better (or worse) if the ruler keeps changing size?
  3. It can accept lower productivity.  Sure, even if you accept #2 above, that you don’t want to compare yourself to your competition, you have no gauge as to whether better is even achievable.  Software is a relatively slow process, so you don’t get lots of data points out of it.  If you have to wait for your team to build up a measure of productivity, you could be accepting a lot lower productivity than is likely achievable.  Being able to compare yourself to a typical expectation of productivity provides a measurement it will take far longer for you to build up on your own.

I understand that there are people out there who believe software is more of an art than a science; that software will be practiced by small teams doing great things.  I happen not to agree with that.  It may be true some of the time, but certainly not all or even most of the time.  In most cases, software is more likely to be like building houses – unique but largely assembled from similar pieces.  And with that in mind, software is more predictable than we like to admit.  But predictability means you can have expectations of standard work times, and that you needn’t allow each team to define productivity in their own vision.