117
LEAN THINKING & KANBAN For Agile So ware Teams WILL EVANS // NORTH AMERICA 2016

Lean Thinking and Kanban for Agile Teams

Embed Size (px)

Citation preview

Page 1: Lean Thinking and Kanban for Agile Teams

LEAN THINKING & KANBAN

F o r A g i l e S oftw a r e T e a m s

WILL EVANS // NORTH AMERICA 2016

Page 2: Lean Thinking and Kanban for Agile Teams
Page 3: Lean Thinking and Kanban for Agile Teams

If a revolution destroys a systematic government, but the systematic patterns of thought that produced that government are left intact, then those patterns will repeat themselves in the succeeding government. There’s so much talk about the system. And so little understanding.

- Robert M. Pirsig

Page 4: Lean Thinking and Kanban for Agile Teams

OUTLINE FOR TODAY

❏  Introductions ❏  Boundaries ❏  Lean Thinking ❏  Value Stream Mapping ❏  Kanban Simulation ❏  Introduction to Kanban ❏  Theory of Constraints ❏  Closing Discussion

Page 5: Lean Thinking and Kanban for Agile Teams

SPEAKING RATE YOURSELF 1-5

1.  I mostly listen

2.  I talk when I am asked to

3.  I talk in most meetings

4.  I talk first

5.  I interrupt other people

Page 6: Lean Thinking and Kanban for Agile Teams

AGILE/LEAN RATE YOURSELF 1-5

1.  I’ve heard the words

2.  I’ve read some articles

3.  Our teams are Agile/Lean

4.  I coach/manage Agile teams

5.  I’m a recognized expert in Agile/Lean (outside my organization)

Page 7: Lean Thinking and Kanban for Agile Teams

EXPLAIN YOURSELF

What skills do you bring to a team?

Page 8: Lean Thinking and Kanban for Agile Teams

PURPOSE, PROCESS, PEOPLE

❏  Purpose: What customer problems are we trying to achieve to grow the business? What is the value? Where is the target?

❏  Process: How will the organization assess each major value stream to make sure we’re maximizing optionality while decreasing waste?

❏  People: How do we empower people to own the process, own the work, and be constantly learning? How can everyone touching the value stream be actively engaged in operating it correctly and continually improving it?

Page 9: Lean Thinking and Kanban for Agile Teams

LEAN PRINCIPLES

•  Identify Customers and Value

•  Map the Value Stream

•  Create Flow by Eliminating Waste

•  Respond to Customer Pull

•  Pursue Perfection

Page 10: Lean Thinking and Kanban for Agile Teams

CUSTOMER FOCUS

Page 11: Lean Thinking and Kanban for Agile Teams

CUSTOMER / VALUE FOCUSED

1. What is customer value?

Page 12: Lean Thinking and Kanban for Agile Teams

To take a systems view is to think about the organization from the outside-in. To understand customer demand and to design a system that meets it. To enable control in this high variety environment, it is necessary to integrate decision-making with work (so the workers control the work) and use measures derived from the work. If workers are controlling the work, they need managers to be working on the things beyond the control of the workers which affect the system conditions: the way work works. The result is an adaptive, customer-centric system.

- JOHN SEDDON ”

Page 13: Lean Thinking and Kanban for Agile Teams

CUSTOMER FOCUS

If you think of your organization as a system, then a clear, customer-focused purpose that can be used to drive holistic decisions is the starting point for systems thinking. START WITH THESE QUESTIONS:

•  Who are my customers, and

•  What do they really want from my organization?

Page 14: Lean Thinking and Kanban for Agile Teams

SYSTEMS THINKING ASKS 5 QUESTIONS

1.  PURPOSE: What is the purpose of this organization? Is that purpose focused on satisfying a Customer Need?

2.  DEMAND: What is the nature of customer demand? (Failure versus Value Demand)

3.  CAPABILITY: What is the system predictably achieving?

