Successes in Release Planning: An Agile Enterprise Tipping Point

In the “Release Planning” category and series on this blog, I described an enterprise best practice designed to coordinate the efforts of some number of agile teams in order to deliver a larger scale system in a somewhat predictive and systematic manner. I also described this process from a practitioner’s perspective in the Agile Journal.

The first time I remember seeing such a session in largely this format was an effort led by Jean Tabaka of Rally Software at BMC in about 2005. Since then, I’ve seen this best practice employed to good effect in a number of larger-scale agile transformations and I have facilitated a number of such sessions myself. As can be seen in the series, Release Planning is an intense, face-to-face process where team members meet to establish a common vision, set objectives for a near-term internal or external release, identify and coordinate their interdependencies, plan the iterations that constitute the release, and finally, commit to release objectives.

In one instance, we combined a couple of days of agile training and an initial release planning session in an “all in” kickstart for about 100 people. I recently noted a blog post on this topic from some of the participants and it looks like the process, and more importantly, agile in general, is really taking hold in that enterprise. The post is ” The Tipping Point: Release Planning – #3″ , and I’ve taken the liberty of providing a few highlights of “what success starts to looks like”, below:

  • “Vision – We were able to convey enough of a roadmap to declare a common long term goal. Every team had an equal focus on this goal and they understood their purpose. In past release planning sessions, some teams weren’t working on the highest priorities. This caused frustration and doubt.
  • Resources – We kicked off release planning with a known set of teams and resources. We didn’t spend valuable hours trying to figure out who would be on what team. We still had a few resource shifts that weren’t ideal but it was limited to one area.
  • Product Owners – We went into release planning with each iteration team having their most effective product owner …. we hired a few very promising product owners and we elevated a few past iteration team members to high potential product owners.
  • Dedicated Agile Build Team – We finally convinced folks that it was important to have a dedicated build team. Up until this release planning session, builds did not receive the valuable resources they needed.
  • Pre-Planning Preparation – We went into the release planning session with each team’s PM, PO and SM having a good understanding of what needed to happen. The teams had a backlog and they even spent time with the entire iteration team validating their thoughts before the planning session started! In addition, each iteration team brought along at least one of their architects to further improve our results.
  • No Major Surprises – We completed our release planning session without encountering any major surprises. No last minute major misses that could be used by the Agile Naysayers as reasons for why Agile can’t work. The old “Agile doesn’t plan long term” myth.”

This is a pretty insightful post, so I recommend reading it in its full context.

Meeting Deadlines: What’s wrong with this Release Plan #2? (AERP8)

In my last post, Meeting Deadlines: What’s wrong with this Release Plan #1, I noted that the ability to commit to and deliver on near term deadlines is a reasonable and necessary accomplishment of a professional agile team and enterprise. To achieve this, we depend a lot on the release planning function (see Release Planning category on this blog and this article in the Agile Journal). In the last post, we looked at a flawed release plan from one perspective. In this post, we’ll look at the same plan from another perspective.

In Waltzing with Bears by DeMarco and Lister, the authors posit that software teams aren’t historically very good at estimating and meeting deadlines. In my personal experience, that has absolutely been the case and the projects I have tracked over the years are typically late by about 50-100% of the initial schedule. In other words, six months becomes more typically nine or twelve. (Here’s a fun exercise: you do the math to see what an old-time, twelve-month plan becomes. And then reflect back on your last big waterfall project!).

This is illustrated with the probability-of-meeting-the-deadline graph from their book, which looks roughly as follows:

Deadline Probability Curve

Don’t worry too much about the shape of this curve, because it isn’t a science and I can’t draw worth a hoot anyway, but the point is that the probability of delivering before the deadline is basically zero. This is because we’ve most likely identified all the tasks that must be done on the project and they can’t likely be accelerated due to all resources being allocated.

