|
Have you noticed that many Agile coaches
have recently revised their titles to “Lean-Agile
coaches”?
For the longest time, Lean was just another set of
sensible, useful principles. Many Agile thought
leaders have incorporated them into their toolset
with no fanfare. I, for one, have always told my
teams to work on no more than 2-3 stories at a time
without branding that “Limit WIP”.
Around 2008, it became very cool to practise Lean.
Dozens of Agile 2009 participants sported “Limited
WIP Society” shirts. Just like the term “agile”,
there is something bewitching and immediately
grabbing about the term “lean”.
As befits our industry, there is no single standard
or prevailing opinion of what Lean is or what it
looks like. And so, my friend Carlton Nettleton and I
decided to convene an expert panel at the Agile 2010
conference earlier this month. We titled the panel
“Lean and Agile — Roommates, Married Or Twins?”
Our panelists were all experienced Agilists who
incorporate deep Lean thinking: Mary Poppendieck, Jim
Shore, Alan Shalloway and Jean Tabaka. They responded
to questions from our standing-room-only audience. I
would like to share with you some of the highlights
of that panel.
Mary led with a quick definition: “Lean is
delivering constantly increasing customer value for
continually decreasing effort, leveraging energy and
creativity”. The panelists all agreed that Agile is
really a subset of Lean.
While Lean thinking can certainly improve the value
flowing out an Agile team, its strong suit is in
wider-scale application to the business and the whole
value chain, “from concept to cash”. We have to pay
attention to metrics that traditionally sat on the
business side, as Agile lacks discipline around
business methods. Teams must understand the business
justification — and focus on delivering its promise.
Some people claim that “you can't improve what you
can't measure”. But we manage things that we can't
measure all the time. In fact, most systems cannot be
completely measured, and decisions based on partial
measures might well lead to dysfunction. Lean will
help us improve stuff even if it's not measurable.
Lean has us pay attention to throughput and value
flow; it encourages having mechanisms for flow
control. Agile's mechanism is the iteration: Every
iteration, the team produces a bunch of completed
work. Kanban's mechanism is the work-in-progress
(WIP) limit: At any given time, no more than X items
can be in-progress.
Each flow control mechanism is suitable for certain
environments. The Agile iterations, the panel noted,
provide closure. Closure is highly related to teams
being self-organizing. However, some organizations
lack the maturity to make this kind of closure a
reality.
What are the most common mistakes organizations
make trying to implement Lean? Our panelists were
rather unanimous on this matter. Emphasizing
practices over principles and culture; taking Scrum
roles as gospel; not realizing the true nature of
change (believing the only thing that needs to change
are the programmers).
I was surprised by the panel's answers to the
question, “What should teams be trained in?” Jean
answered: “Reflection” — so the team can even take
in the rest of the training, and apply continuous
improvement. The other three all said, “Writing
testable code!” They all emphasized the point of
having great technical skill and writing
acceptance-driven, defect-free code.
(Speaking of which, if you live around Boston and
want to learn this skill from me, I'll be teaching
“Programming without Fear” for the Greater Boston
Chapter of the ACM in November 2010.)
We deliver value to our customers, and who else? I
liked Mary's crisp answer to that:
Treat your employees well, and they'll treat your
customers well. If your customers are well treated,
you'll make money for shareholders. And when you've
done that, you can help the community. And it all
starts with a sustainable environment.
I had a lot of fun co-facilitating this panel,
which we actually did in an Agile fashion: We had two
iterations of taking and prioritizing audience
questions. I wish you could have been there!
With thanks to attendees Jay Packlick and Dave Jacques for sharing their notes.
Copyright © 2010, 3P Vantage, Inc. All rights reserved.
|