Team: Identify the OverHelper's
OverHelper will become a pattern if team members share an uncommon experience level within the team, it will have advantages and disadvantages in the team management & workload assignments.
I have witnessed a few types of OverHelper in the team,
Who spends time in the code review and works with the developer to refactor the code. In this case, actual development starts when the developer submits the code for review.
Who spends time with the developer to clarify the ways the feature can be implemented, explains domain expectation, possible implementation and so on. In this case, the assigned task for both developer and OverHelper developer will be delayed and might not complete on time.
These kind of OverHelpers are good and sometimes turns into trouble in overall delivery timelines. Ideally, the development teams should not depend on each other.
How to identify this pattern of working?
On Scrum Updates, if you noticed team requires more time for code-review to do the refactor.
Check the Pull Request corrections trend, if there are frequent code corrections and commits after the PR is raised.
This pattern is normal in a mentorship or buddy relationship while the team members are onboarded newly into the team. The OverHelper may bring down the timelines on the other hand might increase the code standards and team collective knowledge.
What can be done?
OverHelpers are good to have problems until it is not distributing the delivery or team moral. What can be done in such a way it won’t turn into a problem to solve.
Assign more than one reviewer for the Pull Request, default it to “2” in the GIT settings. If one reviewer gets into the OverHelper situation then ask the team member to get a second opinion from another reviewer. Always track who is reviewing who’s PR in the daily Scrum and update in the comments section.
If the PR is getting frequent corrections after the code review or code review cycle is taking more time than expected. Flag and understand the delay, arrange for cross-training or assign the engineer to a different codebase.
Understand the strengths of the Engineers and assign them to the different code bases as divide and conquer policy.
If concerns are valid and require refactoring then accept and revisit the delivery timelines.
OverHelpers are sometimes inclined towards leadership and coaching as a Manager, you can direct them to correct roles and mentorship.
Identify OverHelpers and align the team early in your timeline and take the right action.