There is a lot to the book. I think it will take me multiple readings to get my head around all of their ideas. I read the book over the course of about a month. I wish that I had been able to read the whole thing in one big chunk, but that wasn't feasible.

The book begins with a chapter on the history of Lean production and its origins at Toyota. I was familiar with the broad outlines of Lean production, but there was a lot of interesting detail I didn't know.

The second chapter describes the adaptation of Lean to software development and lays out the seven principals of Lean development.

* Eliminate Waste
* Build Quality In
* Create Knowledge
* Defer Commitment
* Deliver Fast
* Respect People
* Optimize the Whole

The next five chapters go into detail on Value, Waste, Speed, People, Knowledge, and Quality. As you may have noticed, those mostly but not completely correspond to the Seven Principals. Value and Waste both seem to correspond to "Eliminate Waste." Deferring commitment is address in the speed and knowledge chapters. Optimize the Whole is addressed in various places, including People, and Quality.

The last two chapters are entitled Partners, and Journey. Partners has some really interesting ideas on how to structure incentives so that everyone--individuals, teams, contractors, even partner companies, are all aligned to create synergies and increase value for all parties involved.

The Journey offers ideas on how to begin using Lean methods in your environment. It builds on the "Try This" sections that end each chapter.

There are a lot of really interesting ideas in this book. I've been thinking a lot about how I want to apply them.

One thing that I've realized is that I'm not as clear as I need to be on how my team provides value. And that really matters, because that should be driving decisions about what we do. My team builds automated testing tools that are used internally at a company that makes "Application Delivery Networking" hardware. We also operate the test systems. We used to write automated tests, but now that is mostly done by another group. So what is our primary contribution of value? Is it the capabilities that we deliver to the team that writes the tests? Is it the results that come out of the test systems that we operate? When I have to make trade-offs between those two tasks, which one should be more important?

Another point that Lean has driven home for me is that my team has too much work in progress. We have lots of ideas that we'd like to implement. We also get lots of requests from people. If we meet our goals for the current Sprint (which is far from certain at this point), we will complete about 150 story points worth of work for this release. I already have 145 story points queued up for the next release--and that's with only half of the backlog items estimated. My "high priority" list of work to do after the stuff in the queue is equally large, with equally incomplete estimates.

One of the ideas that I liked and am going to be thinking about is using automation to remove low-skilled, repetitive tasks, especially if they are mistake-prone. There was a list of examples of automation:

* One Click Build
* Scheduled Builds
* Build Result Notification
* One-Step Release
* Bullet-Proof Installation

Things that I would add to this include:

* Build Acceptance Test
* Automated Unit Tests
* Scheduled Regression Test Runs

Ironically, for a team that is all about automation of other people's tasks, we haven't automated a lot of our own work. We have an automated build script, but not everyone understands how to use it, we don't do scheduled builds, we don't have a notification system or automated build acceptance tests, we don't have a one-step release process, and we don't do scheduled regression test runs. We do have automated unit tests, and we do have a fairly good installation script, but only for part of the system.

When we did our last release, we had trouble getting a build out and getting everyone notified. At the review of our last sprint, people had trouble demoing some of the work because not all the boxes were set up the same way. We need some automation here.

Moving forward, I'm going to start devoting some time out of our weekly team meeting to discussing the Lean principals and figuring out how we can apply them. ( )