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

© 1993-2015 Jeff Sutherland & Scrum Inc.

1

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

2

http://www.scruminc.com


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

9

Problem Solving A3


Story Telling Tips

10

“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

11

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)

12

Avoid Hearsay Avoid Email


Nemawashi - Toyota’s Secret Sauce

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


The Process

14

Illustration based on Mike Rother’s Toyota Kata

Winner of the 2013 Shingo Prize for Operational Excellence


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

21

• 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

22

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

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.

26

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?

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

40

Kaizen


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

42

Yokoten

Share across the organization and Kaizen


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

http://www.scruminc.com/category/blog/

http://www.scruminc.com/category/blog/

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

Documents