4.  FLOW: How does the work work?

5.  SYSTEM CONDITIONS: What are the causes of waste in the system?

Page 15: Lean Thinking and Kanban for Agile Teams

WHO ARE YOUR CUSTOMERS?

A customer is anyone who pays for, uses, supports, or derives value from the system you create. Since there could be a lot of people involved, we recommend that you simplify the issue of identifying your custom by considering the entire system you are involved in creating, not just the software.

Page 16: Lean Thinking and Kanban for Agile Teams

CUSTOMER WHO PAY FOR THE SYSTEM

ASK THESE QUESTIONS:

1.  Why do these customers spend good money for my system? 2.  What purpose are they trying to achieve? 3.  What are their key constraints? 4.  How does my system fit into my customer’s value stream?

Page 17: Lean Thinking and Kanban for Agile Teams

CUSTOMER WHO USE THE SYSTEM

Customers who use the system may not be the same as those that pay for the system, and sometimes have a different purpose.

They have a job to do, and the system should support the job they are trying to get done by removing a constraint in ‘their system’ so that value flows faster to positive outcome for them.

Page 18: Lean Thinking and Kanban for Agile Teams

CUSTOMER WHO SUPPORTS THE SYSTEM

When you release a system, you may breathe a sigh of relief now that your work is done; but the work is just beginning for those who support the system.

HOW CONSUMABLE OR USABLE IS YOUR SYSTEM? •  How rapidly and easily your customers can begin realizing the value

from your system? •  Who does it take to install the system or a release? •  How difficult is it to use? •  How hard is it to configure? •  How much training is required?

Page 19: Lean Thinking and Kanban for Agile Teams

WHAT IS YOUR PURPOSE?

A simple statement of purpose form a customer’s perspective can do wonders to clarify what is important and what is waste. Let’s be clear – most customers do not want software; customer’s want their problems solved. If customers could get their problems solved without software running on hardware connected to a network powered by electricity, they would probably be delighted.

Example: I don’t want Seamless. I want Korean food. Preferably hot. The problem I have is not lack of Korean food but instead hunger. Seamless solves for my hunger problem.

Page 20: Lean Thinking and Kanban for Agile Teams

THE NATURE OF CUSTOMER DEMAND?

The next step in establishing a systems view of your organization is to understand the patterns of customer demand for the products or services you deliver.

CUSTOMER DEMAND COMES IN TWO FORMS: 1.  The demand for products and services that provide value by solving

a problem. 2.  When a product or service doesn’t meet customer expectations,

there is demand for failure remediation – that is demand to fix something that appears to be broken, inadequate, or difficult to use, configure, or modify.

Page 21: Lean Thinking and Kanban for Agile Teams

Failure demand

Page 22: Lean Thinking and Kanban for Agile Teams

FAILURE DEMAND

Failure Demand is the demand on the resources of an organization caused by it’s own failures. The system is designed without the affordances required for a user to simply derive value from the system within their system. EXAMPLES:

•  Support calls are almost always failure demand.

•  FAQs are usually a remediation for failure demand.

•  Training is also a remediation for UX failure demand.

Page 23: Lean Thinking and Kanban for Agile Teams

FAILURE DEMAND

Change requests may also be a form of failure demand; for example a change request may come from a failure on your part to understand your customers or a premature decision on your part about what customers actually want.

Even if you deliver exactly what your customer asked for, once they see it they may realize that it doesn’t solve their problem; from your customer’s perspective change requests in this example are a form of failure demand.

Page 24: Lean Thinking and Kanban for Agile Teams

FAILURE DEMAND

Another insidious form of failure demand is the demand on your resources created by technical debt. SUCH AS:

•  Defects you have chosen to ignore

•  Messy coding practices

•  Duplication

•  Lack of effective test automation

•  A tightly coupled architecture •  Multiple code branches

•  Anything that makes it difficult to respond to customer demand

