Understanding A3 Thinking: A Critical Component of Toyota's PDCA Management System

Managing to Learn: Using the A3 Management Process 
By John Shook
Understanding A3 Thinking: A
Critical Component of Toyota’s
PDCA Management System
1
© 1993-2015 Jeff Sutherland & Scrum Inc.
Who We Are
Scrum Inc. is the Agile leadership company of Dr. Jeff Sutherland, co-creator of Scrum.
We are based at the MIT Cambridge Innovation Center, MA.
CEO Jeff Sutherland helps companies achieve the full benefits of Scrum leading our
comprehensive suite of support services and leadership training:
• Scaling the methodology to an ever-expanding set of industries, processes and business
challenges Training (Scrum Master, Product Owner, Agile Leadership, online courses, etc.)
• Consulting (linking Scrum and business strategy, customizing Scrum)
• Coaching (hands-on support to Scrum teams)
Chief Content Officer JJ Sutherland maintains the Scrum framework by:

• Capturing and codifying evolving best practices (Scrum Guide)
• Conducting original research on organizational behavior
• Publishing (3 books) and productizing ScrumLab
President Scrum@Hardware Joe Justice leads our hardware consulting practice:

• Worldwide consulting at leading hardware companies
• 700-800% performance improvement in hardware development
• Builds 100 mpg cars in his garage with help from 500 people in 32 countries
We run our company using Scrum as the primary management framework, making us a living
laboratory on the cutting edge of “Enterprise Scrum”
Find out more at www.scruminc.com.
2
Joel Riddle - Scrum Master, Scrum Inc.
Joel is a Transformational Coach for Scrum Inc. and
specializes in researching and codifying cutting edge Agile
practices for Scrum and Scrum in Hardware.
Joel’s background is in journalism. He cut his teeth at

National Public Radio where he was responsible for the live,
on-air production of NPR’s flagship show, Morning Edition.
Joel also spent three tours in Baghdad as NPR’s bureau
chief.
3
Nigel Thurlow - Scrum Coach, Scrum Inc.
Nigel is a Lean and Agile Coach for Scrum Inc. A Continuous
Improvement Leader, Quality Advocate, and ex member of
“The Machine That Changed the World”.
Nigel’s background is in grass roots IT solution delivery

across networking & telecoms, infrastructure, and software
development. He is a member of the Toyota Alumni, and
specializes in systems thinking and the use of problem
solving tools.
4
The A3 - It’s just a paper size!
5
Toyota Business Practices (TBP)
6
The A3 Changes Behavior
• An A3 forces you to filter and refine your thoughts.
• The document evolves along the way with the

process of learning.
• The process is more important than the A3 itself.
• An A3 is an approach for teaching systematic and

scientific habits of thinking and working.
• The A3 approach is also a method for building

consensus (Nemawashi)
7
The A3 – Telling a story on a single page
• Guide the reader through the story using ABCs or 123s or Arrows etc
• Each step is a logical progression from the last.
• Ensure all facts are on the page. Remember use visuals or draw a picture.
• If you find yourself verbally embellishing to enable understanding, the A3 is incomplete.
8
Various A3 Story Types
Problem Solving A3
9
Story Telling Tips
* “If you can’t explain it simply, you don’t understand it well enough.” -Einstein
“If you can’t describe what you are doing as a process, you don’t know what you are doing.” -Deming
10
The Symbols of Toyota
Numbers create debate about what is a 2 or 3 etc. Symbols avoid this debate.
More IMPACT Great in B&W All Languages
Ideal for Color Blindness Universal for Status or Evaluation. 11

Genchi Genbutsu (Go See)
Avoid Hearsay Avoid Email
12
Nemawashi - Toyota’s Secret Sauce
It’s an advance Scrum technique we like to call “Just Talk” 13

The Process
Illustration based on Mike Rother’s Toyota Kata

Winner of the 2013 Shingo Prize for Operational Excellence
14
PDCA and Scrum
15
A Typical Toyota A3 Layout
16
Background - Setting Context
17
Clarify the Problem - Identify the Gap
18
Using Bad Problem Statements
Don’t state solutions in the problem statement
• Bad – We need a new furnace because it doesn’t stay warm.
• Good – The temperature is 20 degrees below specification.
Don’t create too large a problem

• Bad – The quoting process takes too long.
• Good – The spare part quoting process takes 5 business
days.
Don’t use vague problem statements

• Bad – Customers don’t like the product.
• Good – Customers returns of product X are 35%.
19
Great Example
20
Quantifying your Problem
• Ask yourself how can I measure the problem in terms of
reference relevant to my business or stakeholders?
• What is the size of the problem, and how does this differ from
the expected or accepted standard?
• Think of the $$, or the number of X, and the value of Y.
• Number of defects, number of helpdesk calls, delays, missed
deliveries, failed API calls, dropped connections, failed requests,
timeouts, throughput, CPU/Disk/RAM utilization etc.
If you can’t measure the problem, how will you measure your improvement?
21
The Great Wastes of Taiichi Ōno
Ohno-san considered this the greatest waste.
This was added later by Lean practitioners.
DOWNTIME is a great way to remember the wastes (MUDA)

