In a previous article I shared Five reasons why you must talk about off-cycle releases with your business teams. This article goes beyond the why into the when and how. If you want effective, relationship building discussions about off-cycle releases, read on.
There are two ways to talk about off-cycle releases, reactively and proactively.
This article provides specific guidance for reactive discussions. These happen after the business teams have requested an off-cycle release. I will cover proactive conversations in a future post.
When a business team requests an off-cycle release there are three responses. You can say yes, say no, or have a discussion to understand and evaluate the need.
Saying ‘Yes’
It may be hard to believe, but sometimes it just makes sense to say yes to an unscheduled release request. If you find yourself in this situation here are the suggested steps to follow. These are suggested steps for how to have an effective discussion with the business team. You must follow your own company processes for handling the off-cycle request approval.
- Evaluate the business request. If you agree it is valuable tell the business team that the IT team supports the request.
- Work with the business stakeholders to follow the release request process.
- Jointly propose (request) the off-cycle release.
- Continue working with the business team throughout the process. Let them know if there are issues you must both address. Make sure you give them any paperwork or forms they must complete. Ask them for extra evidence they need to provide
- Be prepared to discuss your recommendation with anyone who doesn’t agree the release is a good idea
- Always be prepared for the request to be rejected.
- Even if you and the business team agree an off-cycle release is a good idea, the final decision may be out of your hands.
You can maximize the benefits of the ‘Say yes’ situation by making efforts to work with the business team. Try not to just work in parallel to them. Agreeing with an off-cycle release request isn’t common. This makes it a good relationship building opportunity. Each team may have separate activities to gain approval, but that doesn’t mean all the work is separate. Take every opportunity to work with the business on the business case to support the request. Your long-term relationship will benefit and that is good for all future interactions.
Saying ‘No’
There is only one situation when the IT team should immediately say no to a request. As opposed to having a discussion about it. In a limited number of situations there are no options for a release outside the fixed schedule. For example, during an annual code freeze or moratorium.
If you are faced with an off-cycle request when you know it isn’t possible, say no and then explain why it can’t happen now.
This may cause the business team to withdraw the request, or they may escalate the issue to try and get the answer they want. Even if they withdraw the request, the situation isn’t likely to improve the relationship between them and you.
You can avoid an escalation by discussing the request instead of refusing it.
Have a discussion
Few requests for an off-cycle release will be met with a straight yes/no answer. Most requests need evaluating to understand the benefits of the extra work. This evaluation either supports or undermines the request.
Evaluating the benefits of an unscheduled release require business and IT teams to work together. Each team must provide facts about the value and the cost for releasing early. Business teams provide the value and IT teams provide the cost.
The business teams should know the time, customer experience, or money value. If they don’t know, you are within your rights to ask the business team to get the information. Everyone in a company is responsible for spending company time and money wisely. If you ask for the value for doing extra work to support a release then you are being a contentious employee.
To balance the business case, the IT teams must provide the estimated cost for the release. This isn’t an exact dollar value. It is a rough estimate of the number of hours needed from the IT teams to complete the release. Depending on the size and complexity of the work and the release process, this ranges from a few hours to a hundred hours or more (testing and release management across multiple complex systems can really add up!).
Business cases usually come own to cost. If you don’t know the hourly rate for the IT teams, make that clear in the information you provide. Someone higher up should have the hourly rate for the work. They can calculate the cost to help with the business case.
As described in the previous article Why talk about off-cycle releases, the business may not be aware that there is any extra work to support their request. Be prepared to explain — at a high level, not in great detail — what a release involves. This isn’t just what is involved for your team, but work is done by all the IT teams involved in a release.
Off-cycle release discussion checklist
Your company processes may include checklists like this already. Please use your own company processes first. If there are no checklists, forms, or guides, feel free to use this.
To ensure a thorough evaluation of the off-cycle request, here is a checklist of topics you should discuss.
- What is the business value for releasing before the next scheduled release?
- It can be easier to answer the inverse question instead: What is the business impact of waiting until the next standard release?
- Loss of revenue? (could be fewer sales, losing customers, giving refunds, etc)
- Bad customer experience? (must be quantifiable)
- Fines or penalties for being out of compliance?
- Other?
- How many hours of extra work are created to deliver the off-cycle release?
- Which teams are involved?
- How many people and how many hours work?
- How much planned work won’t be done because the IT teams have to focus on the off-cycle release instead?
- What value is lost by delivering this work later?
- What risks are associated with doing an off-cycle release?
- Off-cycle releases are often done without the full mechanisms of scheduled releases. This usually means less testing, and that can result in issues not being caught before they get into production. If an issue is missed, there will be more work to roll back the release and/or fix the issue. All of that is more time not spent building whatever was in the originally planned work.
- Quantifying the cost/value impact of the off-cycle release is not always easy. This is a good topic to talk about with your team, your manager, and perhaps to your IT leaders. The IT teams all benefit when they understand the quantifiable impacts of working outside the fixed schedule.
When you have all this information you can compare the benefits and impacts of supporting an off-cycle release.
Remember, everyone in the company is responsible for the wise use of resources. Both the IT and business teams should provide the best data they have to answer the questions. It is OK for either group (business or IT) to disagree with the request if the business case doesn’t make sense.
A note about tone
Keep the tone of any conversation about off-cycle releases focused on knowledge sharing. Don’t be defensive. Once the business teams have the information, they may re-evaluate the request. Alternatively, they may continue pushing for it to happen. In which case you can start the process for handling the request. At least you know it comes from someone who has evaluated the net benefits for the business.
Important: You must follow the processes your organization have in place for these types of requests.
Conclusion
Now you know how to talk about off-cycle releases. When the next request comes along, you don’t have to say yes or no straight away. Evaluating the request together ensures the right proposal is made. This will almost always result in a better outcome for the business overall.
Having a discussion also helps build knowledge and understanding. Both teams will learn about the value of the work and the costs of working outside the schedule.
