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.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s