Adapting TPS Tools and Techniques for Enterprise TQM to Software, Artificial Intelligence, Machine Learning and Deep Learning Development Organizations

1. THE AGILE
LEARNING ORGANIZATION
Adapting TPS Tools and Techniques for Enterprise TQM to
Software, Artificial Intelligence, Machine Learning and Deep
Learning Development Organizations
SEPT. 28, 2020
DAVE LITWILLER

2. OVERVIEW
Core Tools Applied to Software Development Businesses:
• Plan-Do-Check-Act (PDCA) Problem Solving
• Five Why’s and Root Cause Analysis (RCA)
• A3 Problem Solving Tool
• Enterprise and Systems Thinking
• Waste Walk Audits
• Value Stream Mapping of Current and Future States
Getting Started:
• Commencing and expanding TQM
• Change management success factors

3. PDCA
Plan
• Plan a change or improvement, and,
• Determine the goal to be achieved (including strategy and
supporting methods)
Do
• Design (business req’t, function, feature, test method,
success criteria), implement, and test

4. PDCA
Check
• Evaluate results to see if goal was reached, including
recording a checklist of what did and didn’t go according
to plan
Act
• If the changes did not achieve the goal, then continue the
cycle to achieve the goal with a further adapted plan

5. PDCA – SPRINT CYCLE EXAMPLE
Day 1 – Plan
• Priorities
• Architecture
• High level design
• Identify infrastructure requirements and dependencies
Days 2-9 – Do (Build and Test)
• Daily stand-ups
• Remove impediments
• Identify risks
• Share knowledge
• Integrate and align/synch and stabilize

6. PDCA – SPRINT CYCLE
Day 10 Morning – Check
• Product review for the sprint vs. goals
• Lessons learned and reflection
Day 10 Afternoon – Act
• Deploy
• Evaluate project health
• Review risks and audit them
• Determine next steps

7. PDCA – BUSINESS
PROCESS/WORKFLOW EXAMPLE
Plan
• Conduct as-is (current state) analysis
• Determine the changes to be made (future state)
Do
• Build and test
• Inputs
• Outputs
• Processes, approvals and escalations
• Error detection and exception handling

8. PDCA – BUSINESS
PROCESS/WORKFLOW
Check
• Check that the process meets the initial future state req’ts
Act
• Implement the new process, or,
• Begin a new improvement iteration until the requirements
for the targeted future state are achieved

9. 5 WHY’S AND RCA

10. 5 WHY’S AND RCA

11. 5 WHY’S AND RCA
Moving upstream in the software development process:
• Why the defect was not caught during the Sanity Test in production?
• Why the defect was not caught during Testing (system, integration)?
• Why the defect was not caught during the Test Case review?
• Why the defect was not caught in Unit Testing?
• Why the defect was not caught during the Design Review?
• Why the defect was not caught during the Requirement or Contract
Negotiation phase?

12. 5 WHY’S AND RCA
• Once there is an understood causality, then the process moves to
what to do to prevent or mitigate similar future events
• Improving:
• Value prop and market targeting
• Requirements discovery, understanding and triangulation
• Architecture and high-level design
• Data fitness, limits, systemic skews, scrubbing
• Detailed design and coding
• Test (unit, integration, system) and test planning
• Environmental issues (h/w, s/w, configurations, code complexity)
• User training
• Tools
• Employee experience and training (awareness, use of SOPs)
• Communication (vague, ambiguous, untimely, lack of monitoring,
inappropriate assumptions)
• Management level issues (priorities, decision rubrics and control rules
for delegated decision authority)

13. 5 WHY’S AND RCA
A well-defined problem is a problem half solved
• What is the problem?
• What is the sequence of events that led to the problem?
• What systems were involved?
• How long has the problem existed?
• What is the impact of the problem?
• Who was involved and who should be interviewed?

14. 5 WHY’S AND RCA
• Brainstorming ground rules at the start of the 5 Why’s
investigative process:
• No criticizing or blaming others
• No judgement of ideas. No ideas are bad
• Build on the ideas of others
• Give each participant time to share their views
• Encourage out-of-the-box and what-if thinking
• Don’t fall in love with an early idea to the exclusion of
considering other options
• Assumptions are often required to keep the process
moving, but each assumption should be noted for follow-up
confirmation or correction by going to the source of those
closest to the work subject to a provisional assumption

15. 5 WHY’S AND RCA
• Five is a placeholder, and is often enough to reach root
• Sometimes though, the chain of causality is deeper than
five, or multi-threaded
1. Keep asking and answering Why? successively until the
answer to Why? stops changing
2. Diversity of thought is vital in the early phases of
investigation, remember the Ishikawa Diagram:

16. A3 PROBLEM SOLVING
TOOL

