Book notes: Implementing Lean Software Development

These are my notes on Mary Poppendieck and Tom Poppendieck's Implementing Lean Software Development.

After reading The Lean Mindset, 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
• 2 - Principles
• 3 - Value
• 4 - Waste
• 5 - Speed
• 6 - People
• 7 - Knowledge
• 8 - Quality
• 9 - Partners
• 10 - Journey

Chapter 1 - History

Main point repeated in other chapters.

Chapter 2 - Principles

• Software development should be an empirical process.
• 7 Principles:
  1. Eliminate waste.
  2. 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.
  3. 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.
  4. Defer commitment:
     • Make decisions reversible.
     • Last responsible moment.
     • Plans are useless, planning is indispensable -- Eisenhower.
  5. Deliver fast:
     • Repeatable and reliable speed is impossible without superior quality.
     • Deep customer understanding.
  6. Respect people:
     • Give people goals.
     • Process should be improved by the team doing the work.
  7. Optimize the whole (value stream):
     • From order to real need is addressed.
     • Crossing organizational boundaries is expensive.

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:
         2. Leadership team:
         3. Shared leadership.
  2. Complete teams: Marketing + customer support + ops.
• Delight customers:
  • Discover needs that customer is not aware of.
  • Exponential increase in satisfaction (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.

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.

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

Chapter 6 - People

• System of profound knowledge (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: 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.

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.

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.

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
• IT Contracts: focus on how parties will work together to determine what to deliver, instead of an specification of what to build.

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.