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)]
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:
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.