Page 25: Lean Thinking and Kanban for Agile Teams

FAILURE DEMAND

The purpose of looking for failure demand is to identify as much failure demand as possible because failure demand is waste in your system that you can actually do something about. When you first map your system of work to a kanban they best thing to do is classify stories as either failure demand or value demand.

Chances are as much as 90% of work flowing through the system is failure demand.

Page 26: Lean Thinking and Kanban for Agile Teams

Value demand

Page 27: Lean Thinking and Kanban for Agile Teams

VALUE DEMAND

The primary demand on your organization should be value demand.

This demand can be in the form of requests for work that will add value from a customer’s perspective, or it can be in the form of unmet needs that customers don’t know they have, but that you discover through understanding their value stream and satisfy through your product or service.

Value demand, when satisfied, usually generates revenue for your organization (depending on your business model).

Page 28: Lean Thinking and Kanban for Agile Teams

VALUE DEMAND

Almost every software development organization we know of has more demand for its services that it can accommodate, so a good question to ask is:

“What portion of incoming demand does my organization have capacity to satisfy?”

Page 29: Lean Thinking and Kanban for Agile Teams

VALUE DEMAND

If value demands exceeds your capacity to deliver, there are two steps to take:

1.  Focus on eliminating failure demand so you have more time to work on value demand;

2.  Evaluate how you filter demand (prioritize) to decide which work you will accept and which you will turn down.

The first solution that comes to mind should never be to add more designers, developers, or testers to your organization.

Page 30: Lean Thinking and Kanban for Agile Teams

CUSTOMER CENTRIC MEASUREMENTS (KPIs)

1.  Time-to-market for product development (for the entire system) 2.  End-to-end response time for customer requests (request-to-

resolution time) 3.  Success of the system in the marketplace

(profitability, lifetime customer value, market share, NPS) 4.  Business value attributable to the system

(measurable business improvement) 5.  Customer time-to-value after delivery

6.  Impact of escaped (post-release) defects (customer downtime, financial impact, cost of delay)

Page 31: Lean Thinking and Kanban for Agile Teams

CUSTOMER CENTRICITY

Steps Towards Customer-Centricity require the entire team (not just product and UX) to:

1.  Understand the market, the customer, the technology, and the perceived constraints on the system. Later we challenge the constraints, but it’s important to document them up front

2.  Observe real people in real life situations to find out what makes them tick; what confuses them, what they like, what they hate, where they have latent needs not addressed by current products or services

3.  Visualize through prototyping new concepts or countermeasures and how they will fit into the customer’s existing value chain. This means you probably should spend enough time with the customer so that you map their value stream, and map how your’s fits into theirs!

4.  Evaluate and refine prototypes in a series of quick iterations. This is where creating multiple options that solve the same problem is useful.

5.  Implement the new feature, service, or product and test it with real customers in their environment with your whole team there to observe and take notes.

Page 32: Lean Thinking and Kanban for Agile Teams

VALUE STREAM?

VALUE STREAM “The flow of information into a product through a social network (team or organization) is what we call a value stream.”

– Jabe Bloom

Page 33: Lean Thinking and Kanban for Agile Teams

MAP THE VALUE STREAM

2. How is customer value delivered?

Page 34: Lean Thinking and Kanban for Agile Teams

If you have a stable system, then there is no use to specify a goal. You will get whatever the system will deliver. A goal beyond the capability of the system will not be reached. If you have not a stable system, then there is no point in setting a goal. There is no way to know what the system will produce: it has no capability.

- EDWARDS DEMING ”

Page 35: Lean Thinking and Kanban for Agile Teams

MAP YOUR VALUE STREAM

First, starting by identifying who your customer is (the person that uses the software you make).

5 minutes

Page 36: Lean Thinking and Kanban for Agile Teams

MAP YOUR VALUE STREAM

Second, from the point of delivery, walking backwards, write every step in your current process so that you can deliver software to your customer.

