Interesting post Harold!

I have my doubts about Agile in general (
http://www.martijnlinssen.com/2010/06/no-agile-gospel-please-just-give-me.html) as it strives to deliver a project rather than a product. By that I mean that it is very focussed on quick, fast development interknit with test - depending on verbal rather than written communication

Agile is such a success because they work in small groups (10-15 max), face-to-face, and don't document much if anything. In a sense it's the XP version of RUP

That's why they can shift easily during phases, without having to change much else than their common opinions and goals. The problem however is the fact that even after project delivery there's not much written communication (aka documentation) to be found, making it next to impossible or very costly to sustain or maintain the product delivered

I agree with the power of Pull described by Clark and the inability for or uselessness of predicting or anticipation (and the desired absence of management in order to fix that)

The same problem I see in the collaborative co-design proposed: I can see how it gets you "there" faster and better, but I wonder how it will keep you there: how will you retrieve the state of a given workflow so you can know how and why to change it?

Regardless of that, what you'll need is relatively highly skilled employees, whereas in E1.0 you can do with relatively low skilled employees and a high-skilled manager to compensate for that. Although, of course, the manager nowadays is little more than someone promoted to the side and a lot less knowledgeable about the actual work to be done than any given employee