When discussing code review strategies, agile teams often think their pull requests are too slow. It's not the practice of pull requests that holds teams back; it’s the reality that having a pull request process can slow integration time and limit the feedback that is essential to agile teams being successful.
You can structure your changes in a way that facilitates more rapid feedback, but even then it is still possible to have a slow integration time if people don’t review PRs promptly. Mechanics are part of it, but culture also matters.
While it’s easy to say that reviewing pull requests is important, aligning actions with priorities can be difficult, especially when you’re short on time. As individuals, it’s easy to fall into a frame of mind where reviewing someone else’s work seems less interesting or like a lower priority than writing your own code—even though it’s short-sighted because your work depends on someone else reviewing your code. Organizational factors can play a role by encouraging a focus on individual goals over team goals, in spite of messages that the team matters.
The cultural challenges to pull requests working well on an agile team revolve around the ideas of focus and commitment. If everyone is clear that they need to work together to reach the sprint goal, the decision about whether to do a review and allow work to move forward or to work on something else should be clear. If you have a Review column on your Scrum board, the daily scrum is a good time to evaluate whether too much work is waiting for comment, remembering that it’s better to have work completed than more work in progress.
While the daily scrum is a good checkpoint, once a day may not be frequent enough to move work along. The team can establish working agreements about how promptly code should be reviewed and how to remind people when there is work to review.
Another thing that can get in the way of review is a culture where individuals tend to work alone on backlog items. Consider having pairs of developers work together, so that one is a developer on a feature and the other is the main reviewer. This will ensure that the reviewer has some context for the review, and the developer will know that there is someone who is committed to doing the review and who has enough context to participate in ad hoc design discussions. This approach also helps the team by encouraging the sharing of design knowledge.
There is a feedback loop between the cultural and structural elements of doing reviews and pull requests in an agile environment. While not all the pieces can come together all the time, keeping these dimensions in mind can help you get the advantages of pull requests while still being agile.
