Experiences in Release Planning: Two Days in the Life of an Agile Newbie


facto market leader, now looks like it will evolve into a combination social network/distributing gaming platform for mobile devices. Part MySpace-part SIMS2-part IM for young adults, but all in all a new kind of beast entirely.


. Now that's a big vision and something I can personally get excited about.

10:00 - 11:30 Product Managers at the Helm

Like I said, we're a pretty big company and we had presentations by four, ( yes, four!) senior product managers, each of whom was responsible for an individual line of games. Their time was short, so they had to be pretty concise. Each took us through a short deck with some context setting describing his gaming line, the current challenges in the market, and the big pain points our largest customers have been beating us up with. (S o I dangled a participle here, I'm a software developer, after all. ) It looked like the product managers had agreed to a presentation template in advance so it went pretty fast. Each went something like this:

  1. Competitive context for the product area - who's doing what to us and to others.
  2. Specific issues, opportunities, and challenges with customers.
  3. Our priorities for the upcoming releases.

But what I really remember were the last two slides from each product manager which highlighted the top five to seven specific initiatives in his area, in priority order! At the end, they distributed each of their presentations. There was no summarized, aggregated priority slide, but at least we knew what each of the four of them thought was important. All in all, we had all four decks in hand, and an aggregate of 20-some prioritized features.

A lot of these don't have any impact at all on me and my teams , I thought, but some do and some are pretty dang big, and some, I'm not so certain. This is getting a little more interesting, I wonder what happens next......

11:20-12:00 Engineering Management Speaks

 Next, Jan got up and delivered a "state of the engineering union" speech, discussing the general engineering process and our move to agility. She also described a couple of major architectural initiatives underway, including driving increased componentization, better separation of concerns through APIs, and rototilling the multitasking kernel, which needed to be replaced to support the new distributed games on mobile devices.

Fortunately, none of this last part was new to me, as a number of system architects had visited our team off and on over the last few weeks, describing the new product requirements, and amazingly, listening, as well as talking. So while the architectural issues were almost as intimidating as the vision and customer priorities, at least they weren't new and we had a chance to put our imprint on how this all needed to happen technically. What was new to me was the release process model she and Bill presented (see Figure 1).

Figure 1: Our release process model

She said there weren't very many rules about how we developed software ( thankfully) but the ones she did say were certainly eye opening!

  1. We'll build and integrate working software every two weeks.
  2. It will be integrated, unit tested, component tested, and system tested across all components every two weeks, too.
  3. We'll have a potentially shippable "internal" release available every 60 days. The iteration pattern will be three "development" iterations and one "hardening" iteration ( whatever that is ).
  4. The target for time to market for the first distributed game application (probably a port of two existing games) was in 120 days (around the second internal release). It

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.