Critical Chain

Let's imagine that you have a development chain in progress. An analogy for it could be a conveyor belt where work is being done and created. In this conveyor belt, each programmer works at a different speed - in conveyor terms, we would say they can process a different number of items. So, all of us, humans (even machines differ in performance), will always have a bottleneck in this conveyor belt. It could be a developer or a group of developers (in real life, most often it's a single developer) whose progress blocks the entire chain.

In project development, it's not even a whole programmer but a piece of their work. What are we talking about? Let's suppose we have an excellent programmer on our project. They handle solving complex tasks and code reviews. Since no task can enter the codebase without our great guru's review, they occasionally block tasks because the code reviews pile up while they are busy solving their tasks.

How can we solve this? Ideally, we would relieve this guru from solving large complex tasks and make them focus solely on code reviews. But in our world, no one will allow that. In practice, it is sufficient to communicate with the programmer and emphasize the importance of code reviews because they block the rest of the team. Roughly speaking, the workday should start with code reviews for all tasks or have two code review sessions per day.

And the bottleneck doesn't have to be code reviews. It could be the quality control department, for example. During development, it is worth making programmers write test cases for the tasks so that they can be tested. Often, a task is ready, but how to test it is unclear, and this clarification takes time.

What to do with the bottleneck?

Identify and nurture your bottleneck! Don't overload it with too many tasks. Always ask yourself how you can alleviate its burden.

Why?

Firstly, this way the entire process will be more efficient from a mathematical standpoint.

Secondly, the bottleneck usually feels the weight of this responsibility and tends to burn out, putting the whole project at risk. Unfortunately, this is a harsh reality.

Conclusion

A great sign that your processes are improving is when you notice that different processes of the bottleneck are being shared among other project participants. This indicates that the project is moving toward recovery.