What is the real root cause of your problem?

The beginning 

There is a project. Code is written, everything is tested, coverage is high, and features get delivered. There are bugs from time to time, but incidents get fixed fast, and no one worries about the situation. Well, business as usual. 

Time passes...

From time to time, there are situations where people get nervous due to critical issues after the release. All hands on board, and after several stressful hours things get fixed. 

Time passes...

The number of incidents gets bigger. Teams spend more time fixing them. And people start to wonder how to get back to comfortable times from the past...

Let's make the world a better place!

There is a decision to run a post-mortem to find a way to make everyone's life easier. Everyone wants to solve the problem, every developer, tester, manager, analyst, etc. What do you need more? 

The meeting is fruitful, and there are a lot of ideas:

• add more tests;
• analyze requirements more carefully;
• invest more time in knowledge sharing.

Yet another productive meeting with a great outcome!

What just happened?

It is worth noticing decision teams made added more work. They need to write more tests, spend more time on analysis and run additional knowledge-sharing sessions. Like it or not, they just decided to increase their lead time. 

Of course, it does not have to mean they made a wrong decision. Sometimes it is worth doing so for a short period, as an investment. The question is: are we talking about this scenario now? 

Did they make a good decision?

Things are tricky because on the surface everything makes sense: more tests, better analysis, knowledge-sharing sessions - it does not sound like anything harmful. 

Yet, what is the missing part of this equation? 

When things get worse, the first step should not be to look for improvements but for the root cause of a problem. You should first look at things that changed. In our imaginary scenario:

• the code coverage is still the same as it was when everything was fine;
• developers were and are writing tests;
• analysts are sharing requirements using the same practices they are using for years.

If this is true, why do we think we need to improve the good practices we are using for years? If the same exemplary techniques with the same quality are used why do we think there's a problem in those areas?

Is the "root cause" you found the real ROOT CAUSE?

When you face a problem that was not present in past, you should first look for the things that changed. I'm not saying this is always the cause of the problem, but this is where you should start.

What did NOT change? The code is written in the same manner, the coverage and metrics are on the same level, the quality of devs, testers, and analysts is still the same, and the same techniques and practices are used to deliver new functionality.

What changed? The complexity of the project is different. Each feature, each new definition, and supported scenario is new knowledge. This is great, but this gets bigger over time. And this is where you should look for improvements. 

Instead of adding more tests, spending more time on analysis, spending more time on meetings, and adding more checks and validations, you should think about how to tackle the greater complexity of your project. Is that easy? Of course, not. But having that and fast delivery in mind you can finally look for the improvements your project needs.