Exclusive Excerpt - Lean Vs. Agile
Join the DZone community and get the full member experience.
Join For FreeThis 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!
Opinions expressed by DZone contributors are their own.
Comments