Inconsistent colors

I really like chocolate, so many days after lunch, I’ll stop by our local Lindt store and pick up a few pieces of chocolate for a sweet bite in the afternoon.  But there’s one thing that drives me crazy about Lindt… for years, they really didn’t offer much besides chocolate bars and their truffles.

When you bought a mixed bag of their truffles, you always knew what you were getting by the wrapper.  Brown are hazelnut, orange are peanut butter, red are milk chocolate and blue are dark chocolate.  For years, Lindt quietly and unconsciously trained us to associate certain colors with certain flavors.  Then, they introduced new lines of chocolate.

Suddenly you could buy small, individually wrapped chocolate squares, crisp caramel clusters, coffee flavored chocolates, tiny little chocolates that played on famous desserts like creme brulee and more.  They also introduced marzipan chocolates – one with a milk chocolate shell and the other with a dark chocolate shell.

Can you guess what color the milk chocolate marzipan candy was?  You’d think it ought to be red, right?  Well, no, it’s blue.  Why?  Who knows.  And the dark chocolate one?  Obviously, it’s red.  Years and years of training people that red = milk and blue = dark, and then you introduce a new chocolate where the only difference is the type of chocolate shell and you switch the wrapper color?

It seems like a little nothing, but every time I go into Lindt to get a chocolate – and I really like marzipan – I have to read the label to figure out which one I should be buying.  It constantly confuses me, and I don’t really like milk chocolate.

Now, at Lindt, are they really wasting much of my time?  No.  But what if you did this to your own employees?  What if you used a certain color scheme and then suddenly made it mean the opposite?  One thing I constantly read in articles from LEAN.org is that it’s these kinds of questions that get asked on Gemba walks.  Why are we inconsistent?  Why is this different or special?

Inconsistent colors may not seem like much, but it stands to confuse and slow down your business just ever so slightly.  It’s not the one time you do it, it’s all the little times that you do it in various places that slow everyone down.  It adds up.

Unnecessary process steps

LEAN is greatly concerned with waste, and yet we often don’t see it when it is right before our eyes.  Take for example, granting access to a particular website.  These days, its downright commonplace for you to simply create your own account and get going.  You name it – Facebook, banks, online retailers – all off them just let you make your own account.  And some of these places are dealing with your finances or your credit card!

Yet, we don’t think much of it.  In fact, we sort of take for granted that people just create their accounts as they need them.  But in corporate environments, not so much.  Here we rely on access requests, either emailed about or managed through service request tracking systems.  In some cases, the protection is necessary.  Companies often have closely guarded marketing plans which they want as few people to know about as possible.  But, in many cases, we make people request access to things that we’d never deny them access to.

It might not seem like much to deal with an access request.  What is it after all, less than a minute, maybe two minutes at most to create the account for someone?  But what is that cost over months or years?  It’s like a form of water torture… drip, drip, drip.  And what about the person waiting for access, twiddling their thumbs while they wait for someone else to finally get around to granting the access they need to do their job presumably?

Things like this slowly eat away at your productivity.  One little innocent but unnecessary request at a time.  If you’re never going to deny an access request, then why have access requests at all?  Just open up the system and let the users in, or leverage single-sign-on to track who does use the resources.  But having the process step of requesting access just because it’s a corporate norm… silly (and wasteful).

A delightful discovery

Generally, I think it’s kind of silly to spend time patting yourself on the back about what you did.  Especially when there is so much more yet to be done, but I wanted to share an experience and an anecdotal measure of what a good process looks like.  (Apologies up front for the self-congratulating nature of this).

Almost 10 years ago, before I learned a thing about LEAN or Six Sigma, I worked for a large company.  When I was there, I put into place a very simple multi-stream waterfall process.  I didn’t know anything about LEAN, but I knew at the time that I didn’t want a burdensome process, just an effective one.  Books like Steve McConnell’s Rapid Development and my past experiences were my only guides.

I had no idea at the time if the process was a good one.  I had no idea when I left if the people who stayed would still use the process or abandon it the minute I was out the door.

Recently, I had the need to recreate something like that process I put in place 10 years ago.  You’ll find from my writing that I have not jumped on the Agile bandwagon.  Based on my own research, the work of individuals like Boehm and Turner in Balancing Agility and Discipline and a healthy amount of valid criticism from the Internet community, I’m convinced turning to a craft-like approach to software is not the answer.  Thus, my need for a simple multi-stream waterfall process…

