On my current project, new functionality is often released in increments over a period of several months, as opposed to developing the functionality and deploying it in one release. This is a good approach to release management because it reduces risk, since relatively small changes will be made to the production environment. It also allows the client to see some of the new functionality early and gives them an opportunity to adjust the design for future increments. However, this release management strategy can be problematic when there is a large amount of overlap in the schedules for two increments. Consider the following schedules for increments 1 and 2:
| Aug. 15 | Sept. 1 | Sept. 15 | Oct. 1 | Oct. 15 | Nov. 1 | |
| Increment 1 | Development Begins | QA Begins | Release | |||
| Increment 2 | Development Begins | QA Begins | Release |
The same developers are likely going to work on both of these releases, and as a result they will need to split their time and the quality of work performed for each release will most likely decrease. Management may argue that development for the first release is complete and that there is no problem with this overlap. By asserting this management is implicitly stating that there won’t be many (or any) problems with the code. This is generally a bad assumption because:
- Rushed development timelines mean that developers are more likely to make mistakes. This is often exacerbated by schedule slippages that result from the development team fixing problems with the first release.
- Full regression test suites are poor or don’t exist, which means that it is possible (and likely) that the new changes will break existing functionality.
However, management may not want to reduce or eliminate overlap in the schedules because they fear that the development team will be underutilized. Here are a few examples of activities that developers can perform during their “down time”:
- Write and/or enhance unit, and possibly integration/functional, tests.
- Develop and/or enhance an automated regression test suite. (This should help reduce the amount of time allocated to QA activities in future increments.)
- Address quality or security issues in the code.
- Review the requirements for the next increment and start designing the features to be developed or enhanced.
- If the above activities are complete (which is unlikely), then the developers can start writing code for the next increment.
In my view, development for Increment 2 should begin (at the earliest) a few days before the release for Increment 1, since at this point the QA team has tested the release several times and is unlikely to identify new issues. The amount of acceptable overlap should probably be determined on a case-by-case basis. How much overlap do you have between releases on your project?
