MSF Agile and service packs management

Not a while ago, a customer asked me about how to incorporate the service packs and hot fixes to the agile development process, this triggered an interesting debate about the importance of a QA and release manager.

The UAT environment always must reflect the live environment, this means that the automatic updates should be off (or downloads without installing them), otherwise hot fixes and service packs will alter the test environment.

Every change in the environment should go through a new iteration, this sometimes causes confusion when developers thinks that the agile iteration will be only followed if a change in the code is introduced. This is not correct, Agile is not about development only, is about a product life cycle that includes the environment where the software will run.

A change on the environment will trigger a new iteration, where the product manager needs to approve (and justify) the change. This can be a security fix that affects the production environment. The iteration will not trigger an automatic change on the code (unless specified by the update) but the code will be included on the new iteration.

At this stage we have a new build ready to install. The QA manager should install the service packs or hot fixes on the UAT environment and install the build. The entire test must be executed on this new environment and the QA team will raise any problem detected as a normal iteration. Once the QA manager signs off the build under the new environment this will be hand over to the release manager for the production environment upgrade.

At the end of this iteration a new build has been generated with the upgrade notes attached, this will help in the future to track down the context where the software has been tested.

This post should help you to understand that the MSF Agile is a full life cycle methodology that can be extended to all the areas that affects the software, including infrastructure.