I found a second article describing an iterationless agile SW process. This time it’s Dan Rawsthorne from Danube introducing the new Scrum III. He says that the Sprints should not be anymore strictly obeyed, but the user stories can enter the WIP (Work-in-Progress) -queue accriss the Sprint boundaries!
It seems that he wants to move Scrum more to the direction of the Lean by replacing the Sprints by an iterationless Kanban/Just-in-Time pull-system. I found already one article earlier about the same idea. For me this seems rational, since the original Lean really actually has no iterations, they are just remnants of the legacy SW Engineering idea of Iterative and Incremental processes. A true Lean process is always one that releases one feature at a time, with a constant pace, regularly, and carries no Technical Dept or half-finished features. The optimum way is to use one-piece-flow meaning working only on one job at a time. Multi-tasking has been scientifically been proven to be sub-optimal since you introduce waste by increasing the unnecessary waiting time, making the cycle times slower and thus increasing the inventory / WIP. If you don’t release immediately when your feature is completed, you essentially store your code in a non-productive warehouse. You have paid the salaries, but haven’t earned a cent out of the investment. The situation gets even worse if you have happened to code some bugs in – the waiting time before release increases the cycle time for finding and fixing the bugs. The faster the feedback cycle time, the better, thus you should release in small batches and immediately when you have completed some code worth of business value. In the Extreme Programming the 2-week fixed iterations are suboptimal in this sense, although you have the Release Often -rule. However, working on two or more user stories simultaneously increases the real cycle time and thus cost.
I’m not currently managing any SW Engineering team, but an iterationless XP/Scrum is definately something I will use on my next project. The only thing to do is to work only on one user story at a time. Shouldn’t be too hard to get it to work :).