The concept of “relay” as an alternative to the sprint

This article is motivated by desire squeeze the developer enable developers to reach their full potential and draws heavily on the book “Team Topologies” (Matthew Skelton and Manuel Pais).

I will not quote books, and its content will not necessarily be covered with my understanding of the material read, especially since I have not read it yet.

My task in this article will be to present my vision of the existing development processes and cycles, their shortcomings, as well as an alternative approach to them. so, let’s begin

Sprint

We have a backlog with tasks. Tasks have some weight – points or time. We limit the maximum weight of tasks per person, indicate the execution time – usually two weeks and get a sprint, and with it an individual implementation of tasks, a lack of understanding of what to do with code review and who and when to do it, low quality documentation and tests.
This is not so, you say – the process can be adjusted so that everyone knows when and what to do, and documentation and test standards can be hammered somewhere in the documents and not give approve until the task meets these standards.
If that’s what you mean to say, then you’d be right. Or maybe you won’t. I don’t know.
There are no statistics, and if there are, who knows what they really display. There seem to be generally accepted practices, but each individual project seems to implement them in its own way. Various FAANGs are falling, and firms with twenty people are being sold for billions of dollars.

I have changed several companies. Somewhere there were sprints, somewhere not. Someone did standup every day, someone once a week.

In general, if you draw the x axis – motivation of team members and y – following project management paradigms, then I, probably, at different moments, was in each of the quarters of this plane and I don’t remember the difference. Regardless of firms, we have never moved mountains. The documentation could always be the best (or just could be), and the tests covered something. The assignments were done. The business was happy.

You might think why am I talking about tests and documentation since this article is about sprints. And what about the motivation of the team? I’m already explaining.
I don’t want to discuss how to make good documentation or what good test coverage means. In this article, we will accept that there is only one approach to writing tests or documentation, and our team follows this approach, while the team itself is as motivated as possible. We will also accept that despite the unique approach to tests, documentation, etc. we do it inefficiently. The problem is not what we do, but how we do it. The problem is the sprints themselves.

Sprint Disadvantages

The book I recalled earlier is not here by chance. One of its best elements is the attention to Conway’s Law, namely the observation that the structure of any system follows the structure of communication between its authors.

For example. If you want to make microservices, it is not necessary to specifically divide the project in order to distribute separate pieces to developers. Divide the most developers into groups and limit communication between groups. In a natural way, in conditions of limited communication, groups will be forced to make their part of the project so that other parts of the project can interact with it without knowing how the system is implemented inside. That is, the API will appear.

This observation plays a crucial role in the optimality of sprints. If communication so strongly influences the structure of the system, what kind of system will be obtained if each of its elements is done in isolation from the other? And that’s how sprint tasks work.
Everyone does their own tasks, the other person intervenes only when it is necessary to do a review. The review itself is done by one or two other developers, not by the whole team. Knowing life, such reviews are made reluctantly, on the last day of the sprint, even if the tasks were closed 3 days ago. And then you still need to make adjustments. So the tasks go to the next sprint.
There are at least 2-3 other things that happen as a result of such a process. I think you have come across them, so I will not develop this topic.

Another drawback is the central role of the deadline, that is, time. Here you can pull up the pyramid: time – quality – price, but we will not. I honestly doubt that the quality of the code itself will change if the emphasis is shifted from deadlines.
Here the matter is different. There is no better motivation than internal – inherent in the task itself. That is, you can certainly say: you have 2 weeks, do the task or die. Or you can give a task to a person who will pick up the task himself with pleasure and interest and perhaps even cope faster than in 2 weeks. This is how backlogs work (unless, of course, you are allowed to choose a task from there yourself)

Another disadvantage is the atrophy of relationships between developers. This arises naturally in connection with the individual distribution of tasks. You and Vasya do not have common goals. He gets hit in the neck for his tasks, you for yours. If your task hangs for a month without review, then this is “their” problem, but since you cannot collectively punish, and each team member was busy with his tasks, then the problem is nobody’s. You can spread your arms, and in a year go to another company where you will again sharpen tasks yourself remotely without any “friends at work”.

Relay race

While reading the book and reflecting on my experience, I thought about how to create another process that would serve as an alternative to the sprint and, if possible, correct some of its shortcomings. I decided to call this process a relay race, since this is also a sport, also connected with running, but at the same time a team one. The name may not be the best, as it implies some sequence in the performance of tasks, but this is not important. What is a relay race and how should it work.

The main feature is the lack of a deadline. It’s there, of course, but you can’t see it.
The implementation is extremely simple – developers take tasks from the backlog as before. They work on assignments the same way. No two people turn gray on one task, which means we will not force them. Differences begin when a person has finished his assignments and submitted them for review. Since it is not supposed to do a review for oneself, a person will be out of work, which means that he needs to be provided with a job. There are two options: he can pick up a colleague’s unstarted task or start reviewing completed tasks. When everyone is finished and all reviews are done, and tests and documentation are written, then the relay race ends. The next relay race will start either on Monday or Wednesday (whichever is closer), and the developers still have a well-deserved day off.

Here you will notice that the most productive worker will punish will be rewarded with additional work. But in sprints, you also get tasks, right? Moreover, look from the other side: every relay race someone will be the last, this is a person who will constantly need to be helped. If all the time it will be the same person, how many relay races will it take to understand that this person is not suitable for this team? How many sprints would it take?
Notice also that now, not only a common goal naturally appeared – to finish the relay, but also a common reward. Each of these elements will bring the team closer together. Not to mention the general reading of the new documentation and general review.

conclusions

The relay should transform the team. Even if the team does not become more productive, it must unite, which means that the system being developed must become more coherent. Common goals, as well as common rewards, will contribute to this. Weak elements of the team will be detected faster, which means they will stop pulling the whole team down, and someone more suitable can come in their place. Documentation, tests and code review will improve as now almost the whole team will read them, and writing them will not be a nobody’s task, as they will be part of the whole process – by design.