And where are we now? At the beginning of the "Lean"
phase?
Had a lot of interviews recently and at almost all of
them one of the questions has been 'have you used
agile?', so I guess quite a few people are behind the
curve... When I last interviewed about 5 years ago, I
don't think development methodologies were even
mentioned.
The pace of our industry spitting out new methodologies
'that will solve all our problems' is only surpassed by
our industry spitting out new technologies 'that will
solve all our problems'. I think this (quite correct)
observation of yours is the flip-side of the same coin
that keeps us believing that 'the thing we need is just
around the next bend, if only we could get there fast
enough' but it turns out that there isn't a silver
bullet out there to replace hard work coupled with
common sense :)
Except that Lean isn't a 'methodology' - at least not
'methodology' means what it means for CMMI, Agile, and
Scrum. There's little doubt that the word 'methodology'
can be used as a descriptor for Lean, but there's no
essential representation of an implementation of Lean
that can be pointed to, as is possible with CMMI, Scrum,
Agile.
If we group Lean with CMMI, Scrum, and Agile in general,
we're missing the better part of an often bigger
methodological picture.
The things that we learn from CMMI, Scrum, and Agile are
all applicable in Lean, depending on the context. So,
for that matter, are the things we learned from RUP - at
least from RUP implementations that weren't twisted by
institutional bureaucracies created by high-ceremony
implementations of CMMI and Scrum.
Lean doesn't have a canonical implementation. It's these
attempts to distill canonical implementation that
installs the limitation of a life span.
At the moment, I think there's another intriguing
question to consider:
What's the lifespan of principles?
Lean came to life (1950's) long before CMMI, Scrum,
Agile, RUP, Objectory, Booch, Structured Analysis, etc,
etc, etc, and it may long outlive them. The reason it
may outlive them is that they are not the same kinds of
creatures.
I can capture all of Scrum in one book or one training
course. That's simply not possible with Lean. In some
senses, it's inevitably a parallel universe that isn't
described by the process universe, or even the process
framework universe. It isn't prescriptive. It isn't
material. It won't die the same death or live the same
life as material, and so far it hasn't.
It never began in the software process world, and it
won't end in the software process world. But that's not
to say that we can't underestimate it and tie that
underestimation to materialism and ensure that
underestimation dies a predictable death. But then Lean
will still be with us in the myriad industries where it
has been used since it began industrial adaptation in
the west in the 80's.
If you narrow the field of view to something the size
and shape of CMMI, Scrum, or Agile, and look at Lean
through that lens, it will (and should) take on some
resemblances of CMMI, Scrum, or Agile. And no matter how
valuable that perspective is in helping us to see and
ultimately understand Lean, the lens that we're looking
through isn't the thing itself.
This is funny but (sadly) true. We need to concentrate
more on what we want our process to do for us. Without
goals we've got no idea where we're headed, much less
how to get there with a quality system. For me, process
creates an environment where teams can still breath, the
necessary parties have the necessary visibility, and
quality is built right in.
To Scott's exception, I'd add "except CMMI isn't a
'methodology' ". It is a model- one you could compare
your actual methodology to as a point of reference.
Of course, some people try to implement the model as a
methodology, which leads to an ugly mess.