During the development team life cycle, we encounter many problems related to the lack of timely communication. This can lead to regular high costs associated with changes that come too late, or with the progressive demotivation of each team member.

Examples?

A very long time of processing pull requests. Suppose person A is working on a particular feature. After a week of working alone (IMO not a good habit) he creates a PR. Another team member starts the review. Unfortunately, the prepared solution is suboptimal at best. Everything goes to waste. It is time for the author to rewrite his code. Then another round of code review, and another. It takes ages to merge the prepared code. PRs become a bottleneck and slow down development. In such a situation, no one even thinks about what would happen if the lifetime of the branches were shortened.

Not enough people are involved in the idea validation process. I came across a problem. I prepared a solution for it, and it was accepted by one of the team members. It was merged. Three weeks after the event, another team member accidentally notices my code and asks a pretty good question affecting the effectiveness of the solution. My first thought - oh no, I didn't think of that at all. I spent a week on the first version of the code, and now I have to add an extra one to rewrite it. The repetition of such situations causes us to go round in circles instead of moving forward.

Fixes to potential problems come out much later than noticed. Someone on the team noticed that the execution time for tests on each PR is very long, resulting in their general dislike of the short-living branches approach. First thought - in 1.5 weeks we have a retrospective, there I will bring up this topic. But it turns out that more important topics came up along the way and it was not discussed. Two months later, after newer and newer tests were added, it turns out there is a build timeout and it stops the entire team from merging over the next few days. Now we are on fire and we have to react instead of act.

Domain and technical knowledge is dispersed among different people. Oh, I can do that but you know - Jimmy knows this area better, so it would be a nice idea to give it to him. Or Sarah is the only one who touched this area. In this way we unknowingly build silos. Later it is very difficult to replace such people.

Besides swarming, pair and mob programming and other things that I described in this article, there is still a place for something called a Dev Carousel. This is a regular, as flexible as possible, daily meeting attended only by technical people where we talk about technical issues related to architecture, structure, problems, patterns, strategies, implementation, and many, many more. Like coffee and cars :)

Okay, but what does it look like in practice? I will try to describe it chronologically.

When? It has to be done on a daily basis, preferably in the morning, before any other meetings (7 or 8 am). Everyone is fresh and it is easier to focus.

How long? Usually lasts from half an hour to an hour.

Who? Only technical people should attend it. There is no leader in such meeting, everyone has an equal voice. Participation is not required, you can join whenever you want - if you are needed, you can always be called by others. You can also leave at any time - especially if you are not interested in the topic.

How to start it? Anyone who participates in the meeting can start the discussion, e.g. by saying "Guys, I have a problem in... and would like to consult it" or "Are there any problems that occurred during last day?" or "I found... that we need to solve as soon as possible" or "Did you see yesterday's game?".

However, if it is a problem to start discussions inside your team, in the beginning, you can always select one guy to act as a "meeting lead" - next time, another person will be chosen. If there are no problems (somewhat rare), you can leave the meeting or drink coffee and talk with others about life :)

What topics can be discussed? Anything you can think of:

You work on a feature and decided to use Abstract Factory but you are not sure and would like to discuss it with others

You are not sure if the direction of your feature implementation goes in the correct direction and prefer to validate it before you continue

You spent half a day on a problem and still cannot find an optimal solution

There is a security leak that you spotted yesterday and now you can think together on a plan and solution

You read an article about test strategy in big tech companies and want to share it with others. Based on the discussion and opinions you can plan action about the integration of it inside your environment

There are 2 different approaches in application code for the same thing and you want to vote with others to follow one of them

Discussions, discussions, but what next? It is very important to plan an action immediately when the topic is raised. Let's assume that someone started with problem X. Before we go to another problem, we have to find a way to solve the first one. So, everyone in the team of 8 people can share his opinion. Each member can propose a potential solution. In the end, e.g. 3 are collected. Now you do the voting for each solution:

It is clear that solution C lost, so you drop it (haha, you never know if it won't come back). Now, you need to repeat the voting. If the winner is clear, the next step is also clear - you plan when to solve the problem with the selected solution. However, it may happen that both options have the same number of votes:

In this case, you need to present the arguments again - both one side and the other. In the vast majority of cases, one of the options will prevail. If not, you can decide as a team what to do - maybe you have one team member that you trust the most, maybe you say let's give a spike to option A and when there are issues, try option B or you bring in someone from the other team to vote? There are many options and no limitations!

There is one, very important thing related to the above voting. If you do not participate in the meeting, you accept the vote of others. In most cases, the selected solution will be good enough and you should not have anything to complain about. However, if you see that there is a leak or something critical, bring it as soon as possible to another carousel meeting.

How to end it? When you see that there are no more technical topics you can just decide to end the meeting (or stay for a chit-chat). If you run out of time, you can agree to discuss the problem during the next meeting or if it is critical one or a blocker, decide what steps to follow - extend it or meet in a smaller audience (you can still discuss it in the bigger round next day).

The dev carousel meeting addresses a number of different issues that plague teams by shortening the feedback cycle. Thanks to it:

We optimize the duration of PRs - catching misunderstandings quickly. Of course, PRs can be replaced completely by pair programming but it is not the topic of this post

Many eyes look at the same problem - if a team of 8 agreed to a solution, then we can feel safer than with 2 people

Problems that seem trivial but are actually serious are caught immediately

Potential improvements are not forgotten and agreed on time

Knowledge about concrete areas in the application is spread

Regardless of the methodology in which the project is conducted, there is always a place for such a meeting

It also helps to integrate the team which works remotely, for example when we want to talk about coffee, basketball, or what we did over the weekend

Please keep in mind that this is not a silver bullet. This is an idea for streamlining certain processes in your team. And most importantly, you can optimize it in every way possible - as you wish. Try not to make this a required thing or a standard - this is supposed to be the kind of meeting you want to be at, not have to.

Give it a try. If you - as a team - find that you don't need it or there are voices saying why such a thing, just drop it!

FREE Case Study: How was it possible to run such meetings effectively for more than 10 people? Book an appointment with me to know more!