Stabilization and quality don’t go together

Recently my friend told me nice rule.

If you have stabilization period during your development and in the same time you are developing new features, than you cannot say anything about quality of your product.

At the beginning I didn’t agree. I thought that it is possible to work on new features and on old defects in the same time. But later I started to think about it. Now I’m sure that he was right, but my first understanding was wrong. I think this problem is more complicated that.

Let’s look at example of company Agile.


  1. They do Continuous Integration.
  2. They have automatic tests, but it is impossible to cover 100% of scenarios.
  3. They work with SVN and codebase is huge.
  4. Team is quite big.

Assume that they release working version of their product every 4 months and they spend one month in each release on bug fixing (in the same time they are starting development of next release).

What’s wrong with this approach?

Working on one code base with different goals – my first thought.

It can lead to big conflicts, when one team is working on defects and in the same time developing new features. Those who are responsible for current release don’t what to introduce any risky changes, refactor or reduce technical debt. Their main goal is to make product “stable” so it can be shipped. On the other hand, those who are developing new features are not afraid of making bigger changes, even architectural.

Moreover, looking from outside you are not able to say if some bug fixes don’t influence newly developed features and those features don’t introduce new defects. Some can say – let’s create branch for each release and then merge changes. That can work, but as always, we are only humans. Somebody can forget to merge his changes to some branch and whole team will lose time on investigating the same issues once again.

Stabilization – second thought

After some time I discovered that whole idea about having stabilization period is wrong. If you have big backlog of defects and you have to spend time to reduce it, than you are doing it WRONG. You should stop, rethink your approach, review process and decide where you want to go. If you want to be agile you have to provide shippable version of your product after each iteration. If you are not able to do so, stop where you are, clear your backlog, pay the debt. I know that sometimes it is hard – there is marketing, there are some contracts, etc. But without taking this step it will get only worse and worse.

Continuous Integration

As Uncle Bob said during one of his speeches: “If it is green, I ship it”. I think that this the most important change you should make in your process. You should be confident and trust your CI it the way that you can immediately ship your product when it passes all tests. Those tests should be fully automatic. Of course you don’t have to run all tests in one build. Your process can have some stages with for example only unit tests, than integration tests, than automated regression tests, etc. It is important to setup process and have full agreement among all team members and stakeholders.

There is one issue with this approach. Building that kind of solution and writing software with 100% coverage has to be top priority for whole team. If it is not, situation will not get better.

Moreover not having correct process makes feedback loop much longer. Without big test coverage you are not able to say when you break something until your user calls you at the middle of night.


In my opinion the ultimate goal is not to have stabilization period at all. There are multiple ways to achieve that, but the best is to stop what you are doing and redefine your whole process, approach and what’s most important – goals. This requires having strong team with strong leaders. I will talk about this in my next posts.