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.