5 minutes

Page 37: Lean Thinking and Kanban for Agile Teams

MAP YOUR VALUE STREAM

Third, write a sticky for how a customer request is turned into an idea for a solution. Place that at the beginning of the value stream.

5 minutes

Page 38: Lean Thinking and Kanban for Agile Teams

REFLECT

What did you find interesting about what you just did?

Page 39: Lean Thinking and Kanban for Agile Teams

REFLECT

How many steps did does it take from idea to delivery of value to your customer?

Page 40: Lean Thinking and Kanban for Agile Teams

REFLECT

What steps in the process actually add add value (from the perspective of the customer)? What steps in the process are non-value added?

Page 41: Lean Thinking and Kanban for Agile Teams

MAP YOUR VALUE STREAM

Fourth, now map the value stream of your customer (the value stream that your software system fits into). This is up one level, and shows how your customer creates value. Follow the same steps as previously done, which is start from your customer’s customer. What did they do immediately before they started to receive value? Identify where your solution fits into their value stream.

5 minutes

Page 42: Lean Thinking and Kanban for Agile Teams

SYSTEM CAPABILITY

Once you understand your customers and what it means to deliver value to those customers, the next step is to gain a clear understanding of your capability to deliver that value.

The starting point for improving your capability to satisfy customer needs is to understand how your current work methods actually work, what the are they currently capably of delivering?

You need to understand how your capability compares with the needs of customers and the capability of your competitors, both today and in the future.

Page 43: Lean Thinking and Kanban for Agile Teams

VALUE STREAM MAPS

Far too often, providing customer value is thought of as a series of separate input-process-output steps, rather than an integrated flow of work through an organization.

If no one takes an end-to-end view of a customer problem or a product as it moves through a work system, customer problems fall into the cracks between functional silos, hard earned knowledge evaporates at handovers, and the things that customers will really value get lost along the way.

Developing an understanding of the end-to-end flow of work through a work system is fundamental to systems thinking.

Page 44: Lean Thinking and Kanban for Agile Teams

END-TO-END FLOW

One way to evaluate the end-to-end workflow through your system is to draw a process flow map – also known as a value stream map – of the end-to-end flow of a product or a customer problem as it makes its way through your organization.

Page 45: Lean Thinking and Kanban for Agile Teams

VALUE STREAM MAPS

There are two reasons for drawing these maps: 1.  Discover the reasons for failure demand, so it can be eliminated

2.  Find waste in the flow, so it can be removed

Remember, all time spent handling failure demand is waste.

It is better to map the process that creates the failure in the first place, than to map and improve the process that handles the failure demand.

Page 46: Lean Thinking and Kanban for Agile Teams

MAP VALUE DEMAND

A value stream map is a diagram of the end-to-end flow of value-creating work through your process; its purpose is to help you understand the workflow for value demand so that you can improve your process.

Page 47: Lean Thinking and Kanban for Agile Teams

MAP VALUE DEMAND

Your current capability is the end-to-end flow time for an average item moving through your system. Your value stream map will show you how much time is spent actually adding value, versus how much time until the customer is actually realizing that value.

Page 48: Lean Thinking and Kanban for Agile Teams

MAP VALUE DEMAND

Two tips for improving the your system:

1.  After you map the entire process end-to-end, identify the biggest loopbacks or queues (steps with bottlenecks), and improve that, then do another value stream map.

2.  Just as the team should map their value stream, the team should identify the biggest sources of waste, and the team should work to design a countermeasure to remove the waste.

Page 49: Lean Thinking and Kanban for Agile Teams

INCREASE FLOW

3. Take those actions which increase flow of value.

Page 50: Lean Thinking and Kanban for Agile Teams

ELIMINATE FAILURE DEMAND

Failure demand is waste. To improve flow, the best questions to ask are:

1.  What % of our current flow of work is failure demand?

