Often the first step I take is just make it work, in most straightforward way. Make sure that it is tested. When I say tested, I do not mean, write a unit test for each permutation for each small piece of code. You don’t want to test the implementation, but focus on the behavior, what should this code do to make the customer happy.

If that is done, I start refactoring. I now know the problem space much better, making it easier to do sweeping changes of interfaces, and because the test are most focused on behavior and the interfaces, that shouldn’t require that much work.

When i’m Happy with the design, and the basics are working. I start working on the edge cases, and to refactor the internal implementation to something that is focused on maintainability.

So I think your approach should be to teach your colleges to first, just make it work.

That said, if you are a team lead, I think you should think of the psychology of your developers. Why are they so focused on the edge cases. Does the business blame them when it goes wrong. Are the stories over promising, leaving little interpretation for the developers to only think about the gold road.

If that is the case you should definitely be more involved when the features get specified. If everyone is clear what edge cases are not involved, then it will lift the burden of the person coding the feature.

Also, perhaps you should move the developers to projects were a more rigid approach fits the project. I know I’m pretty terrible to hack something together in a couple of hours. But I’m the person that works a week on it, so it’s stable, works and tested. Different kind of developer for different kind of projects.

Just make sure you encourage the developers to work the way you like, and to be there when shit hits the fan because the edge case is not as edgy as they expected.