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.