Wikipedia describes Bus Factor thus:
In software development, a software project's bus factor is an irreverent measurement of concentration of information in a single person, or very few people. The bus factor is the total number of key developers who would need to be incapacitated, (as by getting hit by a bus) to send the project into such disarray that it would not be able to proceed.It's name is irreverent, but it focuses our attention on a very serious point. I've worked on many projects where it would have taken just one specific person in the team to have met an accident for the project to have stopped or slowly died due to the huge loss of knowledge.
"Getting hit by a bus" could take many different forms. This could be a person taking a new job, having a baby, changing their lifestyle or life status, or literally getting hit by a bus: the effect would be the same.
What is the Bus Factor of your team? What is the smallest group of people in your team whose loss would bring your project to its knees? Look around your team and ask yourself what would happen if each of them didn't come in to work tomorrow. If you find somebody whose disappearance would have a critical effect on your project then you've got a Bus Factor of 1, and you're at risk of big trouble.
The simplest means of improving (increasing) your Bus factor is to encourage sharing and collaboration amongst your team members. Share technical knowledge, and share knowledge of the activities in the team.
- Get a good spread of expertise
- Do peer reviews of code
- Don't encourage ownership of code. Expertise is good; ownership is bad
- Don't allow a name to be placed at the top of each piece of code
- If you don't have a daily stand-up meeting, you should at least have a weekly team meeting where everybody shares critical information
- If possible, have a weekly 20 minute presentation by a member of the team on something interesting they did last week. Make sure it's a different person every week, and everybody gets a turn
Are you dispensable?!