The bus factor


After being gone for some time I will start with a light management post 🙂

So let’s get going.

First we have to find out what the bus factor is. According to Wikipedia the bus factor is:

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.

So basically the higher the bus factor of your project the better.

Regarding this little project metric there are two question that arise:

  1. How to determine the bus factor
  2. How to raise the bus factor

How to determine the bus factor

First we have to clarify that the bus factor is a subjective measurement and therefore does not lend itself to monitoring. But regardless of that the measurement is quite useful to point out problems in your team.

So if you want to know the bus factor you just have to ask yourself the following simple question for every team member:

Could the project continue if he got hit by a bus?

The more yes-es you have the better 🙂

It is quite impossible to put a general rule of how high the bus factor should be because it depends on to many factors. Personally think that 50% of your project team but not less than 2 is a good number. But that is just my personal impression.

But regardless of my opinion if your bus factor is 1 (one) then you are clearly doing something wrong!

How to raise the bus factor

If you have come to be in the situation that your bus factor is a little to low for comfort then your goal should be to get the factor up.

Basically it all comes down to increasing communication in the team. In a software project communication is everything! If your team members are not communicating you as a manager have weary few options left in your repertoire of management tricks.

To get this clearly out of the room. My personal opinion is that if a team does not harmonize then the irritating factor should be removed from the team. It makes no sense to let four people suffer because one can not drop his ego.

All that you as a manager can do is to provide a platform for the individual team members to communicate. These include:

  • Organize daily standup meeting where the whole team can get together and discuss what has been done since the last meeting
  • Organize extra budget to do pair programming
  • Organize code review session with all team members (this will do wanders for your project in more than just one way)
  • Identify the person which has the highest knowledge accumulation and persuade him to share that knowledge

The last point is the hardest to do. Depending on the organizational atmosphere this is almost impossible to do. In some firm a developers salary is dependent on their inexpendability. In such an environment the developer will actively refuse to share his “knowledge” and to be honest I can understand him. Why should I endanger my position in the company and risk a lover pay or ever being fired later on? It is the job of the manager to answer this question and give reassurance (real reassurance and not just the moral one).

The biggest bus factor is you

If you manage a project you are the biggest bus factor! You are the manager! You keep the company from the development team to give them time to actually do their job. If you become “unavailable” then the project team has to do all of your tasks plus their own.

Do not underestimate what you do for the team. I am a developer but I know what a project manager does. All the little tasks that the development team does not like to do:

  • Managing timeliness
  • Communication with other development team
  • Reporting to upper management
  • Getting the developers what they need to do their jobs (from paper clips to that component from the other team)

So you have to find a way to take yourself out of the equation. There are a few ways that you can do that:

  • Have a deputy at hand
  • Tell the team what you are doing
  • Keep a public list of all your communication contacts (who from the aurora project time have you been communication with)
  • Make all documentation that you have created accessible to the team

Conclusion

I hope that you have gotten a sense of the importance of the bus factor. It is something that you will not be able to include in your annual project progress report but is something that is worth keeping an eye on.

You newer know when a bus driver will fall asleep.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s