Implementing Lean Software Development – Part 1

At midday yesterday my carpool buddy and I looked at the weather map, saw a scary blob of impending frozen doom, and decided to heed the Governor’s advice to go home. But the snow that was forecast — the blizzard that was supposed to mess up the evening commute — never really materialized here in the Commonwealth. Oh well. Only 1-2″ to shovel.

While working away the afternoon at home, I started reading Mary and Tom Poppendieck‘s Implementing Lean Software Development. I guess “rereading” would be more accurate, this time with an eye toward actually implementing the ideas. Here are my notes from the first few chapters.

What is Lean Production?

  • Use just-in-time (JIT) flow of work products.
  • Stop the line to fix problems as soon as they are discovered.
  • Eliminate stockpiles of in-process inventory. Create small batches.
  • Make mistakes impossible from the beginning.

Product development is knowledge creation via exploration of designs, experimentation with prototypes, and integration meetings that evaluate designs and make decisions.

Schedules have synchronization points, but let expert workers function autonomously between them.

Explore multiple options and make competing prototypes. Defer the decision about which to actually build until the right time (usually later than you think).

Software should be easy to change. Employ all of those high-quality best practices and metrics during construction.

The Toyota Product Development System — upon which the Poppendiecks base their book — is very empirical. The final idea/design/product emerges during development. At the outset, define the goals to meet, not the technology or architecture you’re going to use to satisfy it.

1: Eliminate Waste — Minimize the time from request to fulfillment

  • Waste is everything that doesn’t actually add value to a customer feature. Focus on value.
  • Reduce the amount of partially done work (inventory). [Basically, don't work on what you haven't been asked for, and complete what you start. Get it written, tested, checked-in, and reviewed.]
  • Reduce the time between requirements, coding and testing. This helps reduce requirements churn. Use test-driven development (TDD). Shun “big bang” integration.
  • Avoid extra features and scope bloat.

2: Build Quality In

  • Control the conditions for creating quality components, preventing defects.
  • Write tests first. Use TDD.
  • Continuously integrate. Integrate code and tests together.
  • Write less code. Keep it clean and simple. Don’t duplicate. Refactor.

3: Create Knowledge

  • Go from a sketch to detailed design during construction.
  • Release a minimal set of functionality to customer for feedback.
  • Create daily builds and get feedback (knowledge) from integration tests.
  • Have an experienced team. Pour learning back into the team.
  • Build a modular architecture that supports adding/changing features as you learn more.
  • Generate new knowledge through disciplined experimentation. Codify that knowledge and make it available to the larger organization. Build a knowledge base. Encourage long-term thinking.
  • Continuously improve processes.

4: Defer Commitment

  • Try to make most design decisions reversible/undoable/nonbinding.
  • Schedule irreversible decisions for the last possible responsible moment.
  • Always move toward the concrete, and identify where change is likely to occur.
  • Experimentation reduces the risk of making the wrong decision.
  • Planning is an exercise, but plans are overrated. Avoid “plan-driven methods.”

5: Deliver Fast — Compete on time

  • Be faster than your customers’ ability to change their minds.
  • Requires low defect rates, high quality processes, good understanding of the customer.

6: Respect People

  • Favor ownership at the worker level, not top-down.
  • An entrepreneurial leader should own the product and foster engagement.
  • Develop and nurture technical expertise as a competitive advantage.
  • Give general plans with reasonable goals. Then let the group self-organize to meet them.
  • There is no “one best way.” There is continuous improvement, though.

7: Optimize the Whole

  • Optimize the whole value stream, that is, not just local processes.
  • Pay particular attention to where products,code and processes transition between departments, teams, organizations or physical locations.

The product development timeline:

  • Concept — What’s the unmet customer need or desire?
  • Feasibility — Test feasibility by experimentation. Build stuff. Ship betas. Design systems. Investigate the major features of the business process, key hardware modules, interfaces, boundary behaviors, software architecture and constraints. Can the product really be built? Will it work?
  • Pilot — Work with your customers. Show off the product; collect data; iterate. Let people choose from multiple options by playing and “voting with their attention.” Run multiple pilots to refine the design.

You have to go way beyond meeting basic expectations, even beyond adding new features or improving performance. You have to identify needs customers don’t know they have and then delight them by meeting those needs. This requires developing a deep understanding of the customers’ world.

That’s all for now. I’ll post more as I continue my way through the book — perhaps the next time it “snows.”

This entry was posted in Book Notes, From the Yellow Notepad, Software Engineering. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>