2.  Why is the process producing failure demand?

3.  What decisions were made that led to the failure demand?

4.  What can be changed to prevent failure demand?

Page 51: Lean Thinking and Kanban for Agile Teams

ON FLOW When we talk about flow, we could be talking about the flow of information within the system, the flow of raw materials, or the flow of components that ultimately deliver value to a customer who is willing to pay for it.

Page 52: Lean Thinking and Kanban for Agile Teams

JUST IN TIME

4. Make what is pulled by the customer just-in-time.

Page 53: Lean Thinking and Kanban for Agile Teams

STOP STARTING Adhering to the flow concept mandates the abolishment of local efficiencies. Ohno addressed this issue again and again, stressing that there is no point in encouraging people to produce if the products are not needed in the very short-term.

Page 54: Lean Thinking and Kanban for Agile Teams

Flow efficiency

How long did we actually spend

working on it?

10 TO 20 TIMES

LONGER Typical organizations take

to deliver something than they actually spent working on it

How long does it take to deliver a

piece of work?

Page 55: Lean Thinking and Kanban for Agile Teams

RESOURCE EFFICIENCY

Page 56: Lean Thinking and Kanban for Agile Teams

VALUE & THROUGHPUT

Page 57: Lean Thinking and Kanban for Agile Teams

PROCESS EFFICIENCY

Page 58: Lean Thinking and Kanban for Agile Teams

FLOW EFFICIENCY

Page 59: Lean Thinking and Kanban for Agile Teams

OBSTACLES TO FLOW

•  Silo thinking (vertical vs horizontal thinking)

•  Leadership is incented through performance evaluations and promotions to form and protect silos

•  No coherent strategic intent

•  Focusing on processes that are not the constraint on the system

•  Leadership maximizes organizational resources for local efficiencies, not system throughput.

•  Optimizing inside a step (removing waste inside of a step), instead of between steps, or removing steps altogether.

Page 60: Lean Thinking and Kanban for Agile Teams

CONTINUOUS IMPROVEMENT

5. Perfect this by removing all forms of waste and constantly improving things.

Page 61: Lean Thinking and Kanban for Agile Teams

Releases suck.

Change management sucks.

Death marches suck.

Quality sucks.

Morale sucks.

Moral dilemmas suck.

Firefighting sucks.

Things that suck.

Page 62: Lean Thinking and Kanban for Agile Teams

SYSTEM CONDITIONS

Waste is anything that depletes resources of time, effort, space, or money without adding value -- in the eyes of your customer. Most of the waste in a system is caused by the system itself, and by the fact that most managers don’t realize that it's their job to manage the system.

Much of the waste that exists inside a system are created by policies and procedures of the organization. Until these policies change, the waste will not go away.

Page 63: Lean Thinking and Kanban for Agile Teams

8 FORMS OF WASTE

Page 64: Lean Thinking and Kanban for Agile Teams

POLICIES CAUSE WASTE

The first and most important policy that causes waste in a system is engineers not being allowed to talk with customers.

Subsystems like “Help Desk,” or L1, L2, and L3 support are meant to insulate engineers from customers.

This creates waste, removes or dampens feedback loops, and is the source of most quality problems with software.

Page 65: Lean Thinking and Kanban for Agile Teams

POLICIES CAUSE WASTE

The five biggest Causes of Policy-Driven Waste in software development are:

1.  No feedback loops between engineering and customers 2.  System Complexity

(We treat features as requirements, and believe there is a linear relationship between features and value, adding more features increases system complexity nonlinearly)

3.  Economies of Scale (Batch and queue mentality)

4.  Separating decision-making from the work

5.  Wishful Thinking (We mistake plans and planning, and believe that plans can remove uncertainty from a system -- they don’t!)

6.  Technical Debt

Page 66: Lean Thinking and Kanban for Agile Teams

Having no problems is the biggest problem of all.

