You are here

Learning Lean, Part III

I've been attending a web based class on Lean development presented by Alan Shalloway. The most recent session was on the Lean-Agile Connection. See this entry and this entry for notes from previous sessions.

  • When doing value stream mapping, focus on the delays, not improving the work.
  • For example, delaying testing or integration makes debugging issues significantly more difficult.
  • Other examples include deferring decisions that don't need to be made (ex., analysis, architecture) or waiting for responses from other teams.
  • Batching increases WIP. It results in work that shouldn't be worked on. Waste increases as doing things early results in knowledge lost if it isn't used quickly. It may also result in wasting effort on things that never get used.
  • There is an analogy between this approach (focusing on delays, not improving work) and waterfall vs. agile. Waterfall tries to optimize the job done in each step along the way. Agile tries to optimize the delays.
  • The biggest risk in software is building software that is not needed! i.e., misunderstanding customer needs.
  • Refactoring = changing code without adding features.
  • Even if you write high quality code, design needs to adapt (be refactored) to accomodate new requirements.
  • Refactor the design so that it fits the new requirements and then add the new functionality. This is just in time design. You add complexity of design when you need it.
  • High code quality, but insufficient tests means you can make code changes easily, but without safety.
  • High code quality and good tests mean you can make changes easily and safely.
  • It is more wasteful to anticipate future need and to carry that additional complexity.
  • Complex scheduling systems never work in the face of variation, surprises, or unknowns.
  • Larger project size => more in progress at once => more thrashing => average project length increases
  • The best people tend to get involved in the most projects resulting in big hits to their productivity due to thrashing. Ironically this causes others to think of these people as unresponsive when really they are high performers in a sub-optimal system.
  • It is generally not a good idea to change team composition frequently. Team members learn how to work together over time.
  • Most agile teams who fail do so because they don't understand the underlying principles.

P.S. For those also taking the class, it appears I didn't summarize the third session. These notes are actually from the fourth session.

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer