This excerpt was taken from The Art of Lean Software Development, which was written by Curt Hibbs, Steve Jewett, and Mike Sullivan. These three authors also just put together DZone's Refcard on Getting Started with Lean Software Development. To download the free Refcard, click here. 

Lean Versus Agile

So, what is so different about Lean and Agile software development? On the surface, not too much.

Both Lean and Agile software development aim to improve both the quality of the software (as perceived by the customer) and the productivity of the software development process. They both value (and even welcome) the changes in requirements that will almost certainly occur over the course of the project. They both place the highest value on delivering software that meets the customer’s real needs (not the initial perceived customer needs).

The difference is in the underlying perspective and philosophy...the mindset.

Agile mostly concerns itself with the specific practice of developing software and the project management that surrounds that software development. Agile methods do not generally concern themselves with the surrounding business context in which the software development is taking place.

Lean principles, on the other hand, can be applied to any scope, from the specific practice of developing software to the entire enterprise where software development is just one small part. It is common in Lean manufacturing to even go outside the company and include suppliers in the scope of Lean process improvement. The larger the scope, the larger the potential benefits.

Most Lean efforts start out small and expand their scope over time, realizing more and more benefits in the process. In any case, it can be safely said that Lean views all Agile methodologies as valid supporting practices.

The primary focus of Agile software development is on close customer collaboration and the rapid delivery of working software as early as possible. Lean sees that as worthwhile, but primarily focuses on the elimination of waste in the context of what the customer values.

A key Lean tool for detecting and eliminating waste is the Value Stream Map (VSM). The VSM is a map-like diagram of all activities that take place from beginning to end, for example, from when the customer requests a new feature to when that new feature is delivered to the customer. Each step is then identified as value-added (from the customer’s perspective), nonvalue-added, or nonvalue-added but necessary. VSMs will be covered in more detail in Chapter 9.

Finally, Agile has a fair number of formal methodologies, whereas Lean has no formal methodologies. Lean, instead, has a toolkit of recommended practices from which to choose.

In fact, when implementing Lean software development, it is quite common to pick a lightweight Agile methodology as a starting point and begin applying other Lean tools (like VSM) from there.

For those of you who want to take this approach, we recommend using Scrum. Scrum provides all the essentials and has a very low learning curve. Most people find it easy to learn Scrum in just a few days.

Getting Started

The journey of a thousand miles must begin with a single step.

If traditional and Waterfall-style software development is such a failure, and if Lean and Agile software development are so much better, what is stopping everyone from switching? Of course, there are many, many reasons. However, this book is aimed squarely at what we think are two of the biggest reasons: fear and confusion.

Back in the days when the name IBM was almost synonymous with computers, there was a widespread saying that, “no one ever got fired for buying IBM.” The point was that buying a computer from IBM was safe. It didn’t matter if the project was a success or a failure; no one was going to blame you for going with IBM. The inverse implication was that if you went out on a limb and purchased a competitor’s computer, you’d definitely get blamed if anything went wrong.

Moving to Lean or Agile software development practices can elicit the same kind of fear. Sticking with the current method of developing software can seem like a safe path, while pushing for Lean or Agile software development practices might feel like going out on a limb and exposing your career to unnecessary risk.

Perhaps you have imagined yourself having just convinced your boss to let your team use that hot new Agile methodology on your new project, selling them on the promise of higher productivity and higher quality. Now your neck is on the line to deliver. There are so many new practices to understand and implement, and you’re not really sure how to fit them all together.

Then management unknowingly sabotages your nascent efforts by periodically “borrowing” a teammate to solve some high priority problem on another project. Or maybe they just add new features without extending the deadline (but hey, you’re doing Agile, so we can handle changes, right?).

Even worse, you don’t have enough experience to recognize the serious impact that this will have on your delivery promises (and deal with it appropriately). In the end, you get blamed for the project running behind schedule and over budget. And to compound your misery, you just “proved” to management that Agile doesn’t work!

This is the kind of fear that holds many people back.

Add to this the confusion created by too many choices, and you’ve got the perfect recipe for paralysis!

So Many Questions

Making changes to your development process can be a daunting task, especially if you are learning that process as you go. You may find yourself thinking along these lines and, believe us, you’re not alone:

Should I go with Agile or Lean? If I choose Agile there are so many methodologies, which one is best for me? I don’t have time to read about all of them, how do I choose? Ok, I’ll just pick one, but there are so many new things to learn, and I’m supposed to tailor it to my needs, but how do I know what to use and what to leave out?

If I leave out something really important maybe I won’t really be doing Agile and my project will fail. Maybe I should just play it safe and do everything. But that’s more work than what I was doing before—how is that Agile? Maybe I should go for Lean.

I could do a Value Stream Map, but this new project hasn’t even started yet and I don’t know how to find waste in a development process that I haven’t even decided on yet. I see there’s a bunch of recommended Lean Software Development practices, but which ones should I use? All of them?

This is too confusing. I’m on serious mental overload here…

There are plenty of books, articles, and other published material that gives you a gamut of possible practices and approaches. Agile methodologies that you don’t understand can seem intimidating and complex, especially if they have to be tailored and you don’t have the knowledge and experience to do so.

Lean software development provides little guidance beyond giving you a heap of possible practices. This means you must decide what to use (or not to use) and when to use it. Once again, this is difficult if you don’t have the knowledge and experience to make those decisions.

The Good News

Don’t despair; there is good news. In this book, we’re going to take a different approach, an approach that will let you incrementally adopt Lean and Agile practices at your own pace. As you do so, you will gain the knowledge and experience needed to make the decisions outlined in the previous section.

A number of practices are universally found in nearly all Agile methodologies and Lean software development implementations. Each practice, on its own, will give you productivity and/or quality benefits. You can adopt these practices in any order that you wish (with a couple of exceptions), but we will present them in the order that we think provides the most return for your effort:

• Practice 1: automated testing
• Practice 2: continuous integration
• Practice 3: less code
• Practice 4: short iterations
• Practice 5: customer participation

This book devotes a chapter to each of the practices listed above, along with a couple of prerequisite practices that you are probably already using (source code management and scripted builds).

Click here to learn more or to purchase this book.

Don't forget to download your free copy of DZone's latest Refcard on Getting Started with Lean Software Development!

Authored by Lean experts, Curt Hibbs, Steve Jewett, and Mike Sullivan, the Refcard provides a step-by-step approach to implementing a Lean Software Development process. Adopt one, several, or all the practices and take your first step into the world of Lean Software Development.

Click here to download it now!