And since the area under the curve (total probability of meeting the plan) is 100% (assuming that it will eventually be delivered at some point), then the probability that it will be delivered on any one day predicated in advance, including the deadline date, cannot be 100%! In other words, while it could happen, it isn’t very likely and it would be a stupid thing to build external dependencies on. In addition, since it can’t be delivered early as we discussed above, the logical conclusion is that it will probably be delivered late. Sadly, our own experience has aptly illustrated that this is the most likely outcome.

DeMarco and Lister hold that the proper thing to communicate is not the deadline itself, but the probability of meeting any particular date over time. However, that is a pretty sophisticated notion for most of today’s enterprises.

So are we forever doomed to bad outcomes relative to plan?
Do we need to consider a career change?

Not if we take the lessons learned and adjust our predictive model.

Now, back to my earlier post. We saw in this post that the first plan proposed by the team was flawed, i.e.:


Relative to the risk profile curve above, the flaws are pretty obvious, i.e.:

Original Release Plan

The probability of meeting the deadline is small, since it cannot possibly be delivered early and there is no allowance for the inevitable gotchas.

In response, the team came up with a revised plan as follows:


This plan was better received at the release planning session.

Why might this plan work when the other likely would not? Because it builds in the allowance for deadline risk mitigation as the following figure shows:

Revised plan with higher probability overlay

This has the effect of moving the probability curve to the left. Since the third iteration is lightly loaded, it might be possible to deliver a little early, thereby starting the upward curve earlier. Moreover, with the lightly loaded third iteration having the capacity to take on the unanticipated tasks and absorb any underestimated tasks from iterations one and two, it is much more probable to deliver it on time.

The probability is still not 100%, because it can’t be 100% at any particular date, but the area under the curve indicates that there is a higher probability of meeting the date than there is of being late!

Perhaps that’s as good as it gets. This is Research and Development after all. And it’s all software, even at that.

(Refer to Waltzing with Bears for a deeper and more meaningful treatment of the probability curve and its effect on risk management.)

Meeting Deadlines: What’s Wrong with this Release Plan? (AERP7)

Ideally, we wouldn’t have deadlines in agile. As Tom Gilb noted “it’s as though I as a project manager weren’t allowed to know the projects end until the date arrived. The only instructions I’d get in advance would be to “be ready to pack whatever you’ve got every morning and deliver it by close of day” (Waltzing with Bears, pg 132). That would sure force extreme incrementalism the XP way!

