Note: This is part of a series of posts (AERP1-n) highlighting the critical role that release planning plays in achieving enterprise agility. (These are organized under the Release Planning Category on this blog.) In my last post, Release Planning Day 1 Narrative, I described the program and content of the first day of a two day enterprise event (see the post Organizing and Planning the Release Planning Event). In this post, I’ll finalize this sub-thread with the Day 2 Narrative.
(Also – for a different perspective on this topic, I recently Published an “Inside-out” view – taken from the perspective of a newbie agilist – of this entire release planning process in the Agile Journal at:
Experiences in Release Planning at Enterprise Scale: Two Seminal Days in the Life of an Agile Newbie )
Bur for this thread, here’s where we left off last time……
Where We Left Off Last Time:
By the end of the last program session on Day 1 (Problem Solving/Draft Commitment) it was obvious to all in the room, including the senior product managers and executives present who have ultimate accountability for the outcome, that the objectives of the release are likely impractical. We also noted that this conclusion, while perhaps disconcerting, is actually quite reasonable in that we would question the aggressiveness or competitive edge of any enterprise or process that brings together such resources in order to discover a release plan that is already “in the bag”. So having more work to do and some scope to be cut is likely, reasonable and appropriate.
And while the last session on Day 1 was reserved for problem solving, scope management and tacking these hard issues, in all probability, this can’t be accomplished in the one or two hours left in that meeting. After all, that’s why we have scheduled the session for two days – not one.
Session VI – The Evening after Day 1
While informal and ad hoc, the evening of Day 1 is typically a valuable working session for most teams. There are a number of reasons the teams will likely want to meet independently that evening:
- Reviewing the draft release plan with members of the team who could not be present for the full day session, re-estimating stories, adding missing stories for infrastructure and the refactor backlog
- Brainstorming shortcuts and applying out-of-box thinking for ways to meet the objectives of the release with the resources already available
- Assessing the impact of any scope reductions, interdependencies, etc. that surfaced during day 1
All with the goal of:
Program Agenda for Day 2
We described the program template for the day 1 session in the following graphic.
In a like manner, the program graphic for the Day 2 session is as follows:
Session VII – (Day 2, Session 1) Revised Objectives for the Release
The plenary session on Day 2 is reserved for whatever purposes might be necessary. Typically, this includes executives and senior product managers summarizing the tentative conclusions from Day 1, resetting objectives as necessary for the upcoming internal release, reassigning resources to teams with critical bottlenecks and setting the agenda and objectives for Day 2.
Session VIII – (Day 2, Session 2) Re-planning as Necessary
Component Team Breakouts: Based on this input and the conclusions from the teams prior evening’s working session, the teams again breakout to update and modify their particular release plans. It is often the case that many teams are already done, in which case they may use that session for localized problem solving and agile process adjustments or perhaps getting a jump on planning the next iteration in more detail. In any case, this breakout session should provide the opportunity for all teams to come up with a plan that IS compliant with the revised objectives of the release.
Product Manager Breakout: This is an opportune time for the product managers to get together and assess their roadmap based upon the tentative conclusions of the session. At this point, they should have a high fidelity (and highly probably) understanding of what the teams will deliver in their next internal release (IR1) and they can use this data to update their communication plans and longer term roadmap. In many cases, some of the backlog that didn’t get into the first internal release objectives will roll over into IR2, and since they already had some objectives that were not on the first draft IR1 objective list, they will now likely have a reasonably likely view of the next two internal releases (120-180 days of feature/forecast visibility). The output artifact is an updated “plan of record” roadmap for the next few internal releases that might take a format something as follows:
In addition the PM team will also develop a mapping of internal releases to external release candidates, so as to start having some visibility as to what they intend to deliver to the market, and when.
Session IX – (Day 2, Session 3) Final Plan Review
The third Day 2 session is a plenary session that essentially repeats the session 3 (Initial Re-planning Session) from day 1. Each team presents their plan for review and input – issues are noted – and the next team takes its place until all teams have presented. By now, a plan should be visible that does meet the revised objectives of the next IR, with a little backlog visibility into IR2.
Session X – (Day 2, Session 4) Commitment
Now comes the crucial test. However, before asking for a commitment from the team, the issues list must still be addressed. In this process, the facilitator, engineering managers, program managers (whoever is chairing the entire process) leads an item by item review. This process is complete when every item is either:
- Resolved to the satisfaction of the entire group, or
- Assigned to an accountable team, manager, or executive who has accepts the responsibility to resolve the issue before it has the potential to put the release at risk.
Then and only then, can the leaders ask the team for a commitment to the release objectives. Some teams have used the “fist of five” voting scheme which provides a visible outcome of the confidence of the teams in meeting the release objectives. In this process, each attendee is asked to vote (in full view of all the others) with a confidence factor in a show of fingers ranging from zero (meaning that there was no way we were going to do this plan or anything like it) to five (extremely high confidence).
With any luck at all, after all this work, the team will reach a high confidence factor (perhaps an average of 4-5 fingers) and the meeting can be adjourned shortly thereafter. (If not, a subset of the process must to be repeated again until a commitment can be reached.)
Final Session – Closing Comments
Based on the evidence before the teams and the conclusions that can be drawn, the meeting leaders will often provide a few closing comments. This section might include any of the following elements:
- A discussion of how the release will be tracked as progress develops and how progress mitigation and ongoing scope managed will be addressed and communicated
- A presentation of the updated roadmap by the product managers
- A general thank you to the attendees, perhaps with some small gift or token of appreciation
In any case, it’s important to put a nice “wrapper” on the end of the meeting so that teams leave with the confidence they voted and they feel good about the hard work that they invested to reach that point. Most importantly, the teams must also leave with an understanding that they have now committed – to themselves – to their teammates – and to the company, to doing whatever is necessary to meet the objectives of the release.