Enterprise Agility-The Big Picture (6): The Release

Note: In the post Enterprise Agility: The Big Picture, we introduced an overview graphic intended to capture the essence of enterprise agility in a single slide. In prior posts, we’ve discussed Teams, Iterations , the Agile Product Owner,  types of Backlog and User Stories and the Iteration Backlog. In this post, we’ll discuss the purpose of this entire endeavor, the Release. [callout (6)]


Big Picture 6-The Release

In the last few posts, we’ve described how agile teams cooperate to produce increments of software in iterations. While the goal of each iteration is to produce a “potentially shippable increment” of software, teams-especially larger-scale enterprise teams-find that this is a “tall order” and it may simply not be practical to achieve a shippable increment at each iteration boundary.

Not Every Iteration Can or Should be Released

There are a number of internal, technical reasons as to why an iteration may not be releasable:

  • Accumulation of technical debt (needed refactors, test automation, accumulated defects). No iteration is perfect and even good teams often build up some technical debt
  • Need to create specialty documentation and certifications that may not be practical or economical at each iteration
  • Need to test the application across the “matrix of death”, i.e. compatibility checking for the hundreds of variants that are likely necessary to cover all platforms, devices, interfaces etc
  • Need for more extensive performance, reliability or compliance testing,  for which the tools and resources may not be available or practical for each team

These are some of the reasons we have included a hardening iteration in our Big Picture model.

Moreover, there are good business reasons why not every increment, even if it were potentially shippable, should be shipped to the external customer:

  • Potential for interference with a customer’s existing purchasing contracts and support agreements
  • Potential for customer overhead for user training
  • Potential for disrupting customer’s existing installation

This is the reason many agilists have recommended the Two Levels of Planning and Tracking as I described in Chapter 10 of SSA. (Note: XP explicitly calls out the Release and Iteration pattern. Scrum, per se, has only the single Sprint construct, but in practice many Scrum teams have evolved a model of releases following a Sprint-Sprint-Sprint-Release Sprint (hardening Sprint) pattern, so I don’t think there is much debate in the agile community about this basic two-level construct).

A Release can be Internal or External

In Chapter 18-Systems of Systems and the Agile Release Train and Chapter 21-Impact on Customers and Operations, I described a number of constructs and constraints that cause teams to focus more on a continuous stream of Internal releases (truly potentially shippable increments) than External Releases (General Availability- release to market, upgrade install base, push to distribution, etc.). This focuses the team on things they can control – including fixed internal release dates, quality criteria, etc.- rather than what they cannot control – timing of announcements and PR, impact on install base, fixed trade show deadlines and the like. This may best be illustrated by the “firewall” construct in the following graphic:

Firewall between Internal Releases and GA

Firewall between Internal Releases and GA

So while the Big Picture labels it simply as a “Release”, it is with the understanding that the release can be either Internal or External and the general cadence is driven by a periodic and fixed Internal Release calendar.

Releases are Driven by a Theme and Feature Content

Be it internal or external, all releases follow the same basic pattern. They are driven by a Theme or Set of Objectives, a label that clearly communicates the business objective of the release along with a prioritized feature backlog. In the same manner that stories are sized to fit in iterations, features are sized to fit in a release. This helps assure that each release is driven by a set of objectives that deliver holistic (even if modest and incremental) customer value. At release planning time, features are decomposed into stories. With appropriate automated tooling support, the status of features can be tracked via accumulated story completion.

Planning the Release is a Seminal Event in the Enterprise

I’ve blogged extensively about the criticality of period, face-to-face Release Planning events and I won’t repeat it here. But in any case, every release has a kickoff Release Planning session that the enterprise uses to set the company context and to align the teams to common business objectives for the release. The teams, in turn, plan the release and provide an estimate of the feature set that will be delivered in the release. This is the team’s commitment to the release, and they endeavor to meet their commitment by satisfying the primary objectives of the release, even if it turns out that not every feature makes the deadline.

We’ll describe how the release content is driven by a Vision and a prioritized feature set (the Release Backlog) in the next post.

5 thoughts on “Enterprise Agility-The Big Picture (6): The Release

  1. I agree with everything outlined above. The one area to be careful about though is that agile relies on a continous feedback loop. If you have the luxury of leveraging very strong product managers and product owners, this risk is mitigated some because they can serve as a strong voice for the end client.

    For new products, it’s much more difficult because you are often implementing something with lots of unknowns. You may have a solid foundation for the core system but the outer 20% relies on direct and timely feedback from the real users of the system. In this scenario, you want to avoid a situation where you are leveraging too many internal releases. Furthermore, you want to target a very small customer to avoid situations where the end user wants everything working the way it did before PLUS some new features

    At the end of the day, Dean hits the mark on the key things to understand. The comments above shouldn’t be viewed as a contrary view. Instead, take items such as the folloing into account when deciding internal vs. external releases
    * maturity of the product – is it bleeding edge or established with your clients?
    * maturity of your product owners in the agile world – do they really understand what the end client needs?
    * how much downstream overhead do you have – are you an agile company? or an agile development organization within a non agile company?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s