Paradox 1: If you want to Develop Faster, take More Time
...more time for specification and finding the appropriate technical solution (the "architecture").
A Short Story
which illustrates this. "Help, the standard comes into force at the end of the year.... And none of our 12 control systems meet the new requirements." We then invested a total of four (4) months in specification, the first two months until we had an optimal technical solution and four control variants remaining. Then another month each with product management to dump one control variant each.
During this time, very clear and detailed specifications and a clear architecture were created, which documented the consensus with product management, mechanics and production. We were then able to bring the remaining two variants to production maturity within six (6) months, on schedule by the end of the year. And by the way: the controllers are still being produced today, after thirteen years, without any significant changes.
What Happens when one Starts Fast?
If you start with a product development based on unclear requirements, in embedded development this has the disadvantage that the developers have to make assumptions when selecting the processor, the operating system, the interfaces, etc. If these then turn out to be wrong in the course of clarifying the requirements, e.g. the processor is too weak, the result is a huge effort for redesign or for development around "bad technical decisions".
And What about Agile?
The agile processes and work methods of generating specifications during the project usually do not solve the problems and can increase the risks.
Fast and smooth development must be bought with early clarification of the requirements.