22
Point of Cause vs Root Cause
23
Breaking Down the Problem
24
Breaking Down the Problem - What
• What happened?
• What was being done when it happened?
• What was being used?
• What processes were running?
• What equipment was involved (hardware/
network/comms)?
• What code was being run?
• What services were running?
• What APIs are being called?
• What Database are being accessed?
• What is the quantity or volume or size (lbs, GBs,
MIPs, Requests)? etc
25
Breaking Down the Problem - Where
• Where (location) did it occur?
e.g. server room, cloud, geography, building etc
• Where (process) did it occur? – draw the process.
• Where (network) did it occur? – draw a network diagram
• Consider tools such as Value Stream Mapping.
Typical Value Stream Map

26
Breaking Down the Problem - Who
• Who is involved? Customer, supplier, user, developer, etc
• Who is impacted?
• Who did what?
• Who does what?
• Who uses the application or device?
• Who reported the issue?
• Who is responsible or accountable?
• Who was notified?
• Who gave directions or instructions?
27
Breaking Down the Problem - When
• When (time) did it occur?
• When in the process? – e.g. when a function call to an API
occurred?
• The time a process took to execute?
• The time a delivery took?
• The time taken to transfer files?
• The day of the week?
• The time of day?
• The precise minute or second?
• Maybe things are different from day to day or hour to hour?
28
How about How?
• I heard about the 4Ws and the 1H. Why don’t you
use that approach?
• The Toyota process does not need the HOW.
• The HOW can be answered by the 4 Ws.
• HOWever, there is nothing wrong with using it.
• The important thing is to Break Down the Problem

effectively!
29
Our Painful Foot Problem
30
Breaking Down the Problem Example
31
Setting a Target
If you don’t set a target how will you measure your success?
32
Root Cause Analysis
• You are now ready for Root Cause Analysis, but only if you've
completed all the other steps!
• Jumping to Root Causes is the same as jumping to conclusions.

Invariably you'll get it wrong as you are not in possession of all
the facts!
33
The 5 Whys?
34
Testing Why Analysis with Therefore
35
Root Cause Analysis Example
36
Knowing when to stop?
• Remember our broken glass problem?
• Knowing when you’re beat, even if you’re right!
• Knowing when you’re at the limit of your capabilities.
• We Break Down Problems & Prioritize using the 80/20

Rule so we address the right causes.
37
Countermeasures vs Solutions
• Toyota calls improvements countermeasures (rather than the
ubiquitous “solutions”) because it implies
• a) We are countering a specific problem we have identified.

• b) It is what we will use now until we discover an even better
countermeasure through Kaizen!
• PDCA is ongoing and never ends. Continuous Improvement!

• We never have a final solution as we can always improve.
• Final is static thinking.
• Therefore, we apply countermeasures based on what we know
now, and then look for the next Kaizen (improvement).
38
Defining Countermeasures
39
Define your Plan & Method
e n
a iz
K
40
Monitor and Review
• What were your actual results vs expected results?
• What did you expect to see vs what you actually saw?
41
Other Steps on the A3
Yokoten
Share across the organization and Kaizen
42
The A3 - It’s A Living Document
43
The Complete Example
44
Hansei (Self Reflection)
The ability to acknowledge your own

mistakes and to pledge improvement.
45
Questions?
46
Stay Connected
Scruminc.com
• For up coming events, new content releases, and more!
ScrumLab
• articles, online courses, tools, and papers on all things
scrum
• www.scruminc.com/scrumlab
Blog
• http://www.scruminc.com/category/blog/
Online Courses
• advance your scrum with our online courses. Visit the
Scrumlab store to view upcoming topics.
Twitter, Facebook, and G+

• @ScrumInc, @jeffsutherland, scrum and scrum inc.
47

Understanding A3 Thinking: A Critical Component of Toyota's PDCA Management System

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Understanding A3 Thinking: A Critical Component of Toyota's PDCA Management System

Uploaded by

Copyright:

Available Formats

Managing to Learn: Using the A3 Management Process

Chief Content Officer JJ Sutherland maintains the Scrum framework by:

President Scrum@Hardware Joe Justice leads our hardware consulting practice:

Joel’s background is in journalism. He cut his teeth at

Nigel’s background is in grass roots IT solution delivery

• An A3 forces you to filter and refine your thoughts.

• The document evolves along the way with the

• The process is more important than the A3 itself.

• An A3 is an approach for teaching systematic and

• The A3 approach is also a method for building

More IMPACT Great in B&W All Languages

Ideal for Color Blindness Universal for Status or Evaluation. 11

Avoid Hearsay Avoid Email

It’s an advance Scrum technique we like to call “Just Talk” 13

Illustration based on Mike Rother’s Toyota Kata

Don’t create too large a problem

Don’t use vague problem statements

Ohno-san considered this the greatest waste.

This was added later by Lean practitioners.

DOWNTIME is a great way to remember the wastes (MUDA)

Typical Value Stream Map

• The Toyota process does not need the HOW.

• The HOW can be answered by the 4 Ws.

• HOWever, there is nothing wrong with using it.

• The important thing is to Break Down the Problem

• Jumping to Root Causes is the same as jumping to conclusions.

• Knowing when you’re beat, even if you’re right!

• Knowing when you’re at the limit of your capabilities.

• We Break Down Problems & Prioritize using the 80/20

• a) We are countering a specific problem we have identified.

• PDCA is ongoing and never ends. Continuous Improvement!

• What were your actual results vs expected results?

• What did you expect to see vs what you actually saw?

Share across the organization and Kaizen

The ability to acknowledge your own

Twitter, Facebook, and G+

You might also like

Managing to Learn: Using the A3 Management Process 