| Some iterative development enthusiasts seem to get very nervous about detailed visual controls, or indeed any kind of suggestion that something predictable happens to new software features while they are under development. I think the fear is that this is (or will become) some kind of prescriptive serialized process that inhibits iteration.
I worry that an important point has been lost in some of the discussion about the WIP-limited workflow systems that we promote. The purpose of the kanban limits is to inhibit forward flows, not backward flows. Pull workflow systems handle design iteration just fine. I would never have gone down this path if they didn’t, but don’t take that as an endorsement that you should iterate with wild abandon. Consider this advice from Ron Jeffries: I prefer treating the acceptance criteria given at story insertion If the customer decides that the story needs more work, s/he can The basic idea is quite simple: we don’t undertake to build anything Your goal is actually to minimize cycle time and minimize variation in normalized cycle time. Let me say that again. The fundamental measure of a Lean process is its cycle time. The reason you should care about all of this Lean business is because that is your goal. In-process iteration has consequences for cycle time, so please be aware. The reason why backflows are not a problem is that you can’t really give the kanban back until a process is complete, and a process isn’t complete until the person that gave you the kanban decides that it’s complete. Until then, the kanban is still in process. This might be problematic if we used per-station takt time, but we don’t, so it isn’t. Remember, we’re not operating a factory assembly line, and we don’t pretend to. Even though one kanban might be exchanged for another one at different stages in the workflow, the total number of kanban in the system never changes as a result of a backflow. Some consequences of backflow are different for information system development because of the physical nature of the facilities involved. Brains and computers are typically much more flexible and adaptive than machine tools. Which is not to say that iterative backflows are without consequence. On the contrary, the system will react strongly to their presence by freeing up resources to help them to move forward again. That kind of “swarming behavior” is fully expected and exactly what we want. |
{ 2009 02 26 }
Dew Drop - March 4, 2009 | Alvin Ashcraft's Morning Dew | 04-Mar-09 at 7:53 am | Permalink
[...] Backflows are self-regulating (Corey Ladas) [...]
Keith Braithwaite | 05-Mar-09 at 6:22 am | Permalink
“Your goal is actually to minimize cycle time and minimize variation in normalized cycle time”
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?
Corey Ladas | 05-Mar-09 at 12:06 pm | Permalink
Would you like to delight your customers next week or next year?
http://www.poppendieck.com/compromise.htm
http://www.poppendieck.com/pipeline.htm
Keith Braithwaite | 05-Mar-09 at 1:19 pm | Permalink
I’d like to delight them this week.
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?
Corey Ladas | 05-Mar-09 at 2:41 pm | Permalink
Why do you use those practices? What makes them “good” other than the results?
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.
Keith Braithwaite | 06-Mar-09 at 12:49 am | Permalink
The results make them good. I’m not sure I understand what else there could be. The results include some path-dependent effects: it’s not just the appearance of the feature that ticks the box.
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.
Corey Ladas | 06-Mar-09 at 11:31 am | Permalink
I suspect that we’re going to disagree about timeboxes and value. The customer, and only the customer, gets to decide what has value. A Minimum Marketable Feature is the smallest thing that has value to the customer. There is no reason whatsoever that such a thing will always fit neatly into your time box.
Keith Braithwaite | 08-Mar-09 at 1:46 am | Permalink
You have put your finger on the very thing that makes me unhappy with the rush to adopt Lean practices: a MMF strikes me as far too big a thing to be used to plan and track software development effort, particularly in the case of a small team.
Versus a well run “generic agile” team I see Lean teams increasing WIP because of this.
Corey Ladas | 08-Mar-09 at 10:39 am | Permalink
1) It works for these guys: http://office.microsoft.com
2) Most people who use MMFs for Lean development break them down into smaller units, which are subject to WIP limits determined according to the throughput metrics.
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.