Book notes: Implementing Lean Software Development
Tags: books, lean
Published: 2020-09-15 17:45:51

---
title: Book notes: Implementing Lean Software Development
published: true
tags: books,lean
canonical_url: https://danlebrero.com/2020/06/24/implementing-lean-software-development-book-summary/
description: Book notes on "Implementing Lean Software Development"
cover_image: https://danlebrero.com/images/blog/implementing-lean-software-development.jpg
series: Book notes
---

These are my notes on [Mary Poppendieck](https://twitter.com/mpoppendieck) and Tom Poppendieck's [Implementing Lean Software Development](https://www.amazon.com/Implementing-Lean-Software-Development-Concept/dp/0321437381). 

After reading [The Lean Mindset](https://danlebrero.com/2020/03/04/the-lean-mindset-summary/#content), I decided to reread my old (13 years!) "Implementing Lean Software Development" copy. Unsurprisingly, most of the content still applies today.

# Key Insights

- Software development is a knowledge-creating process.
- Process should be improved by the team doing the work.
- Instead of predicting the future, aim to reduce response time so we can respond correctly as the future unfolds.
- Product quality is determined by quality of information flow.
- The cost of complexity is exponential.
- Dont automate complexity. Simplify before automating.
- Synergy between parts of any system is the key to the success of the system.
- When things go wrong, the cause is inherent to the system, and therefore is a management problem.
- Build cause of low quality and productivity is inherent to the system, hence must change the system to address those.
* The thing that turns a group into a team is the mutual commitment of the members to pool their various skills and work together for a common purpose.
* Teamwork is essential, but someone always needs to be responsible.
* You get what you reward:
    * Find effective ways to reward collaboration.
* Decisions: First decide when the decision must be made.
* IT Contracts: focus on how parties will work together to determine what to deliver, instead of an specification of what to build.
* Measure a few key indicators:
    - cycle time.
    - financial results.
    - customer satisfaction (NPS).
               
# TOC

* [1 - History](#ch-1)
* [2 - Principles](#ch-2)
* [3 - Value](#ch-3)
* [4 - Waste](#ch-4)
* [5 - Speed](#ch-5)
* [6 - People](#ch-6)
* [7 - Knowledge](#ch-7)
* [8 - Quality](#ch-8)
* [9 - Partners](#ch-9)
* [10 - Journey](#ch-10)

# <a name="ch-1"></a>Chapter 1 - History

Main point repeated in other chapters.
 
## <a name="ch-2"></a>Chapter 2 - Principles

- Software development should be an empirical process.
- 7 Principles:
    1. Eliminate waste.
    1. Build Quality in:
        - Target is to not need a defect tracking system.
        - Job of testing is to prevent defects.
        - If final verification routinely triggers test-and-fix cycles, then the development process is defective.
    1. Create Knowledge:
        - Codify knowledge for use in future products is essential.
        - Instead of predicting the future, aim to reduce response time so we can respond correctly as the future unfolds.
    1. Defer commitment:
        - Make decisions reversible.
        - Last responsible moment.
        - Plans are useless, planning is indispensable -- Eisenhower.
    1. Deliver fast:
        - Repeatable and reliable speed is impossible without superior quality.
        - Deep customer understanding.
    1. Respect people:
        - Give people goals.
        - Process should be improved by the team doing the work.
    1. Optimize the whole (value stream):
        - From order to real need is addressed.
        - Crossing organizational boundaries is expensive.
        
## <a name="ch-3"></a>Chapter 3 - Value

* Product development performance (Clack and Fujimoto, 1991):
    - Product quality is determined by quality of information flow.
    - Customer quality: flow between marketplace and development team.
    - Technical quality: flow between technical team members.
* To facilitate information flow:
    1. Leadership:
        * Champion:
            * Understands the customer's job.
            * Understands the technology that surprise them.
            * Makes key product decisions.
            * Accountable.
            * Possible models:
                1. Chief engineer:
                    * Learn what the customer wants.
                    * With senior management direction.
                    * Role: Integrate knowledge.
                1. Leadership team:
                    * Market expert + Technical expert (+ manufacturing expert)
                1. Shared leadership.
    1. Complete teams: Marketing + customer support + ops.
* Delight customers:
    * Discover needs that customer is not aware of.
    * Exponential increase in satisfaction ([Kano model](https://en.wikipedia.org/wiki/Kano_model)).
* Internal IT should be run as a software company:
    * Research what the market wants. Do not expect other to do it.
    * Perform cost/benefit analysis. Do not implement everything that business asks for.
    * Products are successful. Do not leave all responsibility to the business unit.
    * Accountability rests on the business funding the effort.
       
## <a name="ch-4"></a>Chapter 4 - Waste

* Waste: Anything that does not add customer value or delays it.
* Write less code:
    * The cost of complexity is exponential.
    * Justify every feature.
    * Less bugs.
    * Minimum useful feature set.
    * Dont automate complexity. Simplify before automating.
* Seven wastes:
    * Partially done work:
        * Avoid with small batches.
        * Too early requirements.
        * Long live branches.
        * Untested code.
        * Undocumented features.
        * Undeployed code.
    * Extra features.
    * Relearning:
        * Retrying something that did not work in the past.
        * Not leveraging on existing knowledge.
    * Hand-offs: tacit knowledge is lost.
    * Task switching.
    * Delays.
    * Defects.
* Mapping the value stream:
    * Find the delays (queues) and loop-backs (churn).
    * Map the process, not an event.
    * Concept to cash.
    * Preparation:
        * What to map.
        * When to start/stop the timeline.
        * Approval process should be included.
    * Value from the point of view of the customer.
    * Identify value stream owner.
        * Someone that cares about organization cross-boundary issues.
    * Keep it simple:
        * About 10 steps.
        * Value stream maps have no value by themselves.

## <a name="ch-5"></a>Chapter 5 - Speed

* Speed is the absence of waste.
* Cycle time is the measurement that alert us when anything is going wrong.
* [Little's Law](https://en.wikipedia.org/wiki/Little%27s_law): in a stable system cycle time = things in process / average completion time. 
* Reduce cycle time by:
    * Reduce WIP. (<-- cheaper)
    * Increase speed.
    * Event out the arrival of work.
    * Establish regular cadence:
        * If big flurry of activity at the end of iteration, then iteration is too long.
    * Limit work to capacity.
    * Use pull schedule:
        * Queuing at the edges of the organization.
        * Keep queues short: two cycles of work.
        * Changes in queues are ok, but not once the work is being done.
        * Team pulls works.
        * Queue must have a max size.
* Unstable systems:
    * High variation: Fix by small batches.
    * High utilization: Above 80%, things start to slow down.
    
## <a name="ch-6"></a>Chapter 6 - People

* [System of profound knowledge](https://medium.com/10x-curiosity/system-of-profound-knowledge-ce8cd368ca62) (Edwards Deming):
    1. Appreciation for a system:
        * Synergy between parts of any system is the key to the success of the system.
    2. Knowledge about variation:
        * Build cause of low quality and productivity is inherent to the system, hence must change the system to address those.
    3. Theory of knowledge:
        * [Deming cycle](https://en.wikipedia.org/wiki/PDCA): plan, do, check, act.
    4. Psychology: 
        * When it comes to people, things that make a difference are skills, pride, expertise, confidence and cooperation.
* Deming's 14 points on quality for management (page 122):
    * (1) Dont focus on short-term profitability.
    * (3) Quit depending on inspection to find defects.
    * (6) Institute training.
    * (8) Drive out fear.
    * (9) Break down barriers between departments. Do not undermine team cooperation by rewarding individual performance.
    * (11) Eliminate arbitrary deadlines. This is management by fear.
* When things go wrong, the cause is inherent to the system, and therefore is a management problem.
* Toyota's real innovation is its ability to harness the intellect of "ordinary" employees.
* Do you talk about trust with suppliers but insist on fixed price contracts?
* The thing that turns a group into a team is the mutual commitment of the members to pool their various skills and work together for a common purpose.
* Teamwork is essential, but someone always needs to be responsible.
* Process leadership != product leadership != technical leadership.
* Responsibility based planning and control:
    * Chief engineer sets synchronization events. Teams figure themselves how to meet them.
    * Remember to:
        * Give people the time to do the job.
        * Details will/can change.
        * Limit work to capacity.
    * The job of managing dependencies should fall to the system design, not the schedule.
* Self-directing work: everybody can figure out what is the most important thing they can do without being told.
    * Three levels of info:
        1. Kanban:
            * Challenges:
                * Right size.
                * Enough detail.
                * Correct priority
            * The card is not a specification.
            * The card is a signal to bring together the right people to create the detailed design, verifications and implementations.
        2. Anden: Board with any abnormalities that requires attention.
        3. Dashboard:
            * How do people know their progress towards meeting the overall goal of their work?
            * How well the team is doing.
* Two types of companies:
    * Economic company: exchange your skills for remuneration.
    * River company: exchange your care and commitment for the fact that the company will try to develop you to your maximum potential.
* Eliminate annual performance ratings: They kill cooperation and pride.
* You get what you reward: Find effective ways to reward collaboration.
* Performance evaluation: time set aside to reflect on where your potential lies and next steps to develop that potential.
* When an employee is not performing, the first question a manager should ask is: What am I doing wrong?
* Compensation:
    1. Make sure the promotion system is unassailable.
    2. De-empathize annual raises.
    3. Reward based on span of influence, not span of control.
    4. Find better motivators than money.
    
## <a name="ch-7"></a>Chapter 7 - Knowledge

* First step in any improvement effort should be to ask two basic questions (Art Smalley):
    * How do you intend to make a profit and satisfy your customers?
    * What exactly is your main problem?
* Disciplined problem-solving method. Train everybody on this.
* Piles of documentation are useless as a learning tool:
    * Condense knowledge in a A3.
    * If it does not fit an A3, use an A4.
* Decisions:
    * First decide when the decision must be made.
* The work of any SW development process is to create knowledge that gets embedded in the software.
* Set-Based design:
    * Implement several options at the same time.
    * Each option is better but less likely to hit the deadline.
    * When to use:
        * Unmovable deadline.
        * Failure is not an option.
    * Best method to meet deadlines and to learn the most.
* Refactoring is the fundamental enabler of limiting code complexity, increase change tolerance, value and longevity of the code.
* Kaizen Events:
    * Representatives from different functional areas to work intensely for a few days to solve a well defined critical problem.
* For longer improvements, see GE Workout.

## <a name="ch-8"></a>Chapter 8 - Quality

* Prioritize:
    1. High value before lower value.
    2. High risk before lower risk.
    3. Features that create new knowledge before those well understood.
    4. Lower cost before higher cost.
* Standards: follow them, but also challenge them.
* Pair programming, automation, TDD, CI.
    
## <a name="ch-9"></a>Chapter 9 - Partners

* The fundamental reason for partnership is synergy: achieve better results through cooperation.
* Fuelled by trust and paid with applause.
* How to build global teams:
    * Frequent integration.
    * Exchange people.
    * Exchange tests.
    * Proxy: one person acting as a proxy of a full remote team.
    * Traveling team leader.
    * No second-hand citizens.
* Outsourcing: avoid conflict of interest of employees and companies involved.
* Contracts' purpose, either:
    1. Protects each party from opportunistic behaviour.
    2. Setup appropriate incentives to work together in a synergistic way.
* [Relational contracts](https://en.wikipedia.org/wiki/Relational_contract)
* IT Contracts: focus on how parties will work together to determine what to deliver, instead of an specification of what to build.

## <a name="ch-10"></a>Chapter 10 - Journey

* Start lean initiative by answering:
    1. How do you create value for customers and make a profit?
    2. What is your main problem right now?
    3. What threatens your continued existence?
    4. What do you really believe about people?
* Effective way to start lean development:
    1. Train team leaders and supervisors.
    2. Emphasize on-the-job thinking.
    3. Measure a few key indicators:
        - cycle time.
        - financial results.
        - customer satisfaction (NPS).
* Automation should aim to "upskill" workers, not "deskill" the process.
* Theory of Constraints:
    * New technology is useful if it removes a limitation.
    * We must deal with the existing accommodations: existing rules/mechanisms to cope with the limitation.
* Critical chain:
    * Theory of constraints applied to projects.
    * Product development is a project.
    * Key constraint: estimates regarded as commitments.
    * Because of this, people over-estimate, and then [Parkinson's law](https://en.wikipedia.org/wiki/Parkinson%27s_law).