Agile Soft­ware Devel­op­ment is all about pri­or­i­ties and iter­a­tive work. You pri­or­itze your task list and start work­ing on the top tasks, break­ing them down to small bits which can be han­dled in a short time. The goal is to enhance the respon­siv­ness to chang­ing require­ments. There are many meth­ods that describe how agile soft­ware devel­op­ment is imple­mented suc­cess­fully (Scrum, for exam­ple, proves to be vastly suc­cess­ful). Release Man­age­ment is one of the duties in a soft­ware devel­op­ment cycle which is not eas­ily imple­mented in an agile way. In my opin­ion, this is because the con­cept of a “release” in itself is not agile.

A “Release” means deliv­er­ing a soft­ware bun­dle which sat­is­fies pre-defined con­straints. Con­trary to com­mon agile mech­a­nisms, where only short-term goals are con­crete work pack­ages, these con­straints define long-term goals for the soft­ware. Fur­ther­more, a release of a large soft­ware bun­dle spans the work of many agile teams.  Scrum defines a team as 5 to 9 peo­ple work­ing together closely.

The project owner is the one respon­si­ble for the out­come of one team’s work. He rep­re­sents the inter­ests of the stake­hold­ers, and is the one who relays exter­nal goals (and pri­or­i­ties) to the team. But, alas, good prod­uct own­ers are hard to find — and release man­age­ment is not nec­es­sar­ily one of their strengts. Inter-team man­age­ment is out­side of the scope of at least this agile method, leav­ing the plan­ning of releases to another, non-agile method “above” the team-level.