Notes From Implementing Lean Software Development - From Concept to Cash

I read the Poppendieck's book on implementing lean software development almost a year ago and I continue to go back to it for advice and insight. I finally brought myself to put together a brief summary on the first half of the book and decided to share it with my blog readers. One of the great things about the book is the set of industry examples they provide to exemplify to the points that they are making. This is especially useful to me, since I often have no debating ammunition aside from my personal beliefs. To make it easy to look up those examples, I'm including the page numbers along with the ideas below.


The book can be purchased from Amazon. 

• pg 24 Early specification does NOT reduce waste, it encourages it
• pg 28 "Do It Right the First Time"
• This means TEST first to keep bugs OUT. It does NOT mean think of all possible future needs of the feature.
• pg 32 Forecast predictions, not fact. Avoid "analysis paralysis."
• Build processes that allow quick feedback and responses, rather than building for an uncertain feature
• pg 33 "Plans are useless, but planning is indispensable" - Eisenhower
• pg 34 Achieving high value, low stress feature delivery is impossible WITHOUT superb quality (in the form of tests)
• pg 38 Sub-optimizing is BAD
• E.g. Optimizing the writing of ONLY the feature code, but NOT the test code
• --result--> More complex code, higher potential for introducing new bugs, longer to write new code
• E.g. Optimizing ONLY your part of the process. The overall process still drags along and you get frustrated.
• --solution--> Team ownership!
• pg 74 7 Wastes
• Relearning by failing to engage current knowledge
• --solution?--> Information needs to be accessible. People should not be siloed and should talk often.
• pg 101 Increase estimation reliability by decreasing variability (i.e. estimate and commit to smaller projects)
• pg 105 FASTER delivery --> Reduce the number of things in WIP (queue theory)
• pg 124 Exec thinking is so ingrained that Lean concepts are invisible
• pg 126 Group is NOT a team until everyone is COMMITTED
• E.g. Sports - track versus rowing
• pg 150 Story by Rally does a great job highlighting the DRAWBACKS of Technical DEBT incurred by NOT slowing down to address untested code
• pg 151 You must *commit* to action items coming out of Retrospectives
• Nothing is accomplished if you only discuss problems.
• pg 153 More important than processes is LEARNING (understanding), SHARING, and SOLVING PROBLEMS
• Experience over documentation. 
• Refined documentation far outweighs garrulous documentation