Flow-Based Product Development

Notes for the book The Principles of Product Development Flow: Second Generation Lean Product Development (Amazon) by Donald Reinertsen.

As a summary

• The author has a strongly opinionated view on how product development should be done
• The book is built as a collection of principles for various areas
• The author takes inspiration to product development from various domains (e.g. queuing theory, data communication networks, warfare)

The Principles of Flow

It ain't what you don't know that gets you into trouble. It's what you know for sure that just ain't so. (Mark Twain)

• The author states that the dominant paradigm for managing product development is fundamentally wrong.
• New paradigm emphasizing achieving flow, emphasizing e.g. small batch transfers, rapid feedback and limiting WIP.
• Could be labeled Lean Product Development (LPD), though lean manufacturing has very different characteristics than product development.
• Also ideas from different domains -> the new paradigm is called Flow-Based Product Development

What's the problem?

• Current paradigm based on internally consistent but dysfunctional beliefs.
  • E.g. combining the belief that efficiency is good with a blindness to queues -> high levels of capacity utilization -> large queues and long cycle times

Problems with the current orthodoxy:

1. Failure to Correctly Quantify Economics

• E.g. Focusing too much on proxy variables

2. Blindness to Queues

• Too much design-in-process inventory (DIP)
• Why? Because DIP is typically both financially and physically invisible
• Also we're often bind to danger with high level of DIP

3. Worship of Efficiency
4. Hostility to Variability

• Without variability, we cannot innovate.
• Variability is only a proxy variable

5. Worship of Conformance

• Utilizing the valuable new information constantly arriving throughout the development cycle.

6. Institutionalization of Large Batch Sizes

• Coming from blindness towards queues and focus on efficiency
• Blindness to the issue of batch size

7. Underutilization of Cadenza

• E.g. meetings with regular and predictable cadenza have very low set-up cost.

8. Managing Timelines instead of Queues

• Failure to understand the statistics of granular schedules
• Queues are better control variable than cycle time because today's queues are leading indicators of future cycle-time problems

9. Absence of WIP Constraints
10. Inflexibility

• Specialized resources and high levels of utilization -> delays
• How to tackle it? Currently focus on the variability
• Instead, book recommends focusing to making resources, people and processes flexible

11. Non-economic Flow Control

• Current systems to control flow are not based on economics.

12. Centralized Control

Major themes of the book

The book has eight major themes and a major chapter for each.

• Economics - Economically-based decision making
• Queues - Even a basic understanding of queuing theory will help a lot with product development
• Variability
• Batch Size
• WIP Constraints
• Cadenza, Synchronization and Flow Control
• Fast Feedback (Loops) - Suggesting that feedback is what permits us to operate product development process effectively in a noisy environment
• Decentralized Control

Relevant idea sources used

• Lean Manufacturing
• Economics
• Queuing Theory
• Statistics
• The Internet (protocols)
• Operating System Design
• Control Engineering
• Maneuver Warfare

The Design of the book

• The book is organized into principles by theme
• A complete list of 175 principles can be found from The 175 Principles of Flow from the book website. (Found also from Spine Model Catalog)

The economic view

• Why do we want to change the product development process? The answer: To increase profits.
• Proxy objectives/variables often used
• Experience on asking people what a 60 day delay late to market for a project would cost the company - Typically range of 50 to 1 in answers
• Approach product development decisions as economic choices

The Nature of Our Economics (Principles E1-E2)

• Select actions based on quantified overall economic impact.
• Five key economic objectives: Cycle time, product cost, product value, development expense and risk
• We can’t just change one thing.

The Project Economic Framework (Principles E3-E5)

• Unit of measure for a product and project: Life-cycle profit impact
• If you only quantify one thing, quantify the cost of delay.

The Nature of Our Decisions (... E6-E11)

• Important trade-offs are likely to have U-curve optimizations.
• Important properties of U-curves
  • Optimization never occurs at extreme values
  • Flat bottoms -> U-curve optimizations do not require precise answers
