This succinct book explains how you can apply the practices of Lean software development to dramatically increase productivity and quality. Based on techniques that revolutionized Japanese manufacturing, Lean principles are being applied successfully to product design, engineering, the supply chain, and now software development. With The Art of Lean Software Development, you'll learn how to adopt Lean practices one at a time rather than taking on the entire methodology at once. As you master each practice, you'll see significant, measurable results. With this book, you will:
Understand Lean's origins from Japanese industries and how it applies to software development
Learn the Lean software development principles and the five most important practices in detail
Distinguish between the Lean and Agile methodologies and understand their similarities and differences
Determine which Lean principles you should adopt first, and how you can gradually incorporate more of the methodology into your process
Review hands-on practices, including descriptions, benefits, trade-offs, and roadblocks
Learn how to sell these principles to management
The Art of Lean Software Development is ideal for busy people who want to improve the development process but can't afford the disruption of a sudden and complete transformation. The Lean approach has been yielding dramatic results for decades, and with this book, you can make incremental changes that will produce immediate benefits.
"This book presents Lean practices in a clear and concise manner so readers are motivated to make their software more reliable and less costly to maintain. I recommend it to anyone looking for an easy-to-follow guide to transform how the developer views the process of writing good software."
-- Bryan Wells, Boeing Intelligence & Security Sytems Mission System
"If you're new to Lean software development and you're not quite sure where to start, this book will help get your development process going in the right direction, one step at a time."
-- John McClenning, software development lead, Aclara
Chapter 1 Why Lean?
The Problem with Software Development
The Agile Success Story
The Lean Success Story
Chapter 2 Applying Lean to Software Development
Lean Software Development
Lean Versus Agile
Chapter 3 Practice 0: Source Code Management and Scripted Builds
About Zero Practices
Source Code Management
Discipline in an Integrated Environment
Chapter 4 Practice 1: Automated Testing
What Is Automated Testing?
Kinds of Tests
Approaches to Testing
Chapter 5 Practice 2: Continuous Integration
End-to-End Automated Builds
Dedicated Build Servers
Continuous Integration Software
Implementing Continuous Integration
Continuous Integration Builds Quality in
Resistance to Implementing CI
Chapter 6 Practice 3: Less Code
Leaning out the Codebase
Developing Less Code
Resistance to “Less Code”
Chapter 7 Practice 4: Short Iterations
Short Iterations Generate Customer Value
Developing with Short Iterations
The Fallacy of Iterative Development
Big Tasks in Little Pieces
Chapter 8 Practice 5: Customer Participation
Customer Participation Is a Two-Way Street
Paving the Street
An All-Too-Common Problem
Chapter 9 What Next?
Lean Thinking and the Analysis Practices
Value Stream Maps
Other Lean Techniques
Other Complementary Approaches
Where to Go from Here
Chapter 1: Why Lean?
Chapter 2: Applying Lean to Software Development
Chapter 3: Practice 0: Source Code Management and Scripted Builds
Curt Hibbs has always been slightly obsessed with new technologies and tracking technology trends. But he will tell you that this is simply because he is lazy, always looking for new methods and technologies to make his work easier and more productive. This led to his discovery of Ruby in 2001 (when it was still relatively unknown outside of Japan) and to his founding several highly successful Ruby open source projects.
For most of his professional career, which started in the early 1970's, Curt has been a consultant to well-known companies like Hewlett Packard, Intuit, Corel, WordStar, Charles Schwab, Vivendi Universal, and more. He has also been a principal in several startups. Curt now works as a Senior Software Engineer for The Boeing Company in St. Louis.
Steve Jewett is a software developer with The Boeing Company, where he is involved in the development of network-centric cognitive decision support systems. His software experience started with BASIC and FORTRAN on a DEC PDP 1170 back in high school. The trail from there to the present day includes a litany of languages, a broad spectrum of design strategies and development methodologies, and a bevy of software projects, some of which were actually successful. Over a 20+ year career, he has developed software for automated test equipment, weapon/aircraft integration, embedded systems, desktop applications and web applications. His primary areas of interest are software architecture design and software development methodologies, particularly agile software development and its relationship to lean processes.
Mike Sullivan has over 6 years of experience teaching at the university level, and has spent the last 4 years working with software teams in small companies and large corporations to drive valuable solutions and improve team dynamics. He is currently working in a small research team within a large corporation, implementing Lean techniques to improve the software his team delivers. Mike's interests include golf, Cardinals baseball and teaching.
Not what I was expecting, but I'm not disappointed
By Edmonton Linux User Group
Comments about oreilly The Art of Lean Software Development:
When I ordered this book, I only had the title to go by. I was expecting a high level of detail on how to create software without all the overhead. Instead, I now have a book with a bit less detail, but more content on "LEAN" Software Development, and how it is similar to (different from) and related to "Agile" Software Development. Not what I was expecting, but I'm not disappointed.
I do not think the book is as detailed as it could be for something that is in a series called "Theory In Practice." However, there are certainly some good definitions, clarifications, and descriptions. If you are not familiar with Agile and Lean, these will give you a better understanding of the Lean philosophy.
Although I have tended to be doing a lot of what the authors describe (in a methodology still in development itself), I appreciate the additional information for areas I have not gone too deeply into, for various reasons.
If you have never tried eXtreme Programming, Agile, Lean, etc. this book may be useful for you to evaluate the potential benefits and a roadmap to get there. I recommend it for this purpose.
Reviewed by ELUG (http://elug.ca/reviews/the_art_of_lean_software_development.shtml)
Comments about oreilly The Art of Lean Software Development:
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.