I'm not sure this model works, in at least my case. Where there is perhaps some circuit you need to validate actually works with some sort of code - it's often

I'm not sure this model works, in at least my case. Where there is perhaps some circuit you need to validate actually works with some sort of code - it's often useful to write some bad display driver for example so that the hardware team knows what needs to be changed and that process is not blocked. The code may drive a very dirty clock signal that tells them: 1. Circuit works in the basic sense 2. Some part of the circuit doesn't work 3. Some other part of the circuit can now be added now that the basic circuit has been confirmed It's okay saying "build the entire thing perfectly", but spending the difference between one and two weeks validating that something at least has the chance of working is massive. You can't afford to block every team that needs to know whether the part you are writing is even a valid concept. This may come back down to design, but sometimes - especially with hardware, the manufacturer/API doesn't tell you the whole story and you need to know that as soon as possible to start compensating for it. I think building a rough implementation and re-factoring it is way more agile than trying to build the correct version first time, possibly leaving some unknown problem to remain undiscovered for longer. It seems backwards to me when we're talking about anything that has an element of risk.