An Agile Approach to Release Management

thus have only small integration issues.

Once changes are committed an Integration Build serves as a gatekeeper for more exhaustive verification. The integration build is run on a build server that may be using some sort of Continuous Integration  tool such as Anthill, Cruise Control or Team City. Since the exhaustive testing is run asynchronously from the development team, tests that you expect will pass will not delay commits. An agile team often has a discipline that a failed Integration Build is an "all Hands" even, thus ensuring that integration problems are addressed quickly.

The combination of small commits, and frequent integration means that the cost of change is small, enabling rapid development.

A Release Build and a Release-Line may seem like odd beasts to mention in an agile context. Release builds typically have a few extra requirements that aren't strictly necessary for all Integration builds. And Release Lines are structured to have policies that limit change because you want to be extra cautious with released software. On the other hand, having a Release Line frees the Active Development Line to move forward and risk mistakes. Likewise, moving "almost ready to ship" code to a Release Prep Codeline  means that new feature work can move forward, while still enabling the team to address integration issues that may come up in final testing. While an ideal agile team will not use a Release Prep Codeline, it is a very useful pattern in practice.

Also the agile mindset is to think about what is possible, and decide whether or not to actually do something based on cost and relative value. Not to attempt improvements because the changes seem unattainable is an obstacle to improving your release process

Most any team can benefit from incorporating some of what we call Agile SCM Practices into their release management plan.

Common Questions about Agile Releases
Like many processes that work, an agile approach to release management raises some questions. Here are some common ones, along with some answers.

What does "deliver at the end of each iteration really mean? Being able to deploy or deliver  working software at the end of each iteration is an agile principle. It is also a principle that many projects, agile and not, seem to treat as unreasonable. Let's talk about how you can think about this practice in a way that makes practical sense, and also
address some common concerns people have about this idea.

What if my customer can't accept changes every 2 or4 weeks? The fact that you have "Working Software" does not mean that you need to actually deploy it into production. The benefit of having software in a working state is that your can make the "release" decision at each iteration, as business needs dictate.

Documentation, Integration Testing and the Meaning of Done
Many organizations worry that they can't have a fully shippable release each iteration. There is documentation. One thing your team needs to decide on when adopting an agile process is what it means to be "done" with a feature for an iteration. When you are using a non-agile process, "done" may mean that you have a complete distribution package. This is an excellent goal for an agile team, and it is attainable, but starting out with this as your done threshold may end up frustrating you. Agile practices are an excellent tool for risk management, so consider what the riskiest parts of your application are: Is it documentation, or is it the software?

A perfectly valid definition of complete software is:

• All visible features complete and stable
• All in progress features implemented in a way that does not break existing functionality and which can be hidden if needed.

There are also ways that you can get closer to a completed documentation set. While certain things, like final screen shots, may not be able to be done