So, I called up a friend who still worked at my former employer and asked for the old process documentation I had created.  I was convinced that they were no longer following it, so I should be getting back exactly what I had left them with.  To my surprise I was told that no they did not have what I wanted.  Not because they had promptly filed it in the trash, but because it had evolved!

They sent along a package of templates and flows which, while it strongly resembled what I had left, they had expanded upon and improved to meet changing situations.  The spirit of what I had created 10 years ago was still intact!

Two things are important about that experience.  One, I was with that company almost 5 years before I left.  That duration, the authors of LEAN Thinking point out, is about the amount of time needed to make a change permanent.  Had I left a year or two into the process change, it may have not survived.  For five years I pushed hard on my team for change, and I had left thinking that it was all for naught.  Not so!  The type of persistence that Womack and Jones write about paid off.

The other was that processes will continue to evolve.  On one hand, I was kind of hoping to get back exactly what I had left them with.  I was a little disappointed that I did not because selfishly, it was no longer quite mine.  But, after a moment of reflection, I realized that the fact that it was living and evolving was necessary to its survival as a viable process.  It also meant that team, many of whom are still there from when I was there, has taken ownership of it and made it their own.

It’s personally gratifying to see a process survive for so long and grow and change and be perfected but not abandoned for the latest fad.  But what’s more important, the team has been able to steadily improve by working from standard process and continuously, patiently modify it in little ways.  It’s heartening to know that Kaizen works.  We talk about it a lot, but how often do we get to look back 10 years and see its effects?

An interesting way to level demand

This evening, we went to a restaurant in Providence, RI called Fire and Ice. It is a form of restaurant that I’ve seen called a Mongolian BBQ. Essentially, you fill a bowl with an array of starches, vegetables, meat and sauce and hand it to a cook who places it on a large round flat-top grill.

What is really interesting about this is the way they handle the complications of all these different ingredients that need to cook at different speeds. Towards the outer edge of the grill it is cooler, and it is hotter towards the middle. As a result, when the cook takes your bowl, he lays out its contents in a line from the edge towards the middle, placing the meats closest to the center and the vegetables to the outside. If you have shrimp or fish, it goes somewhere halfway between the edge and center.

What’s more, you can also have a burger made on this grill, and though I didn’t watch closely, it is easy to imagine that if you want a rare burger you place it closer to the outside, and for more well done, place it towards the center of the grill.

In this fashion, the chefs slowly walk in a clockwise circle around the grill, giving the various columns of food a few tosses. In two or three trips round, your food is fully cooked and they simply take off each column of food in a simple first on, first off manner and deliver it to the waiting customer.

The solution is so elegantly simple. You get served in the order you came to the grill, so you never wait unusually long. The food cooks in uniform time, despite not needing uniform treatment. And the routine for the cooks is incredibly standard, despite the potentially millions of unique combinations that can be created.

What other solutions are out there to take dissimilar needs and devise ways to take the non-standard out? I think there is a lot to be learned from how this restaurant functions.

My convenience at your expense

Being involved in software quality means having a lot of conversations with quality assurance folks about the test process.  In a recent conversation, we were discussing the use of risk based testing.

The idea with risk based testing is to identify those items which are high risk/high value to the customer and test them first.  That way, you confirm that the most important functionality works before you move on to the less important stuff.  Doing risk based testing doesn’t necessarily mean you won’t test something, but if push comes to shove and something has to give, it’s the low value stuff that won’t get the attention.

At any rate, one of the activities that I often advocate for is auditing.  Auditing is completely non-value-added work, but it is necessary to assure that people do what is expected of them.  A grim reality as it may be, the cliche “you get what you inspect, not what you expect” holds true.

As I was discussing auditing for proof of risk based testing being applied, a particular tester pressed me on the topic saying “we can’t always do the high value cases first because sometimes we have to do a low value case in order to set up for what we really care about.”  Essentially, their point was that we should not expect people to test  according to the risk value because other overriding reasons would get in the way.

Of course, unhappy with that answer, I proposed, that you do a low value case followed by a high value case.  By setting up for one test and then doing the high value case, you will at least run some high value stuff as early as possible.

