Kaizen: Lean Enlightenment
It’s taken me a while to write this blog posting, mainly due to time available, and one particular horrible work weekend that didn’t help blog matters; from waking up at 7am Friday morning to Monday night 10pm (87hrs), I got just 9hrs sleep 
. Anyway, I first read Implementing Lean Software Development a few years ago, having re-read it again in the last few weeks, I thought (as normal) I’d blog the points that jumped out at me 
Anyway, to the book.
Implementing Lean Software Development is one of those books that every developer should read. It’s full of worthwhile information that is obvious but yet help to clarify that you are not going mad in your daily job Even the forward by Jeff Sutherland (Scrum) (page xix) touches and important point with regards to managers, and the need to load developers at 110 percent purely to create a sense of “urgency” so developers will “work harder”. I love the last two sentences of the second paragraph which speaks volumns about todays project management: “They (managers) want to micromanage teams, which stifles self-organization. These ill-conceived notions often introduce wait time, churn, death marches, burnout, and failed projects.” I suspect we can all think of one or more projects we have worked on that have had !Muri and !Mura.
Wikipedia provides the principles of Lean, so I won’t re-iterate them here. Instead I will pick out a few “classic” tip bits of information from chapter 2 (Principles):
- Waste (page 24) – requirements churn. Stop the madness of specifiying requirements far in advance prior to coding. Likewise the features that incur huge cost, but aren’t really needed – I think we have all see this a few times.
- Build Quality In (page 25) – when will management understand that quality doesn’t come for free? We want to get to low defect rates, and short timeframes to find the cause of defects. We don’t want the 100′s/1000′s defect list managed by the testing team.
- Create Knowledge (page 30) – early release (get feedback early), daily builds, good decisions, modular architecture – obvious stuff, and not rocket science! Process improvement efforts should be the responsibility of the development teams, with team setting aside time for this on a regular basis (page 31).
- Respect People (page 36) – I liked Joel’s Excel macro story
Very cool
Chapter 3 (Value) offer insight into the 3M Handspreads. In software engineering land, think prototypes, especially when entering the world of UX – SketchFlow, paper prototype etc.
Waste (chapter 4) offer the Seven wastes (page 74) – defects being one of them. Try a value stream map on your project and see what waste you find Also, drop the queue’s (page 89). Long queues of work to be done in the future leads to a time wasting excercise of maintaining those queues, and building false expectations (page 90). In finance the business can changes quickly (credit crunch) which will always impact work queues. Likes wise writing requirements early leads to churn. What you want is small chunks of work that can be developed, tested and released quickly which zero defects outstanding.
Speed (chapter 5) provides good direction on why an iteration should be managed and not overloaded (page 97). Lean development please! I particularly like the “Limit Work to Capacity” (page 110). I think we all know that business can be demanding, which effectively causes a slow down in development – thrashing.
One of the problems with working in investment banks is that often the offices do not catered for software development – lack of white boards, meeting rooms, visual dashboards etc. A build dashboard for example is a great tool (page 140), it’s just a shame that often projects are forced to adhere to the Furniture Police (Peopleware).
People (chapter 6) offers some good advice on incentives. Page 145 for example suggests rewarding the team based on the business success of its efforts, and not the technical success.
Knowledge (chapter 7) provides some good direction on tests, and the need for automation – moving to development without debt (page 151), and the “amazing” concept of a “hack-a-thon” which provides creative and novel ideas to aid the project and improve productivity. Unlike the usual madness of moving from one sprint into the next with no break in the belief that if a project keeps moving fast its productivity will increase
To sum up, this book is a classic that should be read cover to cover and kept close to hand when madness strikes your project. Reading the book you realise that most of the bad things about a project can be solved adopting lean. The project unfortunately is that unless everyone on your project read the book, and gets it, things will probably take a long time to change.
