Lean Archive


Lean Business Report Presented by LeanKit

Lean Business Report
You’ve heard of the State of Agile survey?

Welcome to the Lean Business Report Survey!

I would describe myself as a whole lot of things, including a Lean Practitioner.  I was forwarded this survey and thought I would give it a go.  It only took me about 10 minutes and it felt great that I was able to contribute.

Why not help out?  Get started here >> Lean Business Report Survey

In the survey, you’ll be asked to share your experiences in learning, adopting or practicing Lean. LeanKit will compile and share the results in early 2016. Together, we’ll gain a deeper understanding of how Lean works for business.

If you provide your email address, you’ll receive an early copy of the Lean Business Report and also be entered to win one of five $500 Amazon gift cards.
Here are some quick facts to know before you begin:

  • The survey will take approximately 11 minutes.

  • Only questions marked with an asterisk (*) are required.

  • Your responses are completely anonymous.
Thank you again for your input!

How to Use an A3 Report

What is an A3

An A3 is more than an 11 x 17 inch piece of paper that is structured into several sections and not all A3’s are created equal. An A3 is a structured problem solving and continuous improvement approach, first employed at Toyota and typically used by Lean manufacturing practitioners. What your A3 looks like depends upon the situation. The example below consists of the following pattern, as part of an Agile Transformation:

  1. Current Situation & Problem
  2. Root Cause Analysis / Conclusion
  3. Goal
  4. Corrective Action

After we agree on the four steps, we’re going to implement the correction action and then verify the results. The content of an A3 follows the logic of the Plan-Do-Study-Act (PDSA) cycle.  What I want you to take away from this blog post is not so much TQM, PDSA, and A3’s, as much as how you could benefit from them when doing an Agile transformation or any kind of process improvement.

A3 Report Example

When doing an Agile Transformation, I’m going to always cycle back to 3 core goals.

  1. Form complete cross functional teams
  2. Build backlogs
  3. Deliver working tested software

Anything that gets in the way of doing these is an impediment that has to be removed.  The example I have above describes how a team is under-committing each sprint.  We’re using a story point completion ratio to know if the team is delivering working tested software. We’re going to use this single page to have a shared understanding with our client and agree on a course of action.  Now, I’m not saying you have to use this template. If you can remove an impediment informally, by all means, do it!  But, to make sure my client agrees there is a problem that needs to be prioritized and addressed, this is an effective tool and it’s pretty lightweight.  You may also notice I don’t call this an A3 on the actual example.  I’m going to call it an Action Report so my client feels comfortable with common language and I don’t need to distract them by introducing Lean terminology.  When I say “A3”, there are certain expectations.  Let’s not get hung up on that and just call it an Action Report going forward.

Flow of the Action Report

You’ll notice that I structured my Action Report so that your eyes will be drawn to sections. I want to compare 1 and 3 (Current Conditions and Goals) and 2 and 4 (Root Cause Analysis/Conclusion and Corrective Action).  This allows a transformation consultant to note impediments and identify root causes independently but then be prepared to collaborate with the client on goals and corrective actions.  I’m going to stress this again.  We’re only going to go through this process if the consultant can’t resolve the issue informally.  If not, he or she will need to collaborate with the client to confirm the goal and agree on an appropriate action. The consultant doesn’t do all of this in a vacuum.  When looking at action (or A3) reports used by others, I’ve seen them identify the goal prior to looking for root cause. From my experience, if I’m required to identify the goal before moving forward, this may create an unnecessary delay.  If I don’t think something is right, I’m going to start investigating right away and then circle back with the client to validate their goal. But, I’m not going to stop and wait to be told what their goal is before beginning to look for root cause. I don’t want to stop until my personal curiosity is satisfied. Also, I’m not saying to not collaborate with the customer. I’m saying keep moving forward on multiple fronts and to circle back at the first logical opportunity.

Current Conditions

We have several opportunities during the transformation to get this information.  It could be, we just completed a formal assessment of the team or organization.  Maybe we just reviewed metrics of the team or organization.  Maybe I just walked out of a really long and unproductive meeting. Whatever we did, I’m looking for some kind of objective criteria or indicator to describe the condition.

Root Cause Analysis / Conclusion

In order to propose appropriate corrective actions, we need to identify the root cause of the condition. Avoid using logical fallacies like anecdotal, appeal to emotion, or false cause. I like to use Socratic method or ask the 5 whys to help reach the root cause.


The goal listed above in the illustration focuses on getting a team’s story point completion ratio to 100% +/- 10%. This goal is pointing back to building backlogs and delivering working tested software.  By getting the teams to keep their commitments of delivering working tested software regularly, we allow the business to make better commitments to their customers. If we can build that trust and safety within our organizations, we’ll start to build balanced systems.

Corrective Actions

Identify corrective actions that is both short term and easy to implement. If the actions are neither, I keep a higher level corrective action around and then break it down so I can incrementally work toward the goal.  Personally, I keep my daily activities on a Kanban board. For an overall transformation, I keep the actions and activities in a rolling 90-day plan.  This keeps the client informed on what value I’ve delivered and what value I plan to deliver in the coming weeks/months.

Plan Do Study Act in an Agile Transformation

When doing an Agile Transformation, PDSA is just one pattern to map the approach.  Not mentioned in this blog post are the original inputs into the initial coaching plan and 90-day plan. (both of which are collaboratively defined and continuously evolved with the client). But, how do I fit it all together in a high level “plan do study act” process, more emblematic of the original A3 process? I use the following:

  1. Coaching Plan (Plan)
  2. Rolling 90-Day Plan (Do)
  3. Adoption Assessment (Study)
  4. Metrics (Study)
  5. Action Report (Act)

Inputs and Outputs of an A3 Report


I hope this provides some insights into how you can take some of the hand waving out of your next (or current) Agile transformation.  There are a lot of moving parts and you need the process and tools to keep an eye on your goals and manage progress, without adding so much overhead that you stifle the forward momentum.  Let me know if you have questions!

Download a free copy of the A3 Report Template


Tags: , ,

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.