From wikipedia, a “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
From my personal experience, I'd say that more than 70% of projects suffer from a bus factor of 1. It only takes one specific person in those teams to not be able to be there for the project to halt or slowly die in painful agony as people try to makeup for lost knowledge.
How do you recognize the bus factor?
in your mind, go through each person in your team and ask yourself if
the project could go on pretty much as usual if they were fired tomorrow. (fired is important because people who leave in good terms can still play ball and get you through tough stuff they worked on through phone conversations).
If you say “no” or even hesitate about the answer, you’ve found the bus factor in your team.
How do you get rid of the bus factor?
Most of the collaboration techniques you’ll find in many agile methodologies like XP try to solve the idea of the bus factor, but you don’t have to be agile to use those techniques.
- Use daily standups to share critical information
- program in pairs every once in a while, or at least on key components of the system
- do code reviews on every piece of code that gets checked in
- do weekly half hour or one hour presentations by team members about interesting stuff they did this week
- Ask the bus factor carrier to teach someone else from the team to do their work and vice versa. Tell them that next week they will be working alone on that material so they should get ready for that by working together on it.
The biggest bus factor is you
As a team leader, you might just be the biggest bus factor carrier of them all. What happens if you get fired tomorrow? can the team go on without you?
Your biggest challenge as a team lead, over a long period of time would be to make yourself dispensable – to make the team mature enough to continue on day to day things without needing you. Removing yourself as a bottleneck is one of the best things you can do for yourself and your team.
this is one of the reasons why in scrum we have a SM and a PO. Yes their role is different, if they are a good pair, they could temporary take over each others positions.
It does not make the bus (or truck as I know it) factor == 2. But at least to higher then 1.
That is also why it is good to be away to conferences from time to time, your team learn's to deal with a SM / PO who is absent.
And again, why don't i want the job security of being the "bus factor"?
In this day and age where redundancies in IT are common (offshoring to India etc), I would much prefer to have the bus factor and make myself more valuable to the employer.
It's dog eat dog out there so I'm afraid I don't agree with your article on a personal level, but to better the team i can see your point.
I want to keep my job!
In my experience, the reason so many projects have a bus factor of 1 is that most projects only have one good developer with the rest being medicore. No amount of pairing or code standups will make those so-so programmers become good. As soon as one other good developer is added to the project the bus factor is halved.
@Pepe. Exactly, it's about skill+knowledge, not just knowledge. But programming is not the only relevant skill. How many people on a typical team can produce pleasing UIs, or readable manuals, or efficient and non-brittle tests, or team motivation?
@Jake, @Lygpt, I won't be hiring you today as I'm looking for developers who can collaborate and share ideas to produce a better project. I'm also looking for people who can grow the team around them so that I can move them to new, more challenging positions where they belong. Anyway, thanks very much for your time today and good look in the future!
Ivan
I'm a new team leader and my project suffer from a bus factor but he is in India (because of the offshoring).
How do you process, when your deadlines are so close that you hardly have enough time to implement the new functionalities ?
This is worth responding to, even 8 years late, because it is a timeless problem.
Any organization that wants to mitigate its risk is going to add a bit of knowledge transfer time to the project. "Knowledge transfer" here must include a mandate for proper documentation. Data structures must be specified, protocols (especially) must be specified, and basic system behavior (as observed from the outside) must be specified.
That takes a little bit of time, but not anywhere near as much time as recovering from the knowledge loss if a critical team member is lost in the middle of the project. Coding style also comes into play -- if you're working in a language with type annotations, are they actually being written? If there are in-code documentation features available, are they being used? etc. These sort of issues must be a required talking point that is covered during code reviews or else your team is very likely creating write-only code -- and that's not usually in the project's best interest.
As for the core issue here -- time pressure... Time pressure and offshoring go hand-in-hand, and usually in the worst sort of way. Offshored code is, so far in my experience, 100% write-only code and nearly impossible to verify or modify (if it even comes close to what you required in the first place). Offshoring sounds nice if you have never coded before, but in reality while there are many great remote coders who happen to be located literally "off shore", the goal of sourcing an offshore coder should be really to find a good team member rather than find a cheap code monkey.
A really good team member will strive to document things and render their own loss survivable, no matter where they happen to live.
In the best case your project will hold itself to a standard that requires enough documentation about the project exist that if everyone on the project were to die tomorrow, aliens could come along in a million years, read your docs, and implement your project with no help from anyone on the team. That takes time, and requires its own time budget. If your business stakeholders have NOT set aside the time required for this, then they are taking a risk. It is our job as engineers to inform them of this risk, and help them quantify it so they can make a business decision about it, because documentation HAS business value -- specifically, the risk-mitigation sort of business value.