I was asked this question off-line in response to my posting that
"You talked about this on the scrum list, but I don't find it my
search. Do you have reference for it?
And I very much like explaining scrum practices in terms of lean.
Ungrounded practices have a much harder time of being accepted. Lean
is concrete and has many examples of successful adoption. Talking
about empirical process control always seems a little distant from
Thought I'd elaborate here as others would likely be interested. I
discuss this in the context of how this relates to Scrum.
Womack and Jones talk about Lean as Fast-Flexible-Flow in their book
Lean Thinking. This viewpoint is very powerful and is completely
consistent with both the Poppendieck's view of Lean Software
Development and the Scrum method of developing software.
The concept behind Fast-Flexible-Flow is:
Fast deliver value to the customer quickly
Flexible what you are delivering is different most every time so
your process of delivery has to change accordingly
Flow view this process of fast delivery as a flowing of adding
Let's look at these a little more in depth and explain how they
relate both to the principles of Lean Software Development and Scrum.
FAST. Adding value to the customer quickly has many advantages.
Scrum's iterative process guided by the customer/product owner is
geared towards this. Lean Software Development's "Deliver Fast" is
another way of saying this. Both Womack and Jones and the
Poppendieck's explicitly say this speed must be maintainable. I
don't recall Scrum specifically talking about this, but it is a
strong implication of Scrum and all of my favorite Scrum coaches
talk about automated acceptance testing as one means of
accomplishing this. We want speed now and in the future. We are
not talking about hacking. I like to talk about it as "focusing on
the ability to add value quickly now, without adversely affecting
the ability to add value quickly in the future."
FLEXIBLE. Building software is a series of related one-offs. The
ultimate in flexibility. Ironically, Lean's roots go back to when
the Japanese had to create short runs of cars since they could not
compete with the United States' mass production. How to create work-
cells to build small runs was of paramount interest. I suspect this
is what drove Toyota to focus so much on the time aspect of building
and developing things. Time is even of more essence in software
development since our value (thoughts, knowledge,
) degrades much
FLOW. The metaphor of flow is very powerful and provides many
insights. Think of a stream bed where water is flowing through it.
The maximum rate of flow occurs when there are no blockages.
Conversely, anything that impedes flow is bad. This is the basis
for the "stop the line mindset" of Lean where when something impedes
the flow you fix the impediment, you don't work around it. This is
also consistent with the Daily Scrum where we mention impediments
with the intention of removing them and thereby keeping up the
productivity of the team. Having a workcell be one of the practices
of Scrum is also consistent with this. There is no waiting for team
members who are needed to work on something which would impede
flow. There is no thrashing of team members caused by working on
multiple projects since in Scrum we have everyone work on one
project if possible.
Of further interest, the 5 principles on which Womack and Jones'
base their fast-flexible-flow approach (Value, Value Stream, Flow,
Pull, Perfection) are a pretty much exact match of Scrum
values/practices as well. But I won't go into those here.
In summation, Scrum's workcell approach to building stories as
smoothly and quickly as possible mirrors Womack and Jones' view of
building/developing things with Fast-Flexible-Flow. By building off
the decades of thinking about this problem in manufacturing and
product development, we can assist our own thinking of how to apply
our practices in the world of software development.
CEO, Net Objectives
Training, Coaching and Mentoring Services worldwide.