Many IT departments deliver their work in releases. These are also called iterations, or cycles. Yes, some companies have a ‘continuous release’ capability. But most companies in the world still operate with periodic releases. Releasing new code weekly, fortnightly, or even monthly releases cycle.
The problem is, business teams don’t like release schedules. Maybe it’s because they don’t understand the steps or the need for the process. Perhaps it’s because, from the business point of view, release cycles slow down the delivery of fixes. It could also be because most business stakeholders don’t understand the implications of not having a release cycle.
Whatever the reason, if you work in IT, knowing how to talk about release schedules is important.
Why do you need to talk to the business about releases and release schedules?
Release schedules drive many of the processes for IT teams. It is almost impossible not to talk about them with the business stakeholders. Here are three reasons to talk about release schedules with their business stakeholders:
Reason 1: You want to give the business teams the right dates
A common planning mistake happens when IT teams talk about completion dates. The team developing the code provides a date for when they will finish their work. This is the date the team stops working on the code and starts to work on something else. But that isn’t the date the code will be available in production.
A common frustration occurs when a development team tells a business owner that the code will be complete on a set date. Then the business owner finds out they have to wait four more weeks before the work is available to use in production. You can avoid this situation if you talk about the release schedule whenever you talk about delivery dates.
Reason 2: Release schedules can help reduce scope creep and manage requirement changes
If requirements change (Ha! I should write when they change). When requirements change, the new work may not be ready in time for the originally planned release date. The business owner needs to know the impact on the final production release date whenever they ask for new or changed requirements.
If a release date is missed it can be a month or more before another scheduled release. Never assume the business teams know this. always talk about the impact on the release schedule when you talk about requirement changes.
Reason 3: Release schedules help the business teams plan their work
Most IT releases need some business inputs. It might be as simple as a business owner signing off that requested changes took effect. Or, the business users might run expensive tests to see if everything is working. In some cases, the IT release schedule includes mandatory business involvement.
Never assume the business teams know they have inputs or involvement in the release process. When starting new work with a business team make sure you talk about what that team (or person) needs to do to support the release. Because, whatever their level of involvement, the business teams need to plan their work just like you do.
How to talk about releases and release schedules
Be explicit and name every date you give: When a project manager or business owner asks for the date that your work will be done, be clear which date you give. For example:
The project manager asks ‘When will the work be finished?’. You respond ‘Our team will finish on July 17.’
- Does this mean the development team will finish the coding on the 17th?
- Will the testing will be complete by the 17th?
- Is that the date for the code drop before the release?
- Is this the day of the release — with the release happening at 11pm?
- Is this the live-in-production date? The day after the overnight release?
Giving a date without being explicit about what it means will often cause confusion. You can avoid that by stating exactly what will happen on the date you give.
Differentiate between your team’s done date, and the ‘live in production date’: To be sure the business team understands the dates you are giving, give the date your team expects to complete your part of the work AND you must give the expected ‘Available in production’ date for the finished product.
- Example: ‘Our team will complete the work on April 9th, and it will be live in production on April 28th. The 28th is the morning after the release.’
Make it clear when you don’t know the production release date: If you only know the dates for your own pieces of the work, and not for the release of everything the business is asking for — say that.
- Example: ‘Our team will complete our work on April 9th. I don’t know what the other teams are doing. You should check with them to find out the final release date for this all to be in production.’
How to talk about release schedules if the business stakeholder doesn’t want to wait for a release
Sometimes business teams are resistant to the idea of a release schedule. this is frustrating. But, it is also an opportunity to learn. It is an opportunity to share information, and to build a relationship with your stakeholders.
You can learn by asking questions to find out why they are resistant to the release schedule. Delving deeper into the reasons behind a requested delivery date can help find alternative ways to meet the business need. You can read more about how to talk about deadlines and delivery dates here.
You can share information about the release schedule. Formal information like the release calendar shows how the releases are set for the rest of the year. You can also share informal information such as the reasons for release schedules.
You can build relationships through both learning and sharing information. The more business and IT teams understand each other, the better their working relationships.
Conclusion
You should include the release schedule topic in any discussions about timelines and requirement changes. As well as in conversations about and business activities connected to the release. If you do, the business teams will have a better understanding of the release process. This helps avoid the dreaded ‘off-cycle release’ request.
