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 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
- Build Acceptance Test
- Automated Unit Tests
- Scheduled Regression Test Runs
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.
That should generate plenty of new blog entries!