The "bus factor" is a measure of a project, the term holds the question "what would happen if someone on the team (specific or not) is hit by a bus?". Will the project go on as usual, barely survive, or is there knowledge that is compartmentalized in such a way that if you take someone down everything will come crashing down?
On our team, despite daily scrum meetings, we feel that once tasks are assigned people on the team can't easily take over for a member who was run over (or went on vacation, for that matter).
How do you keep up your bus factor?
Do you?
Nice Tips?
Share it all!
Top comments (5)
Are you doing a lot of peer-to-peer code reviews? This will give everyone exposure, if not more in-depth, knowledge of each other's code. You could use XP style pairing or a variation of it if you wanted to take it a bit further. The good side effect of frequent code reviews is that it also will prevent one or more developers from getting "Gollum Syndrome" where they start calling their code "Precious" and won't let other people see or touch it.
Do you have design documentation? Of course, nobody likes documenting, especially something really formal, but it really doesn't have to be terribly complex. It could just be a white board session discussing the design of particular modules, recorded on video or even just snapshots. Make this a living set of documents by putting it in your version control system.
Do you have designated backups for each task? This could be handled by the pairing mentioned above but you can still designated backups even if you don't do pairing. Just having someone who knows a little something about the other person's code can go a long way. Even if they can't fully take over in the event of a problem, they would be able to help get a new team member up to speed quickly.
Great tips
A few tactics:
Keep a glossary. Everyones needs to be speaking the same language. Make sure everybody is using one name for specific features, patterns, ideas, etc. Reducing conceptual debt is crucial.
Capture the "whys" of all major decisions. It is much easier to pick up where someone left off if you understand the rationale behind the decisions they have made. It let's you reframe the problem from their perspective and inhibits new folks from bikeshedding or exploring already-solved problems.
Create tickets for everything, with explicit "Definitions of Done." I always try to create tickets for every task - partially because I'm forgetful, but mostly because it creates visibility and accountability. Don't define how something should be done step-by-step, instead detail exactly what the expected outputs are, with zero ambiguity. It takes time and care to create the tickets, but you make up for it by removing confusion and ambiguity.
Your concern is legitimate. Liked it
I think for critical work cases, we can apply the parity rule, so that team members are synchronized.
Define a pairing scale, that is, schedule the people who will be part of the partnership, always keeping one constant (the person responsible for a certain subject).
The daily scrum also helps in synchronizing day to day activities. I believe communication could be improved on the daily scrum.
See the article I recently published about the most common errors in the daily scrum.
tfsolucoes-tecnologicas.com/14-com...
Maybe your team is experiencing one of these problems.
Hope this helps.
I wrote a series of articles on the topic. You can check it here.
Here are the few points that seem important to me in the end: