Doing Review Procedures the Right Way

It helps us avoid mistakes, develop our skills, and achieve the best performance possible. See how the continual review process can improve the team’s workflow and help employees evolve in no time at all.

Before I go into details about specific review processes utilised by our teams, I need to mention something that ties all of these together. This is a set of three rules which aims to cultivate a peaceful and positive atmosphere that keeps productivity at high levels: precise communication, friendly approach, and constructive feedback.

Communication basics

“You are not your code” is one of our core values, but this applies to all departments, not only developers. Giving and receiving feedback, especially the negative kind, can be hard at times, since you are forced to rid yourself of any insecurities about the evaluation of your work by others and the anxiety you can experience from hearing something unpleasant. There is nothing bad - there is only room for improvement. Ask, clarify, keep things real - these are the rules every team member should follow.

Now that you know a little bit about the way we communicate, let’s get down to business. Let me present you with our review agendas for developers, Project Managers (including Leaders), and Quality Assurance specialists. We always remind ourselves that two heads are better than one!

1. Code review

Code review (obligatory for all projects) used by our developers in order to maintain the highest quality code. We realise that even if you are a pro dev with vast experience, the code you write can be improved upon - it just needs an outside perspective. To make sure the whole process is running as smoothly and efficiently as possible, we use an internal app and external tool, CircleCI.

Our internal app is used for managing projects and labelling them as accepted, passed, or rejected. The second tool’s role is to block updates to staging when necessary, i.e., depending on whether rejected commits are present. If CircleCI spots any rejected commits in the repository, the staging won’t be updated. If there are no rejected commits detected, CircleCI will execute the changes and update the staging. Code review is all about knowledge exchange and - as a result - making the results better and better.

2. Project log review

Project Managers also review their work. Once a month, they take a look at each others’ projects in JIRA. This helps identify the flaws and potential hazards that might impact on a project’s performance in the future. The factors checked are:

• the correct use of tools (such as labels, epics, release bars),

• the quality of stories descriptions,

• the time estimations assigned for particular tickets.

Sometimes the PM may not even realise that some choices or strategies actually make his/her life harder. The PM performing the review is there to spot these obstacles and propose more effective solutions. Receiving useful advice from fellow managers expands your knowledge every day, so we do it with gusto!

3. Leader review

This review takes place quarterly. The Team Leader takes a quick look at the project and provides on-the-spot remarks. They make sure the project development is running smoothly from a technical point of view. The evaluation hinges on basic performance indicators:

• time duration per individual commits and deployments,

• the number of tickets with added commits (we love tracking our progress!),

• the number of performed deployments.

In contrast to the Senior review (described below), the Leader review is not as thorough, but it can be truly valuable if executed by a Leader who knows project development inside out. Sometimes the number of commits doesn’t reflect the project performance and the long duration of the ticket might not be a bad sign. Our most experienced employees use their advanced knowledge and skills to help Project Managers support developers and monitor the progress of projects.

4. Senior review

Every 3 months the projects are reviewed by Senior Developers. This review is more elaborate, involving an inside look at the project code to ascertain what state the codebase is in and providing advice and assistance to the team on the general project architecture. Here are some of the things Senior Developers do during a review (of course, there’s much more to it than outlined here, but to include a whole checklist for each type of review would make this post Mobydick-long):

• Check the overall state of the project and setups. For example, checking: that all tools are up-to-date, which processes could be performed with less commands, and how servers are configured.

• Perform high-level code review, e.g., the state of feature testing and codebase feedback.

• Help to manage future commits with further deployments, priorities, and specs in mind.

If required, the Senior review may also serve to correct the codebase direction. This review process requires more time and preparation than the Leader review, and usually involves a Senior Developer pairing with at least one of the team members.

5. Backup review

Just like the previous two, the backup review should be done every 3 months. Its goal is to ensure that all our data is available for recovery from backup when needed. An automatic reminder should be set up for this review, but ultimately it’s the team’s responsibility to stay up-to-date on the matter. Backup review is performed both by a selected developer participating in the particular project and a developer on Support Duty. The developer on Support Duty is a person selected each week from a developer team whose role is to help others with any issues they come across in their projects.

Now, let’s discuss how the backup review is done. The application copy is launched from the backup on a separate server. In this way, the whole team is always informed as to whether the backup works correctly, where exactly it’s located, and how to use it. Backup review is also when teams establish backup drills with their Project Managers, in order to be prepared for such situations.

6. Quality Assurance review

QA team performs their review in order to check whether all available project materials are crystal clear. The goal is to make them sufficiently transparent that a QA specialist from a different project can take over at any time. Another team member’s perspective may also bring fresh insights to testing procedures and UX.

This process covers different areas within project development, such as staging, production, or hard-coded apps. Since the QA’s job amounts to that of a go-between for developers and Project Managers, what is most meticulously checked during the review are project docs (as everyone involved depends on them) and attention to detail. The QA works according to a review checklist outlining all the factors to be looked into. Among other things, this includes project information (including links to staging, beta and production, login data, people involved in the project, etc.) and mockups. Also, s/he takes a look at Pivotal Tracker to make sure that bugs are labelled correctly and properly described.

Yes, Netguru reviews everything, and we’re proud to share our experience of reviewing with you. I hope this post helped shine a spotlight on its importance, and inspired you to introduce the same solution to your business. Or, perhaps you already conduct reviews among your teams? We’d be delighted to see your point of view in the comments!

Code review is a part of a broader process: knowledge exchange. Check out the tips gathered by our developer Maria.