During the lifetime of IT project requirements are constantly added. We can think of requirements as dots and connections (for IT people: dots represent the classes or microservices and connections represent the interactions/dependencies):

At the beginning of the project there are a few requirements (above), complexity is low. After a few sprints the number of requirements increases and so does the complexity:

After a a few months of development the complexity of the solution can be quite high:

After a year or two of development, the complexity can be so high that no one in the project really knows what’s going on. I was in such project. Small changes caused many bugs, even major processes stopped working. Business has complained that features are being delivered slowly, and developers have complained that they spend a huge amount of time implementing even small features.

How can we avoid situations where everyone in the project was constantly solving problems and complaining that the complexity is so enormous? What can we do to make the project enjoyable?

Continuous improvement/refactoring

I think it’s pretty obvious that productivity depends on complexity. The more complex the environment and solution, the lower the productivity.

We already know that the new requirements increase the complexity of the solution:

Depend on the project size and developers skills, sooner (big projects) or later (smaller projects) project will achieve high complexity, unless, we devote time to make improvements/refactoring of the solution:

Improvements/refactoring reduce complexity thus improving productivity.

We can devote time for improvements/refactoring every sprint, or devote more time every few sprints – it depends on project.

The business wants its functions to be delivered quickly and with high quality (without bugs). Developers/testers want job satisfaction – simple, understandable code, quick implementation and easy testing. All this can be achieved through continuous improvement/refactoring.