• See e.g. this blog post
• Even imperfect answers improve decision making
• Many economic choices are more valuable when made quickly.

Our Control Strategy (E12-E15)

• Background: Many small decisions creating most value when done quickly
• Use decision rules to decentralize economic control
  • Instead of controlling the decisions, control the economic logic of the decisions.
• Ensure decision makers feel both cost and benefit.
• We should make each decision at the point where further delay no longer increases the expected economic outcome.

Some Basic Economic Concepts (E16-E18)

• Importance of marginal economics to e.g. avoid "feature creep"
• Avoid "Sunk cost" fallacy, instead look at the return of the remaining investment

Debunking Some Popular Fallacies (E19-E21)

• Concept of set-based concurrent engineering (SBCE)
  • Trading development expense for risk reduction
• High probability of failure does not equal bad economics
  • See e.g. Newsboy problem

Managing Queues

• Festina lente
  • Time spent in queues might be more important than speeding up the activities

Queuing theory basics

• Queuing Theory originates from telecommunication
• Basic concepts
  • Queue - Waiting work
  • Server - Resource performing work
  • Arrival process - The pattern with which work arrives (can be unpredictable)
  • Service process - The time it takes to accomplish the work (can be unpredictable)
  • Queuing discipline - The sequence/pattern in which waiting work is handled
• A simple queue: M/M/1/∞ (Kendall notation)
  • First "M" - Arrival process (here a Markov process)
  • Second "M" - Service process (also a Markov process)
  • 1 - Number of parallel servers
  • ∞ (infinite) - (No) upper limit on queue size
• Measures of queue performance
  • Occupancy
  • Cycle time

Why Queues Matter (Q1-Q2)

• Idle time increases inventory, which is the root cause of many other economic problems.
• In manufacturing, we are often aware of work-in-progress (WIP) inventory. But in product development, we're often not aware of the design-in-progress (DIP) inventory.
• Product development queues are often bigger than manufacturing queues.
• Product development queues are often invisible -> not sticking into the eye.
• Effect of queues:
  • Increased cycle time
  • Increased risk
  • Increased variability
  • Increased overhead
  • Lower quality (by delaying feedback)
  • Negative psychological effect

The Behavior of Queues (Q3-Q8)

• For M/M/1/∞ queue, capacity utilization (𝜌) allows to predict many properties of the queue
  • E.g. Number of Items in the Queue: 𝜌/(1-𝜌) -> as the utilization starts approaching 100%, the queues start grow exponentially
• Capacity utilization is difficult to measure. Instead, queue size and WIP/DIP are practical factors to measure.
• See also A Dash of Queueing Theory - A good blog post on the topic with live simulations of various processes
• High-state queues cause most economic damage
• If possible to balance the load / share a queue between multiple servers, that helps to manage queues. See M/M/c queue for more details (the book uses term M/M/n queue)

The Economics of Queues (Q9-Q10)

• Find optimum queue size with quantitative analysis, avoiding simple "Queues are evil"
• Scheduling affects the queue cost (more on scheduling later)

Managing Queues (Q11-Q16)

• Cumulative Flow Diagrams (CFDs) are useful for managing queues
• Little's Law: Mean response time = mean number in system / mean throughput
  • Can be applied both to a queue or to the system as a whole
• Control queue size instead of utilization or cycle time
• From statistics of random processes: Over time, queues will randomly spin seriously out of control
  • The distribution of cumulative sum or a random variable flattens as N grows
• "We can rely on randomness to create a queue but we cannot rely on randomness to correct this queue"
• -> Monitoring the queues and intervening when needed

Exploiting variability

We cannot add value without adding variability but we can add variability without adding value

• Economic cost of variability (by an economic payoff-function) is more important than amount of variability

The Economics of Product Development (V1-V4)

• Risk-taking is central to value creation in product development.
• We cannot maximize economic value by eliminating all choices with uncertain outcomes
• Asymmetric Payoff is important with creating economic value with variability (See e.g. Product Development Payoff Asymmetry)
  • Note that payoff functions in product development are different than in manufacturing as in manufacturing variance is most typically a negative thing.
