I first read Lean Software Development: An Agile Toolkit by Mary and Tom Poppendieck several years ago when I was introduced to lean. While attending a leadership training, the practitioner had us perform an activity involving building paper airplanes. She split the class into 3 groups, each with 7 people. She showed us how to build a paper airplane in 7 steps, with each person having a step in the process.
Round 1: Each person performed their step and our goal was to get as many planes completed as we could. The statistics looked something like this…
Completed Planes Without Defects: 3
In Progress Planes: 17
Round 2: She gave our teams a few minutes to try to make adjustments to improve the number of completed planes. My team reorganized so that we were in the logical flow order, designated one person as a floater to aid when a backlog developed and reduced a complicated step into 2. The new statistics were…
Completed Planes Without Defects: 26
In Progress Planes: 6
It was at this time that I started to understand the benefits of lean and I could somewhat understand how they would relate to developing software, but there were still a lot of gaps. The practitioner recommended that I read Lean Software Development: An Agile Toolkit and I am very glad that she did.
One of the great things that was done in this book was to very clearly articulate how the seven traditional wastes in manufacuring (where lean originated from) could be applied to software development.
|The Seven Wastes of Manufacturing||The Seven Wastes of Software Development|
|Inventory||Partially Done Work|
|Extra Processing||Extra Processes|
In addition to understanding waste and showing you how to map an agile value stream, the book walks in great detail through 8 core concepts.
- Eliminate Waste
- Amplify Learning
- Decide as Late as Possible
- Deliver as Fast as Possible
- Empower the Team
- Build Integrity In
- See the Whole
- Instructions and Warranty
My favorite part about this book is that it does not describe one methodology (ex. Scrum, Kanban, etc), but instead provides you with the fundamentals that can be applied to any framework/methodology you choose. For example, the difference between breadth first vs. depth first problem solving and when to use each. By teaching the concept and how to think lean, you are better prepared to adopt the correct tools based on the situation rather than following a cookie cutter process that will not work for every situation.