An Agile Approach to Release Management

and then how to inject it into (propagate to) possibly multiple release streams. For these cases, agile teams can use a traditional Release Line  approach, with an agile twist.

An agile process also makes it easier to manage the disruptions to day-to-day development caused by bug fixes. The key to managing multiple release streams in an agile environment is to prioritize all the work for a team together. The product owner needs to decide how important a "bug fix" is compared to a feature. Agile planning techniques make the cost obvious. All teams, not just agile ones, work best in an environment where change is managed. When additional work is introduced mid-iteration, the performance of the team can suffer. The iteration approach of agile
methods gives the product owner a choice when an issue presents itself: "do I fix this immediately, and forego feature work, or do I wait until the next iteration (2-4 weeks hence)."

Laura Wingerd discusses some of the basic "rules of the road" for "channeling the flow of change in software development collaboration" in chapter 7 of her book , Practical Perforce. where she discusses the "flow of change rules" and the "tofu scale". The Tofu scale and change-flow rules/protocol are concerned with the relationships between codeline policies across the entire branching structure when it comes to making decisions about stability -vs- speed: One codeline's policy might make a certain tradeoff, but it is the presence of multiple codelines and how they work together, and how their policies define the overall flow of change across codelines, that is key to release management across multiple releases+codelines. These change-flow rules (which also
relate to the Mainline pattern) advise us on exacvtly how and when to do this. The change-flow rules are also well aligned with Lean principles ideas of minimizing the form of waste known as "inventory" or "work-in-progress" - functionality that has
been developed but not yet released.

We have had experiences where applying an agile approach helped manage the
flow of bug fixes. One team commented that their agile method involved a 2 weekly release cycle and they didn't need to rush bug fixes out -it had always been OK to wait for the next release. A key factor in the success of their development method was the trust that the rest of the organization had in the process - work got done (and released), and if
a feature was scheduled to go into a release it almost invariably did.

While agile teams pride themselves on their ability to be responsive, being agile does not mean being chaotic and undisciplined. Change has its cost, and agile methods provide ways of making the cost of change explicit. An agile project works best when there is some sort of rhythm for release cycles. Notice that we mentioned that a codeline is
"potentially shippable." Whether or not to ship is a business decision. (Which is how it should be!) Even though the codeline is always supposed to be "potentially shippable" all throughout an iteration, the decision to ship (or not) occurs at the end of an iteration. This is important, and emphasizes that the rumors that agile processes are chaotic are not true. You need to plan your releases and iterations to align or you risk hurting the efficiency of the team. 

Agile Release Management Enablers

They key enabling patterns for an agile project are

• Private Build

• Integration Built

• Release Build
• Continuous Integration (with automated tests)
• Release Line

• Release-prep Codeline
• Active Development Line

A Private Build  enables all team members to test any changes they make with some degree of confidence that they will not break the codeline. As part of the private build appropriate tests are run that give some degree of confidence that the code works. Because of the Private Build pattern team members can commit code often and