My approach is "Risk Driven Development" - find the most likely causes of failure for your project, and structure your methodology around reducing those. The s

My approach is "Risk Driven Development" - find the most likely causes of failure for your project, and structure your methodology around reducing those. The standard lean startup risk is building something the customer doesn't want, so it makes sense that the way to mitigate that is by getting customer feedback quickly. But other projects can have substantially different risks - for example, one project I worked on involved building a pipeline to process a large amount of data every day. There was no real customer risk, the spec was pretty much "do this thing that's valuable on some data, but for 1,000x more." Instead, the major uncertainty was whether the libraries we considered would scale up. To mitigate this, we built small prototype projects with each library on production workloads, and found something like 7 out of 12 of them would work with minor adjustments, while 5 had to be discarded pretty much entirely. We then wrote the project with alternatives for those 5, or writing replacements for the functionality we needed from scratch. As teams grow, coordination becomes a bigger risk. One way to reduce this is by having interfaces between modules, and enforcing those interfaces in code. My preferred method is static types and functions, but of course there are others like JSON APIs.