#5 Don't Play Alone: Ride A Carousel With Others
When setting up a development team, it is important to enable clear channels for communication. One of these is to organize opt-out morning meeting just for technical people - a dev carousel.
During the development team life cycle, we encounter many problems regarding 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?
It takes a very long time to process 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, there was another round of code review. 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, which one of the team members accepted. It was merged. Three weeks after the event, another team member accidentally notices my code and asks a pretty good question affecting the solution's effectiveness. My first thought - 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. Repeating such situations causes us to go around 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, where 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 turned out there was a build timeout that stopped the entire team from merging over the next few days. Now, we are on fire and must react instead of act.
Domain and technical knowledge are 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 is Sarah the only one who touched this area? In this way we unknowingly build silos. Later, it will be very difficult to replace such people.
Besides swarming, pair, and mob programming, there is still a place for 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 daily, 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 should attend? Only technical people should attend. There is no leader in such a 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 uninterested in the topic.
How do I 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 going to another problem, we must 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 must present the arguments again - both on 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 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. If it is critical or a blocker, decide what steps to follow—extend it or meet with a smaller audience (you can still discuss it in the bigger round the 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. Most importantly, you can optimize it in every way possible—as you wish. Try not to make this a requirement 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 voices are saying why such a thing, drop it!