Priority of a Code Review in Scrum?

Question

Let's say we're talking about a Scrum development team.

A task can be implemented wrong or the implementation may contain unaccetable flaws. If this is discovered near the end of a Sprint the Sprint Goal may not be achieved. So a code review is an important procedure and should be performed as soon as possible from the possible risks' point of view.

On the other hand, if a developer performs a code reviews (of ther developers' tasks) two or more times during a day, then this inflicts a considerable context switching.

In a Scrum team, when should a developer perform a code review of another developer's task?

• after completing their own task (another developer's task becomes blocked, increased risks)

• as soon as possible (may inflict a lot of context switching)

• a policy is required (e.g. a developer performs all code reviews at the end of the day)

I'm inclined to the last option. What is your approach?

Answer 1

I think DevOps defines the best practices here: specifically the principle of small batch sizes.

In other words, if the batch sizes (code commits) are small, then the code reviews can be frequent and short.

I would live with the frequency because that's more of an Agile thing and it's OK! Build a team culture that supports it. DevOps also tells us to optimize for the success of the team, not the success of the individual developer.

Overall, the key is the small batch sizes because the developers can actually understand what they are looking at and contribute in a meaningful way to the code review process.

For further reading, I highly recommend the indispensable DevOps Handbook.

https://www.amazon.com/DevOps-Handbook-World-Class-Reliability-Organizations/dp/1942788002

Here's a link to the relevant section:

https://books.google.ca/books?id=ui8hDgAAQBAJ&pg=PT304&lpg=PT304&dq=devops+handbook+code+review+size&source=bl&ots=WudlbdSBWX&sig=ACfU3U34CUeyyGuxBxkG38RDa3o466SAOg&hl=en&sa=X&ved=2ahUKEwizvLfY6IPnAhXXJzQIHa01DyUQ6AEwBXoECAoQAQ#v=onepage&q=devops%20handbook%20code%20review%20size&f=false

Answer 2

Scrum intentionally does not layout exactly how the team will build the product. There are a number of reasons, but most pertinent to this question is that what works for one team may not work for another. Similarly, what works with the tools of the early 2000's may not apply as well today.

One of the reasons we work in iterations is because it gives us the opportunity to refine our process. I would encourage the team to identify what they think may work best, try it, then review. You could even pick 2 or 3 different approaches, try each for a sprint, then reflect on the results.

There is the logical notion that after all of these years, some best practice must have come out. While it is sensible to think this, the truth is that a development team is a complex environment. People have different preferences about how they work, code may be worked on at varying levels of granularity, and many other factors will come into play. Even today, weekly code reviews will work perfectly for one team and pair or mob programming is the solution for another.

Answer 3

I suspect there is no single answer to this question.

Individuals are different. Some may find that doing a code review is a welcome distraction from their coding tasks. Others may struggle with the context switching or may not enjoy doing reviews.

Teams are also different. I can see the nature of code reviews varying depending on many factors including:

• The nature of the code they are writing
• The typical size of coding tasks
• The extent the team uses automated code quality metrics
• If the team uses pair programming
• The extent to which the team defines coding standards

My recommendation would be to try different approaches and monitor the results.