Bus Factor

A Bus Factor measures the minimum number of team members who have to be hit by a bus to put the project in jeopardy. Aim to increase your Bus Factor as much as possible? Read for more to learn how!

What Is a Bus Factor

A Bus Factor defines the number of developers that are vital to a project. If something happens to them (they get hit by a bus), the project is in danger. To get hit by a bus is probably a little extreme. Consider another scenario: if a key team member takes a long vacation or is sick, the project can be easily put at risk. The goal is to increase the Bus Factor as much as possible. The best way to increase the number is by encouraging knowledge sharing inside and outside your team.

Source: The Bus Factor

A Bus Factor is also known as the bread truck scenario, lottery factor, truck factor, bus/truck number, or lorry factor.

Why You Might Want to Increase Bus Factor

• It detects the single point of failure within the team before it happens.
• Sharing knowledge prevents the project from falling apart.
• Trying to increase the Bus Factor continuously can give you a good control over your projects.

Problems that Increasing the Bus Factor Solves

• "Not my problem" mentality
• Meaningless work
• Unsuccessful product
• Unhappy clients
• Disconnect Between Business and IT
• Poor code quality
• Demotivated Team
• Toxic team culture

How to Increase the Bus Factor

• Re-assign Usually, the project relies on one or a few "heroes". The company has to be prepared for them to leave or be absent. Re-assign the heroes to a different part of your project or to a completely different task. Their replacement will have time to complete a knowledge transfer and ask them questions while the heroes are still part of the company. The heroes can be very useful in their new area as well.

• Code Reviews Code Reviews help to find bugs and helps other developers to get familiar with your project. Also, shared responsibility creates a friendlier atmosphere. For more information, see Code Review.

• Improve the level and experience of junior team members It is important to let the juniors become valuable team members as soon as possible. Do not always give complex and difficult projects to the senior developers. Juniors might spend longer figuring the projects out, but they can always ask for help. Discussing the issues with more advanced colleagues helps juniors grow fast.

• Pair programming Fixing the bugs can be done by someone who did not write the code (if it does not need to be fixed as soon as possible). For more information, see Pair Programming.

• Regular meetings If your team does not do daily standups, ensure to meet all the team members from time to time to share critical information. For more information, see Agile Events.

• Write explicit code It is very helpful if anyone can read your code. You can improve your style, structure, or naming. Also commenting is useful. For more information, see Poor Code Quality.

• Stay close to the domain You should understand your client’s domain. Adopting the same vocabulary as your client can help your team to understand what they are trying to say. Help them with the project description and summary, and write it all down in a glossary.

• Write tests and documentation Functional tests help developers to understand the project very quickly. Document (at least) the main goals of your project. For more information, see Software Documentation, or Performance Testing.

Common Pitfalls of Increasing the Bus Factor

• Team substitutability is missing. It seems like everyone is familiar with the product but there is only one person (or a few) that can release it. This can be prevented by automatization.
• The Bus Factor may be hidden. It does not have to be only about knowledge of your project. It can be just one password that is not shared and protects an important part of the project.
• The documentation is poor or nonexistent. If the developers do not share their ideas, it is very important to write them down. This can be avoided by building trust, or even signing non-disclosure agreements if requested.

Resources for the Bus Factor

• Agile Advice: Truck Factor
• Medium: Lessons learned about Bus Factor
• Medium: The Bus Factor
• Dev: How To Increase Your Bus Factor
• Medium: Writing Highly Readable Code