Note: This is part of a series of posts (AERP1-n) highlighting the critical role that release planning plays in achieving enterprise agility.
Recently, I outlined a standard (or perhaps initial starting) agenda for Day 1 of such an event in the following graphic.
Here’s the hour-by hour narrative that should accompany this graphic.
Session I – Business Context
The kickoff to the program should be led by the most senior executives who have responsibility for the product, system or portfolio which is the subject of the session. The meeting planners (Project or release managers, engineering managers, facilitators, etc.) should reach as high in the organization as possible for the kickoff speaker. That individual should have the awareness of the company’s context in the market as this is a great opportunity to bring a key group of stakeholders (those dev managers, team leads, product owners etc. who are present) up to speed on what matters most to the business. This might include internal organization or other factors, as well as revenue, market share or other external indicators of the company’s position in the market. If there are new corporate initiatives underway, this is an opportunity to present those as well, but remember there is typically only one hour for such a discussion, but the next opportunity is only (insert Internal Release Schedule interval here) days away!
Session II – Product Vision
The next session is a presentation by the product managers of the current vision for the product and the tentative roadmap going forward. The main objective of this session is for the product managers to communicate to the teams the objectives (or themes) and the specific feature priorities for the upcoming release(s), which may be either an external release (general availability to customers) or internal release (potentially shippable, but in any case, fully evaluate-able, complete system increment). If there are multiple product managers for the system, each will likely need some time on stage, but time must be limited based on scope and size of the meeting. Also, if there are common requirements (standards, performance and reliability objectives, internationalization, etc.) that must be imposed on the subject system, those should be highlighted here as well and posted somewhere for easy access by the teams. At the conclusion of this session, product managers should provide a handout or post their feature priorities visibly as those are the driving elements for the upcoming sessions.
(Note: Taken together, this meeting delivers the first two elements (Vision and Roadmap) of the enterprise practice Lean Requirements at Scale (Chapter 17).)
Session III – Initial Release Planning: Development Team Breakouts
The next session is the longest (three to four hours) and perhaps most critical session of the two-day event. In this session, the component teams break out into separate meetings (typically team and tech leads, agile masters, product owners, etc) and draft their initial plan to achieve the objectives of the next upcoming release. (Note: Rarely does time and visibility allow planning more than one such release at such an event). In this session, the teams iterate through the following process:
- Brainstorm and estimate all the stories that are necessary to meet the objectives of the release
- Place the stories on iterations on the release plan in sequenced and prioritized order
- Factor in local dependencies as well as interdependencies with other teams
- Create a backlog of things that can’t be accomplished in the period and that can be postponed
- During this process, there will also be variety of discussions with product managers, system architects and other teams to better understand scope, priorities, necessary infrastructure development, potential shared code, etc.
This process continues until one of two things happens:
1) the objectives are met, or
2) the available resources for the release period are fully allocated
For example, if the teams have adopted the “standard” iteration and release pattern I proposed in a prior post, then a team’s draft release plan might looks as follows:
(Note: we’ll discuss the above picture in a “What’s Wrong with this Draft Release Plan?” future post. But for now, we have a draft plan.
Session IV – Initial Release Plan Review
The next session is an “all hands” session designed to develop a common understanding of “how we are going to deliver this release”. In this session, each team presents their draft release plan in front of all the other teams (15-30 minutes maximum, depending on number of teams) highlighting issues, bottlenecks, interdependencies and the like. During this review, all teams will be looking for any impact on their plan that the subject release plan may imply. The big questions that are being asked and answered in this session include:
- Is it overloaded (too many stories) or under loaded (too few)?
- What blocks or interdependencies may be present or implied?
- Does it respond to the vision and feature priorities presented?
And finally, the key question
- Is this a sensible plan from this team?
During this process, any blocks or issues that are raised that are outside the control of the team and which must be addressed before any commitment are placed on an issues parking lot.
Session V – Problem Solving/Draft Commitment
By the end of this session, it will start to become obvious to all in the room (including the senior product managers and executives) as to whether the objectives of the release are practical or impractical. Most typically, the latter answer presents itself as a tentative conclusion and much more work remains. (Note: while this may seem disconcerting, we would question the aggressiveness of any enterprise or process that brings together such resources in order to discover a release plan that is already “in the bag”.)
So in this likely case, the next session is designed for problem solving, scope management and tacking the hard issues. Perhaps during this period an agreement on a new scope can be reached and all the issues that have been raised can be addressed. But in all probability, this can’t be accomplished in the one or two hours left in this meeting. That’s why we have scheduled the session for two days – not one. Even then, the teams will likely have some important homework assignments for the evening.
The evening assignments and the day two program and narrative will be the subject of future posts.