Roadmap: How to Adopt the Production Release Practice |  |
This roadmap describes how to adopt the Production Release practice.
Main Description
### Getting started The goal of the Production Release practice is to transform the business value developed in Feature Development Sprint/Iterations into a finished product that can be released into production along with other products as part of a coordinated Release. If a development team has never practiced Production Release before, the best way to think of this special type of Sprint/Iteration is to consider a past project in which your team spent a week of 16-hour days doing all the things necessary to prepare for a deployment based on an arbitrary release date. Then realize that you do not have to operate like that any more, and that a Production Release Sprint/Iteration is your opportunity to calmly deal with all the preparatory activities that accompany a well-managed, coordinated release while other development team members are doing the same. In short, the Production Release practice represents the way you always wished you could prepare for a release but did not have the opportunity. ### Common pitfalls Because production release provides a development team the opportunity to "fine tune" a product and tighten up problematic areas of the code, it is good practice not to squander that Sprint/Iteration. A Release Sprint/Iteration is not a time to rest: Some development team members think that when they get to Production Release they can relax and not work too hard. However, when practicing the Agile value of Sustainable Pace, teams should not need to rest, and team members should maintain the tempo that they established during previous Feature Development Sprint/Iterations. Testing is not more important than documentation and training: While the various types of testing that are conducted in a Release Sprint/Iteration (integration, system, UAT) are important, documentation and training are just as important because how well end users can actually use the product to do their work is critical to a successful delivery. Successful hardening is more important than squeezing in marginally tested features: Do not think that more features delivered is necessarily better. While there is always a temptation to deliver more functionality in a Release, resist that desire and deliver only features that are mature and have been well tested and integrated.
This program and the accompanying materials are made available under the Eclipse Public License V1.0, which accompanies this distribution. EPF Copyright.