Stabilization Process

The stabilization process is completed, as are the other phases of the project, by the entire project team. Each team member must execute his or her responsibilities with the primary goal of shipping the product. The somewhat frantic final days of the development process, when the team is pushing very hard to get the product out the door, is often referred to as the end-game. Within project teams, many stories can be related about activities and heroics during this end-game crunch time, which demonstrate the team's complete commitment to releasing the product.

Unlike the other phases of the development process, this phase is not characterized by the action steps; rather, it is characterized by the interim releases. The same steps are repeated within each interim release: fix the bugs, synchronize all product deliverables, ship the release, and extensively test the release. Eventually, the team will determine that a release is ready for prime time, and that will be the Final Product Release.

Who Does What During Stabilization?

Although the team works together to achieve the Release Milestone that marks the end of the Stabilizing Phase, individual team roles have their own focuses during this phase. Because the primary emphasis is on shipping the release, every role focuses on something to do with shipping the product.

Table 13.1 identifies some specific team role responsibilities for the Stabilizing Phase. The lead for each team role ensures that these responsibilities are carried out and communicates with the rest of the project team.

Table 13.1 Team roles and Stabilizing Phase responsibilities

Role	Responsibilities
Product Management	Coordinate interim product releases with the customer. Plan for the Product Launch.
Program Management	Manage Beta and Pilot product releases. Maintain the project schedule. Drive the sign-off process from the customer along with the operations and support groups for the final product release.
Development	Focus on finding, reporting and fixing bugs. Ensure product integration is completed and succesfully tested.
User Education	Ensure the user support materials are ready to ship. Designate and coordinate trainers and user training for the interim release sites. Designate and coordinate trainers and training for product release with the customer, end users, operations, and support groups.
Testing	Execute the test plan. Find, report, and classify the application bugs. Close bugs and verify they are properly resolved. Heighten focus on usability, installation, and configuration testing.
Logistics Management	Interim product release installation, configuration, deployment, and support. Plan released product deployment. Provide training to the operations and support groups, including the Help Desk team.

Interim Milestones

Unlike the previous phases that can be characterized by steps, the Stabilizing Phase is better characterized by its interim milestones. Each interim milestone functions as a product release. These product releases continue in an iterative fashion until the team determines that the final product release has been created. At each of these interim releases, the team synchronizes and ships all the product deliverables. With each successive interim release, the product is tested, bugs are tracked, and corrections are made. The final product release decision is a shared responsibility across the project team leads, the customer, and the operations and support groups.

Milestone #1: Interim Releases as Bugs Converge

As discussed in Chapter 12, the team can release the interim product releases to portions of the user community to provide additional testing. During the Stabilizing Phase, the team should see a downward trend in the number of reported bugs. This downward trend signifies that the application is becoming more stable. Although there are often peaks and valleys in the number of reported bugs, overall the team should see a downward trend that is manifested over time, not necessarily at each fixed point in time.

Milestone #2: Zero-Bug Release

ZBR is the first point in the project when the development team finally catches up to the testing team, and there are no active bugs, or no bug is active for more than a specified length of time (usually 72 hours). It is to be expected that the bug count will increase after this product release, but the development team will continue to fight to get to ZBR with each successive interim product release. Reaching ZBR is a strong indication that the team is in the final stages of shipping the product, and the end-game is in full swing.

Milestone #3: Release Candidates

When the team thinks the product is potentially ready for final release, a release candidate is built. Each release candidate includes all the elements required in a shippable product, and has no active bugs. The team will perform highly intensive testing against the release candidate to flush out any final show-stopping bugs. This intensive testing determines whether the release candidate will become the final product release, or if the team must generate a new release candidate with the appropriate fixes. It is unlikely that the first release candidate will be the one that ships, as show-stopping bugs are often found in the first release candidates.

Milestone #4: Final Product Release

The final product release is the release candidate that all the key stakeholders, team members, and customers agree is the version that will be shipped. This is the release that is shipped in the box, and on which no further development or testing is conducted. Determining which release is the final product release is a difficult decision. Ultimately the answer is about shipping the right product at the right time. Does this product fully meet the needs of the customer? Other key release considerations are the bug report data, the results of the release candidate testing, and the supportability of the product. As with most major decisions, there are many inherent risks, but the decision will be made as a team effort.