“ - TAICHI OHNO

Page 67: Lean Thinking and Kanban for Agile Teams

Toyota Chairman

Go See, Ask Why, Show Respect.

“ - FUJIO CHO

Page 68: Lean Thinking and Kanban for Agile Teams

LEAN MANAGEMENT

Lean management is not about experts providing answers, or aligning ‘resources’ to a vision. It’s about providing a system of constraints for people to ask the right questions, find purpose in their work, and be empowered to make decisions and constantly learn & improve through experimentation and failure.

Page 69: Lean Thinking and Kanban for Agile Teams

LEAN MANAGEMENT

Addresses the purpose problem by identifying product family value streams for specific customers:

•  Makes value easier to specify

•  Makes the flow of value easier to see Addresses the process problem by assigning a leader to each value stream:

•  Makes current condition of entire process clear to everyone

•  Proposes a better “future state” process and takes responsibility for implementing it

•  Makes condition of the new “current state” clear to everyone Addresses the people problem by teaching people to see the entire system and align it to strategic intent, and not just focus on local optima.

Page 70: Lean Thinking and Kanban for Agile Teams

HORIZONTAL VERSUS VERTICAL

•  Most organizations place the organization chart and assets in the foreground.

•  Managers think vertically to optimize their area, department, headcount, budget.

•  Horizontal flow of value to customer is easily lost.

•  Organizations always scale vertically, often to the detriment of the horizontal value stream.

Page 71: Lean Thinking and Kanban for Agile Teams

HORIZONTAL VERSUS VERTICAL

As organizations scale vertically, more queues are introduced, more handoffs are required, more SLAs are enforced, more turf battles ensure, and cycle times get longer.

This is the way of all organizations as they scale and create organizational debt.

Page 72: Lean Thinking and Kanban for Agile Teams

HORIZONTAL VERSUS VERTICAL

Lean management places the horizontal flow of value in the foreground: Lean managers think horizontally, with the help of value stream leaders… However…

•  Functions are still strong (or even stronger):

•  Repositories of deep technical knowledge

•  Home base for employees

•  Guardians of career paths.

Page 73: Lean Thinking and Kanban for Agile Teams

KANBAN SIMULATION

Page 74: Lean Thinking and Kanban for Agile Teams

WHAT IS KANBAN?

“A Card (or traditionally, a Kanban) is a symbolic token representing a unit of effort, either to be completed or in the process of being completed.”

– Jabe Bloom

Page 75: Lean Thinking and Kanban for Agile Teams

http://jovannatosello.blogspot.com/2012/06/colors-of-tokyo-day-32-imperial-palace.html

Page 76: Lean Thinking and Kanban for Agile Teams

A PULL SYSTEM

Page 77: Lean Thinking and Kanban for Agile Teams

PROBLEMS

this is 100% utilization this is 100% utilization

Page 78: Lean Thinking and Kanban for Agile Teams

HOW KANBAN HELPS

Is it difficult for every person in your organization to answer these questions?

•  Where are we now?

•  Who is working on what?

•  What should I be doing?

•  What should I not be doing?

Page 79: Lean Thinking and Kanban for Agile Teams

4 PRINCIPLES

1.  Start with what you do now

2.  Agree to pursue incremental, evolutionary change

3.  Respect the current process, roles, responsibilities & titles

4.  Encourage acts of leadership at all levels

Page 80: Lean Thinking and Kanban for Agile Teams

THE J-CURVE

Page 81: Lean Thinking and Kanban for Agile Teams

5 CORE PROPERTIES

1.  Visualize your work (and workflow)

2.  Limit your work-in-progress (WIP)

3.  Make policies explicit

4.  Measure your flow

5.  Model process improvement

Page 82: Lean Thinking and Kanban for Agile Teams

make work visible

Page 83: Lean Thinking and Kanban for Agile Teams

PLAN

DO STUDY

ACT

