This post resonated with me as well, but I think for different reasons. At the beginning a team doesn't really know exactly what kind of flexibility and functi

This post resonated with me as well, but I think for different reasons. At the beginning a team doesn't really know exactly what kind of flexibility and functionality will be required as they iterate. Teams can of course leverage experience with similar projects to come up with possible future requirements, but these are just educated guesses at best, and self-inflicted scope creep at worst. Because very little is known about the stakeholder's needs a team needs to iterate to become more familiar with the domain and the problem space so they can make informed decisions on how to proceed. And in my experience it's easier and less costly to evolve (or replace) something that's dead simple and wrong than to iterate on something very complex and sort-of right. Attempting to anticipate requirements at the outset is always a gamble. If you get it exactly right then you can save months of development time. However, if you get it wrong, even a little bit, then you may find yourself saddled with a not-quite-right solution requiring compromises with every enhancement request. I think part of "slow" (let's say "deliberate") software development is the willingness to put up a straw man for the purposes of getting feedback from the stakeholder and then going back to the drawing board with information gained to build a more appropriate solution. And that's what agile is about--timely feedback and course correction. If in the span of a sprint a team can get a hard-coded form out and learn all of the reasons it isn't a viable solution, then that's valuable information gained at relatively low cost. The alternative, investing many sprints in a more complex solution, may (and often will) yield more technical debt and cost, especially in the long term. That being said, once the project takes form and everyone has a good handle on what the needs are, there is definitely value in shifting priorities from features to design. At that point the insights gained from stakeholder feedback will ensure that the system can be as simple as possible, but no simpler, i.e. easy to understand and test while being abstract and extensible (only) where needed.