How to Speed Up Code Review Process With Code Review Time

This is a chapter from Team Lead 101: Manage and Grow Engineering Teams in Small Startups ebook. Get your copy here.

Goals are good for setting a direction, but systems are best for making progress.

– James Clear, Atomic Habits

Good decisions are those that remove the need to make repetitive ones.

In one remote team that I led, there were repetitive problems that were obvious from looking at the agile board. Tasks spent the most time in the “In Review” column. They piled up in a heap in this column while waiting for initial review or or re-review. In our retrospectives, we discussed the reasons behind this problem week after week, but the problem hit the team on an almost constant basis.

My decision was to try holding a specific code review time every day at the same time. We started with 30 minutes just before the daily meeting and then extended it to 45 minutes, which was a good length for the team of 4 developers.

Here’s what the code review time solved for us:

• Developers knew that we needed to review code daily and that we couldn’t skip it for the day and catch up later.
• Having a specific time for reviews allowed everyone to be prepared for the code review meeting and plan their day accordingly.
• We were all in the same meeting room and could discuss all the issues much faster than in async mode when you wait hours for a review, then respond, then wait hours again for an answer.

As a result, we no longer faced the problem when tasks were implemented but not finished during the week. And the "In Review" column never piled up again.

Make a requirement for everyone to be at the code review meeting. If it’s optional, then you lose all the benefits of the practice.

This is a chapter from Team Lead 101: Manage and Grow Engineering Teams in Small Startups ebook. Get your copy here.