A common practice in engineering teams is to hold a daily standup meeting where the group gets together to discuss what they accomplished yesterday, what they’re working on today, and anything that’s blocking them.
These meetings can help create alignment and provide a rhythm for the team’s work cadence. It’s also the place where, when someone is blocked or facing repeating systematic issues that are slowing them down, the team lead or manager can work to fix the broader issue or at least help the team member move their work forward.
Communication among the entire team is the purpose of the stand up meeting. A stand up meeting every morning is used to communicate problems, solutions, and promote team focus.”
Daily Stand Up Meeting ExtremeProgramming
The problem team leads and managers often face, however, is that real blockers to work are often not voiced—to some, they might not feel like real blockers, and to others the daily standup might not feel like a good place to surface that. This makes it especially difficult to notice when they are patterns in what’s slowing the team down.
One way to begin facilitating more productive conversations in daily standups is to keep a pulse on the team’s work progress and bring any unusual dynamics you’re noticing in the team’s data to the discussion. Point out the dynamic you’re noticing, and see if there’s something causing friction that you can help with or collaborate with the team on ways to move the work forward.
A good place to begin visualizing work progress and noticing dynamics that could be surfaced in daily standup meetings is the Review Workflow. This report has a workflow-centric design and shows all open pull requests across all of your team’s repositories in a unified view. This visualization makes it easy to notice work streams that are stuck waiting for feedback or that aren’t driving towards a resolution.
Today we’ll look at three dynamics in the pull request process that we tend to see customers looking for when operationalizing this data in their daily stand up meetings:
- Unreviewed PRs,
- Long-running PRs, and
- High activity PRs.
Before we dive in, for those who may not be familiar with this report, here’s a quick overview of what the Review Workflow displays:
- The x-axis in the report shows time. You can customize whether you’d like to view the previous week, month, quarter, or any other customizable time period. Essentially, we’re looking at the age of these PRs.
- The default view is to show “open” pull requests (you can also change the PR Status to “Merged” or “Closed” in the top navigation).
- The default filter view is to to show the most recently opened PRs (in the time period that you’ve set). You can also view by activity levels and PR size.
Unreviewed pull requests
“Unreviewed PRs” are fairly straightforward; a PR that’s marked “Unreviewed” is one that’s been opened and has yet to receive a comment or approval. It can be a signal that the individual who submitted the PR might be stuck in a wait state. No one’s picking up their work and reviewing it, so they haven’t been able to move it forward.
As managers or team leads, we generally want to see team members getting the feedback they need to get their work across the line. So when we notice, in GitPrime, that someone opened a PR and it’s being overlooked or missed by the team, we can save that PR by clicking “Pin PR Details” to bring up in the next standup.
Long-running pull requests
Long-running pull requests are those that have had some discussion that wasn’t resolved, oftentimes due to confusion, disagreement, or a lack of a clear path forward. If a manager or team lead notices a PR that had some discussion that was followed by an extended period silence, they can surface it in a standup to make sure everyone’s on the same page. If not, that could be a great discussion to have together as a team to figure out how to move it forward.
An example I recently saw of a discussion that resulted in a long-running PR went something like this:
- Tory submits a PR.
- Spencer comments, “Looks good to me right out of the gates.”
- Jeff jumps in and says, “Actually, I have some feedback.” Tory responds to that feedback. Jeff responds, possibly trying to bring in more perspectives to the conversation, “Hey, this is open for discussion. Let’s figure it out.”
All this happened two weeks ago, which means there wasn’t a resolution to this discussion. The manager or team lead in this situation may want to check in with the team to see if we can make a decision and move it forward.
High activity pull requests
A high activity PR is one where there’s lots of back and forth that doesn’t seem to be driving towards a resolution—there could potentially be space for a third party to jump in and provide direction or facilitate a decision to move forward.
When we notice a high activity PR that was just opened—meaning, the conversation happening in the review is new and active—we can generally leave that alone. It’s when a lively conversation persists and doesn’t seem to be driving the work forward that we can save the PR (just click “Pin PR Details”) and surface that in the next standup.
Using data about the development process in daily standups
When you’re identifying these dynamics—unreviewed PRs, long-running PRs, high activity PRs—and surfacing them in your standups, these discussions work well when they’re very transactional. “Hey, Sid opened this PR and it doesn’t look like it’s getting attention—Sid, are you waiting on feedback from anyone here in this room?” You’ll get awareness as a team. Bring up the data, identify the action item, move it forward, repeat.
Ultimately GitPrime is designed to help engineering leaders support their teams—whether that be by removing impediments, advocating for the value delivered in the underlying workflows, or creating opportunities for improvement that matter most to the team.
If you’ve already been tracking these three dynamics with your team and would like to identify additional ways to support your team with data, reach out to your account manager or in the chat below.