Summary

Lean is the word, is the word that you heard. It’s got groove, it’s got meaning, Lean is the time, is the place, is the motion. Now, Lean is the way we are feeling, or something like that.  The book is all about Lean and the enterprise.  It attempts to make the case to look at Vision to Deployment and find delays in all parts of the process and eliminate them.  The book throws out a lot of concepts and states them as obvious facts, which most seem to be.  You read the book and you say, yes that makes sense, no need to argue.   I like the focus on features and I like the focus on business value.  If you are dealing with something that is nebolous and something that has a lot of business input and the need to get to market fast, lean is interesting.  Also, I like the looking at the whole versus the parts and saying, why, where can I improve the whole process from the big picture.  It also makes the case for Enterprise software development.

Top 3 Things I learned

•  Command (Intent) and Control (Execution) are split functions.  One is done by the senior, the other by the junior.  This holds the key to scaling.
• I liked the Iteration 0 checklist of Chapter 6.  Some good things to think about even if you are not doing Lean.

---

Notes: Introduction

SUMMARY: A gentle introduction

TERM: Principle: Comprehensive and fundamental law, doctrine, or assumption

TERM: Paradigm: Combination of things that define how to view reality or look at a situation

CONCEPT: Core beliefs of Lean

• Most errors are due to the system within with people work rather than to the individuals themselves
• People doing the work are the best ones to understand how to improve the system.
• Ad hoc is not an acceptable process
• Looking at when things are done in a process is a more useful guide than trying to make sure every step of the way is as efficient as possible.
• Our measure for success must be related to the amount of time between when ideas come in and when they are manifested as value to oru customers.
• Management must work with the team to improve the way it works to improve its own efficiency
• Teams are most efficient when the amount of work is limited to their capacity.
• Team efficiency improves by minimizing the amount of work in progress at any one time.
• When evaluating actions, we must optimize the whole, not nearly improve individual steps in the process.
• There are principles in software development that must be followed in order to reduce waste

CONCEPT: Extensions to Lean

• An enterprise focus instead of a team focus
• A product focus instead of a project focus
• Managing requirement elicitation from big picture
• Driving release planning from business value

---

NOTES: Chapter 1: An Agile Devlloper’s Guide to Lean Software Development

SUMMARY: An overview of core lean concepts, specifically, error are introduced by the system not the people, minimize the work in progress, and focus is business value, speed, and quality.  Explains how lean goes beyond just the development time and looks at the whole process from vision to product.

TERM: Principle: Underlying truth

TERM: Paradigm: A visual or contextual model that increases understanding

TERM: Practice: Application of principles to a specific situation and can and should change.

CONCEPT: Errors come from the system not the individual.  If a developer makes a lists of states without DC it is the process not the person’s fault.

CONCEPT: Last responsible moment.  Don’t make decisions too early.  Once we’ve spent time doing something it can’t be undone.

CONCEPT: Emergent Design.

• Design patterns that are resilient and flexible
• Limit design patterns to only those features that are current
• Automated acceptance and unit tests before writing code to improve the thought process and to create a test harness

CONCEPT: Causes of complexity

• Writing code that isn’t needed
• Writing code that is tightly coupled

CONCEPT: Remove delays over delivering fast

CONCEPT: Optimize the whole, not each step in the process.  If you optimize each step you create large inventories between the step.  One-piece flow.  Fast-Flexible-FLow.  Lean focuses on time, eliminate the waste of delays.  Delays represent both risk and waste.

CONCEPT: Just-in-time: exposes problems in production before they have too much impact.  Encourages us to build things in smaller batches.  quick feedback from the customer.

CONCEPT: Value Stream Mapping.  Set of actions that takes place to add value for a customer from the initial request to the delivery of the value.  Analyze the value stream.  Draw pictures of the process streams and then use them to look for waste.  Shows the entire picture. Optimize the whole by identifying waste, delays, multi-tasking, overloaded people, late detection of problems.

CONCEPT: Five Whys: cause and effect relationships underlying a particular problem until it drills down to the root cause.

---

NOTES: Chapter 2: The Business Case for Agility

SUMMARY: Six different ways agile benefits you.  Most important is stop allowing queues of unfinished work to build up

1. Add Business Value Quickly: Net Return, start to get return sooner.
2. Help clarify business needs: Start with what the customer knows best, create knowledge all the time
3. Promote knowledge based product development and Better project management.  Agile process to enable developer to utilize customer feedback
4. Motivation and early learning (Failing).  Make changes quickly
5. Product centered development
6. Improve team efficiency: Stop creating queues of unfinished work.

TERM: Minimum Marketable Features: Min Functionality before deployment. (Note to self-add to inception deck)

CONCEPT: Testing early and often does three important things:

• At release you have fairly well perfected code
• Defects will not be serious
• Allows for testing to find causes not bugs

CONCEPT: Learning (Failing) Early