Practically, however, deadlines DO matter and the ability to predict a reasonable near term deliverable is one of the hallmarks of effective agile enterprise teams. After all, many outside teams and customers are dependent on us, and it’s reasonable to expect some degree of confidence, at least in a near term deliverable. Any reasonable degree of professionalism demands it.Fortunately, defining and meeting near term deadlines is one of the purposes of release planning, that quintessential practice designed to coordinate and steer large numbers of agile teams in a common direction. (Note: an entire discourse on release planning is posted under the cleverly named category “Release Planning” elsewhere on this blog.

I recently published an article in the agile journal (Experiences in Release Planning at Enterprise Scale: Two Seminal Days in the Life of an Agile Newbie) , an inside-out (i.e. practitioners) view of agile release planning, I don’t know yet if anybody read it, and it’s a little long anyway, but I thought this little extract might speak directly to the topic. In this article, in response to some objectives from product management, Mo and his team came up with a release plan that looks as follows:Draft Release PlanThey were pretty proud of this plan, as it appeared to meet the deadline and left room for some “hardening” activities (reduction of iterative technical debt) at the end of the release. The agile coach, Bill however, quickly underwrote their confidence with the following dialog:

Bill: It looks like you guys are in pretty decent shape for the release? But the plan looks pretty heavily loaded?
Mo: Yeah, we think it’s doable.

Bill: I see you have some stories in the hardening iteration. Do you think you’ve identified every story that you will need to meet the release objectives in the earlier iterations?
Mo: Well most of them.

And then the killer question sequence came in rapid fire…

Bill: What’s the probability that no new and significant stories will be discovered in the next 60 days”?
Mo: ummm, probably zero.

Bill: What’s the probability that you have estimated all the stories you have identified accurately, or overestimated the time it would take for each
Mo: ummm, probably zero.

Bill: What’s the probability that every dependency you have on other teams will be addressed exactly as planned?
Mo: ummm, probably zero.

Bill: “What’s the probability that no one on your team will be sick or take a currently unannounced vacation in the next 60 days?”
Mo: ummm, probably zero.

Bill: “What’s the probability that integrations with the other components will work as smoothly as you hope?”
Mo: ummm, probably zero.

Bill: “So what’s the probability that you will be able to deliver your component on time?”
Mo: ummm, ummm, probably zero.

Bill: “I think you need to rethink your release plan and come in tomorrow with an answer way above zero.

After some out-of-box, productivity-enhancing thinking, (see the article) they came up with a revised plan which looks as follows:

This plan, at lease, would seem to have a much higher probability of success. Here’s why:

  1. It leaves room for stories that could not be anticipated at the time of the plan
  2. It reserves an entire iteration for the reduction of technical debt
  3. It leaves room for overflow of stories that were initially underestimated
  4. It leaves room for the inevitable gotchas, interdependencies and refactoring that are sure to follow

Some might call this a “gutless” plan as it doesn’t look stretched beyond belief. And it isn’t. Rather it is simply, considered, logical, practical and probable. In other words, just one less impossible thing to believe in.

Release Planning- Day 2 Narrative (AERP6)

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:

  • Revising the component teams release plan to see if a plan can be created that meets the (potentially modified) objectives of the releases

Program Agenda for Day 2

We described the program template for the day 1 session in the following graphic.

release-planning-day-1-graphic.jpgIn a like manner, the program graphic for the Day 2 session is as follows:

Release Plannign Day 2 Schedule

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:

Sample Roadmap

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:

  1. Resolved to the satisfaction of the entire group, or
  2. 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.

Release Planning at Enterprise Scale – An Inside-Out Narrative

Some of you may have been following the series I’ve been posting on Release Planning at Enterprise Scale. This series of posts is aggregated under blog the category “Release Planning” and identified as (AERP1-n.) You may find it most helpful to read the posts from oldest (#1) to newest (#n) as it makes a better story.

In any case, I got a little bored with my traditional writing style and its abstracted, top-down description of best practices and thought I’d try a different tact for this important practice. The result is an article that was just published in the Agile Journal, which, by the way, is a great source for continuous and current thinking on the state of this movement. It also offers some of the best and current thinking on adoption patterns as well as team-based and enterprise practices.

This article provides an “inside out” (software practitioners perspective) view of enterprise release planning. You can find it here:

Experiences in Release Planning at Enterprise Scale: Two Seminal Days in the Life of an Agile Newbie

I’m interested to see whether readers find this style of writing effective, or not. Please feel free to comment there (on the content) and here (on the style.)

Release Planning Day 1 Narrative (AERP5)

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:

Draft Release Plan Graphic

(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.

issues List

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.

A Standard Iteration and Release Pattern for the Enterprise?

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.

Standard Iteration and Release Pattern?

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.

Release Planning Day 1 Schedule (AERP4)

Note: this is one of a continuing series of posts, categorized under Release Planning.

In earlier posts, I’ve described the critical role that release planning plays in enterprise agility. I’ve described the motivations and objectives (AERP1 and AERP2) and planning and preparation (AERP3).

Over time, I’ve developed a somewhat standardized, two-day “program” for such an event which has served a number of teams quite well. This program provides a draft, tried and true agenda that your teams may want to start with. Of course, as with all things agile, there is no one size fits all, so you should feel free to try it as is, modify it, or throw it out and plan your own event. In any case, I’m confident it will be an important learning experience for the enterprise.
Here’s what Day 1 looks like:

Release Planning Day 1 Schedule

Perhaps you can see from the end of the program, that one day doesn’t always quite get it done; that’s why we have reserved Day 2.

Organizing and Planning the Release Planning Event (AERP3)

Note: this post is part of a continuing series on Release Planning. The main posts in the series are organized and numbered sequentially (AERP1-n), and there are additional posts under the Release Planning category as well.


As we have described, (Release Planning: The Agile Enterprise Main Event (AERP2)) the release planning meeting is the seminal event in the enterprises agile process and representatives from all affected teams should attend. (For larger enterprises, there will be a sequence of such meetings, organized around cooperating components or subsystems.) Other stakeholders (executive sponsors, other departments, customers, etc.) who will be affected by the outcome should also attend. The meeting is typically a two-day face-to-face event with attendees including:

  • Agile Masters, team leads, Scrum Masters
  • Product Owners/Business Analysts
  • Product Managers and Customer Representatives (latter where feasible)
  • Tech lead and representative team members: developers, QA/Test, documentation, etc.
  • System and team architects (if applicable)
  • Release or project managers (where applicable)
  • Engineering Development Managers
  • VPs and executives responsible for product strategy, delivery and/or other affected operations


A significant number of team members have the responsibility to prepare for the release planning meeting. Organized by role, these responsibilities fall roughly as follows:

Product Managers and Product Owners

  • Understand status of current release in process
  • Prepare draft release plan, dates and themes. Where multiple product managers are involved, meet ahead of time and solidify a single vision and a single set of priorities
  • Prepare a product backlog consisting of prioritized features
  • Prepare vision presentation for the meeting
  • Be open to the negotiations/scope management that will likely occur

Development Teams

  • Organize and update the current product backlog (items not in current release)
  • Decide on story estimating mechanism
  • Understand current team velocity (work capacity) and any upcoming schedule constraints (vacations, holidays etc)
  • Understand and prepare to discuss current architectural/infrastructure status and initiatives

Engineering Managers/Release Managers/Project Managers

  • Plan schedule (1-2 day event) and logistics (main event room with lots of wall/board space, plus break-out rooms)
  • Invite and assure appropriate attendance
  • Coordinate executive preparation and presentation
  • Determine program and facilitator/facilitation process
  • Assure coordination and readiness of product managers, architects etc prior to event

With this preparation under way, I’ll describe a program (sample agenda and sequence of activities) in a post later this week.

You Might Need Better Release Planning if…..

The following bit I wrote was just published as the Tip of the Month in Agile University’s newsletter for February.

  • IF your agile team is just getting into the flow in a nascent agile enterprise, and if your teams have been head down so long meeting near term iteration objectives that they are starting to ask about the bigger picture – then there is something wrong with your release planning process (inadequate team vision)
  • IF your company organizes special projects to emphasize new initiatives and project managers spend time meeting about them – then there is something wrong with your release planning process (new epics not factored into release commitments)
  • IF late discovery of interdependencies amongst teams prevent increased velocities of system- level deliveries – then there is something wrong with your release planning process (interdependencies not considered in release commitments)
  • IF your team invests too little time in longer term architectural initiatives and big refactors – then there is something wrong with your release planning process (architectural runway given insufficient consideration in release commitments)

IF you and your teams find yourselves experiencing any of the above problems, don’t worry so much about the symptoms, focus on improving your release planning process.

IF you’d like to learn more on this topic, Agile Release Planning (synchronized, multiple-level release planning for agile teams of teams building systems of systems) is one of the critical, but little understood, enterprise skills I’ll be covering further in my upcoming Agile University Course, Scaling Software Agility: Best Practices for the Large Enterprises, which will be offered in London (Southwark) on February 27, 2008 and in Boulder, Colorado on March 18, 2008. A free copy of the book will be provided to all attendees who register for the course.

Also, I’ll be blogging about the value and mechanics of this important skill in the weeks ahead.