This didn’t seem to sit well, and as I prodded for more information, I figured out why.  In order to do the high value cases in this person’s example, we were setting up to run a batch job.  Thus, we did lots of low value cases so that we could batch a bunch of high value stuff together.

It was convenient for the tester, since it minimized task switching for them, but it was also decidedly batch-and-queue.  No one feature was really getting tested and instead we were doing a huge setup activity in order to batch process a bunch of stuff.

It’s not at all uncommon for software to run in batches (though I think we can apply LEAN principles not only to the software process but the software as well – do stuff real-time instead).  But, if you set up 50-100 tests and there’s something wrong with the configuration, it all becomes wasted effort.  A single test, run through the entire process, would quickly and cheaply uncover that something was amiss before you wasted your effort on the remaining 99 cases.

And, if you spend all that time doing setup only to fail everything, not only do you create massive rework for yourself, but you create late-breaking defects for development to fix.  All of these are undesirable, and all of them can be avoided.  That is, as long as you are willing to trade some of your own personal convenience for targeted, more immediate feedback on whether it’s even worth pursuing the remaining suite of tests.

Respect for People

John Hunter’s post at Curious Cat Management is a great reminder of what respect for people means.  Having respect for your employees, and the work they do, means being able to look someone in the eye and say “that didn’t work so well, did it?” and then to use that experience to help everyone to avoid making the same mistake.

In Agile software development, the manifesto refers to “People over Processes” but, at least in my opinion, I don’t believe that’s necessarily equal to “Respect for People.”  People are a critical part of the equation, but understanding that people are fallible, to respect that reality and use process to compensate for it is a better translation of Respect for People than “whatever the team wants to do is the right choice.” 

In fact, many Agile implementations, are among the most rigorous development methodologies of all.  However, many implementations are not, and in those cases “people over process” is translated as “to heck with the process.”  In one way, it shows enormous trust in your folks, by allowing them to use their best judgement.  In another way, it’s letting them pack their own parachute before jumping out of a plane.  How respectful is it to your folks to allow them to take a known bad path?

Too much choice

I just finished watching an old (2006) TED Talk on the Paradox of Choice.  This fascinating 20 minute presentation is on how the modern western society ideal of choice = freedom and freedom = welfare may be dead wrong.  In fact, he argues, too much choice leads to greater levels of dissatisfaction through:

  • Increased regret and anticipation of regret
  • Opportunity costs (feeling bad about missing out on what the alternatives offer)
  • Escalation of expectations (forcing us to believe that anything less than perfect will dissatisfy)
  • Self-blame (once you have a choice, then if you make the wrong choice it’s your fault)

Dr. Schwartz (no relation to me), provides some interesting real life examples to what choice costs us as a society.  For example, for every 10 additional funds you can invest in your 401(k), participation drops about 2%.  Yet we know that unless you invest and save for retirement, you’re going to be in deep trouble later.

There’s an opportunity here in process design to attack some of these issues head on.  Standard processes means less choice for the individuals in the process.  But counter to our ingrained cultural belief in the individual and individual choice, less choice may in fact make our employees happier and those who have to interact with us happier as well.  Doing things in a standard way may not just be good for consistent results, but it may be good for morale as well.

Get more exercise?

I don’t want to downplay the value of exercise, since we evolved far more active than most of our lives are today.  That said, the get more exercise advice, which I’ve heard hundreds of times before, suddenly struck me as a bit odd today.

Part of that stems from the fact that it’s the holidays.  As I’ve written before, I had lost a bit of weight before and am now trying to maintain my new, lower weight.  Well, with all the overindulging, I ended up about 3-4 pounds heavier than I usually am, so I’m working to correct that before it becomes a permanent problem.  That’s when it struck me that there was a LEAN lesson to be learned here.

For one, I acquired a lot of excess inventory recently.  I was taking in more food than I needed and my body had to store it somewhere.  So, in an effort to lose that weight, I can’t simply return to eating what I ate before I gained the weight.  If I do that, I basically consume enough calories to maintain my weight, whatever it is.  And it’s currently too high for my liking.  I need to ramp down on intake for a bit to use up my inventory, so to speak.

