For teams practicing Agile Software development, value working software over other artifacts, a feature from the release plan is not complete until you can demonstrate it to your customer, ideally in a shippable state. Agile teams strive to have a working system ("potentially shippable") ready at the end of each iteration. Release Management should be easy for an ideal agile team, as agile teams, in theory, are ready to release at regular intervals, and the release management aspect is the customer saying, "Ship it!."
Agile teams work under the same constraints as other software development teams. They must address issues of maintenance and support, the need for external artifacts like documentation and training, and the reality that not every customer can accept change at the rate that an agile team can (in theory) deliver it. To attain the goal of a shippable product at the end of every iteration, an agile team must manage the flow of change from a customer while maintaining discipline and good engineering practices.
We will discuss how release management works in an agile project and also explain how even non-agile teams can benefit from applying aspects of an agile approach so that value can be delivered to customers in a more predictable fashion.
Agile project management practices enable you to manage schedule risk in a project. In a sense, many are simply good practice:
- Plan to work in time-boxed iterations of 2-4 weeks
- Maintain a backlog of feature requests in prioritized order, and revisit the priority at each iteration boundary
- At the start of an iteration select the highest value items from the backlog, detailed planning for these items
- Integrate often
- Verify often
- Deliver and review against a plan
These practices affect how one thinks about release management, as it is a planning activity and any planning activity has uncertainty that increases the distance you are from the present. The goal of having features complete or not at the end of each iteration allows the user to determine what will be available to ship. The prioritization of the backlog allows you to compensate for problems by having the most important features developed first, so that you can still meet a release date should that matter for market or regulatory reasons. The always shippable goal means that you can, if need be, accelerate your release schedule.
An agile approach enables better release planning by combining planning discipline, which helps to focus on the highest value work, and also engineering (including SCM) discipline, which helps to identify and fix problems early, giving you more predictability. Agile practices make shipping a release a decision that product owners can make without worrying if the team will meet a date far in the future. The role of the agile team is to enable allow the product owner to make the decision on short notice if need be.
The IT Process Institute's report on change configuration and release performance study says that:
- Release trumps change: Rigorous release build, testing and rollback practices have broad impact on individual performance measures and overall performance. Change tracking and change oversight practices are necessary but not sufficient to achieve performance improvement on their own.
- Process discipline matters: There are no change, configuration and release silver bullets. Building a process-focused culture and monitoring and responding to process exceptions predict top levels of performance more than the many of the industry recognized best practices in these areas.