Lean Archive


Value Stream for Business Travelers

TSAThe more I travel, the more I find myself observing how business travel (particularly flying) is a lot like application development. The flow of travelers (business value) are processed through a system much like ideas flow from inception to delivery.  When reviewing the processes of  the business traveler (delivery), I keep asking myself why the system has so much room for improvement and why we as participants within it don’t fix it.  I notice many travelers do few things that provide direct value (save time).  Rather, we do things that either provide little or no value but are necessary or are just wasteful.

As a business traveler,
I want to arrive to a destination as quickly as possible
without violating identified constraints.

Constraints: Quality and Cost 

Quality (safety thresholds):

We want to make sure that some knucklehead does not get on a plane and do something destructive.  Rather than quality, the FAA calls this security.  In the end, the underwear bomber who unsuccessfully detonated his skivvies mid-flight is like discovering a severity one bug in Production.  It would have been a lot cheaper, if this guy was stopped at a security checkpoint and prevented from getting on the plane in the first place.  As a result, I have Bubba the TSA Agent measuring me for a pair of pants every time I opt out the body scan. Do these theatrics actually increase quality?  I’m not sure. But I digress. [TSA Removing Body Scanners?]

We want to ensure planes don’t fall out of the sky, due to mechanical issues.  In an attempt to ensure we don’t go below this quality threshold, the FAA requires airlines to conduct regularly scheduled maintenance on aircraft.  As stakeholders, both the airlines and passengers see maintenance translate as on-time departures.  As this relates to application development, customers don’t always think (or care) about code refactoring, fixing bugs, or paying down technical debt.  Still, if they don’t want the system to crash or have a delayed launch, this out-of-site process has to take place on a regular basis.

Cost (budget thresholds):

As a business traveler, I expect my costs to fluctuate, based on quality and the speed in which I move through the system.  If I want to move through parts of the system faster, I can pay more.  In the end, local optimization just makes the process seem less painful.  It is, until you get to the next step or stage of the process.

The overall system:

  1. I arrive at the airport (park in the Daily garage) [every 15 minutes a shuttle arrives]
  2. I stand in line at the security (TSA) checkpoint.   [1-30 minutes]
  3. I am given the choice of x-ray or full body scan [pay more for express search] [1-20 minutes]
  4. I opt out? [doesn’t necessarily increase quality] [5-10 minutes]
  5. I arrive at gate and
  6. Board flight by “zone”  1st Class, Zone 1, 2, 3 [0-20 minutes]
  7. Fly to destination [varies]
  8. Land at destination and disembark the aircraft [5-15 minutes]

Though you can have several local optimums within the system, like any process we need to look at optimizing the system as a whole.

Look for bottlenecks and address them.  If there is a lead time between the start of one of the eight processes listed above and its execution (completion), there is a bottleneck.   A lead time is the latency (delay) between the initiation and execution of a process. For example, the lead time between getting into the security (TSA) checkpoint line (process step 2) may be anywhere from 1 to 30 minutes. In industry, lead time reduction is an important part of lean manufacturing.  In application development, it allows us to shorten our iterations or feedback loops.  In travel, it allows us to get on with our lives with less impact to events happening outside the system.

One way I’ve seen people shorten the lead time at this process step is to just be ready.   Sounds obvious but you would be surprised.  There are signs and videos leading up to the security area.  TSA instructs you to have your boarding pass and photo identification ready.  They inform you what is allowed and what is not allowed (step 3).  I’ve seen countless travelers wait until they are at the podium before digging through purse or pocket, only to have a minor panic attack because they can’t find a drivers license.

I’ve seen the same thing with application development.  Teams don’t have their work ready and then there are delays in getting it done.



Agile on Non-Software Projects

Joe Justice and Derek Huether at Agile 2012Regardless of where I coach or teach, there is always someone who approaches me and says something like, “Agile is great for software projects but what about projects that aren’t software related?”  When asked the question, I usually give examples like a U.S. Marine fire team or air crew or a home construction site. (I’ll save those stories for another time).  I now have a new story to tell about a cross-functional, highly collaborative team, which competed for the Progressive Insurance Automotive X Prize.

While I was at Agile 2012, I met Joe Justice of Team WIKISPEED and had a chance to actually touch a car that was designed and built using Agile methods. (see cool photo enclosed)

Here is some back story from a 2011 press release:   Based in Seattle and led by Joe Justice, WIKISPEED is a collaborative team of over 50 experts and volunteers dedicated to offering ultra-efficient, ultra low-cost, mass-production road-legal vehicles. In 2010 the team’s SGT01 prototype placed in the top 10 in their class out of 136 cars overall in the Progressive Insurance Automotive X Prize.

Joe was able to build his first functional prototype in just three months.  The car that competed in the X Prize got 114 MPG (Highway). Compare that to the Toyota Prius which currently gets 51 MPG (Highway) and was introduced in 1995.  The reason auto manufacturers are so slow to “better” their products is because change is very expensive for them.  It is not uncommon for auto manufacturers to operate on 10 to 25 year development cycles.  Before Object-oriented programming methods were introduced, software teams used to operate much the same way.

By modularizing how we build software, we’re able to shorten our development cycles down to days.  By shortening our development cycles down to days, we give ourselves the opportunity to get feedback from our customers and create things that they really want, not things that we think they want.  We save ourselves and our organizations countless dollars in wasted development, due to waiting too long to get feedback from our customers or by operating in functional silos.  My breaking our teams down into small, cross-functional, empowered teams, we shorted feedback cycles as much as we can.

