In this context, we presented a lightning talk about one of our emergent practices: the “mob review”. One year after, we’re still happy with this method, here is a short feedback.
During 4 years, from 3 to 20 devs in the core team, we continuously updated our workflow through retrospectives actions.
From no code review, passing by optional peer code review, to mandatory peer review with a minimum number of votes, we recently adopted the mob code review.
This practice is inspired by Mob Programming and aims to solve several communication issues we encountered by asynchronously commenting code on Github Pull Requests.
“Mob programming is a software development approach where the whole team works on the same thing, at the same time, in the same space, and at the same computer.” (cf https://en.wikipedia.org/wiki/Mob_programming)
“Mob code review is a software development approach where the whole team reviews on the same thing, at the same time, in the same space, and at the same computer.”
The following slides summarize our evolution regarding code review, the issues we encountered and the pros/cons of this practice.
As usual, there is no silver bullet, it may be useful (or not) in your own work context :)