Tracking change and innovation in the enterprise software development community
Posted by Vikas Hazrati on Jan 06, 2009
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.
A ScrumMaster’s Checklist: Product Owner, Team, Dev Practices, Organizational
Collaboration, facilitation, leadership, coaching and team building - new skills required for Business Analysts on agile projects. Download the Agile Business Analyst to read more.
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.
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.
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.
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.
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
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.
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.
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.
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.
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
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
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
Book excerpt
How are messages
stored by
Apache ActiveMQ?
Download
new Adobe®
Flash® Builder™
Scaling Scrum
in the enterprise?
ScrumWorks Pro
can help.
Start a trial today
JBoss vs. Websphere
Cost, Performance,
Efficiency,
Innovation
IBM wins.
Kelley Horton discusses the reasons why her organization transitioned to Lean-Agile, the approach used and the visual tools helping them minimize WIP, concluding that visibility leads to success.
Alex Blewitt, Kevin Seal and Alex Buckley answer Java modularity-related questions: when is modularity needed, how to address it, and what are the improvements in OSGi-based development.
Adam Blum discusses the current trends in mobile development and smartphones, trying to predict what will happen in this area over the next 5 years so a developer would know what to expect.
Roy Osherove discusses the difficulties met when trying to test code embedded in a framework (cog), presenting several solutions to create unit tests for cogs, using Silverlight code as example.
This short article is a first-person case history of someone taking up Agility for the first time. It covers the problems and reactions that are common to most teams and most developers.
Scott Chacon talks about the technologies that power GitHub (Erlang, Redis,...), and the benefits of Git as a version control and as a storage system. Also: ShowOff, a JS-based presentation tool.
Israel Gat, Erik Huddleston and Stephen Chin present how Inovis realized a higher product throughput by using three unconventional Kanban practices and a Lean Release Management tool called APROPOS.
Ross Mason discusses how to use enterprise mashups by applying a number of patterns, such as FeedFactory, Super Search, and Pipeline, in order to find new ways to benefit from existing enterprise data
10 comments
Watch Thread Reply