What is the Bus Factor?
When an employee leaves a company or takes a long leave, most organizations face the challenge of “handover.” The business areas that a single person is responsible for are often extremely difficult to seamlessly transition to a temporary replacement or even a new hire who hasn’t started yet. To face and solve this problem, organizations can use the Bus Factor as an indicator to assess whether the team’s work will be halted due to personnel changes.
The Meaning of the Bus Factor
Titansoft Strategy Consultant Heishou Ayi described the Bus Factor in his blog, Heishou Ayi’s Agile Practical Report:
The origin of the Bus Factor comes from a hypothetical situation: one day, you receive a call saying that your team went out for a meal and someone got hit by a bus. If it’s one person who got hit, and that person is the team’s super core with a huge impact on the project, then the Bus Factor is 1. If two people got hit at the same time, causing a huge impact, then the Bus Factor is 2.
In other words, the Bus Factor evaluates the impact on the team or project caused by personnel changes. If the most important member leaves and immediately causes a disruption, the Bus Factor is 1. If the two most important members leave and cause immediate disruption, the Bus Factor is 2. If the three most important members leave and cause immediate disruption, the Bus Factor is 3… and so on.
The Bus Factor is also a measure of information sharing within an organization or team. A higher Bus Factor means the team shares information more effectively, and individual influence is less significant. Conversely, a lower Bus Factor indicates that if a key person leaves, the work is more likely to be disrupted.
Titansoft’s Practical Use of the Bus Factor
I’m sure many of you have encountered the dilemma of needing to find someone to take over work when a team member leaves or takes a long leave. As a software company, in addition to the common challenges of handovers, we may also face the situation where, when someone leaves the team, we might have to rewrite code. At such times, the Bus Factor can come in handy to assess the team’s state and determine if any action needs to be taken.
In the corporate storybook A Roaming Whale’s Tale, in the “Titaners Speak From The Heart” section, the company shares real-life examples of using the Bus Factor:
Before adopting Agile, Titansoft’s Bus Factor was only 1. Now, it is generally greater than 1.
When Titansoft was just starting out, it was like marking territories—each person focused on their own area of expertise, accomplishing their tasks with little consideration for others’ work. As a result, whenever a team member took leave, the team would become chaotic and overwhelmed, operating in a way that relied on the “hope that no one gets sick, takes leave, or gets hit by a bus” mentality.
This unhealthy situation changed after adopting Agile, when the company moved to an end-to-end team structure. Through daily stand-ups (Daily Scrum), team members shared work progress and collectively participated during each Sprint cycle, leading to iterative improvements.
Another specific example was how the company implemented the practice of Pair Programming, to avoid the dilemma of team members leaving and leaving behind a system no one could maintain (ultimately leading to a Code Rewrite situation).
Pair Programming is an Agile software development method where two software engineers work together to write code. One is the driver, writing the code, while the other is the observer, reviewing the screen, checking for errors, or providing suggestions. This practice also brings long-term benefits, such as mutual learning and discussions, and helps to mentor younger team members, fostering their growth.
In the early stages of some new projects, Titansoft developers initiated Mob Programming, where they used collective intelligence to build the system architecture foundation. This approach helped the team better understand the core business needs of the project and grasp the business logic behind the system design.
Through this work mode, engineers communicate their ideas early, reducing discrepancies during implementation, and learn how to persuade others in the process. The resulting code, having undergone multiple perspectives, reduces blind spots and improves overall code quality.
Looking back after adopting Agile, Titansoft has never had to rewrite any program or project. Although they still face regular code refactoring during daily development, it is rare to hear of teams experiencing major disruptions due to someone’s departure.
Titansoft places great importance on each team member and invests considerable effort into ensuring that when a team member leaves the company, it does not affect the organization or team’s operations, contributing to a sustainable and positive business model.
Does the Bus Factor pique your curiosity? If you want to learn more about the practical changes Titansoft has implemented along the way, we sincerely invite you to read Titansoft’s corporate storybook, A Roaming Whale’s Tale!
T.8ytes by Titansoft 