I’ve discussed “around this topic” in the book and in various posts as well as the classroom environment, but it occurs to me that I’ve never directly proposed nor published a standard pattern for iterations and releases for the enterprise. While “standardization and agile” are unlike things in many agilists minds, I often fall back on the mantra of make routine that which can be routine in order for the company and teams to be able to focus their energy, creativity and initiative to flex about the things that cannot be made routine. (A daily stand-up is just such an example, meet routinely every day to discuss the events of the prior day and the upcoming day, so as to avoid having to schedule ad hoc meetings throughout the day).
Moreover, I’ve also recommended that agile teams focus on high frequency internal releases, and not worry so much in advance about what does or does not go to the customers or market, as there are a variety of outside factors and other stakeholders who make that determination. (Chapter 20 – Impact on Customer and Operations). Along with that guidance, we have seen or espoused other recommendations that include:
- Standardize on a short iteration length – my primary recommendation – two weeks
- Allow for one hardening iteration at the end of a release cycle. These are iterations devoted almost exclusively to technical debt or additional testing backlog (such as system and performance tests which may require resources not practical in the daily build environment, testing on secondary platforms, etc.), or perhaps finalization of documentation and support materials, etc.
- Push product to the market as frequently as practical – typically 60-120 days maximum
Given these inputs a standard pattern for internal releases can emerge as seen in the figure below. Note: some of these internal releases may morph to become external releases, but the teams do not typically have to worry about that too far in advance, especially if they are just starting down the agile enterprise path.
I’ve used this pattern successfully to kickstart a number of larger enterprises. With some experience, the enterprise will likely modify this pattern it to better suit its purpose over time, but it’s a great starting point.