Frequent Releasing Can Lead to Short and Frequent Planning

Agile approaches can help a team release more often. When a team releases more often, the product people can replan the product roadmaps. The project portfolio people can replan the project portfolio.

Not every team releases often enough to take advantage of replanning small and often. Everyone falls prey to “too much” thinking. The product people don't create MVEs or MVPs—they need the entire feature set. The team thinks they can stuff an iteration full of work and release only at the end of the iteration. Or, they only release when “all” the work is done.

One of the problems with waiting for “all” of a feature set is this: The user might not need most of that feature set. We all use bloated products that make our lives miserable every day.

Another problem occurs at the project portfolio level. Those people want to change to the next important project, but the team is still on the previous feature set.

This “too much” thinking and infrequent releasing can set the stage for multitasking. That's a disaster for finishing anything.

The longer a team waits to release, the more difficult the release can be, and the more the team is tempted to work via architectural layers instead of through the architecture.

There's another problem. The team doesn't receive feedback on their work until they finally release, at the end of the timebox. I've seen three and four-week timeboxes.

The longer the team goes without a demo, the less replanning anyone can do. Everyone requires big planning to deal with big releases—that “too much” thinking. Big planning permeates the organization.

This idea of “potential for release frequency” might help.

If you have a digital product, you can learn to release more than once a day. Maybe you release internally because your customers can't take it yet. However, your job is to figure out how to be able to release every day. (If you have a digital product and you don't feel you can release every day, see the small stories series.)

If you plan to release every day, even if it's an internal release, you see these benefits:

  • You can learn faster, as a team. Everyone (the entire team, including the product owner, can see progress and learn from what the team finished.)
  • Teams don't create tasks—they create stories.
  • You can change what's in the backlog and in the roadmap more often.

A team's ability to release every day helps everyone:

  • The team can stop large-batch planning. That means the team no longer has to plan for a quarter, and maybe not even too much for an iteration. The team might move to flow instead of iterations.
  • The organization can move from quarterly and yearly planning to more-frequent planning of less work. More-frequent planning helps teams stop multitasking and makes it easier to plan product roadmaps and the project portfolio.

Releasing something every day is one way of moving from starting work to finishing work.

Divorce your releasing (release more often) to see progress and plan/replan smaller and more often.

2 Replies to “Frequent Releasing Can Lead to Short and Frequent Planning”

  1. Thanks, Johanna. Another challenge with “all” releases is that I have seen everything in the release locked together. Meaning that the pieces cannot be separated. Making future changes more cumbersome. Making it feel like “agile doesn’t work here”.

    1. Jack, too true! I see this a lot in legacy products, where people didn’t have to (and there was no incentive to) separate the big product into its constituent pieces for ease of building and independent releasing. Many programs have this problem, too.

      Agile approaches challenge many of us to separate where reasonable and think of small independent parts.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.