You’ve got CI/CD going strong, automated testing for everything, and you feel confident that your releases are safe. So you would never need a launch plan… right?
Wrong!
Let’s back up a bit.
What is a launch plan, anyway?
A launch plan is a sequence of steps that should happen before and after a feature is released to its customers. A launch plan could look like a complex and cumbersome document full of approvals and paperwork spanning weeks, but it doesn’t have to. It could also look like a checklist of 5-10 steps that require human action in the hours before and after a code merge flows through an otherwise automated process.
Agile Teams Need Launch Plans Too
A lot of folks associate launch plans with waterfall project management, and think that teams using Agile approaches shouldn’t need launch plans. And it’s true that having a robust test suite, continuous integration, continuous deployment, and small stories means that most of the time, you don’t need to explicitly plan your launches. Every merge to main results in an automated feature launch, with no human intervention required!
But! Not every team has robust, fully automated test coverage. Some teams are small, some products are new, and it’s challenging to have the kind of test coverage that offers a high level of confidence for every scenario. Some third party services are particularly difficult to test using an automated suite.
Secondly, even with all that test coverage, sometimes there’s a big new idea that needs a big, splashy launch. A company rebrand rolling out across multiple platforms. Changing the primary navigation on a web application, or updating the layout on a complex screen.
Another signal that you might want a launch plan is when coordination is needed across multiple teams / divisions / reporting lines - Marketing, Communications, Customer Support, Dev Ops, mobile app dev vs web dev, etc.
It comes down to this - when changes need to be made in a particular sequence and/or require coordination across folks who aren’t working together day to day, then a launch plan can really help.
But don’t just take it from me – The Checklist Manifesto, by Atul Gawande, is a light and accessible read that explores how impactful (even life-saving) checklists can be, especially for smart people doing complex jobs.
The central concept is that when we are in a high pressure situation and time is of the essence, it’s easy for even a smart person to forget a step, with catastrophic consequences. Checklists/launch plans allow us to leverage our reactive brain power to respond to new information, without having to also engage the planning parts of our brains.
All the Benefits, None of the Calories
The way to avoid your launch plan turning into a multi-month gantt chart is simple – keep it Agile by holding to the Principles described in the Agile Manifesto. Pull together the people who will actually need to do the work for the launch and talk about the steps and sequencing that are absolutely necessary for humans to do to release the feature. Automate steps that can be automated.
The conversation itself creates a shared understanding which will help during the launch process – you’re creating a team to self-organize around their shared goal. The launch plan artifact need only make sense to the people who will execute it; prioritize shared understanding over comprehensive documentation.
Refining a launch plan can be a lot like doing a work breakdown on a User Story, and has a lot of the same benefits – uncovering complexity and making simplifying decisions.
I like to keep my launch plans focused on the smallest possible window before and after the launch moment, and I articulate the steps NASA-style (launch minus 1 day, launch minus 1 hour, launch plus 2 hours, etc.). As the launch time changes, the plan stays relevant. I also like to use actual checkboxes in my launch document, in a system like Google Docs or Confluence that make concurrent editing easy. As steps are completed, they can be checked off.
Resist the temptation to create complex launch plan templates, or to lock launch plans in months ahead of the release moment! Start with a very basic checklist and only add information that the team anticipates will be helpful in the moment, such as:
“Which Slack channel should we post to when we want to let Marketing know that they can issue the press release?” or;
“What’s that particular sequence of commands for changing a config variable in that system we hardly ever touch?”
But What Does it Actually Look Like?
Here’s a launch plan one of my teams created recently, with identifying information stripped out:
Overview
Elevator Pitch
We’re firing text notifications to customers for three different types of events, but not if the customers have disabled notifications via the new preferences screen.
Launch Coordinators
Victor & Jacquie
Launch Checklist
Launch - 1 day - Merge flags and copy change & e2e
- Copy Change
- Turn on FeatureFlag
- Manual end-to-end tests done after copy change
- At least one of each type of notification has been triggered and received
- For a user with notifications disabled, at least one of each notification type has been triggered and not received
- URLs in each notification type click through to the right place
- Open tickets in the epic that are not launch blockers have been moved out of the epic
- All epics in the ticket are DONE
- Code deployed to production
Launch + 1 hour
- After deployment - Manual end-to-end tests in production
- Minimal set of happy-path tests to ensure that the pages are visible and that basic things work
- Twilio access to see https://console.twilio.com/us1/monitor/XXX
- Last Message logged before deployment: 2022-12-05 19:47:39 UTC
- 3 different message types
- Type 1
- Type 2
- Type 3
- Check alert systems
Launch + 1 day
- GA confirmation of messages
- updating push notification tokens for new device sign in
Convinced Yet?
Launch plans are a great tool for developers, product managers, and scrum masters to be familiar with. They can take a lot of the drama out of a Big Bang launch, and can also help teams that don’t yet have the benefits of CI/CD and robust automated test suites.
Alex Bernardin
