Question
Statements like "Agile practices and peer/code review are like oil and water" highlight the ongoing misconception of what Agile is. Many still think that the term "Agile" equates to "No Overhead" while attributing concepts such as requirements gathering, code architecture design, QA, and code reviews as "Overhead". This is obviously a highly-flawed viewpoint.
In order to introduce and manage an effective code review process, first identify the objectives and get buy-in from the team (i.e. they need to believe in the objectives). What do we hope to accomplish with code reviews? And 'better code quality' is not an adequately defined objective -- the "SMART(ER) objectives" mnemonic can apply here.
For example, the last time my team used code reviews, we set the primary objective to significantly reduce (more than 50%) the number of staging-level bugs per iteration. The measurement was a simple bug count (admittedly crude). The time spent on code reviews was also taken into account during the estimation meetings so that our deliverables were not affected. We met the objectives of the code reviews, and continued to monitor the net value our code reviews brought to the project.
In summary, yes code reviews are absolutely part of Agile, as long as your team has clear objectives behind them that bring net positive value to the project (higher quality, more scalable / extensible code, etc). Make sure you can measure this net positive value in some way, and don't get married to the code review process itself -- be willing to change it if it's not delivering value.
I had someone tell me that many people in the Agile community believe that "Agile practices and peer/code review are like oil and water." I'm not sure if that's a single person's opinion or if it's a commonly held perception. What's your view on the subject? Do you see code reviews as useful | irrelevant in Agile teams?Answer
Statements like "Agile practices and peer/code review are like oil and water" highlight the ongoing misconception of what Agile is. Many still think that the term "Agile" equates to "No Overhead" while attributing concepts such as requirements gathering, code architecture design, QA, and code reviews as "Overhead". This is obviously a highly-flawed viewpoint.
In order to introduce and manage an effective code review process, first identify the objectives and get buy-in from the team (i.e. they need to believe in the objectives). What do we hope to accomplish with code reviews? And 'better code quality' is not an adequately defined objective -- the "SMART(ER) objectives" mnemonic can apply here.
For example, the last time my team used code reviews, we set the primary objective to significantly reduce (more than 50%) the number of staging-level bugs per iteration. The measurement was a simple bug count (admittedly crude). The time spent on code reviews was also taken into account during the estimation meetings so that our deliverables were not affected. We met the objectives of the code reviews, and continued to monitor the net value our code reviews brought to the project.
In summary, yes code reviews are absolutely part of Agile, as long as your team has clear objectives behind them that bring net positive value to the project (higher quality, more scalable / extensible code, etc). Make sure you can measure this net positive value in some way, and don't get married to the code review process itself -- be willing to change it if it's not delivering value.