Now!
The simple answer is that we want to release as often and frequently as possible. Product Backlogs consist of ideas and hypotheses of value. How long do you want to wait to find out if your hypothesis was correct? If your hypothesis is correct, how long do you want to delay the value it is going to produce? If your hypothesis is incorrect, how long do you want to build on and support that idea? Questions like these can help us gain a sense of urgency to get feedback sooner.
Soon…
Having a sense of urgency driving you to get feedback on your ideas is great! Sometimes we have constraints that make continuous release of done work not possible. Don’t be discouraged and give up trying. Discover as a team how you can improve. Make the progress that you can. There is a company I’ve been working with that was doing annual releases and now they are doing quarterly releases. Compared to annual, quarterly is sooner. We get feedback sooner and more often than before, but the challenge is still there to improve release frequency. Are there ever good reasons to delay releasing?
Later?
Some common reasons I hear for releasing later:
Complexity of the Product
Dependencies with other groups
Big ideas
Expensive transaction costs
All the reasons above (as well as any others) have to be weighed against the reasons for releasing now or soon. Here again are some questions that should be asked:
How long do you want to delay learning if your hypothesis was correct?
How long do you want to delay getting the value from the idea?
How much do you want to invest in an idea that you have not validated?
These could end up being product management, process, technology, or organizational impediments that your team faces in the pursuit of delivering value frequently.
It depends.
Ask a Scrum Master when we should release, and you’ll likely get the answer “It depends”. Things that can affect release frequency:
Automation of deployment, validation, and back out.
When you are doing the above activities manually, there is a significant investment required in skills, technology, and time to get it working. The main trade-off I consider around this is where we are in the life cycle of the product. If we are early, maybe this investment is unwarranted. I also look at if we have a future in this product. If so, this investment can help us retain (or regain) our ability to make changes with confidence.
Ease of implementation approval
Are your policies, processes, and procedures conducive to change, or are they still geared to protection from scope change that is built-in with traditional project management? If your processes are not adapting to the increased capabilities of your teams, it will start holding them back. Influencing a change to the policies and processes can come with proven success by using a solid Definition of Done and providing transparency around the cost of delays.
Customer adoption rate
There are some situations where your ability to change will exceed the desire your customer has to adopt the changes. In this situation, our focus is making the change easy for the customer, not just from an implementation standpoint (though that definitely matters) but also from the standpoint of the change being intuitive without them having to learn extensively to adopt the change. If learning is required, then the change needs to be compelling and valuable from your customer's perspective.
Although an attractive goal for answering the question of “When should we release?” is “now”, It can require significant changes to get there. We can use the questions we have covered to start conversations around this topic:
How long do we want to delay learning if our hypothesis is correct?
How long do we want to delay getting the value from the idea?
How much do we want to invest in an idea that has not been validated?
The answers to these questions should bring visibility to the value we get from releasing sooner and can help us focus on the value of continuously improving our capabilities to create done work that we can release to our customers.
Learn more about Scrum by joining us for one of our courses! Click here to see our full schedule or contact us today.
