Effectiveness of Group Code Review in a Scrum Environment

29 October 2012

Amit Gupta
Siemens Technology and Services Private Ltd.

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.


Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 0 (0 ratings)

Comments

Dinesh Sharma, CSP,CSM,CSPO, 10/30/2012 5:18:27 PM
Why review when you can pair programming? In my opinion code review is reactive whereas pair programming is proactive and I always prefer PP over code review...
Stephen Hawkridge, CSM,CSPO, 11/2/2012 2:44:36 PM
@Dinesh. Pair programming, although having huge benefit to the coding process still does not offer the same problem finding functionality that a review does. Very often, due to the fact that both coders are invested in the code, they tend to miss problems that an outside reviewer would see. I recommend that even when pair programming sufficient review is done of the produced code to ensure he quality of the code.
Rahul Joshi, CSM,CSD, 11/26/2012 10:02:42 PM
@Dinesh. Pair Programming is a way to start verification and validation of the code. But is not sufficient , unless you have a very maure and experienced team and the team has been oiled for quite some time on the product/ project being developed. Answer to "How much review is required for your deliverable's verification and validation ?" would tell whether you need extra third party(in this case group review) review.
Jorge Bejar, CSM, 12/7/2012 10:45:56 AM
Hey Amit, nice article! I haven't heard about involving the whole team in a code review at the same time, it sounds promising at least in some cases.

I have a question: you mentioned that "we should include group code reviews in sprint planning meetings", but no revised code shouldn't be delivered (well, you said it "The review should be included in the criteria for passing or failing a sprint"). It looks like reviewing all the code in next planning meeting is too late (in fact, that happens when the current sprint is over).

If group code reviews are scheduled too late in the sprint, it would be difficult to deliver the stories because implementing the review feedback requires some extra time.

When you schedule the group reviews? Only during sprint planning? If any objections comes up, will code author work on it next sprint? Do you do group reviews for all items or just for complex stories (complementing with single-reviewer reviews for other items)?
Amit Gupta, CSM, 1/23/2013 8:23:57 AM
@Jorger Bejar. Thanks Jorge for reading and appreciating the article. The intention behind writing the lineΓÇ¥ We should include group code reviews in sprint planning meetings, based on the sprint backlog.ΓÇ¥ in my article is that we should plan for it in the planning meeting i.e. we should allocate sufficient time for the group code reviews and the time to implement the review comments afterwards in the sprint for which we are planning. Further we should also consider it while we size our user stories. We cannot and we should not do group code reviews during planning meeting because that is quite impractical as purpose of the planning meeting is entirely different. We should implement the review comments during the same sprint because that will make our user story complete in all respects. In my team we do code reviews for all the code written in a sprint for all the user stories taken in that sprint because then only we mark our user stories as complete at the end of the sprint. From the past few sprints we have started using a web based tool integrated with our source code repository to track that piece of code written by one developer should be reviewed by all the relevant stakeholders.

You must Login or Signup to comment.