Continuous improvement has become a standard practice in many companies with the rise of agile software engineering practices. Atlassian defines continuous improvement as follows:

Continuous improvement is the ongoing process of analyzing performance, identifying opportunities, and making incremental changes to processes, products, and personnel.

As Scrum is by far the most popular agile software framework, many companies rely on Scrum retrospectives to achieve continuous improvement. According to the Scrum guide, its purpose is as follows:

The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.

It’s interesting that the retrospective’s purpose isn’t to increase quality and effectiveness but just to plan to do so. Planning things is easy, but executing these plans can be much more difficult. I think that Scrum in particular and continuous improvement in general share a central flaw: they both assume that only a lack of knowledge is holding a company back from improving. The retrospective is supposed to reveal to the team what to improve on, and then they will just do things better in the future because they have realized the errors of their ways. This is an overly simplistic way of thinking, which rarely works in reality. Sure, sometimes people just realize that they can do things in a better way, and they simply switch to this new working style. More frequently, disfunctional working styles are kept even though their ineffectiveness is known to the team. Often, systemic reasons are the key motivators behind these behaviors, and if these don’t change, then the behavior will not change either. This is a big obstacle when trying to improve on a team level. In some cases, improvement will even be impossible.

The most obvious systemic reason that prevents the team from solving the problem is that the team is not empowered. For example, if the team gets slowed down by bureaucracy, then it is unlikely that they will be able to change that as they are not in control. As a result, continuous improvement can’t fix any problems with root causes outside of the team. In fake agile companies, continuous improvement is almost impossible to realize, a fact that rarely gets discussed. However, some agile coaches acknowledge the problem when discussing retrospectives and even admit that retrospectives are harmful in this scenario. For that reason, it is helpful to focus any attempts at continuous improvement on things inside the team’s sphere of influence.

However, even when we stick to issues within the team’s sphere of influence, we can still have problems that are difficult to fix. For example, the team might realize that it needs to improve code quality in the future to reduce the number of introduced defects but still fail to make this improvement. This could be caused by a lack of time, a lack of knowledge, or the team composition itself. To solve any problem, we need to understand the underlying systemic influences that cause it. These need to be fixed to address the problem. Otherwise, it’s very likely that we will fail.

Here’s another example to make this more clear: Let’s assume that the team wants to move to a different working model. Rather than having one person work on a topic, two should work on the same topic to achieve better knowledge sharing within the team. However, despite having this goal for a long time now, the team just cannot achieve it. Why is this the case? Three reasons come to mind:

  1. The amount of work is just too high. This makes it impossible to “waste” resources by assigning two developers.
  2. There is so much specialization in the team that only certain developers can productively work on certain parts of the codebase.
  3. Not everyone on the team is convinced that pairing is a good idea. Hence, some developers (subconciously) sabotage the change.

The first reason is systemic and probably the cause of the second one. So, we have to modify the environment of the development team to address the first two reasons. Convincing everybody on the team that pairing is a good idea doesn’t require an environment change but can still be very difficult. We have to understand the reasons behind the skepticism of some team members. Maybe there are some lingering conflicts in the team that drive this behavior.

There is another potential pitfall when attempting continuous improvement: mistaking a people problem for a process problem. Sometimes, people are just bad at their jobs, and this cannot be fixed by changing processes. I’ve already written a dedicated post on this issue, so I won’t go into more details here.

But what about issues outside of the team? Maybe during our attempts at continuous improvement, we notice that something could improve in another part of the organization. In that situation, we have to consider the systemic reasons again. Giving a suggestion on how to improve to another team only makes sense if we suspect that a lack of knowledge or awareness is the root cause. If the undesirable behavior is caused by a systemic reason or by a people problem, then it’s very unlikely that our feedback will lead to an improvement. Instead, I’d caution against reporting the issue in this case, as this might lead to resentment and a lot of wasted time.

The key point of this blog post is that improving can be very hard. Whenever we need to address systemic reasons or solve people problems, we’re unlikely to achieve our goal. So, if we fail to improve in certain areas even though we’ve been dissatisfied for years, we’re likely dealing with a systemic problem. In this case, the best thing we can do is to stop trying. Wasting more time and energy on such a problem will not help. We should focus on the things we can improve. The best thing we can do to improve the performance of our team is to add more stars to it, as developer growth is rare. Everything will go much smoother with better people on the team.

Conclusion

Continuous improvement rarely works because many problems are caused by underlying systemic reasons. These problems will only disappear when the systemic reasons are solved. Given that they are systemic, this is difficult and unlikely. As a result, it can be a good idea to exclude certain topics from the continuous improvement process to prevent wasting time and energy on a hopeless cause.

If you liked this blog post, please share it with somebody. You can also follow me on Twitter/X.