Comment Re:Maybe they did it wrong... (Score 1) 395
It isn't that requirements shouldn't be re-evaluated or should never change... this principle of accepting change in Agile makes perfect sense in the context of "providing a solution that meets the actual need."
The challenge comes in with education of the non-implementers who have been sold on their development teams utilizing this methodology.
My experience with "Agile" (can't say the intended way, just the way it has been bastardized) can be summarized with this anecdote: Business guy comes in and wants to fundamentally change what is being delivered for a project. And, no... the "deadline" for when the project is needed isn't changing. But, that should be ok, right? Because Agile allows for changing requirements even late in development.
Don't get me wrong. Agile vs Waterfall (for some project types) is vastly superior. Delivering incremental, meaningful software frequently can help the business evaluate if what was asked for is on the right track or not. But, in my experience, rarely does the whole team understand the use/application of this methodology. People understand in Waterfall "if I don't get the requirements right, it is my fault" because it has been around for a long time and is widely implemented across many industries.
Even with 10 years, Agile methodology hasn't seeped into enough minds cross-discipline to reach this same tipping point. Until that happens, I see Agile representing both/either "we can change it whenever with no consequences" (which ISN'T what Agile is about) and "we can do complete development without the pain of any sort of documentation" (the mis-perception that it completely eliminates culpability for the business for not defining what is needed).
Just my $.02.