- I make a change and test it (and change and test until it's right)
- I package up the change
- I send a note to the group chat to ask for a review
- Someone reviews the code
- I make any suggested changes, get another review if it was a big set of changes
- I check in (done!)
Simple enough. It works... as long as there are always willing reviewers.
For any sort of casual peer review workflow like this to work - whether it's code reviews, idea jams, design reviews, or whatever - all the peers involved have to be willing to balance reviewing and doing. That is, sometimes they have to be the one who is reviewing changes, and sometimes they have to be the one who is doing changes. If you're not in balance, then your casual review process is dividing your team into doers and monitors - and that's a bad vibe long term.
If you have a peer review process in place, and you're getting negative feedback, you might be out of balance. Listen for comments like:
"Well, I finished it yesterday but I haven't gotten a review yet."
"Nope, I didn't do that task yet. I was reviewing all day."
"Jacob will review it. (HAHAHAHHAHA!) Yeah, right!"
If you're out of balance, it's time to figure out how to re-achieve balance as a team, or to decide that the casual self-directed process isn't working. Generally the former is preferable unless the practice is completely useless. Typically, you can achieve balance by formalizing it for a while (e.g., designate a "reviewer of the day" and rotate it on a strict rotation).
Self-driven processes can be highly effective process techniques, but only if the workload is balanced across the whole team. As an individual team member, make sure you're doing your part. And as a team, make sure things still feel balanced. As with anything, how things feel is an early indicator of success or problems. You already know it in your team - just listen.