I would like to echo the recommendations in the answer provided by mmathis. A pull request is a blocker, and a task is not complete until the pull request is approved. I will expand a little on some team process adjustments that might help as well.
Developers get busy. Code reviews involve switching contexts, and it takes time for people's minds to switch from their task, to reviewing code, and then back to their task. To reduce the impact of context switching, you can make some recommendations about when to review pull requests.
Take advantage of natural breaks in your day:
- When your workday first starts
- After any scheduled meeting
- Right after lunch or after a break
- At the end of the workday
Still, this only provides a handful of times when pull requests get reviewed. It could take 2-4 hours before a pull request gets the appropriate number of approvals. When a task only took 2-4 hours to get into code review, this introduces a lot of lag time just waiting for people to review code. Part of the solution involves setting expectations for how long pull requests should take.
My team ran into this problem a few months back. One third to one half of the time it took to complete a task was spent in code review. We had to update our team rules about how long pull requests should be open before getting feedback:
- All pull requests should have at least 1 approval or 1 rejection within 20 minutes of submitting the pull request.
- The pull request should be fully approved or rejected within 40 minutes.
- If you submit a pull request, and have not gotten feedback within 20 minutes, post a message to the entire team reminding them you are blocked.
These guidelines worked well for us, because code reviews are typically quite small. You may choose whatever criteria suites your team. This likely involves meeting with them to address the problem, and have the team come up with a solution.