@DanLebrero.

software, simply

Book notes: Implementing Lean Software Development

Book notes on "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

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:
            • Learn what the customer wants.
            • With senior management direction.
            • Role: Integrate knowledge.
          2. Leadership team:
            • Market expert + Technical expert (+ manufacturing expert)
          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:
    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.


Did you enjoy it? or share!

Tagged in : book notes