Push Reviews

This post is part of 101 ideas for agile teams.

Context

Only the team member developing a functionality knows the code. Knowledge of code is badly distributed inside team.

Code quality is varying throughout source code.

Action

Whenever a developer wants to push (git: push, svn: commit, TFS: check-in) something (code, tests, documents) to the version control system, she or he asks a peer developer to review the changes first.

What you gain

Increases know-how transfer — at least one additional person has seen the changes and may continue working on this particular topic.

Increases quality — the second developer challenges the decisions made by the first developer, which often leads to better and simpler solutions. Often enough, the original author finds gaps for himself when going through all changes again and explaining them.

Increases understandability — to answer the questions of the peer developer, the code/test/document is adapted so that other developers likely will understand it.

How to strengthen

Add push reviews to the definition of done.

Refuse accepting user stories for which push reviews are missing (you can still review with the help of the version control system).

Risks

Team needs to see the benefits, otherwise the reviews are pure waste.

Code that does not fulfill some minimum quality is hard to review. Use style checkers and analyzers for checking for minimal quality.

A lot of reviews at end of the Sprint. Discuss with team how to work in smaller steps.

More ideas at 101 ideas for agile teams

Many thanks to bbv Software Services for making this blog post possible.