Recently I was giving a talk at a local engineering group about the software practices we do at our team and it did surprise me how many people came back saying they did like a lot this very little thing we do to accelerate the whole pull request / code review protocol.

In reality, the idea is super simple:

Every day at 3PM is Code Review time.

But, wait, how does that exactly work?

For us, it essentially means that at 3PM we have scheduled a fixed 1h slot in everyone's calendar. This forces everyone to stop what they are doing and to dedicate that time to peers that are waiting for valuable code review feedback. Having the time officially allocated helps people not only to remember but also to realize that code reviews are very important for a healthy delivery pipeline.

Before this practice, we had a few problems with code reviews:

People forgot about code reviews. Initially, we tried to insist on pushing peers to spend some time in the code reviews. To insist. It worked at first but soon both ends would forget. The reviewee would jump into some other story and forget about telling reviewers to get into action. On the other hand, the reviewers would instinctively wait to be pushed interpreting that otherwise, the pull request was not that urgent to be reviewed.
We do gate PRs by having two approved code reviews. Sometimes people that were too deep into their own user stories would play sneaky and wait for the other reviewer to do an initial review hoping that they can jump into reviewing much later once the initial details have been sorted. Of course, sometimes both reviewers would also try to play that game. You know how it ends.
As a consequence of the above points, most of the user stories were closed later in the sprint. Burndown charts had very usually the shape of a big step. But more importantly, as the sprint end approached, people would rush into trying to get their stories reviewed while at the same time they were being pushed to review other stories and rushing to fix review comments. This usually ended with code with lesser quality than expected to get into master.
As an engineering lead, I try to keep an eye on reviews. I always look at the critical ones and give feedback but I do defer approvals to the team. Very often I was being asked to review without anyone having looked at the stories yet. Usually, the reviewer would do this as an attempt to move things that got naturally stuck by the way we were working.

Now with the new policy in place, I believe we got people into some much better habits. These are some comments on how the team is executing the policy and some personal observations:

The 3PM review policy does not prevent people from doing their code reviews at any other time. People can do code reviews earlier, or even later. But at least from 3PM to 4PM they need to stop and do that work.
Code review time, which is one hour for us, can be used to review either alone or in a group. Now, very often the reviewee and reviewers will join in a pair reviewing session to discuss the changes. This enforces some good dynamics as before there was no fixed time for meeting and people did rarely pair.
If someone does not have anything to review that day then the time can be used on any other tasks.
Since we have established this policy we have managed to keep a much shorter queue of open PRs. Burndown charts still have steps. I will not lie. But these steps are not as steep as they used to be, especially at the end of the sprint.
The hour is totally arbitrary. We did choose 3PM because we thought at that time people would have spent already a good amount of work on the daily tasks and would be a good moment to do a context switch.
Finally, now I do have to review much fewer PRs. I can keep an eye on the critical ones without being asked to review for expediting things.

I don't think this technique is original. In fairness, I got the idea from somewhere that I swear I can't remember, we just formalized into a rule. The 3PM code review rule.

What about you? What techniques do you apply to try to expedite code reviews? Would love to learn from others.

Photo by: Sarah Pflug