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

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

“

”

OUTLINE FOR TODAY

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

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

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)

EXPLAIN YOURSELF

What skills do you bring to a team?

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?

LEAN PRINCIPLES

•  Identify Customers and Value

•  Map the Value Stream

•  Create Flow by Eliminating Waste

•  Respond to Customer Pull

•  Pursue Perfection

CUSTOMER FOCUS

CUSTOMER / VALUE FOCUSED

1. What is customer value?

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 ”

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?

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?

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.

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?

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.

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?

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.

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.

Failure demand

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.

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.

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

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.

Value demand

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

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?”

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.

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)

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.

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

MAP THE VALUE STREAM

2. How is customer value delivered?

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 ”

MAP YOUR VALUE STREAM

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

5 minutes

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

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

REFLECT

What did you find interesting about what you just did?

REFLECT

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

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?

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

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.

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.

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.

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.

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.

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.

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.

INCREASE FLOW

3. Take those actions which increase flow of value.

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?

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.

JUST IN TIME

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

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.

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?

RESOURCE EFFICIENCY

VALUE & THROUGHPUT

PROCESS EFFICIENCY

FLOW EFFICIENCY

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.

CONTINUOUS IMPROVEMENT

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

Releases suck.

Change management sucks.

Death marches suck.

Quality sucks.

Morale sucks.

Moral dilemmas suck.

Firefighting sucks.

Things that suck.

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.

8 FORMS OF WASTE

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.

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

Having no problems is the biggest problem of all.

“ - TAICHI OHNO

”

Toyota Chairman

Go See, Ask Why, Show Respect.

“ - FUJIO CHO

”

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.

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.

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.

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.

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.

KANBAN SIMULATION

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

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

A PULL SYSTEM

PROBLEMS

this is 100% utilization this is 100% utilization

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?

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

THE J-CURVE

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

make work visible

PLAN

DO STUDY

ACT

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.

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 ”

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

A SIMPLE KANBAN

A SIMPLE KANBAN

WIP LIMITS

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

THEORY OF CONSTRAINTS

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

“

”

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.

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.

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.

VALUE STREAM

IDENTIFY THE CONSTRAINTS

BALANCED CAPACITY PLANNING

WHY DOES BALANCED CAPACITY FAIL?

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

“ ”

PRIMARILY FRICTION

ON CHANGE

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

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

- ELIYAHU GOLDRATT

“

”

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?

Applying TOC to organizations

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

“

”

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.

CURRENT REALITY TREE

potential root cause

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.

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.

FIVE FOCUSING STEPS OF TOC

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.

MANAGING CONSTRAINTS

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

REVIEW AND WRAP-UP

Will Evans Chief Design Officer will.evans@praxisflow.com

THANKS