Traditionally, software release is considered to be a handshake between engineering and business. Engineering passes on the tested code to business, which in turn promotes it to the market, thereby completing the cycle. However, with Agile, software release could be bucketed into two categories of internal and external releases. This helps in creating a loose coupling between the two. Internal releases are made by engineering and business has the option of using one of them as an external release.
In a recent article on the Cutter Consortium (download code RELEASEMYTH), Israel Gat of BMC makes an interesting argument for separating the “two” releases in the software world. According to him the internal and external release should be viewed as two faces of the same coin,
A body of code that delivers certain features and functionalities is one thing. The use of this body of code by marketing and sales to accomplish business results is quite another. Not only do the two activities differ, but they do not necessarily need to be tied together through a 1-to-1 relationship.
He gave an interesting metaphor example of a water pool with two pipes, one for inlet and the other for outlet. He compared engineering to the inlet pipe and business to the outlet pipe.
Think of the in-pipe in this example as engineering and the out-pipe as the business. Engineering can post releases at its own pace. The business can selectively choose from the posted releases. In this paradigm, marketing is not obligated to promote a release upon its completion. Marketing might do so in three months; it might choose to promote the current release with another release due at a later time; it might choose to make a release available on a limited basis; or it might choose never to promote a release.
Israel mentioned that since engineering is now loosely coupled with business, they can move towards a fluid release concept in which the software becomes alive and continuous. Engineering can churn out internal releases at a pace suitable to them and business can make a decision on which release gets to the customer as an external release and when.
Commenting on the article, Ryan provided some additional insights that Israel’s team ran three internal releases to one external release. He suggested that the benefit is to get valuable feedback and business can market the external release better. According to Ryan,
It worked great! As a result, I coach most agile teams to start by making sure their "internal release" cadence is twice as fast at marketing, operations and the market is used to. In this way you get a release where you can gain feedback and steer the "external release" to market better.
According to Israel, with Agile, frequent and faster internal releases make the software more alive and fluid. This renders the traditional release process obsolete. The separation of releases helps both engineering and business to work according to their release patterns without disturbing the release frequency of each other.
