I’m working on the release planning chapter for Agile and Lean Program Management: Collaborating Across the Organization. There are many ways to plan releases. But the key? Release often. How often? I suggest once a month.
Yes, have a real, honest-to-goodness release once a month.
I bet that for some of you, this is counter-intuitive. “We have lots of teams. Lots of people. Our iterations are three weeks long. How can we release once a month?”
Okay, release every three weeks. I’m easy.
Look, the more people and teams on your program, the more feedback you need. The more chances you have for getting stuck, being in the death spiral of slowing inertia. What you want is to gain momentum.
Large programs magnify this problem.
If you want to succeed with a large agile program, you need to see progress, wherever it is. Hopefully, it’s all over the program. But, even if it’s not, you need to see it and get feedback. Waiting for feedback is deadly.
Here’s what you do:
- Shorten all iterations to two weeks or less. You then have a choice to release every two or four weeks.
- If you have three-week iterations, plan to release every three weeks.
- Make all features sufficiently small so that they fit into an iteration. This means you learn how to make your stories very small. Yes, you learn how. You learn what a feature set (also known as a theme) is. You learn to break down epics. You learn how to have multiple teams collaborate on one ranked backlog. Your teams start to swarm on features, so the teams complete one feature in one iteration or in flow.
- The teams integrate all the time. No staged integration.
Remember this picture, the potential for release frequency?
That’s the release frequency outside your building.
I’m talking about your internal releasing right now. You want to release all the time inside your building. You need the feedback, to watch the product grow.
In agile, we’re fond of saying, “If it hurts, do it more often.” That might not be so helpful. Here’s a potential translation: “Your stuff is too big. Make it smaller.”
Make your release planning smaller. Make your stories smaller. Integrate smaller chunks at one time. Move one story across the board at one time. Make your batches smaller for everything.
When you make everything smaller (remember Short is Beautiful?), you can go bigger.Tags: agile, continuous integration, lean, project management, short releases, small stories, swarming, user stories