Brian Marick posted this to the Agile-Testing Yahoo Group Today. I thought it was interesting ...
1. It's the job of the team to be able to respond well to requirements they didn't anticipate. That will allow the business to adapt more quickly to a business environment that won't stand still.
2. Something like 50 years of trying has demonstrated that mere mortals are not very good at designing a system that can accept unanticipated requirements.
3. The alternative that seems to work - the alternative the Agile methods take - is that both the team and the code have to be trained, over time, to accept the unexpected with aplomb.
4. The way you get trained is through practice. Therefore, taking a lot of time to get the requirements right is actually a disservice to the project - it will make them less effective when it really matters.
5. For this reason, a lot of teams make a point of not anticipating the requirements they know are coming. By treating them as unexpected, they speed up their own training.
You can read the entire post here.
Schedule and Events
March 26-29, 2012, Software Test Professionals Conference, New Orleans
July, 14-15, 2012 - Test Coach Camp, San Jose, California
July, 16-18, 2012 - Conference for the Association for Software Testing (CAST 2012), San Jose, California
August 2012+ - At Liberty; available. Contact me by email: Matt.Heusser@gmail.com