Originally posted on my blog
If you were hit by a bus tomorrow (knock on wood) would your project get stuck?
I still remember when one I worked on did.
Well, I wasn't exactly hit by the bus, but from the project standpoint, it was close enough.
We worked on an important security change and I was the only dev assigned to the module. The job could be done within acceptable time frame by a single developer.
But I got keratitis (eye's cornea inflammation) and had to take three-weeks-long sick leave (with no option to work on the computer).
There was no developer to take over my tasks. When I got back the project was late. The new functionality was delivered on time only because we pulled quite serious overtime later on. It almost got me sick again.
The bus factor is the number of people on the team who have to be hit by a bus to get the project in serious trouble.
Take a look at your team.
Is there a person you can't complete the work without? Will you be able to function when the most experienced developer leaves or will you miss your commitments?
If the answer is, “Yikes! Without him/her we’d be dead in the water, your bus factor is one. Prepare for a project delay or sprint failure in the near future.
There is no quick fix or simple solution to the low bus factor.Implementing certain practices, though, will help:
Implementing some practices, however, will help:
- Work in a shared space and/or daily stand-upsÂ (communication gets better).
- Regular code reviews (ideally real-time) and pair programming (you share your knowledge about the module you work on).
- Test-driven development (if someoneÂ gets stuck, she/he can check the intent of the code in tests)
- Team focused on one project at a time (team focus shifts fromÂ specific specializations (such as “being the SQL guy”) to how to work together to deliver a specific set of changes)