Agile Alchemy: The Golden Release Frequency
We’ve talked a good deal about Agile Product Management so far, but there’s always more to discuss and a different lens to look at the processes through. We’re going to dig into release frequency today and consider Agile Product Management when it comes to releasing completed work. How often should it be done? Should every sprint be released? Those are the kind of questions we’ll cover. But first, a little background on Agile Product Management to make sure we’re on the same page.
Agile product management allows product managers and teams to build complex products like software while promoting an iterative and flexible approach. Agile is unique in its focus on customer collaboration and support across the globe in nearly every industry you can imagine. Agile values responding to change over following a plan although planning is still important see my recent roadmaps article for more about that.
Agile product management is a mindset; it’s a culture and a vibe that teams can practice and eventually perfect in their own way. It changes the main stage to working products along with individuals and interactions. It sounds obvious, but many companies care more for comprehensive documentation, processes and tools. The simple way to think about it is all work is completed by teams of teams. Teams are made up of individuals and the “work” is really those individuals interacting at different intervals while they complete tasks, knowledge work or anything else. The individuals and interactions within a business will make or break the product, culture and company projections.
To further the need for Agile Product Management, let’s consider Conway’s Law. “Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.” Read that again as it’s key. Any product organization will create products that mirror its internal communication structure and their culture. I’ve seen several companies ignore this advice, and none of them are doing well today. I’ve also seen companies ignore the advice when I tell them, but then later follow it when they “have the idea.” This is just the way Agile coaching goes. I consider that a success albeit a rude and inconsiderate one. The important thing is that work is getting done more efficiently and that teams can deliver that work incrementally.
Release frequency is a buzz word that’s often kicked around in quarterly meetings. It should be a word that’s constantly being used by your product and leadership teams. Where much of Agile is about planning and accomplishing the work, delivering that work isn’t always straightforward especially in software where different code branches and versions of the app or existing features may conflict if you’re not careful. The Agile way to think about releasing is in small updates. It’s not very Agile to release 20+ changes to the app and two new features. Now, if your organization is big enough or you have multiple product teams the above may be just fine. That’s the hard part with all of this Agile product management. It’s abstract and relative to your unique scenario, team composition product and position in the market.
Faster time-to-market, improved customer satisfaction, risk mitigation and, once again, adaptability are all benefits to be gained from improved release frequency. Release frequency, itself, is the number of days since your last release. To talk about this further, we need a way to measure it. As you know, product managers are always testing their assumptions and hypotheses. The best way to do that is to have a solid tangible way to measure a thing before experimenting with it. This makes product management scientific and facilitates innovation when done right.
Cycle time is one measurement used when discussing release frequency. The cycle time measured in days or hours (if you're crazy fast) is the time it takes from the beginning of development to the release date. This can show the heartbeat of the company. How long does it take for something to get to customers once the product team has given it the green light? That’s the cycle time. To have a decent cycle time, you need to have a reasonable release frequency. If you’re not releasing regularly, then work that was started previously is sitting, and the cycle time on that work is increased every day it’s not released.
The other key measurement for release frequency is escaped defects. The escaped defect count is your measurement on the quality of work being completed and also an indicator (albeit lagging) that there are process/interaction issues on the team or a QA gap. If there are one or two escaped defects, those can be ferreted out by increased QA effort and attention to detail on ticket writing and estimation. If there are 5+ defects (bugs) in your release, there’s too much in the release.
The escaped defects can be mitigated quickly by releasing smaller incremental updates. If the changes are small and simple, they can be tested quickly and released with confidence. Big sweeping changes that need thorough QA or complex edge cases are sure to be released with one or two defects without extra caution. Software is not easy; there are always edge cases and “unknown unknowns” that you just need to do the work to uncover, and more times than I’d like to admit, the users do something different than the QA team or even product was expecting.
Releasing small changes often allows product teams to get early and frequent feedback. The more you release, the more feedback you can get. That sounds pretty straightforward, but many companies hold back on releases trying to get everything just perfect. They finally release when customers are upset and end up missing something anyway. They should have just released smaller updates to the product that were testable, understandable and tangible. Even the most forgiving customers will tire of constant release defects if not handled properly.
Outside of product feedback and improvement, a quick release frequency means your team of teams can improve its process quickly and adjust with each sprint iteration. This is why in writing stories or making art as a beginner, it's suggested to complete your work. This aspect of seeing the project through each step even if it’s not perfect facilitates learning and natural curiosity as well as motivation to improve. A product without regular feedback or a team without process adjustments and awareness is not a successful one. It might be successful now, but it won’t be in three years.
Customers want to know that the company is capable of fixing its problems. It’s hard for them to just trust that things will be okay. Transparent and constant releases with a good release frequency do this. It shows the customers that you’re working on the product and where attention has been recently. If customers have needs or concerns, they should be able to see some of those moving through the cycle, if they are good moves for the product overall that is.
Cycle time relies on release frequency and helps to measure the efficiency of a team of teams doing complex work. It’s surprisingly hard to do this and many measurement methods turn out to be annoying authoritarian middle management tactics. Having concrete stats, like cycle time, takes the emotion and control out of the equation and allows teams to focus on doing what they do best. You can identify other bottlenecks in cycle time once you have a steady release frequency. If things are taking too long, you can use a cumulative flow diagram to see where the bottleneck is happening and improve that aspect of the organizational structure next.
Agile product management with well-defined and easily measured stats is like a roving magnifying glass that looks over the business. There’s no need for oversight as the numbers speak for themselves and teams tend to like it better this way too. When measured stats trend up or down, action can be taken and again measured to gauge the impact. There’s no one answer here again; agile relies on the practitioner being very aware of their unique situation alongside the tenets and recommendations of the agile community.
Speaking of what teams like, they like to be successful as a team of individuals. What does that mean though? The team only exists to ideate, refine, develop and release value for the company and the customers. Releasing valuable work for stakeholders is a major component of team happiness and morale. Without regular small victories, work can feel like a death march with no end in sight. Teams on these marches will start fine but inevitably culture and morale will take a hit over time which decreases the communication effectiveness and overall quality of everything in the business. With a lower release frequency of around 7 to 14 days, most software teams will feel accomplished with their work and see the needle moving on their projects.
Some startups and companies feel like this is too fast, but to be honest, your release frequency is most likely too slow unless you’re Amazon or Google. Amazon releases over 100k times a day. That means their release frequency is about half a million releases per week and most other companies building software release two times a month! Consider that the difference is astonishing and the value Amazon can create is visible and apparent. Fast releases mean more bug fixes, more feedback, more innovation, faster everything. The writing is on the wall here and teams could and should be set up to release as often as technologically feasible. All organizations are going to have some limiting factor here whether it be budget, resource, technology, process, the marketplace or more.
Start by measuring your current release frequency, cycle time and escaped defects on the last few releases. Then, measure the next one. Take these stats to the team or to leadership and propose ways to improve them. Many people like to play office and have meetings while getting nothing done. Focusing on these numbers and having serious conversations about continuous improvement is how work should “work.” Once you have a solid number for your teams, cut it in half and see what you can do to get there. You’ll undoubtedly have some problems to correct along the way, but that’s the magic here for agile product managers.
Some concerns with quick-release frequencies can cause teams to stumble or leaders to doubt. First of all, increased release frequency puts more pressure on the dev teams to only commit to what they can complete. Estimating stories to work on needs to be accurate and consistent. There can also be a quality concern with quick releases; teams may not have all the “time” they need to review and QA the work to be done. There are a few ways to think about this problem. If it takes too long to QA, the release is too big. If your releases are still taking a long time, it’s time to join modernity and automate testing.
If possible, your team should be building automated testing around the most crucial elements to speed up releases. Dependencies can also spring up and block progress, which means you need to facilitate very good communication across the company to keep the release frequency moving along and make sure everyone understands what’s happening. With all things in life, you need to find a good balance for the team between speed and quality. Nobody wants to sacrifice quality, but we still need to go faster and continue to push the envelope. Each company will have a different balance here, but they should all challenge themselves to improve constantly against those standards.
To pull it all together now, you can start by getting measurements on your release frequency, cycle time and escaped defects. Release frequency is the time between releases, cycle time is the time from starting development to release and escaped defects is the number of bugs found in each release after it’s live. With these stats, you’re ready to rock and should be able to see what number needs to improve first.
Focus on one thing at a time and watch the effects trickle through your teams before changing focus and improving the next piece. Just like incremental product delivery, you want to think about agile implementation and team/process management as incremental. Release frequency is key to building successful products and determining how your organization is functioning. In the time it took you to read this article, amazon already released ~4000 times! This is the way. Release more often and profit.