Software Releases are a lot more than code

We have a release coming up... are we ready? These words are spoken probably on a daily basis in the tech world. It can mean many things; but generally its putting the team and what they are making on a deadline. This is a good thing, you want to show the world (well, your customers) what you have and how it makes their lives better. You have probably committed some features or fixes as well, so the importance of a successful release is paramount.

Like any deadline, people will probably put off many details until late; and in the rush to make a deadline some details will be invariably left out. That isn't intentional, but without a good plan to release it can become a random exercise. I have worked with teams that have zipped up some code and just did a file transfer (with a 'please contact us if any problems') and some others that started release planning on the first day of the project.

What are our goals for a release?

• Customers get a new version of a product with new features and/or bug fixes
• Sales gets a new feature to sell
• Project managers wants to release a well tested version without stopping feature development
• Operations wants to do less manual work than the previous release
• Product needs to understand the differences between releases to account for new features and fixed bugs
• Everyone needs to understand and plan for what the priority is for the next release

Communicate effectively, and put the hard work your team did in the best light possible

Audience

Who is the audience? Well, customers obviously come to mind, but what stage are those customers in? Are they already paying and using the product? Are they new buyers? are they prospects that need a confirmation to buy? The release is for all of these people.  How does it get to those people? Through support, sales and marketing.

Stakeholders

There are many stakeholders that have an interest in the application you are making. It's important to keep contact and update status whenever there will be a change to the outside facing product.

1. Customer Success needs to know how new features work, and bugs are fixed before the Customer does.
2. The Product team should know the status of features and the deliverable before the demo to the larger group. They will get questions and shouldn't be put on the spot.
3. Sales and Marketing should know the status of any features or bug fixes promised so they can communicate to the Prospect or Customer.

Challenges

Things get out of sync with some many pieces that comprise a release. Code, docs, diagrams, how-to, support articles; there is just a lot of things flying around. How to know what is current and what is old?
Deliverable have dependencies. For the product to have accurate documentation, the product needs to be tested and the results documented. You need the software in a good state before you can do that.

Solution: Release everything, release often. Version the code, and everything around it. 

Versions are a great way of indicating when something was last edited, or just approved as still being the most relevant piece of information about the current state of reality.

A Product release strategy : Start in the center with a development release and work your way out. To get to the customer you need to get through the company.

Inner circle: Develop and test to get to a release candidate
Second circle: Company takes the development release and turns that candidate into a product release
Outside circle: Customer and prospects use the release, and the cycle continues.

Development

Lets start in the inner circle, and get that to a state that can be consumed by the 'company' circle. That will provide a solid foundation for the company to release that and everything supporting it for the customers to consume it.

Development releases everything from debug to testing to production, and validate each step

• use branches to isolate a release candidate, pick fixes for mainline/master. Pick a time for a 'feature freeze' and work on making the master branch solid
• Version: major.minor.dot = features.tech.fixes
• Start release notes
• These are all the issues in the release done lane on your kanban/agile/whatever board
• Smoke testing try to catch exceptions, crashes
• automated functional tests speed up this step. Always try to automate more each release
• Regression testing 
• Are specific features working from previous releases?
• End user testing 
• UX flows with jobs to be done test all the features together

Outputs for Development Release

Internal release notes (audience is product, arch, programmers, engineers)

1. known issues - in release note
2. how-to use new features - in help doc
3. Configuration for deployment
1. changed properties, added or deleted properties
2. Dependencies - package code dependencies, client lib for system dependencies
3. Environment - run certain process or application as a precondition
4. Architecture quality model, 4C's diagram. 
5. Programming notes (code standards, patterns, guidelines, review process)
6. Project: team dependencies
7. Engineering measurements
1. feature usage, performance, scale-ability,
2. cost of operations

Demo all this to the development team with latest version. This step is the final before releasing to the company.

Product

The internal product checkpoint reviews the metrics

• personas - problems defined and prioritized. What have we learned since our last release?
• feature usage since last release and collected feedback
• The key personas using the product
• The key personas buying the product
• market needs, competitive analysis
• ideas, feature requests
• traffic, conversions,
• The view from the customer
• A demo script/playbook with one user persona and one buyer persona represented
• The external messaging on the marketing website
• The Product/Major features on the internal pricing list

Demo to stakeholders (internal team, external sales) deploy to demo site. Also, releasing the Story for Sales and Marketing turns out to be really valuable. They had a deadline and had to make decisions on priority for the roadmap; so they had to commit to the priorities for the next 30 days. This aligned the development planning accordingly.

Product release notes

External release notes (audience is buyers and users)

• summary for buyer (reflect on marketing site)
• summary for user (user and setup guides)
• completed features and fixed issues from development release notes
• one-pager for sales and marketing

Goal setting for next release

Road-maps are part of a release! Define and publish monthly goals, and prioritize top 3 themes for team

• 30/60/90 road-map of upcoming features and fixes
• UX prototypes and story map from design sprint
• publish top 5 priorities for app
• publish top 5 priorities for team

Review ideas and problems on a regularly scheduled basis, but only talk vision stuff on those days, keep notes between the meetings to keep the focus on fulfilling the vision; and less time spent on rehashing it. Sometimes these big efforts fail because people are just tired of talking about them.

So, have a vision up front, but don't formalize it. Give some compliance guidelines in a quality model (aka non-functional story backlog) and let the design decisions during the iterations do the formalization when it is needed.

The Overall Story shouldn’t change too much; if you are totally re-writing the Story with a major release, that would be a pivot… but changes will happen as more is learned about the market/customer.

Wrap it up

This may seem like a lot, but it is what's required. The first time you do this it will be a lot, but each time after will be substantially easier. The benefits from this organization efficiency will show quickly and get better over time.

Get it out: Each released version just needs to be more coherent than the last. not finished, just better