Book notes: Implementing Lean Software Development

#books #lean

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

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.