View Review Details
| Book: | The Art of Lean Software Development | |
| Subject: | I Wanted to Like It... | |
| Date: | 2009-02-02 08:14:08 | |
| From: | Ted Young | |
|
Rating:
 
I’ve already read James Shore and Shane Warden’s "The Art of Agile Development", and whether you liked it or not (I thought it was good enough to purchase half-a-dozen copies for people in my company), I don’t think you can argue that it’s not comprehensive. "The Art of Agile Development" is definitely from the "here’s what we did in the real world with real businesses" school of books. With that book as a reference point, "The Art of Lean Software Development" sounded very appealing and I had high expectations of learning about using Lean ideas in real-world software development. The books is on the short side, only 144 pages, though this can be a good thing since then there shouldn’t be any filler material (unlike the sell-by-the-pound books). Alas, I was sorely disappointed. The book starts out with the seemingly standard "here’s why software projects fail, here’s how waterfall doesn’t work, and here’s the Agile Manifesto and the typical Agile processes." Maybe I’m jaded, but it’s a somewhat old story by now, no? A bright spot is that they point out how Winston Royce’s paper on Waterfall was misunderstood, misinterpreted, or never really read (since Royce actually rails against the down-flowing waterfall process). Next, the book summarizes the Lean Principles: Value, Value Stream, Flow, Pull, and Perfection. And I do mean summarize: the authors spend about a sentence or two per principle. I would’ve liked some more background here, especially the more about "Value" and the "Value Stream", but they promise the next chapter will apply these to software development. Chapter 2 starts by referencing the Poppendiecks’ books on Lean and Software Development ("Lean Software Development" from 2003 and "Implementing Lean Software Development" from 2006) and summarizes their seven principles, diving deepest into the "Eliminate Waste" principle by mapping the manufacturing lean terms to software development terms, e.g., Overproduction -> Extra Features and Transportation -> Handoffs. The authors then go on for only a few more pages on relating the other principles to the process of software development. The chapter ends with a short comparison of Lean vs. Agile, which the authors feel is mainly due to "the mindset" of Lean, i.e., "the elimination of waste in the context of what the customer values." With the introductory material out of the way, I expected to find out more about how to apply the Lean mindset to software development and was eager to learn some new tools. Here’s where I felt really let down. The next six chapters talk about the Lean Practices (starting at the Zeroth), but honestly, there is nothing new about these practices. The Zeroth Practice is "Source Code Management and Scripted Builds". Does anyone doing commercial software development not use source code management? And scripted builds are nothing new. Practice 1 is "Automated Testing". I don’t think there’s any question that this is a must — mainly the arguments are around do I write the tests first or have I gotten 90% code-coverage, etc. Practice 2 discusses "Continuous Integration", but again, this is nothing new and certainly isn’t exclusively a Lean Practice. Practice 3 is "Less Code", i.e., write less code and you’ll have fewer bugs and the system will be easier to maintain. Yup. I totally agree, been doing things that way for decades. Practice 4 is "Short Iterations", which goes back much further than the "translation" of Lean Manufacturing ideas to Software Development. And here I take issue with the recommendation for iteration length: "the best starting point is in the middle of that range—four weeks": my experience is that shorter iterations, such as two weeks, are much better for teams that are starting in Agile because of the shorter feedback loops and more opportunities for inspecting and adapting the process to the needs of the project and the team. The last is Practice 5: "Customer Participation", which is eXtreme Programming’s On-Site Customer. Nothing new here. At this point, the book hits Chapter 9: "What’s Next", which already sounds like the conclusion and I haven’t learned anything new! It does go on for a little bit about Kaizen and Value Stream Maps, but this should be the meat of the book: show me how it’s been applied to projects. Show me the elements that don’t translate to software development. Show me a real-world Kanban board and not just a pretty Visio picture of some columns with rectangles. How does the Kanban really work? How do I deal with wide variation in the tasks? How do I know when and where to put the buffer queues? This section ends with "Make It Visible". Um, Burn-Down Charts? I’ve been using those for years in Agile. And why do I only get a couple of pages on "Root Cause Analysis (Five Whys)"? Chapter 9 ends with some references to "complementary approaches", and I’m very surprised when the authors state "There is currently a little bit of industry talk about applying ToC and CC to software development, but there are no serious efforts that we are aware of to actually do so." Have they even read David Anderson’s 2003 book "Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results"? It’s actually listed in the "Resources" section — unless the authors don’t consider that book (and the kanbandev and Real Options Yahoo Groups email lists) as a "serious effort". All in all, a most disappointing book and definitely not recommended: it doesn’t provide any real-world project information; the authors don’t seem to have participated in any of the mail lists that discuss Lean and Software Development (a quick Google search doesn’t find anything they’ve written in this area); and ultimately it fails to truly show the difference between the various flavors of Agile and how it’s different from "the mindset" of Lean. I really wanted to like this book, but it didn't add anything concrete to my knowledge of Lean in software development, so I suggest reading the books by the Poppendiecks, the Agile Management book by Anderson, the Scrumban book by Corey Ladas and skipping this one.
|
||
