What would happen to your project if one of your developers got hit by a bus tomorrow? What if it was more than one? Or two? Or Three? In other words, what’s your “bus factor.”
A “bus factor” (or “key person risk”) is a thought experiment designed to help teams factor in missing critical components (such as team members). Your developers (hopefully) will likely never get hit by a bus. But how secure is your project or sprint if work from a team member goes undocumented, is never shared, remains unpublished, or is encrypted? You may be at risk of losing a key component due to the absence of a team member, and if you are unprepared for such scenarios, your project’s advancement may falter.
Having a low bus factor is risky. For example, if your project grounds to a halt once just one or two team embers are down, you may have a problem. Having a high bus factor, on the other hand, illustrates an increased distribution of knowledge of the general code across the team. That way, if one or two (or more) people drop off, you still have members in place that can jump in and pick up the slack without much of a slowdown at all.
Why You Need to Embrace a High Bus Factor
If you have a team where one or more developers have a good understanding of every area of the code, you as a manager have more comprehensive options for assigning tasks. You’ll also be blessed with more people who can provide thoughtful reviews. This can help prevent bottlenecks – especially near the end of a sprint.
However, if, instead, you have siloed workers and only certain team members have expertise in certain areas of code, you’ll have difficulty assigning work. On top of that, if one of those siloed workers is taken out of the picture, you’ll have a real gap in knowledge.
How to Find Your Bus Factor in Git
Look at your Knowledge Sharing Index. You’ll be able to see your team’s knowledge distribution at a glance. A low index translates into an inadequate distribution of knowledge (and a higher bus factor risk). This also will warn you as to if silos are forming within your team. By addressing silos, you’ll also be helping to manage your bus factor.
The Index is a great place to start, as it allows you as a manager to get a macro understanding before drilling down into the team itself. Are there dynamics at play? Do you need to address those as well? For example, if certain team members only review each other’s work, you may have to tactfully break the habit and move some around to other areas of code.
Achieving Knowledge Distribution in Git to Reduce Your Risk
Make sure each team member is making small commits frequently and collaborating with various team members on numerous code areas. Foster collaboration and debate within your team.
You can also provide helpful feedback in one on ones and reinforce healthy habits (like not approving one’s pull requests) during training and onboarding.
Get team members more involved when you notice a low Sharing Index (low Bus Factor) by encouraging them to be more interactive in the review process. And don’t just focus on the negative – when you see commendable behavior, call it out during teamwide meetings. This helps reinforce positive trends and encourages all team members to embrace specific work habits.
Conclusion
Don’t get caught off-guard when you’re down a team member. Make sure you have enough personnel that understands enough on the underlying code to ensure you can avoid interruptions or delayed project completion.
Integrate Git with Jira using Bitband. We have a variety of great highly-rated plugins for Bitbucket, GitHub, Gitlab (and more) available now on the Atlassian marketplace.
Want more Bitband insights? Check out:
- Git and The “Bus Factor”: How Safe is Your Project?
- How to Leverage Sprint Retrospectives to Improve Your Product
- Long-Running Pull Requests: A Sign of Trouble?
- Expanding Refactoring in Git Projects: A Sign of Scope Creep?
- The Problem With Self-Merging Pull Requests
Want more Bitband insights? Check out:
