Add to Google
More on the Agile Release Train – Internal vs External Releases
Posted on November 16, 2008 by Dean Leffingwell in Agile Release Train, Release Planning, Scaled Agile Framework/Big PictureIn a number of posts, including Enterprise Agility – The Big Picture(5) The Release Revisited I’ve commented on the desirability of separating Internal Releases (or Potentially Shippable Increments) from External or General Availability Releases. Although not directly represented in the Big Picture itself, this is the assumption behind the Agile Release Train graphic in the model. This creates a separation of concerns that allows development to work on the fasted possible pace, producing PSIs at an even and fast cadence, while the market and our marketing teams make the appropriate decisions as to what gets released to customers and when.
In a recent article entitled to To Release No More or to Release Always, posted for free download at the Cutter Consortium, (note you’ll need to enter the promotion code RELEASEMYTH) Israel Gat of BMC comments on this model as follows:
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.
He then goes on to note an even more potentially aggressive release postulate:
An intriguing question poses itself if you accept this premise of asynchronous operation. If the business is free to determine how it will promote a release in the market, why should engineering be bound to producing releases in the traditional manner? Can everyone benefit from relaxing the constraints that usually surround a release and move toward a more flexible, fluid release concept?
Ryan Martens, Rally Software’s CTO, commented on both this article and indirectly on the method behind the madness of the Agile Release Train in his recent post at Agile Commons, Ryan notes:
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.
Couldn’t have said it better myself.
–Dean
Hey Dean,
I just read this post: http://scalingsoftwareagility.wordpress.com/2008/11/16/more-on-the-agile-release-train-%E2%80%93-internal-vs-external-releases/
And then I read Israel Gat’s article at Cutter C., which this post refers to.
Well, I can definitely say it is interesting one and made me think
. So, the idea of fluid releases is based on multiple (very frequent) internal releases that are all actually shippable to client. And marketing choose from that set which one to release and when. So my understanding is that if you work in 1 or 2-week iteration pace then every iteration you deliver shippable version.
You can now use your frequent iterations for two purposes 1) make a piece of functionality, make it shippable; 2) make more (?), make non-production-ready spikes, not fully tested functions. I perfectly understand that 1-st sounds ideally in XP-fashion although exploited by minority. 2-nd way is more realistic but is definitely devoid of beauty. Well, I’m pretty overwhelmed by multiple thoughts after reading this post, probably that’s why I might be not very clear on what I express here. But still here’s qustions that it currently spawns in my mind (with first attempts to answer it):
Q: Is fluid release model only possible in XP environment?
A: Seems to me – yes. But then isn’t this the same rare bird as XP itself?
Q: What is better for a company (not particularly for engineering) assuming that 100% shippable 1- or 2-week increments are not feasible: keep delivering frequent non-100%-shippable increments with same frequency or shift to less frequent 100%-shippable increments?
A: I think 1-st is better, because gives you much more information based on high frequency. It’s a deeper question of “why you would need frequent iterations”, almost the same as “what you wonna do with an increment”. Now what makes me excited is very frequent iterations help company (not engineering only) understanding where they move to better, because product team, marketing and engineering pursue goals that have close intersection and “see how it works” often. So, to be able to “see how it works” and then make conclusions (do we want this feature in or out, will that be wise to invest more in extending the feature or not, will the feature be easy or hard from maintenance standpoint etc) – seems like important trans-iteration objective.
Q: The extent of flexibility in fuild release model actually based on how big the Pool Volume is? It sounds the same as “… based on how rarely marketing particiapte/iinitiate/cause changes in external release feature backlog”?
A: Features can not be “frozen” in backlog. They must change. Backlog has to change. But if it changes, then it means that company needs this change and something new is needed to be delivered instead of what was previously planned. And now it restrains the fluid model, because change per se dictates that the new increment (which includes the change) is desirable choice. In other words, chnages in backlog neglects it (?).
Honestly, Dean, I dunno why but this post was the most exciting thing I read about software engineering for few weeks or even more. For some reason it made me think a lot. Thank you and sorry for flooding you with all this
Sasha.
Thanks Alex,
Your comments always get right to the point. Even in light of Israel’s comments, I’m not sure it’s practical or even possible to ship every increment.
I’m not even sure its worth the effort to try at large scale and that’s why I always describe two levels of planning and tracking to begin with. For example, with the internal release cycle, it’s possible to implement larger architecture refactors within those boundaries without the necessity of making every iteration a potential PSI.
Most teams I work with are challenged to start producing PSIs every 60 (min) to 120 (max days) and that allows them to ship that often or less. It also isn’t homogeneous. One team I know ships server software updates every two weeks but a 2 gig client download only every six months. But they still cadence to every 90 days internal release.
So I support your conclusion:
“Q: What is better for a company (not particularly for engineering) assuming that 100% shippable 1- or 2-week increments are not feasible: keep delivering frequent non-100%-shippable increments with same frequency or shift to less frequent 100%-shippable increments?
A: I think 1-st is better”
–Dean
Couple of key thoughts from experience…
* Internal vs. External provides you a lot of options whether it’s enabling a focus on architectural functions, enabling catch-up on maturity of maintaining a true agile cadence or guess what… aligning within a waterfall or other system release schedule
* The one thing to remember is that the more you ship externally, the more of a true feedback loop you get. If you don’t have a true understanding of what your clients need (either due to lack of access or to lack of a sufficient proxy), you must deliver externally or you fail to gain the one item agile needs most to succeed – consistent feedback that allows you to change your implementation and product direction as appropriate
* As Dean mentions, getting teams to produce consistently is a difficult challenge and it will require 6-8 months of maturity and experience. Maintaining a consistent cadence even if one is internal vs. external will allow you to become more proficient at executing. For example, following a 3×2 cadence for any delivery still allows you to deliver every other release externally
* Internal releases can be very dangerous if people view them as short cuts – we don’t need to unit test or fully QA because we can always catch-up later… That’s a recipe for disaster and one should never use an internal release as a crutch for not addressing a flaw in execution!