• Variability is not desired or undesired as such. Instead, it is desired when it increases economic value.
  • -> It shouldn't be minimized or maximized
• A 50% failure rate is usually optimum for generating information. Note here that all activities are not designed to maximize information, though.

Reducing Variability (V5-V11)

• Two main approaches to improve the economics of variability
  • Change the amount of variability
  • Change the economic consequences of variability
• Diffusion principle: When uncorrelated random variables are combined, the variability of the sum decreases.
  • E.g. diversifying a stock portfolio
  • Doing many small experiments instead of one big one.
• Repetition and reuse reduce variation
• With buffers we can trade e.g. cycle time for reduced variability in cycle time
  • -> Finding the best amount of buffering (not minimizing buffer nor maximizing confidence)

Reducing Economic Consequences (V12-V16)

• Usually the best way to reduce cost of variability
• Rapid feedback
• Aim to replace expensive variability with cheap variability.
• Note: Often it is better to improve iteration speed than defect rate.

Reducing batch size

• Product developers don't usually think of batch size, which would be an important tool to improve flow

The Case for Batch Size Reduction (B1-B10)

• Reducing batch size (normally)
  • Reduces cycle time
  • Reduces variability
  • Accelerates feedback
  • Reduces risk
  • Reduces overhead
• Whereas large batch sizes (normally)
  • Reduce overall efficiency
  • Lower motivation
  • Cause exponential cost and schedule growth
  • Lead to even larger batches

The Science of Batch Size

• Economic batch size is usually a U-curve optimization (see Economic Order Quantity (EOQ))
• Batch size reduction often lowers transaction costs, which saves more than originally assumed
  • -> Usually we don't know the optimum batch size without testing and measuring.

Managing Batch Size

• Separate
  • "production change batch" - Changing the state of the product
  • "Transport batch size" - Changing the location of the product (typically more important)
• To enable small transport batch size, reduce distances. -> Co-locate teams etc.
• Note: Small batches require good infrastructure
• Consider sequence/order of batches
• Adjust batch sizes as the context changes

Applying WIP constraints

It is easier to start work than it is to finish it

Start finishing, finish starting.

• A tool to respond to growing queues
• WIP constraints, can be seen in e.g.
  • Manufacturing - Toyota Production System (TPS)
    • Note: Mainly repetitive and homogenous flows
  • Telecommunication networks & protocols as inspiration
    • Assuming highly variable, nonhomogeneous flows

The Economic Logic of WIP Control (W1-W5)

• WIP constraints
  • Enable controlling cycle time and flow
  • Note that also reject potentially valuable demand and reduce capacity utilization
  • -> Cost-benefit analysis
  • Force rate-matching
• Theory of Constraints (TOC)
  • Identifying the bottleneck in the process -> work according that
  • A global constraint
  • Useful for predictable and permanent bottlenecks
• When possible, constrain local WIP pools (Local Constraints)
  • E.g. TPS Kanban system
  • Useful when there is no predictable/permanent bottleneck

Reacting to Emergent Queues (W6-W14)

• The core of managing queues is not in monitoring queues but the actions when the limits are reached

Various ways to respond to high WIP

• Demand-focused
  • Block all demand on WIP higher limit
  • Purge low-value jobs on high WIP - Kill the "zombie projects"
  • Shed requirements
• Supply-focused
  • Extra resources
  • Part-time resources for high variability tasks
  • Powerful experts to emerging bottlenecks
  • T-shaped resources
  • Cross-training
• Mix change

WIP Constraints in Practice (W15-W23)

• W15-W23 are practical principles for controlling WIP
• As one pick: Inspired by Internet protocols "window size", adjust WIP as capacity changes

Controlling Flow Under Uncertainty

Anyone can be captain in a calm sea

• WIP constraints are important but don't solve all our problems.

Congestion (F1-F4)

• Congestion: A system condition combining high capacity utilization and low throughput
• Traffic flow = Speed x Density
  • Vehicles/hour = Miles/hour x Vehicles/Miles
