3 Reasons Why a Sprint is Not a Release
Last year, a very bright product and engineering leader at one of the world’s largest media companies asked me a question — “What’s a product release?” I had never thought a release needed explanation, but sometimes the simplest questions are the most profound. In the past, I have written about other seemingly simple questions, including, “What’s a product?” So, in hindsight, I should not have been surprised when this question was posed.
The question was as much about the mechanics of a release as it was about how best to organize teams around them. He was asking a human engineering question veiled as a best practices to product management inquiry. And in a world where teams are increasingly heads-down on the technology due to “agile ambitions,” it is no wonder that the very concept of a release needs attention.
I believe the following to be true. A sprint is not a release. And releases are still important. Releases represent the big ideas that you are bringing to customers and the market.
Having clarity around what a release means to you and how they are managed drives accountability and responsibility. However, lots of teams move forward without such agreement and transparency. They often do suffer, and do not even know why delivering product feels so painful.
But the moment you start using an application like Aha! you are forced to think more seriously about your product releases and how to deliver new software efficiently, even when everyone wants to keep sprinting. Getting teams properly aligned around the notion of a cross-functionally supported release seemed obvious to me. I really never thought of addressing this most fundamental of product management and roadmap questions until the customer asked…..
“How would you recommend we manage releases? We are a widely distributed and dynamic team and we need to rally many groups and stakeholders to deliver functionality that customers can use. Other non-technical groups have given up on us. That’s because we often struggle keeping the entire team in sync and on schedule. What’s the best practice for thinking about releases?”
In a world of physical goods, defining a release is fairly straightforward. In most cases, it is when the product can be wrapped and sold on a shelf. And that act creates a forcing factor for most to be organizationally ready. A solid definition of a release for a physical product is something akin to the date that customers can purchase the product. Even if there are many components that go into the final offering, the item that customers are looking for and the final deliverable is generally clear because it can be bought and supported.
However, when we start thinking about digital goods, many of us have lost our way. That is because we have convinced ourselves that it is ok to think about the technology we deliver separately from organizational or even customer readiness to adopt it. Many now wrongly think that is enough to deliver great new software and the rest will take care of itself.
When we talk about virtual offerings like software — especially cloud-based services — teams often confuse rolling out new features with the total customer experience. This is why a sprint is not a release. A release is the date when the company is ready to deliver a new customer experience and support every customer interaction point associated with it — not just the act of providing access to new technical functionality.
Just because you and your engineering team are oriented around the technology stack does not mean that is all that customers care about or need. Do not mistake internal, technical-bits with how you should manage releases or set up a team to successfully deliver them. Customers read your website, call support, try to reconcile what they now can do with what they did the day before, and want to be able to explain to their boss what is new.
So, when our customers ask us how they should think about releases in Aha! we provide the following guidance and provide these suggestions. We suggest that this guide is useful for any team that is building a digital product and debating how to get everyone working together on releases.
It takes a product team This is the first principle, and everything else is meaningless if you get this wrong. It is critical to organize a cross-functional product or core team of leaders who can provide insight into and take ownership over key efforts within their organization. This is necessary to get ready to provide customer delight at every turn. A typical team is led by product and includes leaders from program management, sales, support, ops, and marketing. This team should meet weekly, have real authority, and be responsible for all aspects of a release including any required internal communications and training.
Track technical and non-technical deliverables If you are thinking more broadly about the entire customer experience, it is obvious that you need to track all of the technical and non-technical work that needs to be completed — in one place. Doing so will ensure everyone stays in sync as dates or plans change. How many times have you found that a date has slipped and most of the organization has no clue? This is where automatic product team notifications and using a consistent template of phases and milestones for every new release can help get you ready and make it clear who needs to do what. For example, if you are delivering a few bug fixes and incremental enhancements you probably will not need to rev the go-to-market engine.
Take responsibility Clear ownership drives accountability. Even though you might work in an agile environment with sprints, your job is to see the bigger picture. There is a reason the product manager is often considered to be the CEO of her product. So, as you think about all aspects of the product experience, you should be the customer champion and help each group be its best.
Hopefully, it is clear that a release is everything that impacts a customer. It starts with the new technology but carries on through every interaction. The key is to start from the perspective of your customer and orient your releases around delivering value to customers every way possible. If you do, you will set up your product and team for success.