Exercise?  I don’t exercise.  That’s not to say I just sit at my computer all day, but I’m not going out of my way to get to the gym.  Why?  Using over-processing to handle inventory?  That just sounds insane to me.  The thing is, I don’t need that much food in the first place, so to take it in, and then run around just to burn off what I didn’t need in the first place???   Exercise deals with the symptom without ever addressing the root cause that I’m simply eating too much.

Yes, there are other benefits, such as heart health and so on, but from a purely weight perspective, eat less is more than enough, and you need far less food than you think you do.

It’s the same with your processes.  Don’t treat your problems by dealing with the symptoms, like inspecting for defects rather than preventing them in the first place.

Chronic loss vs. sporadic loss

Total Productive Maintenance is a piece of the LEAN arsenal designed to keep your machinery up and running.  As I was taught it, when a machine breaks down we notice it.  This is sporadic loss. 

However, when a machine is “quirky” and requires lots of little adjustments to keep running, has minor but annoying down time, can’t be run at full speed, etc. it’s chronic loss.  Ignored, chronic loss is something that simply becomes part of the background noise of manufacturing.  We just learn to live with the lack of availability in little bits and pieces.

Software can be very much the same way.  If you find yourself with a large support staff but you can’t put your finger on exactly what they’re doing, maybe it’s chronic loss.  Are you fielding the same phone call over and over and over?  Are you restarting a batch job every time it fails because you know if you just try it again that it’ll work?  These are the chronic losses of a software environment.

And these losses become all to easy to live with.  We measure our support folks in terms of first call resolution, which if you’re going to have an issue is nice, but we never talk about how not to receive the phone call in the first place.  Support people like to be employed, so where’s the impetus for them to make fixes permanent.  The entire job of support thrives on the failure of development to make a truly robust system that “just works.”

The clues that you put too much focus on sporadic loss are easy to see:

  1. You rate your production incidents by severity and then only discuss the Critical or High severity incidents.  The medium and low incidents, despite their quantity, get little to no attention.
  2. Any of your definitions of quality metrics (if you have them) puts additional focus on higher severity incidents.  Yes, a complete software outage for 10 minutes does affect all your customers, but what about that 30 second annoyance that happens to every customer several times a day.  Which one actually adds up to more time lost?
  3. Anyone has ever said “we have too many low severity incidents to classify them all.”  It’s likely these incidents are the same repeat offenders over and over again.
  4. You have an inordinately large support staff compared to the size of your development team.
  5. Your support staff has written scripts for how to deal with the issues they get calls for.  If it happens so often that you can write a script for it, you can fix the defect that causes it.
  6. You’ve ever closed a defect as “routine resolution.”  Defects should not be “routine.”

I think you get the idea.  Sporadic losses may be highly visible and painful, but chronic loss drags on your organization forever and builds upon itself over time.

LEAN is not common sense

One characterization that I’ve heard a few times about LEAN is that it is “common sense applied with discipline.”  However, the more I learn the less I like that definition.  Some things abut LEAN are quite counter intuitive, in fact.

Take, for example, single piece flow.  If that were so intuitive, why did so many factories evolve into batch-and-queue systems?  It seemed like, at the time, that switching over dies on presses and the like was slow, so it seemed to make sense to do big batches of stuff rather than figure out how to make switching over fast.  It was this problem that undid Henry Ford.  He figured out how to make one thing repetitively, but he couldn’t figure out how to offer variety.  Remember “you can have any color… as long as it’s black.”

Pull isn’t common sense either.  The idea that materials resource planning might not need to be done at all competes with our desire to predict the future.  We forecast demand and plan production because we struggle to consider that if we were able to respond in an instant that there’d never be any need for forecasting at all… we’d simply do what you asked exactly when you asked for it.

SMED… not intuitive.  The idea of shifting from internal time to external time, then minimizing internal time and finally external time doesn’t dawn on people.  It’s in our nature to shut off the machine first – it seems logical to shut it off if you are about to work on it, but that’s exactly the point.  The longer the machine can be up and running, the more time it can produce parts.  It needs to be down for as little time as possible.

If LEAN were just common sense, there’d be no people teaching it.  There’d be no lean.org, no blogs (like mine and many others).  I still have lots to learn, but one thing I have learned is that LEAN shows people how to look at things in a different way.  We have to start with, “this thing isn’t common sense.”  The use of “common sense” implies we already know what there is to know and we can simply get to it with discipline.  A deeper look is necessary.