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.
Community comments
Not the same thing, but very early beta releases achieve similar goals
by David Sims,
Re: Not the same thing, but very early beta releases achieve similar goals
by Vikas Hazrati,
Re: Not the same thing, but very early beta releases achieve similar goals
by David Sims,
Things to be in concern
by Fidel Chavarria,
Internal versus External Releases
by Israel Gat,
Re: Internal versus External Releases
by Vikas Hazrati,
Re: Internal versus External Releases
by Jeff Santini,
Couldn't agree more
by Henrik Leion,
In-pipes, Out-pipes, and flow
by Scott Killen,
Re: In-pipes, Out-pipes, and flow
by Israel Gat,
Not the same thing, but very early beta releases achieve similar goals
by David Sims,
Your message is awaiting moderation. Thank you for participating in the discussion.
It isn't the same thing as a stream of internal releases from which business selects some for external releases, but in a similar vein, we're trying out a very early beta test process. That is, of course, nothing new, but it's new for us to release a beta of our software this early in the cycle. Usually we wait until the code is nearly complete. In this case, we have the core of our code working correctly and a Team City continuous integration build server running tests on every Subversion checkin. The result is that we have the confidence to release a very early beta to just a select number of users who can begin trying it out.
This way, while we flush out all the functionality, we can prioritize the work needed by those select users who are trying out the very early beta release.
Cheers,
David
Flux - Java Job Scheduler. File Transfer. Workflow.
Re: Not the same thing, but very early beta releases achieve similar goals
by Vikas Hazrati,
Your message is awaiting moderation. Thank you for participating in the discussion.
It sounds like a pretty interesting and doable alternative to internal releases. So do you get a lot of feedback from the "select" early users? Does this feedback help in making a decision on whether the beta release should be made GA?
Do the select users complain about getting frequent early beta releases?
Sorry lots of questions but I am curious to understand how easy is it to extend the internal release analogy to beta releases.
Things to be in concern
by Fidel Chavarria,
Your message is awaiting moderation. Thank you for participating in the discussion.
In this approach internal releases are produced constanly, and this is great but these releases doesn´t get an appropiate feedback; the feedback that can only be provided by a customer. As a developer i think this approach will not give business value to the company since it leads to wrong expectations by our CEO's,
it gives the feeling that the engineers are producing software but...
Are they producing software that's fulfilling customers needs with their internal releases ...?
They will only get to find out this until an internal release become an external release.
The sooner we make external releases, we will be gaining more feedback by our customers and for sure, gain more business value for our company.
Re: Not the same thing, but very early beta releases achieve similar goals
by David Sims,
Your message is awaiting moderation. Thank you for participating in the discussion.
Hi Vikas,
> So do you get a lot of feedback from the "select" early users?
Not yet, but that's because the release isn't until tomorrow. :) However, I've been in contact with some of these users, and I know them fairly well. I know that they're depending on some of the new features in the new release, so I know I'll get some feedback.
> Does this feedback help in making a decision on whether the beta release should be made GA?
The key will be getting them to use the very early beta. And the onus is on me to know my users well enough to know which ones can really make good use of the very early beta. So, I don't have an answer yet to this question nor about the frequent releases, but I'll know if this was successful or not within four to six weeks.
One thing it *does* do is force our development team to do that "last 10%" of work necessary to do an actual release, which I personally like very much, as it forces us to consider most of the potential problems now (performance, documentation, packaging) instead of right before a target release date.
I hope that's helpful,
David
Flux - Java Job Scheduler. File Transfer. Workflow.
Internal versus External Releases
by Israel Gat,
Your message is awaiting moderation. Thank you for participating in the discussion.
I could not agree more - it is the feedback loop between developer and end user roles that makes Agile so powerful.
Having said that, it is a matter of fine balance. Any external release is somewhat disruptive operationally. The cadence of a hyper-productive Agile team is usually quite different from that of IT Operations teams in the customer base.
Israel
Re: Internal versus External Releases
by Vikas Hazrati,
Your message is awaiting moderation. Thank you for participating in the discussion.
I think though this would be ideal to get actual & quick feedback, however I agree with Israel that external releases are operationally heavy and need to be balanced out.
Couldn't agree more
by Henrik Leion,
Your message is awaiting moderation. Thank you for participating in the discussion.
I always advocate the use of automated building and (some) automated system testing where the build server creates (internal) releases and the system test script install and use these releases, as being a beta tester. Those outside of the development team can see the system test reports and choose a release to forward as an external release. An external system test team download real releases which have already passed the basic system test suite for their manual testing.
The build server is the natural delimiter between internal and external releases. Fully automated building and releasing makes it simple to separate the two. External deliveries are most probably a manual chore (and in my experience quite rare, typically a handful per year), but internal releases are not. In a recent project the build server created and tested an internal release after 20 minutes of SVN inactivity.
Re: Internal versus External Releases
by Jeff Santini,
Your message is awaiting moderation. Thank you for participating in the discussion.
Releasable builds(Internal Releases?) are great, but until a real user tells me they love it, I am sceptical of the result. Therefor, I would prefer to focus on getting users in front of the screen, an minimize any sense of "doneness" one might feel from a successful internal release. Of course having an automated build that creates releasable builds regularly is a prerequisite to frequent external releases, but I believe it is not an ideal end goal in itself. It is only a enabler to get real users in front of your product as quickly as possible
Actually JetBrains provides an excellent example of early releases. I am sure there are other great examples, but their Intellij IDE almost always has a beta version available to the Early Adopters Program which anyone can join. There is a constant stream of feedback from dedicated end users, not testers, engineers or marketers. And they put out releases at least weekly in practice. It creates a running conversation on their message threads and I assume it is a key enabler of making the best IDE I have ever used.
Whenever organizations suggest frequent releases are to risky I point them to this Early Release Program. www.jetbrains.net/confluence/display/IDEADEV/EAP
In-pipes, Out-pipes, and flow
by Scott Killen,
Your message is awaiting moderation. Thank you for participating in the discussion.
Let's talk about flow. Not about in-pipes and out-pipes with an intervening pool, but instead, let's discuss flow through a value chain that needs systemic optimization.
As agile is wont to do, Israel's example points out a bottleneck in the system. That bottleneck is marketing. Product is stacking up in front of the marketing machine. Time to optimize; and optimization according to Goldratt proceeds thusly:
# Identify the system’s bottleneck. (Marketing)
# Decide how to exploit the bottleneck
# Subordinate everything else to the bottleneck
# Elevate the system bottleneck
# Find and fix the next bottleneck
Of course, this is why agile transformations in development can, and inevitably must, end in organizational transformation. Software development organizations have been the bottleneck for so long that it's hard to realize that development is only one part in a value chain that progresses from ideation through delivery.
To press the water metaphor just a bit further, Taiichi Ohno pointed out that lowering the water causes new rocks to appear. All Israel and his team did was to remove that big development rock sticking up and lower the water level, only to find that a marketing rock was now sticking up.
- Scott Killen
Re: In-pipes, Out-pipes, and flow
by Israel Gat,
Your message is awaiting moderation. Thank you for participating in the discussion.
It is fascinating indeed to consider the subject in the context of Goldratt's theory of constraints. In addition to Scott, my colleague and friend Clarke Ching has indepentedly been very passionate on the subject. Must be more than a coincidence...
Part II of my essay on the subject (published under the same URL: www.cutter.com/offers/releasemyth.html) acrually discusses rebalancing the software value chain in entirety. It covers the fundamental assumptions, differentiation, operations, R&D, packaging, distributin and organizational configuration for so doing. The secret sauce is "containerizing", distributing and provisioning the output of hyper-productive Agile teams as virtual appliances.
Part III should be published by Cutter any day now. It outlines how to speed up time-to-market by adding a third ingredient to the secret sauce. It also proposes a few business designs that take advantage of the rebalanced software value chain.
Israel