In the post, Enterprise Agility-The Big Picture (5): The Release, we described that seminal, value delivery construct of the Agile Release. (see Big Picture below).
But as with all the other oversimplifications in the Big Picture, (which at times seems to create almost as many questions as answers) comments and questions have been raised about what makes a Release a Release. In the book, I described the release on the agile release train in terms of an “internal release milestone” as opposed to a GA (General Availability) release.
The reasons for this are many and for further perspective, I refer you to Chapter 18: Systems of Systems and the Agile Release Train and Chapter 21, Impact on Customers and Operations. In Chapter 21, I described at length how attempting to synchronize the team’s internal development cadence with external release milestones is an over-constrained problem. Dates and features never line up to market events; public relations has an information cycle of its own; customers do not always want to adopt your new software at the rapid pace at which it now evolves, etc. etc. (see Chapter 21).
To address this problem, I suggested that the development teams build their own engineering cadence in a manner conducive to the most efficient development operations and build a GA firewall between the internal development cycle and the distribution model. This is illustrated in the picture below:
This creates a separation of concerns which allows entities on both sides of the firewall to do their best work without constraining each other.
In any case, with respect to the Big Picture, however, I Indicated the Release milestone is just a Release and that has created questions from readers. From a purist perspective, the release illustrated on this picture is really an Internal Release, which may or may not be a GA Release, (though I’ve decided not to update the picture for fear that would be more confusing to the casual observer). If the internal release is not a GA Release, then the question becomes, why even have it? The answer is that the internal release model is integral and seminal to the agile enterprise model:
- From a portfolio planning perspective, the internal release frequency is controlled by the teams to a timeframe that makes face-to-face, enterprise-level release planning feasible from a travel and cost overhead perspective. Re-planning happens at these boundaries and hopefully, only these boundaries.
- From a technical perspective, if for whatever reason, it is difficult to assure true system level quality at iteration boundaries, then this milestone represent an absolutely Potentially Shippable Increment at the system level and it meets all the reliability, performance, standards compliance, and compatibility that is required for a GA release. Its fast, it’s frequent, it is of high quality and it is available!
- From a human resource perspective, teams perform best when they work together long enough to be in the flow (the performing phase of the Forming – Storming – Norming – Performing model
of group development) and that typically takes a release cycle or two, so the release boundaries
are the best times to adjust teams to address the current bottlenecks in value delivery. This provides teams with the stability they need for high performance, while simultaneously giving the enterprise the resource flexibility it needs to achieve agility.
Hopefully, this clarifies some of the questions and comments on the Big Picture Release.