Interesting comment. My wife can't see the difference between 1080i satellite broadcast and Blu-Ray. She also can't hear the difference between our old speakers and our new ones, even though it's like we took blankets off. Several people I know can't see the jitter problems with LCD that make me sea-sick. So I've got a spectacular 60" plasma, single pane of glass. Yes there are still jitter issues but minor compared to LCD.

I'm puzzled by this whole discussion. In my experience, agile programming causes: - communication daily, to ensure there's no surprises or silly delays - developers and management communicate - management to prioritize. They can't have everything in a month. - developers to provide reasonable rough estimates for features. After a few months where you actually work on what you say you're going to work on instead of lots of interrupts, you learn how long things really take - developers have control: we don't deliver X because that's not on this sprint backlog. We don't deliver Y and Z this sprint because the estimate says 50 man weeks and we only have 20 man weeks this sprint. Agile programming keeps management from saying a product is ready when its not, keeps management from asking for unreasonable deadlines, and enables developers to clearly communicate what needs to be done. In short, it allows for developing a product in stages and maintaining a product. If your experience equates "agile" with "rush the design" then I question whether the R&D team was properly playing its role in the process. The R&D team should say, No you can't have this feature this sprint because it depends on this exploratory work. But that feature can go in next sprint if you put the exploratory work as a goal this sprint. If you don't want the exploratory work this sprint, you can't have the feature next sprint either. It's up to management to decide what goals it wants, but Agile empowers the developers to insist on realistic timeframes. In my limited experience. Obviously your mileage differs. Stuart