Staying Releasable
The first step is to break the release into iterations. Opinions vary on what the correct length is, but typically two weeks is about right. If you want to do something which will take more than two weeks, you'll need to break it up into increments. The best increments are those which introduce customer value and are testable. In other words, don't break it into design, implement, test. Or for that matter back end and front end. Instead break it into smaller features which can be designed, implemented and tested within an iteration.
Once you're attacking things in iterations, try to pull the full lifecycle into that iteration. Testing within the iteration is critical. It requires a lot more interaction between development and QA. The two need to go hand in hand. Next is documentation. Make sure that any changes to the documentation are also done in the iteration.
Once you have those in the iteration, focus on fixing any resulting defects within the iteration as well. Make sure any changes to the install or upgrade are done within the iteration. Start focusing on downstream affects like changes to the bill of materials or changes to training materials.
Getting to the point that all of this is done consistently within the iteration can take a while. It requires a lot of evolution in the organization. One way to cope in the interim is to add "hardening" iterations. The objective here is to add some time to clean up anything that you couldn't do within the iteration. You might start with one or more mid-release hardening iterations. And leave one through four hardening iterations at the end. Your goal is then to reduce the need for these with every release.
_____
tags:


