Review: The Art of Lean Software Development: A Practical and Incremental Approach

Authors: Curt Hibbs, Steve Jewett, and Mike Sullivan Format: Paperback, 142 pages Publisher: O'Reilly Media, Inc.; 1st edition (February 2, 2009) ISBN-10: 0596517319 ISBN-13: 978-0596517311 What is Lean Software Development? Fortunately, that's an OK question to ask if you are reading this book. It's not written for developers who are well versed in "lean" or "agile" development. That's good for the rest of us. For instance, in my "day job" we are slowly moving towards a more Agile development model. I suppose if some folks around here weren't all that sure what "agile" meant, reading up on it would be helpful. That's the sort of role this book hopes to fill relative to "lean", with the understanding that the "pro-lean subculture" is well associated with Agile development. The book is lean. I mean that in the plain meaning of the word. It's a short book at only 142 pages and each of its nine chapters is less than 20 pages long. The idea, according to the Preface, is to avoid "padding our chapters with useless fluff". Like a string held taught between two tin cans or a tightly focused laser beam, the book attempts to describe the shortest distance between two points; between start and destination. Actually, the last sentence in the last chapter states, "Remember, Lean is a journey, not a destination", so I guess my review is already somewhat inaccurate. "Lean" then is the string or the laser beam. As you may have guessed by now, the process of Lean development is to make software development..."lean". That is, it's what government is always proposing to do; to use less resources and produce superior results more effectively (I'll avoid my usual commentary on the whole "stimulus package" theory of "lean" or "anti-lean" in its case). The first chapter in the book establishes why lean is a good idea and where it came from. In order for you to be interested in the book, the authors must first sell the reader on the desirability of lean development. The use of the term "subculture" a few paragraphs back was not really a euphemism. Lean development even has it's own "glossary" of sorts, which is also presented in Chapter 1. Like any philosophy, it comes with it's own "mindset" and "world view" relative to software development (and beyond). Considering its Japanese origins, the ideal of group cooperation in any endeavour is both espoused in the lean development vision and within the pages of this book. Certainly the authors wrote their book with that philosophy in mind and it makes sense. The short definition of Lean development is to reduce a series of tasks to the simplest set of steps possible. Why use two words to say something when you can do it with one? At the same time, accuracy and making the product work can't be sacrificed for the sake of simplicity of design or speed of delivery. It's interesting that one of the values of Lean development is respecting people (which is also a very Japanese value). You wouldn't normally think of the humanity of software development, but coders are human too, as are the rest of the employees of any software development outfit, and as well as their customers. That also works (at least in theory) across the boundaries between management and line staff; hiring people who know what they're doing and then trusting that they'll do their jobs. I know a few "micromanagers" who could benefit from reading at least this part of the book (no one I've worked for recently, thankfully). At this juncture (or before), you may have asked yourself, "What's the difference between agile and lean"? Apparently, not much, according to the authors, at least on the surface of the goals. Both philosophies and methods claim to do what all managers want to do with their companies; make a superior product more efficiently, using less time, personnel, and money. The underlying "mindset" is where the two paths diverge. Agile is more focused around the specific process of software development, while Lean casts a wider net and includes software development within the larger business context. The book functions as a beginner's primer on Lean software development, describing the philosophy and basic design of Lean development. It's not easy to describe a philosophy using a lean process since the concept of philosophy tends to be somewhat long winded (not unlike myself). The book is sprinkled with little real-life examples, like bread crumbs, from the lives of the authors, briefly illustrating the points to be made along the trail of the book's pages. That's good, because such content doesn't easily lend itself to longer tomes, such as the 430 pages of Shore and Warden's The Art of Agile Development (it's a good book, but you have to really want or need to read it). The benefit of the last chapter, "What's Next?" is that it allows the book to be "lean" and at the same time, doesn't leave the reader hanging in mid-air. Actually, it's the resources listed in the Appendix that shows the reader the roadmap to the next part of the territory, based in the book's bibliography. Despite the "Using Code Examples" section in the Preface, this is a book about concept and not about mechanics. In other words, there are no code examples and no supplementary website for the book. The book is a brief template to be applied to your actual practice, not the practice itself. I can take philosophy in limited doses before I must return to my bolts and my wrenches. Fortunately, Hibbs, Jewett, and Sullivan had people like me in mind when they wrote this book. If you are a manager who is considering moving to a more focused software development model and is wondering if "lean" is for you and your company, it wouldn't hurt to have your first introduction to Lean software development be The Art of Lean Software Development: A Practical and Incremental Approach. At least you will find out fast if you want to explore that path more completely after sailing through the book.