Sustainable Development for New Projects

In many ways, introducing sustainable development principles and practices for a new project is going to be easier than on an established project. Teams on new projects are almost always determined to do things the right way. It's going to be possible, for example, to employ ruthless testing by having good test coverage and building testability into your project.

However, new projects are often launched with unrealistic expectations, or they are too ambitious. If you're going to start with new practices, I recommend you start with the keystone practices from Appendix 1 and then use your retrospectives to tune and add to your processes over time.

Another problem with new projects is that people are often trying out new practices for the first time. I have found that it's vital to have the team talk about its practices in an open way, especially through the initial phases. For example, I worked with one team where the team embraced simple design, but a few developers had read a XP book and thought simple design meant no up-front design. This resulted in some of the code being refactored repeatedly and some obvious features not being planned for. The result was chaotic until the team realized there was a problem and members were able to communicate openly about what they wanted, so they introduced weekly design meetings until the design settled down.

Probably the most dangerous problem with new projects is that their newness rapidly fades. New projects often face immense pressure in that they need to produce a feature-complete project in as short a timeframe as possible. If there are established competitors, this can be an uphill battle. There are going to be more valleys than peaks, and a great deal of persistence and discipline is going to be required to stick with and refine the practices when the temptation is going to be to just crank out the features without considering what type of quality tradeoffs need to be made.