It seems like an open-and-shut case.
Code freezes are a relic. A leftover from the days when rigid Waterfall methodologies offered the only option for product development and release. The whole concept of stopping production and delaying release—just to test for bugs and other functional issues—has no place in modern, Agile product management.
At least that seems to be the consensus view among many Agile gurus.
But does it hold up? Once you scratch the surface of the most common arguments against incorporating code freezes into Agile product management, will they still seem archaic?
In this piece, we’ll explore the three main arguments against incorporating code freezes into your Agile product management, and we’ll break down where those arguments fall apart, all to help you make a better decision about whether or not you should incorporate code freezes into your Agile product management.
Argument 1: Code Freezes are Irrelevant and Unnecessary
This argument is pretty simple and concrete— modern Agile methodologies and tools have eliminated the need for a dedicated QA and testing window.
Agile methodologies such as peer code reviews, pair programming, and the constant monitoring of system health give you much greater visibility into an application or feature’s performance while it’s being developed. Bugs and issues are easier, and more likely, to be caught during development itself, and resolved prior to any dedicated testing and QA activities.
New tools have also automated many tests. They constantly evaluate code to make sure it’s clean and ready for production at all times. Issues are identified in real-time, and alerts are immediately sent out to resolve them ASAP. The number of tests that have been automated is already wide-ranging and continues to grow, dramatically reducing the volume of manual tests that need to be performed.
The result of these new Agile methodologies and tools is easy to see. Most of the core testing and QA activities performed during a code freeze are either being performed during development, or performed by software. In Agile, software and features now exit development at a much higher level of confidence than they used to, making a dedicated code freeze harder and harder to justify.
Argument 2: Code Freezes Break a Core Agile Principle
This second argument is a little higher-level. Basically, it argues that code freezes don’t have a home in Agile methodology because they break one of Agile methodology’s core principles— reducing the time between development and release.
The more refined your approach to Agile, the more you will try to shrink this window of time. The most refined current approaches to Agile are Continuous Integration and Continuous Development (CICD), and they aim to break development into small, incremental changes in order to “release” changes to the code as quickly as possible. In the purest application of CICD, development and release barely exist as distinct phases— new code is integrated into the application almost as soon as it’s completed.
By contrast, you need to maintain distinct development and release phases if you’re going to deploy code freezes. After all, that’s where the code freeze lives— in between those two distinct phases. Instead of trying to minimize or eliminate that window of time between development and release like most of Agile methodology, code freezes force you to formalize this window to the point that you need to build your development and release schedules around it.
If code freezes don’t align with core Agile principles, then it’s hard to make the case they still belong in the methodology.
Argument 3: Code Freezes Lead to Slower, Lower-Quality Releases
This final argument is a big one, and it includes a few different angles.
To start, it argues that code freezes add a lot of complexity and additional moving parts to your roadmap, and naturally increase the chances that something will go wrong and throw off your timeline. Even if nothing goes wrong, the work involved in code freezes is time-consuming and unpredictable (as you don’t know what bugs you will find or how long it will take to fix them), that by simply adding code freezes to your roadmap you will create slower development and release cycles.
Next, it argues that code freezes will reduce your development team’s productivity. While Agile in general, and CICD specifically, keep your developers constantly working in an unbroken chain of productivity, code freezes force your developers to stop work at pre-defined intervals. By doing this, you will break their rhythm and force them to try to work around your code freeze policies, instead of finding and maintaining whatever flow makes them most productive.
Finally, it argues that creating dedicated windows where you stop receiving business requirements will limit the features and functionalities of your releases to whatever can be completed before the freeze, which will lead to lower-quality, less comprehensive software and applications.
Making the Case for Code Freezes: A Losing Battle?
At this point, it’s looking pretty bleak for anyone who still wants to include code freezes in Agile methodology. Detractors from this practice make some very compelling arguments and an overall solid case that, since the development of modern Agile methodology, code freezes have become:
- Obsolete and irrelevant
- Misaligned with modern development practices
- A barrier to rapid, high-quality releases
But while these arguments are compelling, and contain a lot of accurate information, they are not bulletproof. And there are fundamental flaws within each that need to be discussed before closing the book on code freezes as a useful element of Agile product management.
The Problem With Argument 1: Automated Testing Is Not Comprehensive
Automated QA and Agile development practices have increased the quality of code as it’s produced, that’s a fact. But just because a piece of code has passed unit testing, that doesn’t mean it’s actually production-ready. Even the most refined CICD approaches don’t always include critical steps—like regression testing—that ensure a piece of code is defect-free. When it comes down to it there are just some things you can’t test and resolve while a piece of code is in production.
If you choose to utilize code freezes, you aren’t going to give up the benefits of automated QA and Agile best practices. You and your team will simply catch your code’s smaller, more trivial problems during production, clearing the decks to focus on catching larger, higher-impact issues during your freeze, such as the overall stability and reliability of your new software or feature.
The Problem With Argument 2: “Reduce”, Not “Eliminate”
Agile is designed to reduce the time between development and release, that’s also a fact. But there’s a big difference between trying to reduce this window, and trying to completely eliminate it. Doing so would be next-to-impossible, especially for larger projects.
The code freeze may be very short in CICD— or may only apply to a specific branch while development continues on other branches—but it still exists. No matter how refined Agile became, there is almost always going to be a point in all development and release roadmaps where a new piece of software or feature will be evaluated in a fixed state before it goes out to real-world users.
The Problem With Argument 3: Rethinking Speed and Quality
If you utilize code freezes, you will add a new step to your development and release cycle. There’s no doubt about that. And any time you add a new step to any process, you slow down that process and you create a new potential failure point. Code freezes are no exception.
But it’s important to take a step back, and to take a broader view of slowdown and lost productivity.
If your feature has bugs, you will need to fix them, regardless of whether you caught those bugs during a code freeze, or whether they made themselves known after release. From a pure development perspective, the amount of time needed to fix them will be about the same in both scenarios.
But if you’re dealing with bugs in a live environment, you have a host of other issues you need to take the time to deal with, including:
- Deciding whether to roll back the buggy feature or leave it live.
- Taking your developers off their new projects, after they’ve begun work.
- Making it up to your real-world users who were impacted by the bugs.
- Answering to and managing your internal stakeholders who are not too happy about your problematic release.
The list goes on. There’s nothing more complicated, time-consuming, and destructive to productivity—for you and your team—than releasing a broken feature or product. Code freezes minimize the chances of this happening.
And as to the argument that code freezes lead to lower quality features and products because they reduce the amount of business requirements you can collect? Your business requirements will always be little more than a “best guess” as to what your product or feature should function like. The most valuable requirements will always come from real-world users, deploying your product or feature in real-world scenarios. And you can only collect those requirements by giving your users functional releases that they can deploy as fluidly, and bug-free, as possible.
Should You Utilize Code Freezes in Your Agile Product Management?
Ultimately, code freezes still play an important role for many Agile product managers.
Now, there are cases where they play a less critical role. Very small projects may not need dedicated code freeze periods. New features that have relatively minor consequences if they ship imperfectly might not be worth the freeze. The same is true for phased release plans—like Canary Releases—when you just want to test new features with a warm audience who you have primed to expect a buggy, imperfect experience.
But in most cases, it is worth taking the time—even a very short period of time—to make sure your new features are as perfect as you think they are before you put them in the hands of the people who matter most: your real-world users.
This article was initially published on flagship.io
