Devops thought: your project depends on others’ time
The title might state something trivial, but the consequences may be unexpected. Let me frame the issue.
The problem
Working in an organization normally means to collaborate with other people. The idea of the organization is to achieve a common goal, but, counterintuitively, an higher number of people can lead to less output or less output per person.
This because often collaboration means checking/passing the work each other.
And it happens in several occasions:
- review of the work by a peer or a leader;
- waiting for comment by some colleague;
- formal approval by an authority inside the company;
- manual quality assessment by someone else.
This leads to block the work/project for a while, because the receiver is not always available to process it. We can call this time as waiting time.
Consequences
After a while people notice this waiting time, and it creates some recurring pattern to handle the tasks. In my experience I have seen two main consequences/patterns:
- “if I know that I will have to wait, let me send more lines of code”: it is a normal behavior of the human being, we will tend to send more amount of work in approval or review in order to keep an high work/time ratio or high lines per time throughput;
- “I cannot waste time, maybe I can start a new project”: this can also come from management, seeing their employees without work is a waste of money. I agree, but the problem is that normally there is always some unplanned cleaning or enhancement task to do. We should focus more on this technical debt instead of increasing the project workload. In the end the employee will result more busy and will block more their colleagues.
These lead to reduce the customer happiness (shouldn’t we keep in mind the customer?) because:
- Quality of the approvals or reviews, and consequently of the product, will be lower. A reviewer needs a lot of time (time that normally is not present) to review a big work and little mistakes in big changes are hard to spot;
- If we start a new project, it means that we have a commitment with the customer (or its relative business reference), but we already know that project has just a fill-the-spare-time purpose and will not be led in a fast manner. Moreover, this new project will contribute to overload the system and, in the end, have an overall slowness.
Possible solutions
Clearly, there are many solutions for the problem, here some of them.
Automate as much as possible
Removing the human from the loop reduces drastically the waiting time. A good CI/CD pipeline contains a lot of automated tests and few humans, so it can deploy new changes in order of hours (or minutes) and no days. In my experience I have seen also auto approvals, fantastic!
Manage better the time
The key point is that there is some unplanned work to do. As the adjective suggests, it is unplanned so you normally ends up to have your project time that fills all the working time and then you have to find some “spare” time to do this kind of work. To avoid this you should keep yourself idle, or ask your manager to not overload you. My suggestion is to have just a couple of projects. And, as mentioned before, there is always some technical debt to clean in case of idle time. This is important because your colleague can benefit of your “spare” time. They will have a more efficient reviews and they will be less blocked than before. To enforce this “spare” time, you can reserve some recurring slot to do what is not planned. It can seem weird to block some time for what you do not know in advance what exactly is. But, for sure, there will be something to do; trust me.
Track the task status on a Kanban board
The use of a Kanban board helps to understand the amount of workload. In my experience I used it as an evidence to show to my manager why I was not able to accept new tasks. More details on https://en.wikipedia.org/wiki/Kanban_board
Conclusion
In complex organizations is easy to have hidden bottlenecks. I hope this article can help you to spot them and remove this kind of frictions. For me it took a while to understand the problem of waiting time because when I was inside the system I did not care about the overall workflow.
