My corollary to this is that the biggest threat to a project is management. It is management that will cancel the project, after all. Much more than 90% of the time, they will cancel it because they are feeling uneasy about the progress. Your job, if you don't want a cancelled project, is to deliver regular progress that feels tangible to the stakeholders. Every company is different in terms of how often they need that shot of "we made progress", but every company is the same in that the longer you make them wait, the more likely it is that your project will be cancelled.
"Smallest thing that could possibly work end-to-end" is a very good strategy, if the "smallest thing" is small enough. If it's not, then you have to get even more creative. Whatever you deliver, though, it has to feel real and tangible to the stakeholders. Usually specs and design docs do not fill the bill.
It is critically important that if you want to "do it right", whatever that means to you, that you interleave the quality oriented activities within a deliverable matrix. Good specification, good design, testing, refactoring, monitoring, configuration management, etc, etc, etc are things that are invisible to stakeholders from a tanglible delivery aspect (unless you are incredibly blessed). Thus, these activities must be similarly invisible from the external view of development. Shining a spotlight on how much time you are spending on these quality aspects of development will only hasten the demise of your project. At the very best, they will be used as points of negotiation from the business side - "Could you deliver faster if you didn't test this part?". The business should be so preoccupied with looking at what you are delivering that it doesn't notice how you have delivered it.
The biggest mistake I see from developers is the idea that the business must buy into the developers' sense of values. It is, of course, wonderful if that happens, but it is rare in the extreme. Most businesses do not understand those values. To be fair, given the amount of internal bickering we tend to have as developers with respect to "doing it right", I have to say that even we do not fully understand our own values.
It is important, though, that development be able to use the practices that will give them the best shot at success. Just like a developer should not be calling the shots for strategic business direction, so too must the business stay out of our strategic development decisions. To ensure this, you must create a development process that is largely boring for a person from the business side. As soon as you link your development process with the stategic success of the company, you invite the business side to feel as though they should be calling the shots. This is almost always a mistake in my experience.
Deliver early. Deliver often. Make each delivery contain something that has tangible results for the business. Make your process boring without exceptions: "This is just how you do it" rather than "We need more time for analysis". Refactor your code when you need to without asking for permission rather than creating a task to refactor your code. Improve your build system with every small step rather than spending a month up front creating the perfect build system. However, no matter what you do, always remember that there must be delivery. Plan your activities strategically and try to work on quality uniformly.
"Smallest thing that could possibly work end-to-end" is a very good strategy, if the "smallest thing" is small enough. If it's not, then you have to get even more creative. Whatever you deliver, though, it has to feel real and tangible to the stakeholders. Usually specs and design docs do not fill the bill.
It is critically important that if you want to "do it right", whatever that means to you, that you interleave the quality oriented activities within a deliverable matrix. Good specification, good design, testing, refactoring, monitoring, configuration management, etc, etc, etc are things that are invisible to stakeholders from a tanglible delivery aspect (unless you are incredibly blessed). Thus, these activities must be similarly invisible from the external view of development. Shining a spotlight on how much time you are spending on these quality aspects of development will only hasten the demise of your project. At the very best, they will be used as points of negotiation from the business side - "Could you deliver faster if you didn't test this part?". The business should be so preoccupied with looking at what you are delivering that it doesn't notice how you have delivered it.
The biggest mistake I see from developers is the idea that the business must buy into the developers' sense of values. It is, of course, wonderful if that happens, but it is rare in the extreme. Most businesses do not understand those values. To be fair, given the amount of internal bickering we tend to have as developers with respect to "doing it right", I have to say that even we do not fully understand our own values.
It is important, though, that development be able to use the practices that will give them the best shot at success. Just like a developer should not be calling the shots for strategic business direction, so too must the business stay out of our strategic development decisions. To ensure this, you must create a development process that is largely boring for a person from the business side. As soon as you link your development process with the stategic success of the company, you invite the business side to feel as though they should be calling the shots. This is almost always a mistake in my experience.
Deliver early. Deliver often. Make each delivery contain something that has tangible results for the business. Make your process boring without exceptions: "This is just how you do it" rather than "We need more time for analysis". Refactor your code when you need to without asking for permission rather than creating a task to refactor your code. Improve your build system with every small step rather than spending a month up front creating the perfect build system. However, no matter what you do, always remember that there must be delivery. Plan your activities strategically and try to work on quality uniformly.