Should you consider peer reviews outside of code? Will this affect the Agile methodology we are working with? Hexacta’s Methodology & Quality team goes deep into this and analyzes the importance of peer review throughout the entire development process.
Peer review is a practice used for checking the work done by one’s colleagues to guarantee it meets detailed standards. Commonly, peer review processes aim to validate whether the work fulfills the specifications, detect any deviations, and provide ideas for improvements. As one of our Project Managers previously highlighted, “Code review means determining what is being done well in order to keep on doing it and defining what can be improved.”
Peer review is a significant, excellent practice that is commonly related to coding tasks. However, when it comes to quality and outstanding results, this strategy must be considered from end-to-end of the software development lifecycle to ensure that clients and end-users get what they expect.
Would it be possible to do peer reviews in software development areas such as Design or Testing? How would this affect the Agile methodology we work with? To reveal that, Hexacta’s Methodology & Quality team goes deep into this topic and analyzes the importance of peer review throughout the entire development process.
1. It has always been believed that peer review is an activity used almost exclusively by developer teams. Why do you think this is?
M&Q Team: One of the main reasons has to do with how the teams are formed. It is common to have more than one Developer in the project but not more than one Functional (Business Analyst) or Designer, for example. This situation does not occur in all cases. Having one more person at hand who shares the same types of tasks makes it easier for revisions to occur. Moreover, since complex solutions often need to be addressed, the concept of peer programming is very common, which encourages everyone to analyze the code together and have the concept of review more present than ever.
2. Why is peer review a practice that should be addressed in other areas involved in the software development lifecycle?
M&Q Team: Peer reviews ideally should be performed on any work product we do: a requirements document, screen prototype, test case, code block, customer presentation, or even an important email. Keep in mind that our main goal is to deliver quality products to our customers and for them to be satisfied with those products. What could be better than dedicating a little time for someone else to review our work and ensure that we did not forget anything and did not made any mistake? Don’t forget that the earlier errors are detected, the less expensive it is to fix them.
This might be interesting: Tips for boosting your software team’s skills development
3. When should peer reviews be considered in software development? Why?
M&Q Team: Peer reviews should be present at all times and stages, from the beginning to the end of the project: Analysis, Design, Development, Testing, etc. For example, in the case of code, the idea is to ask for a review as soon as we have some functionality ready and before sending it to Testing. However, it may be the case that, due to capacity issues (among other reasons), it is impossible to review the totality of things. In such situations, the advice is to establish criteria and review the most critical elements.
It is important to highlight that we should not believe that reviews must be done only on little seniority employees’ work. The level of experience or position in the hierarchy does not matter. It is always good to have someone else’s perspective when the other person has the required skills.
4. What are the advantages of doing peer reviews in specific areas such as Testing or UX?
M&Q Team: The purpose of the reviews is to perform an internal control to detect defects, omissions, inconsistencies, suggestions, and make recommendations to improve the products generated. Peer reviews are a practice that should always be taken into account, regardless of what we have to do or the area involved. However, we must consider that we don’t always have another person immediately available to review the work. In principle, this can be solved in two ways.
First, we may only have one Functional Consultant or Business Analyst in the team, but we have a Tester with the required skills to review the document we write. In this situation, the Tester can give us a peer review. Second, if this option is not possible, we can call on people from another project or area.
In the latter case, it’s possible the person who does the review does not have the business context of the project. Although this seems like a disadvantage, we can consider it a way to enrich one another and have another perspective. The person’s available time must be taken into account. Choose those work products that need to be reviewed wisely.
5. How do peer reviews, beyond coding work, benefit the development team, the client, and the end-user?
M&Q Team: By having a review instance, we try to detect bugs early so that both the customer and the end-users receive a product that lives up to their expectations. It is better and less expensive to find a problem early in the process than finding it — by the customer or a user — in the productive environment. If anyone has ever tried to fix a bug in production as quickly as possible, they will surely agree that peer review is desirable. While it is almost impossible to guarantee zero bugs in a product, there is no doubt that the number of errors is greatly reduced if we perform reviews.
6. Agile projects are characterized precisely by that — being agile, getting quick results, and performing constant iterations for improvement. How can peer review in processes such as Testing or UX impact the Agile spirit? Are they compatible with each other?
M&Q Team: Although we can have more formal reviews, which involve a larger number of people and require more time (for example, when doing a peer review of the project architecture), generally, reviews are short and normal, day-to-day tasks. Therefore, they should not be understood as a practice contrary to Agile concepts but quite the opposite. They are perfectly compatible.
Take a look at this: Agile process improvement: ways to boost your software projects
7. What should a project have to be a candidate for peer reviews beyond code? Does it depend on the methodology, the team’s size, or the scope of the project?
M&Q Team: Every project should perform peer reviews regardless of its methodology, duration, scope, type, etc. However, it’s possible that, for some reason, not all work products are peer-reviewed. Therefore, the team needs to define the criteria to be considered. They can determine that a peer review is unnecessary for minor changes (as long as the whole team understands what a minor change means). Likewise, the team can define that certain critical functionalities need the review and approval of more than one person.
8. What best practices can teams implement to involve peer review throughout the entire process?
M&Q Team: First, it is essential the team states what and how the peer reviews will be carried out. The important thing is that it is a workflow where everyone feels comfortable. It can either be through the definition of Work Item status, specific tasks in the tracking tool, or pull requests in the code repository, to name a few. The ideal situation is to make the review’s results evident, that is, to document and clarify the suggestions about the reviewed product. Do not forget that peer reviews refer to the work product and not to the person who did the job. We must see them as a positive practice that helps us improve and not as a negative criticism of us or our work.
9. What role does the Product Owner (PO) play in all this?
M&Q Team: Although the PO does not have an active role in peer reviews, they need to know the practice and allow the team to perform it, understanding that in this way, they will receive better quality products. In no way should they tell the team not to do peer reviews, with the excuse that they are time-consuming or unnecessary since we have already realized the benefits they bring to the project at the right moment and time.
Final thoughts: THE IMPORTANCE OF PEER REVIEW IN the development process
Peer reviews are important manual practices that involve organization, stability, and balance. When done correctly, they have the power to significantly transform the way entire development teams work to improve quality and promote communication.
We are convinced that implementing tools such as peer reviews throughout all the development process and as part of the continuous improvement process strategy will positively impact the project’s success. Make sure the team defines early on what should be (or not) reviewed to optimize your time and results.
Comments? Contact us for more information. We’ll quickly get back to you with the information you need.
