Let’s just get it out of the way by saying it out loud together: “I hate meetings.”
It turns out that a lot of engineers I know feel this way about the abundance of video calls currently consuming their daily calendars. We love to code, problem solve, and move tickets. And the more time we spend in meetings, the less time it seems we have to learn, grow, and get things done.
So why am I proposing adding another meeting to your calendar?
Before you head to the exit, hear me out. What is one of the main bottlenecks of many development and release workflows?
The Pull Request pipeline.
Let’s dig in and see how a daily Pull Request Review meeting can speed up your development workflow and help deliver higher quality work in a more efficient manner.
Problems to Solve with Your Pull Requests Meeting
Imagine: it’s the last week of the sprint and your team is swamped. There are various Pull Requests (PRs) in the pipeline, but it’s barely moving as the team frantically attempts to finish their workload and put out various fires. You will likely have to deal with a few merge conflicts between these PRs, as well.
Yikes.
Let’s hope the above doesn’t actually describe your current situation, but I have no doubt there are many teams facing similar issues.
When engineers are overwhelmed with work, they tend to prioritize their own tickets, putting another developer’s PRs to review on the back burner. This leads to the aforementioned bottleneck, where everyone is laser-focused on their own work and less concerned with helping others get work through the pipeline.
Occasionally, approvals will come in just to get things moving, but without a thorough review. Without getting into the many ways to avoid these problems in the first place, let’s focus on how to eliminate the bottleneck and ensure the wheels of team progress keep on turning by making one daily change.
How to Structure Your Meeting for Success
The process is pretty simple. Add an optional 15-30 minute meeting either just before or after your daily team standup. It’s important that this is optional because if there are no PRs in need of attention, the meeting can be skipped altogether to avoid wasting that time.
If someone does have a PR in need of review and approval, the team joins the meeting and helps others make progress.
Create a Slack bot alert to ping a specific channel (either your team dev channel or PR-specific channel, to reduce noise) 15 minutes prior to the meeting. Ask if anyone has any PRs to review with the team. Developers can then ensure their PR documentation is up to date and throw their links into the Slack bot message thread for consolidation and easy access.
What actually happens during the meeting?
Once signed on, the team can work through the PRs, allowing the owner of each to share their screen and walk through their changes. As the owner scrolls through the PR, other developers can ask questions, get clarification, and provide instant feedback.
I recommend making comments right there in the PR as you go through it, so nothing slips through the cracks. Create PR tasks that must be completed before final approval.
Engineers can respectfully hash out opinions on different approaches, structure, and code quality (though I would highly recommend having documented standards for these). Any overlapping or related code can also be discussed to minimize merge conflicts, or to ensure the PRs are merged in the appropriate order.
Once everything looks good, you can get approvals on the spot and experience the wonderful euphoria of merging a feature or bug fix knowing your due diligence has been done.
The Benefits of That One Quick Meeting for Pull Requests
I’ve incorporated this process into many teams and have seen the benefits immediately throughout our workflows.
First, you’ll always be less than a day away from the attention of your team, meaning PRs will no longer sit for days, unloved and growing stale.
The meeting also emphasizes team collaboration and support, which breeds healthy sentiment between teammates. It serves as a knowledge transfer session for those unfamiliar with the specific part of the code base, language, or architecture. Has someone who has been developing in a silo suddenly gets sick and is out for a week? Have no fear! Luckily, you gained an understanding of their recent work through your trusty PR review meeting.
I mentioned setting this up either just before or after your daily stand up for a few reasons. Regardless of when your team has their standup, having the review meeting prior gives everyone an opportunity to get PRs through before their daily update. The latter presents an opportunity to follow up on the updates just given, to ensure things keep moving forward.
By coupling these meetings together, you can minimize interruptions throughout the day when engineers in the “flow” are taken out of it due to interspersed meetings. This keeps team priorities top of mind and ensures that everyone is on the same page about where their tickets are in the workflow.
Conclusion
Engineering teams the world over face bottlenecks at various points in their development workflows, especially when it comes to getting Pull Requests through the pipeline. By scheduling a daily meeting aimed at unblocking this pipeline, you can make your workflow a well-oiled machine. The benefits to your team are massive, from getting tickets out faster and improving code quality to sharing knowledge across potential code silos.
So what do you say? Give it a try, and I guarantee you will discover ways to improve team efficiency and happiness without the dread of another useless meeting.
Looking for more ways to maximize the value of your team meetings?