• Bruce Greenshield's Traffic Flow Model
  • As speed increases, the distances increase and the density decreases
  • Throughput is a parabolic curve - Low throughput at both extremes
  • Low-speed operating point ("left") is inherently unstable
    • Increasing density -> Speed decreases -> Flow decreases -> Density increases
  • High-speed operation point ("right") is inherently stable
    • Increasing density -> Decreasing speed -> Increasing flow -> Decreasing Density
  • See also "Traffic Flow Theory" section at The Science of Kanban - Process
• For a system with a strong throughput peak, we usually want to operate near that point
  • To maintain the system at desirable operation point, easiest to control occupancy (a more general term for density)
• Use expected flow time instead of queue size to inform users of congestion

Cadence (F5-F9)

• Cadence - Use of a regular, predictable rhythm within a process
• Can be used to e.g.
  • Limit the accumulation of variance
  • Make waiting times predictable
  • To enable small batch sizes
• Some examples for use of cadence: Product introduction, testing, project meetings, ...

Synchronization (F10-F14)

• Synchronization vs cadence
  • Cadence causes events to happen at regular time intervals.
  • Synchronization causes multiple events to happen at the same time.
• Valuable when there is economic advantage from processing multiple items at the same time.

Sequencing Work (F15-F21)

• Sequencing in manufacturing vs product development
  • In manufacturing, like the Toyota Production System, work is processed on a first-in-first-out (FIFO) basis
  • Product development is different as both delay costs and task durations vary among projects.
  • Hospital emergency room is a good mental model for sequencing work
• The author emphasizes two points
  • Complex prioritization algorithms often used - Instead prefer a simple approach. (Prevent big mistakes)
  • Sequencing matters most when queues are large - Operating with small queues, sequencing is not needed so much
• When delay costs are homogenous, do the shortest job first (SJF)
• When job durations are homogenous, do the high cost-of-delay job first (DCS)
• When delay costs and job durations are not homogenous, do the weighted shortest job first (WSJF)
• Three common mistakes with prioritizing
  • Prioritizing purely on ROI.
  • FIFO
  • Critical chain (not optimal when projects have different delay costs)

Managing the Development Network (F22-F28)

• Ideas based on managing product development resource network with ideas from managing a data communication network
• Routing tailored for tasks
• Routing based on current most economic route - Often can be selected only at a short time-horization
• Alternate routes to avoid congestion
• ...
• Flexibility helps to absorb variation but requires pre-planning and investment.

Correcting Two Misconceptions (F29-F30)

• "It is always preferable to decentralize all resources to dedicated project teams"
  • Often the case but not always
  • Centralized resources can enable variability pooling and thus reduce queues
• "Queueing delays at a bottleneck are solely determined by the characteristics of the bottleneck"
  • The process before the bottleneck has also an important influence
  • -> Aim to reduce variability before a bottleneck.

Using fast feedback

• Use of feedback loops and control systems
• Combining ideas from economics and control systems engineering
• Issues of dynamic response and stability
• This material will required a mental shift for people with manufacturing or quality control background
  • In economics of manufacturing, payoff-functions have the inverted U-shape curve - Larger the variance create larger losses
  • Product development is different as the goals are dynamic and payoff functions can be asymmetric
• Fast feedback can alter the economic payoff-function as fast feedback
  • ... allows to truncate unproductive paths more quickly
  • ... allows to raise the expected gains by exploiting good outcomes

The Economic View of Control (FF1-FF6)

• What makes a good control variable?
  • Economic influence
  • Efficiency of control
  • Ones that allow early intervention
• Focus on controlling economic impact instead of focusing on the proxy variables
  • -> E.g. set "alert thresholds" to points of equal impact
• Note the difference between static and dynamic goals
  • In product development, we continually get better information that allows to reevaluate and shift the goals

The Benefits of Fast Feedback (FF7-FF8)

• Fast feedback
  • Enables smaller queues
  • Allows to make learning faster and more efficient
• Typically it requires investment to create an environment to extract the smaller signals

Control System Design (FF9-FF18)

