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.

Advertisements

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:

revised-release-plan1.jpg
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 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.

release-planning-day-1-graphic.jpg

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.

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.

Release Planning: the Agile Enterprise Main Event (AERP2)

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:

You Might Need Better Release Planning if….

Yes, Enterprise Agility is Hard

Enterprise Agility is Hard, but Release Planning Helps (AERP1)

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:

  1. the most efficient form of communication is face-to-face
  2. the best requirements, architecture and designs emerge from self-organizing teams
  3. 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:

iteration-release-cadence.jpg

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.

Yes, Enterprise Agility is Hard – But Release Planning Helps (AERP-1)

Note: This is the first post (AERP-1) in a series on Agile Enterprise Release Planning which I hope to continue over the next few weeks. They’ll be labeled AERP1-n, so you can eventually read them in sequence, front to back, if you like.

From the last post, Yes, Enterprise Agility is Hard, I noted:

“I’ve also come to the conclusion that effective Release Planning (agile, synchronized, multi-level release planning that is) is one of the critical keys to understand and implement agility effectively at enterprise scale. While I covered it somewhat in Chapter 12 – Smaller, More Frequent Releases and in Chapter 18, Systems of Systems and the Agile Release Train, I didn’t emphasize it as a significant and somewhat stand-alone enterprise practice that I now see it to be. To address this shortcoming, I’m writing an article on release planning from the inside out, i.e. an experiential, day-in-the-life emulation of a team lead experiencing an enterprise release planning session. This article should be published in the March 12 edition of the Agile Journal, Sharing Agile Successes. In addition, I intend to describe it more succinctly in some upcoming posts this week.”

When transitioning an enterprise to agile, I don’t generally start with the larger enterprise practices (Part III of the book), rather we (meaning me and a number of other coaches I know) typically start teams in what I call “heads-down-iterating” mode. Getting started with agile is difficult enough that first things must come first, and first, development teams must master, or at least have experienced, the basic project management and engineering practices of software agility. Forget the long term objectives for now, focus on what you can deliver and how you go about doing it in an agile, incremental, and quality-embedded way. After all, you can’t build an agile enterprise out of non-agile teams. And you can’t build a big, high quality system out of quality deficient little bits.

To start, many coaches start out by just getting the component teams organized and starting them iterating. This requires some basic reading at a minimum, and ideally some coaching and training. It also requires some time – at least 60-90 days – just to get the basic patterns down, and as I noted in my last post, even longer to master.

In order to help the teams succeed, companies often need to ignore many of the existing process and governance practices, or at least provide a short amnesty for those teams while they experiment with the new model. After all, an agile team can’t run very fast while trying to conform to non-agile milestones like “test plan complete” or “Milestone 2’s 50 point checklist”, or “software requirement specification approved”.

This problem/state of the enterprise is also paralleled in larger companies who are starting to see agile growing from the “bottom up”. Teams are doing stand-ups, software seems to be working and available more frequently and something is definitely different afoot. But in all likelihood, the types of documents, reviews, milestones etc. the company has insisted on prior (we respectfully note that all of which were originally designed to help, not hinder teams on their quest for quality and productivity) are not being followed well, or even at all. This causes a lot of consternation in the executive ranks who are responsible for governing these activities. After all, they are ultimately responsible for the outcomes and their jobs, if not the company’s future, hangs in the balance. It’s also possible that the agile teams may have “thrown out the baby with the bathwater” (for example, a corporate governance requirement that “all components must be subjected to a threat assessment review” in order to assure newly developed software meets security requirements, cannot be safely ignored).

At about this time in the evolution of the company, the entire agile initiative is threatened and if this stage of development is not recognized and addressed, it will “die on the vine” right then and there.

Moreover, the example above is just one example of the many concerns that are appropriately raised at that time. The question naturally arises in executive offices: “If this agile thing is to work, how do we answer the types of questions that some of our original practices were designed to address? Questions such as:

  1. What is the vision the teams are currently working against?
    (“after all, there is likely no marketing requirements document or software specification, so how do we know what they are doing. Even if we trust them, isn’t it our job to take this company in the right direction?”)
  2. What will we ship next and when will we ship it?
    (there is not likely to be a pert char around anymore. Even worse, some agile teams might be telling management, “we’re agile now, we’re adaptable, we’re empowered, and we don’t have to tell anyone what we will ship or when”)
  3. What longer term architectural initiatives must be addressed across multiple teams?
    (“if architecture emerges, how do we impose common infrastructures, usability guidelines, security solutions, etc”)
  4. How do we communicate common requirements across all teams?
    (example: “Can they all decide on their own what programs get internationalized, in what languages and when? That will be chaos.”)
  5. How and when do the teams coordinate their interdependencies?
    (“we know they should work together, but they are too big or too distributed to make that natural. Are they talking about the right things? After all, they aren’t sending us plans, documents or status reports anymore”)
  6. How are our resources allocated to the important, prioritized initiatives?
    (“How do we know whose working on what and whether the priorities are being addressed in a way to assure ROI. We don’t see documented plans any more, so how do we know who is working on what and when”

Fortunately, these are the types of questions that Agile Enterprise Release Planning (AERP) is designed to address. And we must address them, or our initiative will likely fail. So we’ll look further at this important practice in upcoming posts.