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.
| Published on Java Code Geeks with permission by Johanna Rothman , partner at our JCG program. See the original article here: Frequent Releasing Can Lead to Short and Frequent Planning Opinions expressed by Java Code Geeks contributors are their own. |