• Find out what is not working
• Assumptions that are invalid
• Find out what we don’t know

---

NOTES: Chapter 3: The Big Picture

SUMMARY: Very little content.  A whole chapter to say most agile techniques only look at the development and ignore the time from vision to deployment.

---

NOTES: Chapter 4: Lean Portfolio Management

SUMMARY: Describes the term lean portfolio management – focus on business value, deliver most important features early, work in small chunks.

QUOTE: There is nothing so useless as doing efficiently that which should not be done at all

CONCEPT: Analysis in silos is a lean anti-pattern

CONCEPT: Lean thinking’s focus is on

• Sustainable speed
• Deliver important aspects first
• Minimize the work in progress
• Limit work to org capacity

CONCEPT: Why TDD

• Change tolerant design
• Confidence in aggressive design changes

TERM: Pareto Rule: Find the 20% of the work that provides 80% of the value

---

NOTES: Chapter 5: Going Beyond Scrum

SUMMARY: Compares scrum and kanban / lean.  Introduces Scrum#.  Talks about weaknesses of scrum and strength of kanban.

CONCEPT: Scrum: Build software from feedback.  Software is empirical and you cannot control it, but you can control the feedback.

CONCEPT: Scrum weaknesses (that I concur with)

• Product owners are one wring-able neck
• teams a built with generalists

CONCEPT: Product Champion: like a product owner, but relies more on leadership

TERM: Scrum#: Scrum with embedded lean

CONCEPT: Belief | Scrum | Lean

• Iterations | Time-boxed | Either Time-boxed or Flow Based
• Product Direction | Product Owner is 1 wring-able | Team is responsible
• Management | Insulate | Managers lead and coach
• How to Organize | Scrum of Scrums | Value Stream
• How to Learn | Inspect and Adapt | Work from known, good practices, plan, do, check, act
• Story Prioritization | Value to the Customer | Value to the customer and business
• Where to Start | Teams figure things out | Pay attention to batch sizes, queues, WIP, and flow

CONCEPT: Essential Practices for Scrum# (Practice | Description)

• Timely builds and Swarming | swarm on stories, bringing together all of the people required to work on a story at the time when it will do the most to decrease the overall time required to complete the story.
• Define acceptance tests prior to writing code | Ensures conversations
• Complete all stories that have been started | Fewer completed stories that many at 90 precent
• Ask good reliable questions | obvious

CONCEPT: Anti-Patterns to avoid

• Stories are not completed in an iteration
• Stories are too big
• Stories are not really prioritized
• Teams work on too many things at once
• Acceptance tests are not written before coding starts
• Quality Assurance/Testing is far behind the developers

CONCEPT: Kanban beliefs

• Software development is about creating and managing knowledge
• Software development is described in terms of queues and control loops and managed accordingly
• As information flows through a system, we must have some representation of it

CONCEPT: Differences between Kanban and common Agile practices

• Queues in front of developers must stay small
• Work as quickly as possible, but not constrained by a time-boxed system
• Entire value stream from concept to creation
• No estimation

CONCEPT: Cumulative Flow Diagram

• Measure every significant step in the process.
• Wide lines indicate an impediment or blockage of flow
• Thin lines indicate WIP is too small

---

NOTES: Chapter 6: Iteration 0: Preparing for the first Iteration

SUMMARY:  Everything in the chapter is contained in Table 6.2, a checklist for Sprint 0 (zero)

CONCEPT: Sprint 0 Checklist

• Vision
  • Product Champion prepares vision statements for the project and release
  • Team understands vision, drivers, and expected outcomes for the release
• Product Backlog.
  • Features have been prioritized and estimated
  • High-level architectural milestones have been specified
• Story Estimation
  • Stores have been decomposed and right-sized
  • Validation criteria for stories are understood
  • Stories have been estimated for fire few iterations’s work
• Iteration Backlog
  • Iteration length is set
  • Iteration backlog is established and visible
  • The team has committed to Iteration 1 plan
  • Stories are assigned for the first few iterations
• Team
  • The team is staffed with all of the needed roles dedicated to the release and co-location as much as possible
  • The team has received required training, Lean-Agile software development, Test-Driven Development, engineering practices
  • Artifacts and deliverables are determined and visible
• Testing Agreements
  • Definition of done has been established and documented (Unit, Integration, Acceptance)
• Team Environment
  • Lessons learned from previous releases have been intentionally incorporated
  • Tools for testing, coding, integrating , and building have been selected and installed
  • Logistics have been established for daily stand-up (time, location, conference-call information, portal and so on)
  • The ground rules for team life have been agreed to
  • The team workspace is organized (and cleaned up) physical , communication, and collaboration issues have been addressed
  • The team’s project board is stet up
  • The build environment has been established and tested
• Architecture
  • Architectural goals/approach have been identified and made visible
  • Dependencies and risks have been identified and made visible
  • Conceptual design has been completed

