Another advantage to incremental design is the ability to show constant, real progress to investors, which is very important if you are working with start-ups in today's questionable economy.

I've seen investor support become shaky, or tense in cases where they have to wait significant periods of time before seeing exactly where their money is going. It can be very rough if management makes planning changes that are not communicated outside of product creation teams. There is also a period of user adoption, that can begin its course earlier (as appropriate) and grow throughout instead of hoping all goes well, and fast enough, when the product reaches the totality of vision.

We are using agile in a government project and it’s working well for us. Our product owners are seeing results at the end of each sprint and making course corrections for the proceeding sprints. We are also using automated testing to insure that new development works with existing code.

We are also getting better business requirements. We create our story documents 1-2 weeks before development and use a scaled back approach to function. Once user see the story working in the system, we can target hi-value requirements.

Working in a government setting, we do have the constraints of a fixed length of time, budget and deliverables. This is not to say we should have a “here is the money, do anything you want” type contract but the “fixed deliverables” are constantly an issue as we are balancing what the contract requires and what the user goal set is.

I think we should give credit where credit is due: Large corporations like Xerox and IBM and DEC and ... were central in that they established and maintained the research labs that created many of the upsetting concepts that in time changed the world. Once the new concepts were created, the corporations tended to fight them, not because they were bad, but because they were different enough that they required change. Interesting, since that was what the corporations were funding their research to provide. But not surprising: change is hard, particularly in big organizations. What seems particularly odd to me is that corporations leave the change to others (like the HR departments) rather than addressing them head-on as important research topics in their own right.

@Austin: Interesting point. I'm intrigued by the perspective that corporations tend to change by adjusting the criteria with which they attract new candidates rather than doing the harder things: Restructuring, reorganizing, etc. I don't doubt that this happens, and I wonder about its efficacy. Is it easier to remodel yourself by injecting new people, or by reorganizing existing folks? Does anyone have anecdotes to share in this vein?

Incidentally, I just read an interview with the head of a Chinese investment bank, and he basically says that the astronomical salaries of investment banking jobs are partially to blame for the rise of exotic derivatives as they "distort the resources of the country." Instead of going into science or engineering, he says, "you have all these clever people going into financial engineering, where they come up with all these complicated products to sell to people." It's related in a sort of macroeconomic sense to your point, maybe.

http://www.theatlantic.com/doc/200812/fallows-chinese-banker

While I agree with many of the characteristics typically associated with the Agile paradigm, I don't understand why you included age (Gen-Y) as a function of this "new" wave of thinking. When I look across the spectrum of Agile practitioners, I don't necessary perceive an age distinction. Would you explain why this was the first point on your list?

I remember a joint interview between you and kent beck (circa 2002). IIRC it seemed like you were both disagreeing on this specific issue. It's interesting to see your point of view has evolved since then.

Rémy,
Agile is *NOT* the same thing as Beck's XP, even though they share many coding techniques.

I know I know :)

I was specifically talking about incremental design, which i feel is the right path to follow too.

I'm sure in the coming years the whole process will be even refined, to successfull design/code interaction and integration, to have the best of both worlds.

It could end up being a really good competitive advantage - especially important with the current economic context.