In my team we have a policy that each code should be reviewed by at least one other developer. When the review is done the reviewer just clicks the merge button so the code ends up in development. Recently a idea came up that the reviewer should not be able to merge directly, but should pass the code review to a member of developers with permission to actually merge (2-3 people). The team size is about 8 people attempting to work according to Scrum. I would like to get some feedback on whether this is a good idea and if so in which situations.
The idea of a required code review before it ends up in a shared branch is a good idea. Of course, the people who are doing the code review should be the people with the knowledge of the system under development (including the requirements, architecture, and future direction) rather than just any team members. It doesn't make much sense for a brand new hire to be assigned to do code reviews and be able to merge that in, unless they understand the larger context.
The idea of passing a code review along doesn't make that much sense to me, though. If there are a small number of more senior developers, then those people should be the ones doing the code reviews and merging, along with mentoring and coaching the less senior developers to help them get to a higher level of knowledge. As more people gain experience and knowledge, more people can be given the responsibility of conducting code reviews and merging the software.
I don't think that Scrum is going to offer you any guidance, but Lean Software Development will. Both context switching and motion are wastes that, in a lean environment, should be reduced or eliminated. In your current state, you have one person who needs to switch contexts and do work. In the proposed future state, you have two people who need to switch contexts as well as pass messages between each other.