Managing Product Releases

Question

I work as a Product Manager in a company focused on GIS Products. Our software development team works on both internal products and clients projects using agile methodologies.

I'm having trouble planning for each new release of the product, i used to plan each new release as a separate project, with a new project plan, time plan, srs, project closure for each new relea... and now there is too many documents to prepare, might take me a week to plan for a 3 weeks release. How do you guys normally manage a scenario like that?

Answer 1

I would separate a couple of part here:

1. Long-term product development strategy
2. Everyday release management

First, you need to know where you're going so you need to figure out goals which your product should achieve and ways (big chunks of functionality) to achieve that goal. That gives some kind of high-level roadmap which you plan to follow. As it takes into account business strategy you should have there big milestones, like delivering quarterly big hairy version with a big bunch of new thrilling stuff to your customers. And this is the point where you start dealing with releasing product.

You need to know which versions covers which features and when they go into production. Then, you probably need to prepare reasonable amount of documentation if you have once-in-quarter-or-less-frequent-release strategy.

Second, you mention agile as your method of choice and 3-week long timebox. It means that you should have something to release once every three weeks. And for such releases I'd try to limit amount needed documentation to as little as possible. If you don't push each of such versions into production that's good because you can perfectly skip most of documentation, especially parts regarding planning each sprint as a separate product. If you do push each version into production it's even better -- I believe there's little documentation which is really crucial if you release in such frequent manner. You should also have pretty repeatable process after a few consecutive releases so it definitely shouldn't be as painful as you say.

If you want to make it even better think about even more frequent releases. I don't how it is now, but some time ago guys building StackOverflow were trying to push something new into production on daily basis. Then incremental value you deliver is small but your increments are very, very frequent. This basically mean you just have to limit amount of different formalities around release process to lowest possible level which gives you powerful motivation to find lowest reasonable subset of documentations and planning you really need.

Note: that the everyday release strategy is just a way of fulfilling long term strategy so it should be means to achieve some bigger goals. As long as you are aligned with your high-level plan it usually doesn't really matter whether your nth release goes live on Tuesday or on Wednesday.

Answer 2

I have found that transitioning to Agile with short iterations and more frequent releases causes exactly the tension you describe. The old way of working isn't compatible (won't scale into) the new way of working: this isn't an Agile problem so much as a "The business just changed the way they are working" problem.

Some things that have helped relive the tension

• Talk to the consumers/customers for the documents. Understand the minimum information they need from those documents. In many cases all they need is a graph, or a bulleted list, or some other summary.
• For the "time plan" (schedule) - show the burn-up/down charts and see if that will meet their needs. The teams should be generating these naturally themselves
• Requirements/SRS: If you are tracking User Stories for the team, then can't that be used for the SRS? Start with some high level User Stories then decompose them as the team delivers. Don't write it all up front, but refine it over time.

Some things to watch out for

• Teams can ask for -tons- of your time with questions like "Which shade of blue should we use?" and "Ask the customer X for us" Some of these are valid and some should be pushed back into the team to "make their best pass at solving it"
• You might want to write more about "intent" rather than "shall statements" when you describe the project/release. Continuing to write "old style" requirements keeps you in demand from all the teams. Giving them the intent empowers them to take some ownership as well

I'm very interested to hear other perspectives on this. It is a very very common problem for Product Managemnt!

Answer 3

Check out my answer here on our Roadmap approach. Each planned release is a workpackage, and as such is planned within the available capacity.

We have two-weekly sprints, and the whole thing is directed through a monthly SteerCo. So I made one 'project management plan' (or rather a release management plan) for the whole year, and I issue a monthly status report for my SteerCo and other stakeholders.