Little’s Law, Theory of Constraints, Statistical Process Control. If there is a way to be faster, it will be found.

I don’t consider Agile to occupy any privileged position within software development methodology. It is one narrowly conceived and applied subset of iterative/incremental software development, which itself is a subset of software development methodology overall, which in turn is a subset of systems engineering and product development methodology. I hope you don’t see this topic in terms of Lean v Agile. I don’t. I’m interested in Lean applied to the entire body of product development methodology, which includes far more interesting things than timeboxes and story cards. A debate about Kanban v Scrum is a sideshow.

For example, did you know that Genrich Altshuller developed and documented the “pattern language” concept 30 years prior to Christopher Alexander? At least Alexander got it right, unlike the “Gang of Four,” who got it wrong. Altshuller had a lot of other interesting things to say as well. Did you know that Stuart Pugh wrote a book about cross-functional feature teams and set-based concurrent engineering in 1990? Did you know that E.W.Dijkstra wrote about the iterative derivation of code from correctness assertions in the 1970′s? Reinertsen’s book about Lean product development preceded the first XP book by two years. Nearly every idea in Agile is borrowed and watered down from superior source material. I will pick Tom Gilb and Harlan Mills over Ken Schwaber and Kent Beck any day of the week. Further, there is a great deal of additional source material that the Agilists haven’t gotten around to plagiarizing yet. I don’t need Agile’s half-baked interpretation of Lean, because I can have the real thing.

Versus a well run “generic agile” team I see Lean teams increasing WIP because of this.

I am talking about time-boxing, but the product of a time-box is not arbitrary. Anything but: it is carefully chosen for its delightfulness.

Fixing the cycle time is the “takt time” method. I don’t use it myself, but others have been able to make it work. Or are you talking about timeboxing? Which isn’t really fixing the cycle time, because the product of a timeboxed iteration is an arbitrary process artifact.

And I do.

This has been achieved through good (and agile) engineering practices. These have the happy side effect, amongst other things, of allowing short cycle time, but that isn’t my _goal_.

As to the other, I fix the cycle time. I have zero variation of cycle time–is that interesting by itself?

http://www.poppendieck.com/compromise.htm
http://www.poppendieck.com/pipeline.htm

A bold announcement. Why is this my goal? It seems inward-looking, bureaucratic and self-serving.

I’m under the impression that my goal is to delight my customers. Why would a slightly lower normalized cycle time make their hearts beat faster?