A principal engineer at my first engineering job once told me to implement things like they're going into production the first time. I took that advice to heart and added an apparent rule in my life: implement the straight-forward, simple, and working thing first.
Simple and straight-forward things are generally good for production. They're easy to maintain, easy to understand, and easy to fix if they break. I've expanded their advice to most things I work on.
By taking a first step toward a simplified first iteration (or early iteration) you can still be conscientious of future expansion. If reasonable, program in extension points, leave your API flexible, don't get specific unless you need to. Give yourself and future engineers an opportunity to expand, improve, and refactor in ways that don't pin anyone into a corner. Someday someone will be in your code hoping to improve it and if you were forward-leaning at the time then that future engineer (who might be you!) brings more modern thoughts and tools with a fresh out-look that improves your design even more.
Starting simple doesn't mean inefficient, ineffective, or useless. It's foundational.
Relationship to Agile
Does it jive with Agile? Yes, yes it does. It's there in the first principle:
"Our highest priority is to satisfy the customer through early and continuous delivery of valuable software."
Re-enforced here:
"Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale."
And here:
"Working software is the primary measure of progress."
Finally, here:
"Simplicity--the art of maximizing the amount of work not done--is essential."
The common thread here is working, simple, delivered in a timely manner in order to satisfy the customer.
After thoughts
The primary benefit of this approach, for me personally (read: selfishly), is that it helps me understand when I'm implementing or trying to learn something new. The second benefit, if you're in a work environment, is that you (probably) get an acceptable deliverable quickly. The catch is, even doing Agile, we seldom have time to go back and improve on things, hence the concept of implementing something like it's going into production the first time.
Build the simple working thing first with a mind toward future extension and potential expansion and you'll be alright. If you never get an opportunity to get back to it then you did right, laid the foundation, and hopefully charted the course for the next engineer coming in to make improvements.