Project Management

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.

Goals

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

Summary

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

 

Agile 2015 Twitter Feed

Looking for the play by play from Agile 2015? Check out the feed below

Cost of Delay is Important

A few days ago, I published an introduction to Cost of Delay over on the LeadingAgile blog. I asked some of my colleagues to check my numbers because the one thing I've noticed, people can be pretty unforgiving with spelling and math errors. The interest and response from both my colleagues and readers has been really positive. What I demonstrated in the blog post is, surprisingly, doing the most valuable feature first in your portfolio backlog is not always the best economic decision. Next time you prioritize your portfolio, do not just try to maximize value delivered. Limit your cost of delay. - See more at: http://www.leadingagile.com/2015/06/an-introduction-to-cost-of-delay/#sthash.ODrAFTyO.dpuf

Agile Baltimore Unconference

agile-baltimore-logo-21Click here to register for just $29!

Agile Baltimore Unconference

Monday, October 12, 2015 8:00 AM - 5:00 PM ETC Incubator 101 N Haven St Baltimore, Maryland 21224 United States Map and Directions

Join us for the first annual unconference with Agile Baltimore Group as local Lean/Agile practitioners, technologists, entrepreneurs and advocates come together for a day of idea sharing, networking, and collaboration. The conference will be organized with a modified open space format to allow for meaningful conversations to take place throughout the day. As part of your registration, free breakfast, lunch, and beverages will be provided.

What is the goal?

What is the goal?

I seem to lead with that question a lot these days. Is the goal to practice Scrum? Is the goal to apply SAFe? Is the goal to use some other Agile delivery framework? Is the goal to uphold the values and principles of the Agile Manifesto?

They are all means to an end. Your goal depends on your organization. Fundamentally, every for-profit organization I've come in contact with has pretty much the same primary goal. Make money!

Before committing budget for that next project, let's first ask ourselves if we know our core business drivers.

Common Business Drivers

  • Predictability
  • Higher Quality
  • Shorter time to market
  • Lower Costs

But let's look at this again. What is the primary goal? Make money!

How do we achieve the goal?

  • Through predictability, we get better at forecasting sales and delivery (lead times)
  • Through higher quality, we lower costs of rework and increase customer satisfaction
  • With shorter time to market, we can get an earlier ROI and increase cash flow
  • With lower costs, we free up capital for other areas of our organization

Answer these questions:

  1. What is your primary organizational goal?
  2. What are your core business drivers, relative to your primary organizational goal?
  3. If you don't know the goal, how do you know where to spend your time or money?
  4. How do you know where to start?