Introducing Code Review meetings as a new Sprint ceremony

Reviewing pull requests is very important in order to ensure that consistent practice is followed all throughout the code, thus all stakeholders promote pull request review as an important task

Considering a team of 6–7 developers will create 3–10 pull requests in a week it is important that we devote special time to the process. Creating proper pull requests with descriptions and reviewing them properly does take a considerable amount of time and generally, only the team lead or some senior members will review pull requests, other simply ignore them as not part of their duty.

Few reasons why new members or those who consider themselves junior avoid pull request reviews

1. They are not aware of the complete requirement thus it makes reviewing pull requests a difficult task because just by looking at the code it is difficult to gauge everything that was written and why it was written
2. Developers are not actively assigned pull request review tasks, they are just asked to review them, so finding free time to review becomes a less priority
3. Somehow there is a fear in the mind that if I say that I reviewed pull requests yesterday in DSM, others will feel that I didn’t do something productive

Not reviewing pull requests on time introduces delay in process and further delays Testers. Sometimes a pull request is merged at the time when it becomes absolutely necessary to do so, and on the goodwill that it would work well.

This way all the other developers also lose a wonderful chance to understand the coding style of fellow developers and hold a fruitful discussion.

The current practice of pull request review involves a senior member commenting or requesting the change, followed by the author updating the pull request or asking for further clarification, this async email communication while being valuable is slow and boring, we can take a small step in direction of improving the experience by devoting 30 minutes every day where all the developers come together and review the code, give and discuss suggestions together.

It is based on the agile principle that suggests reducing documentation and hold more direct meetings.

In another scenario where a user has done changes in around 50–100 files, the author can easily explain the linking between those changes thus all the other developers will learn about it and there will be no dependency on the author, in case of a bug is raised on the concerned feature.

based on following agile principles

#4 “Businesspeople and developers must work together daily throughout the project.”

#6 “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”

#8 “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.”

#9 “Continuous attention to technical excellence and good design enhances agility.”

#10 “Simplicity — the art of maximizing the amount of work not done — is essential.”