Have you ever heard of Bus Factor?
Once you have an established Agile team, Bus factor can slowly creep in. But how do you overcome it? And what is it?
Bus Factor (sometimes also called truck factor) is an easy concept to understand, imagine in your scrum team one member was to suddenly leave the team indefinitely, and they cannot be contacted, imagine if you like that they have been hit by a bus/truck (hence the term bus factor). Let’s also say that this person that has left them team, coded/designed 70% of the project’s core code alone, and did not document any of it. How would the team react?
“Can other staff pick up and do that person’s job, or will that work have to be relearned and/or restarted? This is the person’s “bus factor”: how much their absence would adversely affect the operations of the organization. The greater the risk of their missing, the higher their bus factor.” — What’s your “Bus Factor”? — Effectivedatabase.com
There are some really easy techniques to reduce a project’s bus factor;
Regular Team Meetings / Communication
This is common sense, within the agile scrum methodology you tend to have a quick stand up each day, during this meeting each developer describes what they done yesterday, what they are doing today and anything that is blocking them from completing their current story/task. Ensuring you have regular team meetings and each member of the team contributes ensure everyone in the team knows what component everyone in the team is working or waiting on.
Peer Review and Comment Code
In the team I am currently working in, after I have completed a story on the agile board, I create a pull request for my branch (we employ a one branch per story technique), at this stage I demonstrate my code and another team member will review my code. This mechanism gives team members the opportunity to comment on my code, and provide any suggestions/changes that could provide either simplicity or efficiency to my code. This also allows team members to become familiar with new features as they are written.
Pair Programming
“Promiscuous pair programming is a good way to distribute critical knowledge around a team so that the truck number is as high as possible. If you don’t swap pairs often and with many different team members, knowledge isn’t distributed very quickly” — JeffH, Is it truck factor or bus factor? — StackOverflow
Simplicity
Keep any project administration simple, for instance allow all team members to have admin access to the git repository, continuous integration server and agile board. Try to BCC team members into client communication.Thismeans should the unfortunate happen, the project can continue.
