How to Speed Up Code Review Process with Code Review Time

This is a chapter from an upcoming book Team Lead 101: Manage and Grow Engineering Teams in Small Startups. Check it out here https://gumroad.com/l/team-lead-101 (clickable link in comments) =========== Good decisions are those that remove the need to make repetitive ones – James Clear, Atomic Habits 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.