The most ignored attribute of development is reviews. Many Scrum teams compromise on review tasks in order to complete their other tasks in a particular sprint. Though they plan separate tasks for reviews, they frequently ignore them. In reviews themselves, the most ignored is the code review. The shorter the sprint, the less the importance and time allocated to code reviews.
I think it should be the other way around. The shorter the sprint, the higher should be the quality of code we can write by implementing effective code reviews. In smaller sprints we build features in smaller chunks, hence we have a smaller part of the work product to focus upon. In code review techniques, group code review is the most efficient.
Group code review is a review done in a formal, time-boxed meeting in which all the developers come together to review implementation of a particular work item. We should include group code reviews in sprint planning meetings, based on the sprint backlog.
Numerous advantages result from implementing group code reviews in our sprint teams:
- High-quality code is produced.
- There is greater adherence to coding standards.
- Greater understanding of the implemented feature is passed throughout the whole team.
- The best possible solution/optimization is reached (new ideas are generated when all the developers come together).
- The author is forced to write readable, organized, and well-documented code.
- The majority of bugs can be caught, thus not passed on to the testing cycle.
- Trivial bugs in the code are located; otherwise they would be difficult to locate either by author or a single reviewer.
- It's the best method of knowledge sharing in the team — everyone involved in the review gets an idea about the design and working of the developed component and also whether it's going to break or improve the working of any other component after integration.
- Integration, coordination, and communication are improved within the team — such a meeting provides the best platform for all the team members to come together and discuss and suggest improvements in the work product.
- There is decreased dependency on individuals — the review increases the competency levels in the team; all the members involved in the review process gather knowledge about the software components reviewed.
- Accountability moves from an individual to a team.
- Personality clashes are less common than in a single-reviewer technique.
- It's a great learning process for new team members.
While implementing this in our Scrum teams, we should dictate some ground rules:
- No code should be checked in until the review process is completed.
- The review should be included in the criteria for passing or failing a sprint.
- The product owner should not accept any work product for which formal group code reviews have not been conducted.
- Allocate sufficient time for a complete review cycle in sprint planning, i.e., allow the time needed for review meetings and implementation of code review comments afterward.
By ensuring these ground rules, we not only ensure the effective implementation of group code reviews but also create a work product of the highest possible quality.
Apart from developers, we can involve other members as "chickens" — that is, they want to learn about the software product, though they don't participate or contribute in the review. For example, we can invite the testing team — it helps them do white-box testing — or we can invite members from other teams or from management.
While doing code reviews, we should follow a simple rule of any review: We should check the code for correctness rather than judging the code. We should not think, "How would I have written this code if I had implemented this feature?"
If group code reviews are conducted effectively in a Scrum environment, they can yield strong results that will, in numerous ways, help the end customer as well as the organization that developed the software.