[tibbon]

I've desire to want to try exactly this. No more 2-week long code reviews, where 2-3 reviewers debate (slowly) over Github about the naming of a local variable. No more drawn out A vs B problem solving. No more 2x a day sync ups. Just put all the stakeholders in a room and crank it out together.

[plgs]

You'd still want to do code reviews after mob/pair programming though, because:

- the whole team might not be here and needs to review the changes to catch up.

- doing the wrong thing as a mob is still doing the wrong thing, and you may need more eyes on your code to spot that (especially if everyone during the session was convinced that what was written is right)

- IMHO, even if 10 persons were involved in writing it, a later review of the code can still improve quality (because people will actually be reading the code rather than writing it, which will expose other kinds of issues)

[lotyrin]

Who reviews, if the mob consists of everyone? If I participated in developing a thing, I would have probably already made the oversight, wouldn't see an issue.

That raises an interesting idea, you split the team, the mob and non-mob, like learning vs testing data. Dedicate some fraction of the team to the mob, then rotate out members. It seems like most of the benefits are realized, if people need skills or compassion for other roles of the project expanded, they get their turn. If the team is large enough that the mob is a minority, you minimize the effect of downsides.