A trip to Wendy’s

If you’ve read my personal blog prior to me starting this one, you know that I enjoy frequenting fast food places.  It’s not because I particularly love fast food (I don’t mind it), but because I enjoy watching people work there.  They’re great places to observe lean (not) in action.

As many days go, I pop out for lunch right around noon, pretty much assured to hit the lunch rush.  It is really no fun to watch a fast food joint off hours – there isn’t enough volume to really get a sense of what’s going on.

The first thing I observe about this particular Wendy’s is the horrible traffic flow they’ve created.  Due to the placement of the entry and the drive-through, drive-through traffic blocks the entry to the rest of the parking lot.  Therefore, some number of people sitting in the drive-through line really want to get a parking space and go inside.

Once I was inside, the line was long.  This isn’t particularly unusual at this Wendy’s, but  I wasn’t really sure what was going on until today.  On this particular day I noted that a Wendy’s employee was standing in the line with the customers.  She had in her hand a pen and a pad of paper which she was using to take the customer’s orders before they got up to the register.  Presumably the thinking was “if we get all the orders taken then it’ll go much faster when they get up to the register.”

I’m sure you recognize this as obvious batch-and-queue.  They were taking all the orders, then going to enter the orders, then fill the orders, etc.  As an aside, Wendy’s is apparently quite prepared to use this tactic, as the pad of paper was actually a extremely complicated (and useless) design.  I was so amused, I took a picture of it with my cell phone camera.

It’s hard to tell from the picture, but the paper has all kinds of sections for filling out your french fry order, your drink order, and a whole section of codes for specifying the burger or chicken sandwich you want.  Of course, the employee used none of these sections.  She just wrote my order in pen at the top, right over one of the sections.  Clearly this was not a brilliantly designed tool.

After taking the order of the 5-7 people in front of me, my order, and maybe one or two after me, the woman returned to behind the counter to help fill orders.  In a funny twist, when it came to my turn, I handed her the same paper that she had handed me and she keyed in my order.  After taking my money, I then proceeded to stand in the crowd of people who now had “efficiently” had their order taken and keyed in but didn’t have any food to show for it.

My food eventually showed up, in my estimation no faster than if I had just stood in line without all this added paperwork, and I sat down to eat my lunch.  While eating I overheard the employee who did all this pre-ordering nonsense say to another “see how much faster the line went when you do the paper?”

I shook my head in disbelief and almost went up to say something to the manager about how silly they were.  Here’s what I observed to be the real issues:

  1.  The perception that paper was faster was really the woman returning back to the value add part of the store.  By being behind the counter she effectively added another person to the factory and made it go faster.  It would have been faster with or without the paper orders by virtue of putting another body on it.
  2. There’s an enormous amount of motion waste going on.  The Wendy’s kitchen is U-Shaped, and so if you need something from the other side of the kitchen (which you shouldn’t, but I watched them do it) you have a very long walk to get it.  The order in which a burger (or other sandwich) is assembled is crazy.  Instead of simply reaching from left to right one bin at a time for lettuce, tomato, pickles, etc. you have to move your hands all over this series of arbitrarily ordered bins.  No thought to the efficiency of motion exists at all.
  3. Because of the shape of the kitchen, people are constantly passing each other essentially on collision courses.  The kitchen isn’t organized to minimize collisions as people run around trying to assemble an order.
  4. There’s massive amounts of inventory cluttering things up.  Piles of buns falling out of their inconvenient storage location, stacks of papers (for wrapping burgers) piled up and so on.

I’ll grant them that they’re trying for a team effort to get things done, but I’d say thus far Wendy’s is my poster child for poorly flowing goods when it comes to the fast food business.  I’ll still go back – both because I like their chicken nuggets better than McDonald’s and I’m kind of tempted to draw them a spaghetti chart and a short list of recommendations.

Why have release cycles?

One thing that continues to fascinate me about software is the adherence to release cycles.  In many large companies, a given day of the week or month is dedicated to be “install day”, often a white-knuckle ride as everyone who has a change to make loads it into production.  Though the actual install event may or may not add risk to production, all change does.  So, why would you want to take all your risky activities, bundle them up and do them all on one day?

Think of it as something of a backward version of demand-shaping.  Instead of rolling out features at a steady pace, we flood the market with features once a week or month.

Perhaps, at one time, this made sense.  If you had to roll out fat clients to your customers, they surely didn’t want a new install every day for the next feature, did they?  But then again, even today, you can often wait several releases before upgrading your system to the latest offering from the vendor.  I, for instance, for no particularly good reason, have been putting off an update to Adobe Acrobat and I finally did it this morning.  I was probably at least two to three point releases behind, but it was working fine for me so why rush to upgrade.

The barriers which once made release cycles sensible are disappearing and yet we cling to them.  Why?  From a LEAN perspective, it interrupts flow and was never a good idea.  Now, with more web-driven computing going on, there’s even less reason to interrupt the flow of goods by batching them up into releases.

Importantly, there’s nothing inherent about the properties of code that make waiting necessary.  Code isn’t like concrete, you don’t have to wait for it to naturally cure, so why do we stuff code into user acceptance environments for a month thinking something magical is going to happen?  I’m arguing, assuming all dependencies are in place, that when a feature is completed it should go to production.  Instantly!  Right then and there.

Change would come at a smoother pace.  Risk would be distributed over time, allowing your support teams to have a more level workload – no white knuckle rides.  Customer value would be realized not on a monthly cycle or even a two week sprint, but as close to real time as possible.

Batching stuff up to move it to production is an outdated way of thinking just as it is in manufacturing.