"Take time for all things: great haste makes great waste."
Benjamin Franklin
Who wouldn't want all their features implemented immediately? It depends. How long will this software be used for? If it will be single-run code then nobody cares because it will not need any maintenance and we can always recreate it from scratch should any bugs rear their ugly heads. But if we want it to go the distance... that's another matter.
There is a limit on fast good software can be developed. At the very least, quality software is a function of the team's ability to adapt to the growing demands of the domain. For a team of one this will take a very long time though we can at least guarantee that the developer will have some memory of how the thing works. However, the moment you expand the team, you now have to think about all the dynamics this introduces. And a lot has been written about this...
At the very least you will need two parts to your team: architecture and development. Architecture makes the decisions on the overall structure so as to ensure that the product is fit for purpose and development realises the actual infrastucture. This is how it is done in the real world: the architects decide on the aesthetic and work with engineers to ensure that the building meets the client's requirements. Only when this is complete can construction begin. Even minor changes can have vastly complex implications. Why should it be any different with software?
Therefore, to move fast, at the very minimum will require these two roles.
But in addition to this, speed will obviously be far easier if the team has:
Without taking these into account it is illusory for a team to move fast only to realise that they are increasingly making their work harder and code more brittle. It will get to a point where you will realise that it is cheaper to start again than try to fix the mess you have engineered.
******
Here is another way to think about it: suppose you want to operate as a freelance software developer and want high paying jobs with a short implementation time. What kinds of jobs would you want? Would you want jobs with a clear architecture, greenfield projects or projects in which a lot of code has been written with no clear architecture but for which a fix is needed? Obviously, we will favour then in the order I presented them. A clear architecture means that the domain problems have been clearly understood and presented through the code in such a way that it is easy for a newcomer to quickly hit the ground running. Greenfields projects may be far easier to work on despite the possibility that the volume of code and unpredictability of the new domain introduce substantial risk. Old code with no architecture can give you nightmares. It reminds me of Sergey Aleynikov, the main character of Flash Boys by Michael Lewis, who decided to leave Goldman Sachs (who eventually sued him for stealing company code) for a greenfield project simply because he got tired wrapping his head around old, clunky code.
The moral of the story is that not all code is created equal. While for the most part writing code can be fun, a lot of work goes into laying the groundwork to make the work of future developers a breeze. It's like a kids' playground: playgrounds are artificial - they don't occur in nature. It takes considerable thought and construction to make them child friendly so that even a child can enjoy them. Perhaps that is the holy grail of architecture: making playgrounds!