• Note the difference between a metric and a control system
  • "What gets measured might not get done"
• Short turning radius reduces the need for longer planning horizons -> reduces the magnitude of the control problem
• Prefer local feedback
• Combine long and short control loops
  • short time horizon for adapting to the random variation of the process
  • long time horizon for improving process characteristics considered causal to success

The Human Side of Feedback (FF19-FF24)

• Colocation typically improves communication
  • Faster feedback
  • Psychological aspects
• Faster feedback improves the sense of control
• Large queues prevent an atmosphere of urgency
• Human elements tend to amplify large excursions -> Aim to keep the system within a controllable range
• Balance personal/local/overall basis of rewarding to align behaviors

Metrics for Flow-Based Development

• For a list, see page 15 of Agile Metrics at Scale
• Flow
  • Design-in-process inventory (DIP)
  • Average flow time
• Queues
  • Number of items in queue (easy)
  • Estimate amount of work in queue (difficult)
  • Quite often the first one is surprisingly effective and enough

Achieving Decentralized Control

• Decentralized control allows fast local feedback loops (the topic of the previous chapter) to work best
• Examining what we can learn from military doctrine
  • Military has long history on balancing centralized and decentralized control
  • Advanced models of centrally coordinated, decentralized control
• The Marines
  • ... believe that warfare constantly presents unforeseen obstacles and unexpected opportunities.
  • ... believe that the original plan was based on imperfect data

How Warfare works

• Typically one side attacks and the other defends
  • Typical understanding: attack and defense require different organizational approaches
  • Old military adage: Centralize control for offense, decentralize it for defense
  • Rule of thumb: For an attacker to succeed, they should outnumber defenders by 3 to 1
• Attacker can concentrate the forces, the defender must allocate forces to the entire perimeter
• Various approaches for the defender
  • Harden the perimeter at the most logical places for attack. But, often circumvented
  • Better: Mass nearby forces to counteract the local superiority of the attacker.
  • Related: Defense-in-depth approach: Outer perimeter that slows attacking forces, allowing to move more defending forces to the area of the attack.
• Maneuver warfare: Use of surprise and movement

Balancing Centralization and Decentralization (D1-D6)

• Decentralize control for problems and opportunities that are best dealt with quickly
• Centralize control for problems that are infrequent, large or have significant economies of scale
• Adapt the approach as the knowledge increases
  • Triage process approach (works if there is enough information when a new problem arrives)
  • Escalation process
• Value of faster response time can out-weight the inefficiency of decentralization
• Pure decentralization is rarely optimal, instead finding a balance

Military Lessons on Maintaining Alignment (D7-D16)

• Misalignment is the risk of decentralized control

  • Locally optimal choices might be bad at the system level
  • Overall alignment creates more value than local excellence

• Maintaining alignment is "the sophisticated heart of maneuver warfare"

• Mission: Specify the end goal, its purpose and minimal possible constraints

• Establish clear roles and boundaries

  • Avoid both excessive overlap and gaps

• Designate a main effort and focus on it

  • Often only a small set of product attributes truly drive success

• The main effort can be shifted when conditions change

  • -> Develop ability to quickly shift focus
  • OODA loop (Orient->Decide->Act->Observe->) by Colonel John Boyd

• Localize tactical coordination

• Make early and meaningful contact with the problem

  • In product development, our "opposing forces" are the market and the technical risks
  • There is no substitute for quick POC-ing and early market feedback

The Technology of Decentralization (D17-D20)

• Key information is needed to make decisions -> share
  • In the Marine Corps, the minimum is to understand the intentions of commanders two level higher in the organization
• Accelerate decision-making speed
  • Fewer people and layers of management -> Giving authority, information and practice to lower organizational levels to make decisions.
  • When response time is important, measure if.

The Human Side of Decentralization (D21-D23)

• Cultivate Initiative
  • The Marines view initiative as the most critical quality in a leader.
• Face-to-face communication
• Decentralized control is based on trust. Trust is built through experience.

Links

• See also book website lpd2.com