Grandmother and grandson doing homework

Reviews, oh no!

Really? How to get the Best Out of Reviews

Time to Read 4 min

Review! The word alone drives developers and project managers away. Everyone thinks that reviews are good for quality and that you can learn something from them, but...

We can see how reviews can be carried out more or less efficiently and effectively. And because there's no point in wasting time and not getting anything useful out of it, we think we should avoid the following pitfalls:

How to See the Wood again, not Just Trees?

Problem

The reviewer gets lost in the review and can no longer see the wood for the trees. The main objective of the review would be to check the correctness and completeness of the artifact. The following aspects can distract from this main objective:

  • a large scope of the content to be reviewed: this leads to many details in which one can get lost
  • an extensive list of checkpoints (e.g. in checklists) with detailed checks on both content and formal aspects

Solution

Communicate the main objective of the review to the reviewer, i.e. correctness and completeness. This can be done in a training course and in the work instructions of the review.

In addition, the aspects to be reviewed can be assigned to individual reviewers. For example, formal aspects (coding rules, naming rules, requirement rules...) can be checked efficiently by a single reviewer, who then does not need to have the overview. Different content-related areas of the artifact can also be distributed among different reviewers.

What Exactly should I Check?

Problem

Too much or too little is checked because it is unclear what should be checked. Only changes since the last review or everything?

Solution

Clearly define the scope of the review in the review documentation, create a formal review invitation with a clear definition of the scope.

That is Good Enough, no?

Problem

Reviewers have very different quality requirements for artifacts.

Solution

Define qualitative requirements and guidelines for artifacts (document, code, ...). Rotate review partners so that a common understanding of the required quality is established over time.

How do I Find what is Missing?

Problem

There is no check for completeness, no check for what has been forgotten. It is usually easier to check the consistency of the existing material than to find out what is missing or has been forgotten.

Solution

Deliberately check the artifact for completeness in a first reading.

Create a checklist with topics that must be included in the artifact.

Check whether higher-level documents (e.g. system requirements when reviewing software requirements) have been fully mapped. Requirements traceability helps here.

Where is the Independent Reviewer?

Problem

A review should be performed by a reviewer who had nothing to do with the creation of the artifact. If the "entire project team" was involved in the creation of the document (e.g. requirements or architecture/design), where can we find an independent reviewer?

Solution

You can appoint someone for each artifact who does not work on it. Or even better, you can involve an independent reviewer from outside the project team. The disadvantage of the "external" solution can be that the reviewer has too little domain knowledge of the specific project and is therefore not very efficient. On the other hand, they can contribute new ideas and impulses to the project.

Or you can use at least two reviewers to ensure that at least the four-eyes principle is fulfilled everywhere.

How to Achieve Consistency?

Problem

The content requirements are not clear to individual reviewers. They only exist in the minds of some of the reviewers and sometimes also the authors. As a result, the content requirements are usually not consistent.

Solution

First document the higher-level requirements, e.g. before the software design review clarify the requirements specification for this software.

A Comma is still Missing... What about the content?

Problem

One of the most common problems is focusing on formal aspects instead of content. Formal aspects (e.g. correct formatting, correct revision history) are important, but content is more important. However, checking the formal aspects is usually easier (and takes less time) than dealing with the content.

Solution

Teach reviewers that content is more important than form. This can be done in a training course and in the work instructions of the review.

In addition, the aspects to be reviewed can be assigned to individual reviewers. For example, formal aspects (coding rules, naming rules, requirements rules...) can be checked efficiently by a single reviewer. Someone else can then take care of the content.

We have Complied with the Review Process... Is that Not Enough?

Problem

More attention and time is given to the correct formal process than to the content review.

Solution

Communicate to the reviewers that the content is more important than the formal process. This can be done in a training course and in the review work instructions.

Matthias Eggenberger

Do you have additional questions? Do you have a different opinion? If so, email me  or comment your thoughts below!

Author

Comments

No Comments

What is Your Opinion?

* These fields are required

Projects? Ideas? Questions? Let's do a free initial workshop!