On the teams I’ve worked on, it seems as though many of the issues I’ve witnessed have been caused by a lack of team cohesion. On teams where projects struggled to get done and goals had to be rigorously defined by management, it felt as though the root of the issue was a lack of care within the team more than anything else. On teams I’ve seen which excelled at self management and timely project delivery, the members of the team showed a greater level of care for one another. When team mates do not care for one another, they are less likely to openly collaborate or improve shared processes. Team members which care about the team as a whole are much more likely to put additional effort into solving shared problems, code cleanliness, and operational health. In short, it seems as though a team’s productivity can be directly tied to the level of cohesion between members of that team.
If we agree that this is likely the case, and teams where members are willing to support each other are more productive than teams which aren’t, then improving team cohesion seems like a solid baseline to improve the productivity of a somewhat lagging team. I’m sure there are many other possible reasons that a team could be flagging in productivity, but as a baseline, I think a team which lacks essential cohesion will also likely lack efficiency.
So how do we identify areas where teams are lacking cohesion? I think one clear litmus test is the code review process. As I’m sure many developers do, I spend my fair share of time chasing down team mates to get reviews on my code. I have noticed that on some teams this seems to be an easy process with changes being merged quickly and reviews collected without reminding, while on other teams it takes days to get even a first review on a code change. In addition, I have noticed that code reviews requested by visiting or “loaned” members of a team take much longer on average than members of the core team itself. To some extent, I think this makes sense. If a friend asks you to review their code, you might be happy to do it since you know them and their track record. If a relative stranger reaches out and requests a review, it seems like a chore. In light of this, I think it’s clear why some teams have efficient code review processes while others don’t. If every code review feels like a stranger reaching out, people are significantly less likely to prioritize that work.
Given the importance of code reviews as an indicator of overall team cohesion, how can we improve the rate at which code is reviewed? I believe there are a few key steps that team leads and managers can take to make code review times more healthy:
- Encourage smaller CRs – This is well documented and certainly improves the speed at which CRs are reviewed and approved. Unfortunately, it can be hard to facilitate without an already efficient code review process. When CRs take a long time to get approved and merged, developers are more likely to want to stack many changes within a single review to prevent chasing down team mates repeatedly. If a team is stuck in a pattern of large MRs, unfortunately I’ve found the only way to correct this is to start rejecting large code changes. This is extremely painful at first, but naturally begins to get easier as the team reviews code faster.
- Improve code change confidence – When code is complex or poorly tested, reviews take longer and require more effort. CRs are reviewed faster when they are easier to review. High code coverage including many layers of testing along with automated format and code smell checkers can be an easy way to improve this. Be ware of making code reviews overly tedious though! A high percentage of test coverage is great, but the difference between 80% coverage and 90% coverage is hours worth of work in some cases.
- Create accountability – Code reviews get easier the more you do them. Sometimes all it takes for a team to improve the rate at which they review code is more practice. Assigning code reviews to individual members from a manager or tech lead level, can create some incentive for members to improve their code review skills while elevating the importance of code reviews to the rest of the team.
- Lead by example – I always find personal change easier than team change. Ensuring that you review every code quickly and often (at least once a day) can be an effective way to show the team the benefits of fast code reviews. While this is likely the least impactful of the options on this list, it is also the easiest to implement.
Overall, I think code reviews are an essential part of any high functioning team. A focus on the speed and throughput of code reviews can uncover deep seated issues within a team’s cohesion. I intend to continue to improve and refine the list above as my experience on different teams grows.