Agile Advisor

The Threat of the Stabilization Phase

Some dev organizations use a stabilization phase as a way to improve quality. But in most cases, it does more harm than good.

• By Gregg Boer
• 09/25/2013

About five years ago, I had a cancer scare. A routine blood test led to additional tests, which eventually led to a prognosis that I could have a fatal form of cancer. After a spinal tap and waiting the longest week of my life, I found out I did not have cancer. To say I was relieved is a complete understatement.

Cancer, in its simplest definition, is unregulated cell growth that invades nearby parts of the body. In other words, the only reason cancer is there is to feed and sustain itself.

During my career I've been through many development projects that had a stabilization phase at the end. The stabilization phase is a period of time where the team focuses on fixing bugs and addressing other debt. Debt is all work that must be completed before you can ship, but wasn't done as part of the sprints. Bugs are a common form of debt. Other examples could include meeting localization, performance or accessibility requirements. More extreme examples include ensuring your product installs or that users can upgrade from a prior version.

These stabilization phases felt like fighting cancer to me. An unregulated growth of bugs and other debt had invaded parts of the product, the process and the team. The organization went through an intensive stabilization phase to eradicate the bugs. Chemotherapy, often used to eradicate cancer, has undesirable side effects, the worst of which is killing healthy cells. The stabilization phase also has undesirable side effects, such as attacking the team morale, feeding on the quality of the product and dulling learning abilities.

The truth I've discovered over the years is that the stabilization phase isn't the treatment of disease, nor is it the cure. Rather, the stabilization phase is the disease. It's the awful organism feeding on your organization. In this article, I'll reveal the stabilization phase for what it really is: the very thing that must be eradicated.

The Stabilization Phase Wants to Live
The stabilization phase is the ultimate self-fulfilling prophesy. If you dedicate a certain amount of time at the end of your development cycle to address debt, debt will grow to fill it.

This became clear to me three years ago. Our organization was just switching to Agile methodology, and was practicing three-week sprints with the goal of being "done, done" at the end of every sprint. However, after six sprints, we planned a three-sprint stabilization phase, just in case. During this time, there would be no feature work, and the focus would be to ensure the product was ready to ship.

In Sprint 4, one team was trying extremely hard to keep their bugs and other debt low. They fixed bugs before starting new features. They ensured all new features met all the accessibility, security, localization and performance requirements at the end of every sprint. However, other teams weren't doing this and, consequently, this team's productivity looked lower.

Someone from management was sent to investigate.

After a long discussion about the virtues of not carrying debt, the management person said: "Look, we only have two more sprints to add features and then that door is closed. Therefore, fixing bugs now would be irresponsible, because you have two months to fix bugs during stabilization. Now is the time to add features. Later is the time to fix bugs."

This person wasn't stupid. This person had a long history of shipping high-quality software. And if you think about it, the logic is irrefutable. The person wasn't the problem -- the stabilization phase was. The very fact that the stabilization phase existed changed the way the development organization worked, so that the stabilization phase became a necessity.

Just like cancer, the stabilization phase wants to exist.

The Stabilization Phase Masquerades as Good, but Isn't
On its face, the stabilization phase appears to be a commitment to quality. It provides adequate time to ensure the quality of the product is high. This is an honorable, risk-mitigating goal.

However, as I've stated, the existence of the stabilization phase encourages teams to save bugs for that phase. And the longer you take to fix bugs, the more they cost to fix. I've been through many, many bug-triage meetings where we closed bugs without fixing them, because we just didn't have enough time to fix them before the end of stabilization. Many of these bugs would've been simple to fix had they been addressed earlier.

The stabilization phase also provides an illusion of productivity during the "development phase." It feels so great to be implementing new features, one after the other, without regard for the debt piling up. Of course, the features aren't actually complete, so the achievement isn't real; no more real than financing a car you can't afford and celebrating that it's yours.

To Kill the Stabilization Phase, It Must Be Starved
If your organization depends on a stabilization phase, just removing it makes no more sense than aggressively yanking out a large tumor. Doing so can cause more damage than good.

The organization must reduce its dependency on the stabilization phase slowly, by starving it of the things for which it lives. In my previous example, our organization went Agile but kept the stabilization phase. That stabilization phase had a "no new features" restriction, which led to bad behavior.

Our organization went on to six more sprints, followed by another stabilization phase. However, this time, any team that could prove they had addressed all the debt could then add new features during that time.

That made a huge difference. Teams who wanted to rely on the stabilization phase still could, but teams who committed to completing features and addressing debt early were rewarded with the ability to add new functionality. Some teams started "no more stabilization" initiatives with the goal of making the stabilization phase no different than other sprints.

The stabilization phase slowly became less and less necessary, but it never really died. It did shrink, however, reducing its affect on the healthy dev organization around it.

Keeping the Stabilization Phase Subdued Requires Work
At the beginning of this article, I talked about how relieved I was to find out I didn't have cancer. However, every three months I go in for some for blood tests and every year I get a full body scan. I'll do this for the rest of my life. My doctor is being very vigilant for any sign of cancer.

Eliminating or reducing your dependency on the stabilization phase is what I would consider the "get healthy" program for a dev organization. After that, the "stay healthy" program begins. As with your body, staying healthy requires discipline and hard work. Our organization found that old habits die hard, and it was easy to slip back into unhealthy behavior.

Investigating the work being done in the stabilization phase is like doing blood tests and body scans on the dev organization. It provides insight into indicators of something unhealthy. Like my doctor, the dev organization must be extremely vigilant. Any work done during the stabilization phase is a symptom of something potentially unhealthy, and should be diligently followed up on.

We found that teams who were "stabilization free" would sometimes go back to depending on it. Investigating why this happens helps an organization stay healthy.

Stepping Back
I'd be hard-pressed to say that any use of a stabilization phase is unhealthy. That feels a little too dogmatic. However, I strongly believe organizations that methodically reduce their dependency on a stabilization phase become healthier and more productive as a result.

Maybe we can't be cancer free, but we can reduce it to be no more threatening than a benign tumor.