17. Title of the issue
Background
Current Conditions
Target/Goal(s)
Analysis
Proposed Countermeasure(s)
Plan
Followup
Overall business objective and issue history
Business incentive to fix or mitigate the issue
The current condition of the application/service
What should be happening by the application/service
Explain the gap
Address above problem(s)
Provide measurable performance terms
State why you think this issue happened (hypothesis)
Provide basis for your hypothesis (e.g. requirements, code, logs)
What might prevent you from reaching your goals
State your proposal (e.g. process or code changes)
Provide alternative solutions
State reason(s) why your proposal should be taken to
consideration over alternatives
How your proposal impacts problems and helps you to reach
your goals
State your plan to apply your proposal
Who needs to do it
What needs to be changed
Where does it sit (organizationally, tech or product stack)
How to make sure your proposal is effective
What are the indicators of performance and progress
Future anticipated issues that you discovered
Unintended consequences of applying changes
Possible failures
Date Status
Owner
initials

18. WASTE WALKS

19. WASTE WALKS
• Other typical issues:
• Document management and version control
• Overly simple early tests, leaving much more serious
issues to be discovered at later, more costly stages
• People doing the same thing over and over (typically
SOPs, tools, training at issue)
• Excessive requests and clarifications about requirements
and contextual information

20. VALUE STREAM MAPS

21. VALUE STREAM MAPS
• Agnostic to development methodology:
• Waterfall
• Spiral development
• Agile
• DevOps
• Continuous integration/continuous delivery
• And, various hybrids thereof

22. VALUE STREAM MAPS
• Define the focus, scope and process to be mapped
• All work is a process, and can be mapped
• Typical objectives for software development value streams:
• Speed or velocity,
• Quality,
• Governance and compliance, and
• Efficiency
• Determine the book ends:
• For example
• Starting with creation of a feature request, or, an approved
new feature request
• Ending with release to production, or, customer sign-off

23. VALUE STREAM MAPS
• Determine the lens through which value will be evaluated
• Most common is customer-defined value
• Three classic schools of thought for customer centricity:
• Peter Drucker:
• “There is only one valid definition of business purpose: to
create a customer.”
• W. Edwards Deming:
• “Companies that understand what their customers’ needs and
desires are and deliver solutions that customers didn’t even
know they wanted will delight customers.”
• Theodore Levitt:
• “Successful companies focus on their customers’ needs, not
their own.”

24. VALUE STREAM MAPS
• Team selection:
• Typically, those able to make the changes that result from
the outcome of the process, moving from current to future
state
• Have the right level of seniority for the orbit of the process
under consideration
• Select the right aggregate functional span of contributing
individuals

25. VALUE STREAM MAPS
• Go to the source: “You can observe a lot just by looking.”
– Yogi Berra
• See first-hand what the current workflow at each stage of
the process is, and what the individual contributors do in
daily conduct of their work
• It is usually best if the entire team can make these
observations

26. VALUE STREAM MAPS
• Map the current stream
• This is usually an iterative exercise of progressively more
detail and accuracy
• Add data informing all stages between the bookends:
• Current cycle times
• Current lead times
• Current queue lengths
• Current up times/SLAs
• Note frequent and high impact exception/error handling

27. VALUE STREAM MAPS
• Look at value-add time, the time spent on value-adding work
• Meetings, reports and presentations are necessary overhead
for communication in a large group development setting
• What is waste is searching for in-house information,
organizing information, waiting for people, re-working,
implementing workarounds, and fixing things people thought
at an earlier time were sufficient
• An efficient lean/agile engineering organization can get
value-adding time up to 70% or even higher
• Whereas, weaker environments tend toward value-adding
time of 20% or so

28. VALUE STREAM MAPS
• Look at what-if scenarios to explore a range of
improvements for the prospective future state
• Develop the target future state value stream map
• Include quantitative targets for attributes such as quality
(data and code), velocity, compliance, as well as more
granular characteristics at each stage such as cycle times,
lead times and up times
• Identify the hot spots and bottlenecks relative to current
skills, tools and resources that will require the most care to
achieve and optimize the future state

29. VALUE STREAM MAPS
• Common is to have implementation targets for 30, 60 and
90 days
• Moving from the current to future state
• Usually with both quantitative and qualitative success
criteria defined in advance against which to measure
progress and make further course corrections

30. VALUE STREAM MAPS
• Typical places for heightened emphasis:
• Steps going from concept to delivery that take a long time
• Steps where there are significant backlogs of work queued
in front of them
• Steps where there is significant waiting, error correction or
misunderstanding rectification
• Especially where management escalations are common
• Easy fixes, as low hanging fruit

31. VALUE STREAM MAPS

32. VALUE STREAM MAPS

