Scrum and Code Review -- they go together like beans and cornbread

Beans and Cornbread had a fight, until they realized they go together.  See documentary.

Do Scrum and code review go together?  Some people think not -- that somehow agile methodologies obviate the need for human beings to look at code.

But Ken Schwaber and Jeff Sutherland, the co-founders of Scrum, say code review is necessary for Scrum.  Specifically, that code isn't "done" until it's been code reviewed.

I know this because I've given talks after both of these luminaries at conferences, and both times they were the keynote speaker (and therefore went first), and both times they specifically named code review as a necessary step to consider code "done."

In fact, Jeff in particular said that the number one way that people perform Scrum improperly is by not having a strong enough definition of "done."  It's not enough to have it checked in, not enough for a developer to say it's ready.  Unit tests are necessary but not sufficient, separate QA is necessary but not sufficient.  Code review is also necessary but not sufficient.

"Shippable code" doesn't just mean "we're willing to ship it, fingers crossed."  It means it really is ship-quality!  And code review is part of that definition.

Of course this isn't the only reason why code review is useful in agile processes.  Another example is in achieving the notion of the self-managing team.  The Scrum team is intentionally small and tight-knit, and most of the team's operations is intentionally shielded from outside management.  The purpose is to foster deep communication and trust within the team, where people help each other, teach each other, and are even able to admit it when things go wrong, because all that churn never leaves the team.

Code review undeniably promotes communication within the team.  Specifically, it ensures that everyone on the team has put their nose in all the code -- not just the parts they're focused on.  Also, by sharing all the tricks and lore about the code base and programming language, everyone gets better at writing code and more similar in their style.

Of course with pair-programming you're already doing "code review to the max."  Barring that, informal code review is still a necessary step in completing your Scrum iteration and delivering code that's truly "done."

Comments

[Tom Harris]

Communication, teaching, and learning. All good reasons for code review. And I won't argue here why pair programming, though valuable, may not quite be "code review to the max".

But the biggest reason code isn't complete without code review is that code review is the only test of the other result of coding. The executable goes off to the testing group, but who tests the codebase to see if it's readable and understandable -- in short, maintainable? Only the developers can do that, with code review.