Using Git Signals to Identify Blockers
"1 out of every 3 features gets delayed with 70% of engineers reporting 'blockers' as the main cause."
Nearly every team runs into blockers. It's an inevitable part of writing software and we do our best to minimize them but - the reality is we can't predict everything.
So rather than talking about how to prevent blockers, we'll be discussing how to quickly identify when your team is stuck so you can remove blockers before it's too late.
Common Ways to Identify Blockers
Most teams today use a few strategies to identify blockers. Some common ones are:
- Standup - Announce Blockers
- Shoulder Tapping - Frequent Progress Updates
- Retrospectives - Review Encountered Blockers
Common Pitfalls
While these strategies can be effective, they often allow blockers to slip through the cracks because they rely on engineers self-reporting issues.
But as engineers, we often:
- Don't Realize We Need Help
- Don't Ask for Help - Or Don't Want to Bother Others
- Move Onto The Next Task to 'Stay Productive'.
You end up with unresolved issues, feature delays, and frustrated team.
"Blockers go unnoticed until it's already too late."
It's not all bad news. Luckily, there are signals that can help you identify when your team may be getting stuck. So we've put together quick list of signals you can use to identify blockers before it's too late.
3 Github Signals to Identify Blockers
- Increasing Open Pull Requests
- Spike in Code Churn
- Idle Development or Review
1. Increasing Open Pull Requests
How to identify: Keep a pulse on Open Pull Requests throughout the Sprint. If you notice your team creating more Pull Requests than they are closing, it can signal a larger issue. Generally you should have no more than 2 Pull Requests open per engineer.
2. Spike in Code Churn
How to identify: Keep a pulse on Commits After Pull Request Opened. If you notice your team making large changes after opening a Pull Request, it can signal a larger issue. The most common causes are scope creep, poorly written tickets, or code quality issues.
3. Idle Development or Review
How to identify: Keep a pulse on each Pull Request Status. If you notice a Pull Request getting stuck in Development or Review, it can signal a larger issue. Compare this to your team's average to see if an engineer is potentially stuck.
Note: Use historical data found in Github to identify your team's Average Time Spent in Development and Review.
Great, but where do I get this data?
The good news is you already have it and it's sitting in your Github account. If you want to start using this data, the obvious starting place is the Github API. They have a robust REST API that allows you to query everything from pull requests to commits.
If you don't have time to build your own home grown solution or fiddle with open source tools, then you can try Haystack which gives you a dashboard and alerts right out of the box.
Haystack helps engineering leaders identify blockers and trends. Directly from Github. Instead of guessing if you're improving, or constantly bothering your team for progress updates, simply use Haystack to get alerts in your inbox every morning. Plus a dashboard to track improvements over time.
.svg){kind=small}
.svg){kind=small}