Page 84: Lean Thinking and Kanban for Agile Teams

WHY LIMIT YOUR WIP?

WIP (WORK-IN-PROGRESS) IS THE PROVERBIAL “BALLS-IN-THE-AIR.”

The more balls in the air, the harder it is to concentrate; attention to detail suffers; quality goes down; things remain undone; you feel bad; work becomes overwhelming and unpleasant.

Page 85: Lean Thinking and Kanban for Agile Teams

What we’ve come to recognize is that the introduction of WIP limits forces conversations to happen that were not happening before… … and the derivative mechanisms resulting from WIP limits such as prioritization meeting and selection mechanisms, impediment escalation and a focus on flow to both shorten cycle time and improve predictability encourage collaboration and cultural change for the better.

- DAVID ANDERSON ”

Page 86: Lean Thinking and Kanban for Agile Teams

10 REASONS TO LIMIT YOUR WIP

1.  Visualize Bottlenecks

2.  Prioritization

3.  Conversations

4.  Predictability

5.  Quality

6.  Processing & Memory

7.  Completion

8.  Multitasking

9.  Context Switching

10.  Learning

Team Effectiveness

Personal Effectiveness

Page 87: Lean Thinking and Kanban for Agile Teams

A SIMPLE KANBAN

Page 88: Lean Thinking and Kanban for Agile Teams

A SIMPLE KANBAN

Page 89: Lean Thinking and Kanban for Agile Teams

WIP LIMITS

Page 90: Lean Thinking and Kanban for Agile Teams

INCREMENTAL IMPROVEMENT

•  Review bottlenecks

•  Pair to increase flow

•  Adjust WIP Limits

•  Use A3 to suggest improvements

•  Measure Lead Time & Cycle Time

•  Perform Experiments

•  Track Results with Meaningful Metrics

Page 91: Lean Thinking and Kanban for Agile Teams

THEORY OF CONSTRAINTS

Page 92: Lean Thinking and Kanban for Agile Teams

If we dive deep enough we’ll find that there are very few elements at the base, the root causes, which through cause-and-effect connections, are governing the whole system. The result of systematically applying the question ‘Why?’ is not enormous complexity, but rather wonderful simplicity

- ELIYAHU GOLDRATT

Page 93: Lean Thinking and Kanban for Agile Teams

WHAT IS TOC?

The Theory of Constraints (TOC) is a management concept that views any manageable organization as being limited in achieving its goals by a very small number of constraints on the system.

Page 94: Lean Thinking and Kanban for Agile Teams

LOGIC OF TOC THINKING

The Theory of Constraints (TOC) applies the cause-and-effect thinking processes to understand and improve all systems, but particularly, how teams work within organizations to achieve flow.

Page 95: Lean Thinking and Kanban for Agile Teams

WHAT IS A CONSTRAINT?

A constraint is: "anything that limits a system from achieving higher

performance versus its goal." – Eli Goldratt

A constraint could also be any thing, object,

person, process, or structure in an organization that prevents the flow of value to a customer.

Page 96: Lean Thinking and Kanban for Agile Teams

VALUE STREAM

Page 97: Lean Thinking and Kanban for Agile Teams

IDENTIFY THE CONSTRAINTS

Page 98: Lean Thinking and Kanban for Agile Teams

BALANCED CAPACITY PLANNING

Page 99: Lean Thinking and Kanban for Agile Teams

WHY DOES BALANCED CAPACITY FAIL?

Page 100: Lean Thinking and Kanban for Agile Teams

PRIMARILY FRICTION

Everything in war is simple, but the simplest thing is difficult. The difficulties accumulate and end by producing a kind of friction that is inconceivable unless one has experiences war.

- CARL VON CLAUSEWITZ

“ ”

Page 101: Lean Thinking and Kanban for Agile Teams

PRIMARILY FRICTION

Page 102: Lean Thinking and Kanban for Agile Teams

