One widely knowns agile principle is Do the Simplest Thing That Works. Often this guideline transforms into "Do the Fastest Things that Works". I suppose that the logic behind this is that if something can be done fast then it must be simple, right? Problem is that given principle is as much about simplicity of reading the code than it is about writing it.
Another rule which can lead to problems if followed too blindly is You ain't Gonna Need It. According to this guideline one should always implement things when they are actually needed, never when one just foresees that they may be needed.
OK I'm quite sure that there are some projects where you can only be certain about the requirements of your ongoing iteration. However quite often (especially in case of fixed price projects) the requirements are indeed quite stable. I'm not implying that we should add extension points or flexibility that is not backed by any existing requirement. However one should consider the risk of requirements change and the added cost of reimplementing it in the future.
For example we once had to implement web application with content submission wizard which would be able to choose next page based on user selections in previous steps. When we started we already knew that it will be needed to support submitting multiple different content items in a bulk. However we decided to ignore that requirement and do the simplest thing that could work for given iteration. Sure we managed to deliver something to the customer earlier but we had to reimplement almost whole wizard during next iterations to make it support that additional requirement bit.
Comments (2)
Jan 30, 2008
jaanus says:
About the wizard example - IMHO there were additional issues, then just trying t...About the wizard example - IMHO there were additional issues, then just trying to implement 'the simplest thing'. At the end of iteration the development got really painful and the code started to get a life of its own. It contained a lot of magic that I even did not try to understand
It definitely did not fail only because of 'over simplifying requirements' 
Jan 30, 2008
Ürgo Ringo says:
I don't remember exactly if initial design had some other issues besides being i...I don't remember exactly if initial design had some other issues besides being insufficient to satisfy these additional requirements. In any case chosen design did not scale very well.
Sometimes the problem is really so complicated that it's not possible or desirable to come up with design that satisfies all requirements (BDUF). However I think that there are cases where some requirements are ignored too easily and it costs a lot more than spending a more time in the beginning.
I think in C3 project (the one where XP was invented) they had similar situation. At first glance 90% of system was done but because of performance (or other inherent) issues work needed to get other 10% of functionality done was much more than just 10% of overall development time.