"Of Course" Your Merge Process is Out of Scope for Project Management
My team consists of 10 devs. We develop some services that are closely connected to each other. We have our codebase on github.com.
Of course every change to our codebase must be reviewed before merging, so one always has to create a Pull Request (PR), wait for someone to review, maybe fix, and eventually merge.
Anytime someone says "of course" the first thing you should do is reconsider your initial assumptions. Otherwise, you're creating X/Y problems and tautologies that will lead you astray. Instead, you should be empowering your development team to reduce friction in the process without reducing quality in whatever ways make sense to them.
Code Merging is a Technical Concern, Not a Project Management Practice
Let's start by addressing the elephant in the room: how a development team develops is a development team concern, not a project management concern. From a project mangement perspective, the only concern should be whether the team is making progress at a predictable cadence towards a potentially-deliverable product increment within defined measures of quality.
In this case, you're making an ex nihilo assumption that this extremely manual and sequential process is intrinsically necessary. However, you've done so without defining:
- The value of a manual code review.
- Why your tooling is driving your process, instead of selecting and configuring tools that support a low-friction process.
- Why you have a low-automation process in the first place.
- Why continuous merging to a shared development branch doesn't provide a Pareto Principle solution to your perceived process problems.
In short, project management should be concerned with outcomes related to schedule, budget, scope, and (arguably) quality while leaving the technical implementation details to the people implementing them. If you're a project manager, that's not you; if you're a developer, then you should be talking with the rest of your development team about the things that are causing you pain.
Define Your Process, Then Automate It
Code reviews can serve many purposes, but code quality is rarely one of them. In general, you should have a Definition of Done that includes things like:
- Writing your tests first, so that you have a clear Definition of Done for each feature.
- Clean patch sets and feature toggles so that changes can be easily reverted if necessary.
- Code that conforms to the living document that is the team's current style guide.
- Code that passes automated linting, unit, functional, and integrations tests that act as executable documentation.
- Automated quality gates that prevent regressions and predictable classes of bugs.
How the team does these things is not the concern of project management, but making sure that the team is empowered to figure out how to do these things in a way that's optimized for the team and the project is certainly within the scope of project management. However, the best way to fail at this is to mandate sequential processes that ultimately boil down to the "million monkeys" fallacy.
The idea behind most of the code reviews of the type you describe is the same as the notion that given infinite time and a sufficient number of monkeys, random typing will reproduce the works of William Shakespeare. While mathematically true, it's a ridiculous way to manage product quality. More random eyeballs on the code don't make the code better, nor does arguing about whether some piece of code should use a case statement or a ternary operator. Almost everything about a code review can and should be automated except validating readability and knowledge sharing. Unless that's what you're doing with your code reviews, whatever you're validating during "code reviews" is going to be subjective, error-prone, opinionated, and fallible.
CYA Isn't a Substitute for Quality Gates
The kind of process you're describing isn't designed to test code quality or improve team communications. Its sole purpose is to spread responsibility in a way that ensures no one is really responsible.
Software bugs are inevitable. Your current process seems primarily designed to ensure no individual person is blamed for the bugs, rather than actually preventing them. The real solution is to improve your process to actively catch as many bugs in an automated and repeatable way as possible.
Test-first development processes, automated testing, continuous integration, feature toggles, and any number of other modern software development practices can help with that. Trying to smooth the communications flow of a fundamentally flawed process is solving the wrong problem. If you choose to focus on that to the exclusion of addressing the underlying process issues, you get to keep both halves of the broken process. Q.E.D.