---

NOTES: Chapter 7: Lean-Agile Release Planning

SUMMARY: Details how release planning is done in lean.  Key differences are incorporating business value and focus on features and MMF before discussing stories and story points.

CONCEPT: De-scope early to focus on the critical 20% – the Pareto Rule and time-box to minimize Parkinson law about work expansion.

TERM: Lower-tech, higher touch

TERM: ELEVATION Release that are not quite real

CONCEPT: Release Planning Steps

1. ID Features (stickies)
2. Prioritize Features
3. Split features using MMF
4. Estimate Business Value of Features
5. Estimate the cost of features
6. Elaborate the features
7. Create the Release Plan
   1. By Date
   2. by Scope
8. Plan Elevation

---

NOTES: Chapter 8: Visual Controls and Information Radiators for Enterprise Teams

SUMMARY: Introduces the idea of an information radiator, which they prefer to use the term, visual control, because they see it as a tw0-way tool.

TERM: Information Radiator/Visual Control: Displays information in one place where passervy can see it.  Don’t need to ask questions simple hist them as they pass by.

CONCEPT: Good Information Radiators

• Vision
• Release Plan, Release and Project backlog
• Burnup/down chargts
• Business Value Delivered
• Impediment

CONCEPT: Product vision

• FOR <customer>
• WHO <needs statement>
• THE <product name> is a <product category>
• THAT <compelling reason to buy>
• UNLIKE <alternative>
• OUR PRODUCT <differentiator>

CONCEPT: Story Board Addition

• Build, Define, Discover
• Shows look-ahead

CONCEPT: Story Board Addition

• Dependency addition, N (iteration), N+1 (iteration), N+2 (2 iterations away)

---

NOTES: Chapter 9: The Role of Quality Assurance in Lean-Agile Software Development

SUMMARY: Discusses role of Quality Assurance in Lean, prevent defects, build quality in, eliminate waste.

TERM: Quality Assurance is suitable for the customer and built correctly.

---

NOTES: Chapter 10: Becoming an Agile Enterprise

SUMMARY: Look at various types of companies and some typical high-level challenges they face in becoming Agile.

CONCEPT: Lean Anti-Patterns

• Teams not well formed
• Teams are not co-located
• Annual planning cycles result in longer than necessary projects
• Large batches of unprioritized requirements.
• Tech and Business compete for resources
• No automated acceptance testing
• Integration done at project end
• Code quality left to programmers
• Root cause not pursued
• No emphasis on continuous process improvement

---

NOTES: Chapter 11: Management’s Role in Lean-Agile Development

SUMMARY: Not much content.  Emphasizes that lean’s management role is to see the program and to fix it versus scrum which only exposes the problem.  Lean tries to go one step more.

---

NOTES: Chapter 12: The Product Coordination Team

SUMMARY: Introduces the concept of product campion teams (PCT) and explains how they are different than a Scrum of Scrums (SoS).  Claims SoS breaks down when work must be coordinated.  I don’t like how a PCT has no authority.  I think a more clearer lines of responsibility and authority are needed before a PCT is really different from a SoS.

CONCEPT: Product Champion Teams are made up of:

• Permanent members
• Rotating members
• Planning members

---

NOTES: Chapter 13: Software Architecture and Design’s Role in Lean-Agile Software Development

SUMMARY: A very short chapter on a complex topic.  Makes a meager case for not doing any design.

CONCEPT: 

• Build only what you need at the moment
• Build in a way that allows for it to change

---

NOTES: Chapter 14: Seeing Lean

SUMMARY: A very good summary chapter, brings together concepts explored in the book.  Highlights Toyota Production System, then goes onto introduce the tree bodies of lean, insights from coaches, and then book recommendations.

TERM: Autonomation: Automation with a human touch, find and fix root cause.

CONCEPT:  3 bodies of Lean

1. Lean Science
   1. Just in Time
   2. Utilization Theory
      1. Small queues and batch sizes
      2. Limit WIP
      3. Little’s Law: Cycle Time = WIP/Througput.  Easiest thing to control is WIP
      4. Causes of Thrashing
   3. Pull Management
   4. Real options
2. Lean Management
   1. Not Servant Leaders
   2. Leaders coaches trainers
3. Lean Knowledge Stewardship
   1. A3s
   2. Kaizens
   3. AAR/Retrospectives
   4. 5 Whys
   5. Value Stream

CONCEPT: Coaches Insight

• Focus on 1 project at a time
• Fewer projects rather than work better
• Shorten batch times
• Get to the root cause
• Minimum release features
• Priorities and WIP
• Productivity and Quality
• Cross-functional teams
• Fast-Flexible-Flow

---

NOTES: Appendix A: Team Estimation Game

SUMMARY: Briefly explains planning poker

---

NOTES: Appendix B: Model of Lean-Agile Software Development

SUMMARY: Explains the basic concepts of Lean in an outline form.