ON CHANGE

Page 103: Lean Thinking and Kanban for Agile Teams

HOW DO WE IMPROVE?

We should realize that to improve means to change!

TO IMPROVE MEANS WE MUST:

1.  Provide products and services that solve customer problems

2.  Release products and services consistent with demand

3.  Reduce variability in our processes

4.  Have measurements that indicate success relative to achieving our goal

5.  Reward people for their contribution to change

Page 104: Lean Thinking and Kanban for Agile Teams

Any improvement is a change, but not every change is an improvement.

- ELIYAHU GOLDRATT

Page 105: Lean Thinking and Kanban for Agile Teams

TOC’S THREE QUESTIONS

For an organization to have a process of on-going improvement, certain basic questions need to be answered faster and more effectively.

THESE ARE:

1.  What should we change?

2.  What should we change to?

3.  How do we implement the change?

Page 106: Lean Thinking and Kanban for Agile Teams

Applying TOC to organizations

Page 107: Lean Thinking and Kanban for Agile Teams

In the layman’s eyes the symptom shows the nature of the disease, and cure means removal of symptoms. The physician, however, finds it important to distinguish the symptoms from the disease and recognizes that doing away with the symptoms is not necessarily curing the disease.

- SIGMUND FREUD

Page 108: Lean Thinking and Kanban for Agile Teams

WHAT TO CHANGE?

From a list of observable symptoms (UDEs), cause-and-effect is used to identify the underlying common cause, or root cause(s), for all the symptoms.

In organizations however, the root cause(s) are inevitably unresolved conflicts that keep the organization trapped and/or distracted in a constant tug-of-war.

Page 109: Lean Thinking and Kanban for Agile Teams

CURRENT REALITY TREE

potential root cause

Page 110: Lean Thinking and Kanban for Agile Teams

WHAT TO CHANGE TO?

By challenging the logical assumptions behind the conflicts, counter-measures to the root cause(s) can be identified. This is only the starting point for the development of a complete solution – as strategic intent – for resolving the root cause(s), as well as all of the initial symptoms.

This often involves changes to the policies, measurements, and organizational structures identified in ‘What to Change?’ Also including the organization’s strategic intent.

Page 111: Lean Thinking and Kanban for Agile Teams

HOW TO CAUSE THE CHANGE?

Taking into consideration the unique culture which exists in every organization, a plan is developed to transition an organization from where it is today to realizing the strategic intent which is aligned to elevate the key constraints on the system which are preventing the organization from achieving flow.

Page 112: Lean Thinking and Kanban for Agile Teams

FIVE FOCUSING STEPS OF TOC

Page 113: Lean Thinking and Kanban for Agile Teams

MAXIMIZING VALUE STREAM FLOW

Just as the strength of a chain is dictated by its weakest link, the performance of any value stream is dictated by its constraint.

THE STEPS TO MAXIMIZE THE PERFORMANCE OF THE VALUE STREAM ARE: 1. Identify the constraint 2. Decide how to exploit the constraint 3. Subordinate everything else to the above decisions

TO IMPROVE THE PERFORMANCE OF THAT SAME VALUE CHAIN, CONTINUE:

4. Elevate the performance of the constraint

5. If in any of the above steps the constraint has shifted, go back to Step 1.

Page 114: Lean Thinking and Kanban for Agile Teams

MANAGING CONSTRAINTS

Page 115: Lean Thinking and Kanban for Agile Teams

CHALLENGES & OBSERVATIONS

•  Walk the Gemba > Walking up the inference ladder

•  Make the board work for you & your team

•  Start with your existing process

•  There is no “one true board”

•  Keep the value stream filled

•  Pull is a mind-set

Page 116: Lean Thinking and Kanban for Agile Teams

REVIEW AND WRAP-UP

Page 117: Lean Thinking and Kanban for Agile Teams

Will Evans Chief Design Officer [email protected]

THANKS