Note: This post is part of a continuing series where I’ve been discussing the critical role that release planning has in enterprise agility.
These seminal release planning events are one of the key mechanisms the enterprise can apply to use its emerging agile practices to drive a coordinated and directed strategy into the marketplace – a foundation for the Agile Enterprise.
I’ve discussed release planning extensively in the book and have more recently emphasized Release Planning as an answer to a number of critical questions in the following posts:
In a nutshell, release planning is to the enterprise what iterations are to the team, i.e., the basic cadence, a critical best practice and organizational metaphor that holds all the other practices together. For without iterating (working software every two weeks), the teams are not agile. Without effective release planning, effective agile teams may well drive the enterprise to distraction – lots of pressures for improvement, increased productivity – but the enterprise itself may not yet have the ability to more quickly drive the right solutions to the right customers in the marketplace.
However, as with all things agile, when one considers the need for even doing release planning, which implies a certain amount of cost and overhead, we are reminded of some fundamental agile (manifesto) principles:
- the most efficient form of communication is face-to-face
- the best requirements, architecture and designs emerge from self-organizing teams
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
And of course, the basic mantra,
“what is the simplest thing that can possibly work?”
These principles drive us to the conclusion that a periodic, one or two day, face-to-face meeting which gathers the right stakeholders together is the enterprises “Main Event”, an event intended to address the following objectives:
- Build and share a common vision
- Communicate market expectations, features and relative priorities for the next release(s)
- Reflect and apply lessons learned from prior releases
- Estimate and plan, in real time, the next release
- Gain a commitment from the team to deliver the next release
- Communicate any governing requirements such as standardization, internationalization, usability, etc.
- Communicate and coordinate any major architectural initiatives, refactors and the like
- Evolve, refine and communicate the product roadmap which the company uses to communicate to its customers and other stakeholders
In addition for those enterprises new to agile, this is an important opportunity to communicate to all stakeholders (particularly the executives) what the current priorities are, how the resources are allocated and reallocated based on priorities, and how the new agile processes are applied to deliver software to the market
Frequency of the Release Planning Event
The frequency of the event is dependent upon the company’s agile iteration and release patterns. We’ve recommended iterations of a maximum length of two weeks and internal releases (internal synchronization points that are potentially shippable, but decoupled from the general availability/customer consumable release) of a maximum length of 60-90 days. (By decoupling the internal releases from the external ones, we provide a degree of freedom that allows internal release planning to be scheduled and periodic, and the engineering teams to have a rapid delivery cadence, independent of any more public commitments (SLAs, public announcement venues, etc) the enterprise must make.)
So for many companies, an internal release cadence consisting of three “development” iterations plus one “hardening iteration” could look as follows:
With this (fairly rapid) cadence, release planning events would be generally be scheduled immediately before or after the internal release milestones. In practice, we’ve found that it doesn’t really matter exactly when, so long as a) the frequency generally matches that of the internal release and b) it happens before the last responsible moment, i.e before the release begins. We’ve also observed that for larger organizations, the 60 day internal release frequency is a big bite, and often we see it at a more leisurely 90-120 days. This may seem long to an agilist, but pretty fast to an enterprise that might have been releasing as infrequently as annually.
With this as context, I’ll be describing the preparation and agenda for the release planning event in posts throughout this week.