33. VALUE STREAM MAPS
• Typical high level KPIs/KPAs:
• Total lead time: the total time it takes to deliver on a
customer request
• Total process time: the total work effort required by all
functions on the timeline critical path of the value stream
• Activity ratio: the degree of flow in the value stream
• A.k.a. Cycle efficiency = value-added time/total elapsed
time
• Compound effect: the quality of output across the value
stream

34. OVERALL – USING TPS
FOR TQM
• Keep the focus on increasing flow:
• Managing and reducing work and information queues
• Batch size reduction
• Increasing the speed and accuracy of feedback
• Managing congestion at rate limiting resources
• Reducing variability, starting with more granular effort and
work breakdown estimates, bottom-up w/ peer review and
feedback
• The TPS toolkit can be used at varying levels of
abstraction for technical and business processes:
• From granular to very high level

35. OVERALL – USING TPS
FOR TQM
• Inventory and backlogs of partially completed knowledge
work are usually a liability, not an asset
• Very different from GAAP accounting for physical
production WiP
• Inventory conceals errors, information mismatches and
problems that should be identified and fixed
• Build, test and ship often, and use pull systems to limit
WiP/DiP (Design in Process)
• Pull systems expose bottlenecks so people can fix them
(tools, training) rather than staying concealed in DiP
inventory

36. OVERALL – USING TPS
FOR TQM
Software example of benefits from reduced DiP inventory:

37. GETTING STARTED
• Make the case for urgency in the need to change
• John Kotter: Failure to establish a sense of urgency is the
single largest mistake people make when trying to change
an organization
• Focus on an early, visible win to build momentum and
quell the skeptics
• Build an early team who are curious, knowledgeable,
believe better is possible, and who have a competitive
drive to win

38. GETTING STARTED
• Expand from the beachhead of success to additional
improvement opportunities, methodically across the
organization
• Often: Using the team members from the beachhead
project as the team leads for the next wave of efforts
• Acid Test: How leadership reacts when a disruption
occurs
• This is when there is usually a temptation to revert to the
old ways as the fastest path through the difficulty

39. EXECUTIVE ROLE
• Prioritization and sustaining continuity of high impact
early improvement projects
• Hybridization of TQM with existing workflows
• Communicating and recommunicating the Why the
organization is doing things related to TQM
• Reporting on TQM progress, frameworks and KPIs in
monthly, weekly and quarterly management reporting

40. CHANGE MANAGEMENT
SUCCESS
• Assume at the onset of any major change initiative:
• 1/3 of people are eager to learn and work in new ways to
improve
• 1/3 of people are willing to learn, but need further coaching
and encouragement to adopt and stick with new ways
• 1/3 of people are reluctant to change or are even cynical
about change initiatives
• Focus on the movable middle:
• Create the conditions so that the influenceable silent majority
of associates will see that the best way to learn and grow is
through the new framework and tools
• Actions count more than words, especially from the
leadership team

41. CHANGE MANAGEMENT
SUCCESS
• Pay attention to what people do, and the way they act, in
order to affect change over time in values, attitudes and
culture
• Do not start with lofty notions of culture, values or attitude
• It is easier to act your way to a new way of thinking than to
think your way to a new way of acting

42. CHANGE MANAGEMENT -
WESTRUM INFORMATION
FLOW MODEL
Rating Why?
Information is Actively Sought (Pull for Information) o
Messengers Can Safely Bring Forward Bad News o
Responsibilities are Shared o
Cross-Team, Cross-Functional Collaboration is
Rewarded
o
Failure Causes Inquiry o
Failures are Treated as Opportunities to Improve
the System
o
New Ideas are Welcomed o

43. CLOSING THOUGHTS
"Continuous improvement is the basic hygiene of knowledge work"
- Tom DeMarco and Tim Lister, Peopleware
Continuous improvement is a way of life, not an event
In TQM, everyone is a process engineer, eliminating waste and
increasing flow
TQM isn’t extra work; it is the new way to do business

44. FURTHER
DISCUSSION
For additional discussion about using methods of the TPS to
advance agility and learning capacity for high growth
technology businesses:
dave.litwiller@communitech.ca

45. IMAGE CREDITS
5 Why’s and RCA:
• https://www.softwaretestinghelp.com/root-cause-analysis/
Value Stream Map:
• https://creately.com/diagram/example/j0c6b2cp1/Value+Stream+Map
+for+Software+Development?utm_source=pinterest&utm_medium=s
ocial&utm_campaign=pinvsm
• https://www.plutora.com/blog/value-stream-mapping
• https://opensource.com/article/18/12/optimizing-delivery-value-
stream-mapping
Small Batch Testing:
• https://d2mug8yhikhiqv.cloudfront.net/wp-
content/uploads/2016/06/23053207/reinertsen-1.jpg