Being Joe is a client facing software consultant, building Agile teams and practices, why would he limit the benefits of Agile to just his customers?  Joe and his team have a car that has a development cycle of seven days.  They do this by modularizing the car.  They can switch the gasoline engine to an electric one in about the same time it takes to change a tire. They could change the car body from a convertible to a pickup truck.  All of this allows them to make changes and develop quickly.

The car is safe (passes road safety standards), because Team WIKISPEED developed safety tests before building the actual parts.  This helps them lower waste (Lean).  Next time you say you can’t afford to do test-driven development, think about that.  They do all of their work in pairs, avoiding time training that is not productive. (XP Practices) Again, the next time you say you cannot afford to pair people, think about that.  Pairing also helps lower the need for most types of documentation.  If everyone has a shared understanding, you have less need for it.  They visualize their workflow to help identify hidden delays and deliver something every seven days (Scrum).

So, do you still think Agile is only for software projects?  The fact that they use 7 days sprints on hardware, when I hear people say they can’t do anything less than 30-days on software, just goes to show you where there is the will there is a way.

Check out Joe’s session from TEDxRainier

Post originally appeared at LeadingAgile

Tags: , , , ,

Coke Freestyle VMS

My family and I went into a California Tortilla the other night to grab a quick dinner. Off to the side I notice a long line of people waiting to fill their soda cups.  It used to be, when you went out for fast food, the people behind the counter would ask you what you wanted and they would hand it to you.  Now, at this location, it appeared it could take as long to get our drinks (in a separate line) as it would to get our food.  Though I appreciate this California Tortilla location wanting to empower the consumer by giving us 100+ choices of our favorite mixture of soda-pop, most people in line appeared paralyzed by the amount of combinations and permutations.  When I went into a different California Tortilla, I noticed an old-school fountain machine.  There was no line and I saw two people filling their soda cups at the same time.  It made me question the value the additional choices offered, especially when all I want is water.

So, I guess my question is, should there be fewer options or a better feedback tool for consumers to respond to?  When doing a little research on this post, I found a poster of a freestyle “menu” at Taco Mac.  I believe the use of this VMS (Visual Management System) could keep the lines short at the California Tortilla location.  But, I don’t know.  Are there shorter (or no) lines at the Atlanta Taco Macs?  To shorten the lines at California Tortilla, I would propose they get the menus and hang a poster near the machine.  I think people would be more apt to decide what they wanted before they stand in front of this machine with 100+ choice presented to them.  I think it would cut down on people browsing the menu, while there is a line behind them.  My goal?  I want the cut down lead time and cycle time as much as possible.  Not sure what those are?  I found a great definition by Corey Ladas.

Lead time clock starts when the request is made and ends at delivery. Cycle time clock starts when work begins on the request and ends when the item is ready for delivery. Cycle time is a more mechanical measure of process capability. Lead time is what the customer sees.

Lead time depends on cycle time, but also depends on your willingness to keep a backlog, the customer’s patience, and the customer’s readiness for delivery.

Another way to think about it is: cycle time measures the completion rate, lead time measures the arrival rate. A producer has limited strategies to influence lead time. One is pricing (managing the arrival rate), another is managing cycle time (completing work faster/slower than the arrival rate).

I know you usually don’t think of Agile or Lean when talking about fish tacos, burritos and soda-pop, but I had to get this off my chest.


Looking for Lean in Inefficient Processes

first-class forever stampThis morning, I wrote a physical check and placed it into a physical envelope. I hand-wrote the addresses on the envelope and even put a physical stamp on it.  I will mail it, when I take my semiweekly trip to the mailbox.  This is the first time I can remember doing this in a few years.  The party recieving my payment is forcing me to follow this inefficient business process of mailing a physical payment to them.  All I can think is how this used to be the norm and now how ridiculously inefficient it appears.

When objectively judging the efficiency of this process, I started by first measuring two things, the Work-in-Process (WIP) and the Average Completion Rate (ACR).

Little’s Law

This law provides an equation for relating Lead Time, Work-in-Process (WIP) and Average Completion Rate (ACR) to any process. The law states: Lead Time = WIP (units) / ACR (units per time period).  The idea is to have the lowest lead time as possible.  Lower lead times means less waste.

Am I the only geek out there who does this?  Where do you see inefficient processes that could benefit from a more lean approach?



Tags: , , ,

The Gemba Walk

As part of a recent engagement I went to assess and coach a group of Agile teams out in Iowa.  Each morning, we would arrive before the daily stand-ups.  Each morning we walked around, listened in on conversations and got updates from the teams.  We quietly studied their large team boards and then how they interacted with the boards and one another. I would describe this daily stroll as our Gemba Walk.  Gemba is a Japanese term meaning “the real place.” In business, it refers to the place where value is created; in our case the gemba was the west side of the building on the 5th floor where the teams were located.

Gemba Walk

In lean manufacturing, the idea of gemba is that the problems are visible, and the best improvement ideas will come from going to the gemba. The gemba walk, much like Management By Walking Around (MBWA), is an activity that takes management to those doing the actual value delivery, to look for waste and opportunities to practice gemba kaizen, or practical shopfloor improvement.  If you are in management and you want to make a real difference, get out of your office and go on a gemba walk.

If you are on a project team, do your managers go on a daily gemba walk?

HT: Wikipedia