understanding a3 thinking: a critical component of · pdf fileunderstanding a3 thinking: a...

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

Managing to Learn: Using the A3 Management ProcessBy John Shook

Who We AreScrum Inc. is the Agile leadership company of Dr. Jeff Sutherland, co-creator of Scrum. We are based at the MIT Cambridge Innovation Center, MA.

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

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)

Find out more at www.scruminc.com.

We run our company using Scrum as the primary management framework, making us a living laboratory on the cutting edge of “Enterprise Scrum”

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

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.

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.

The A3 - It’s just a paper size!

Toyota Business Practices (TBP)

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)

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.

Various A3 Story Types

Problem Solving A3

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

The Symbols of Toyota

More IMPACT Great in B&W All Languages

Numbers create debate about what is a 2 or 3 etc. Symbols avoid this debate.

Ideal for Color Blindness Universal for Status or Evaluation.

Genchi Genbutsu (Go See)

Avoid Hearsay Avoid Email

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

PDCA and Scrum

A Typical Toyota A3 Layout

Background - Setting Context

Clarify the Problem - Identify the Gap

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%.

Great Example

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?

The Great Wastes of Taiichi Ōno

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

This was added later by Lean practitioners.

Ohno-san considered this the greatest waste.

Point of Cause vs Root Cause

Breaking Down the Problem

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

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

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?

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?

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!

Our Painful Foot Problem

Breaking Down the Problem Example

Setting a Target

If you don’t set a target how will you measure your success?

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!

The 5 Whys?

Testing Why Analysis with Therefore

Root Cause Analysis Example

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.

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).

Defining Countermeasures

Define your Plan & Method

Kaizen

Monitor and Review

• What were your actual results vs expected results?

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

Other Steps on the A3

Yokoten

Share across the organization and Kaizen

The A3 - It’s A Living Document

The Complete Example

Hansei (Self Reflection)

The ability to acknowledge your own mistakes and to pledge improvement.

Questions?

Stay Connected

Scruminc.com

• For up coming events, new content releases, and more!

ScrumLab • articles, online courses, tools, and papers on all things

• 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.

understanding a3 thinking: a critical component of · pdf fileunderstanding a3 thinking: a...

Documents

session 18: introduction to a3...

developing people using a3 thinking

a3 thinking

reflection: a key component to thinking...

a3 thinking approach to support knowledge- driven design ·...

a3 thinking for all seasons - michigan lean...

managing to learn mentoring a3 thinking

in chuck norris we trust - a3 thinking intro

lean marketing with a3 thinking

a3 thinking for solving complex problems and evolutionary...

a3’s from each group plus / delta€¦ · austin cop...

impact of the critical thinking component in...

re-thinking residency training using a3 methodology in...

awareness: sbs tool - a3 thinking · 2014. 8. 22. · a3 is...

a3 thinking chapter 1

evolve or die: a3 thinking and popcorn flow in action...

aotb16: ux & a3 thinking

the a3 process and a3 thinking. the source for much of this...

critical thinking unit 1 question a3 ww2 slide share

patterns of kaizen & a3 thinking