“Bus factor” means that we have a project that only one or few people know how to develop or maintain. If these people are run over by a bus and need to take some days off, a project would get stuck. Avoiding the bus factor saves us time in the future. 

Here are some good practices for avoiding the “Bus Factor”

 

Calculate your “Bus Factor”

 

Start with the question “What is the minimum number of people that, if absent, would prevent work from continuing?” The factor of the bus is the number of people on board on which the success of your movement forward depends. If work could not continue with the absence of just one specific key person, you have a bus factor of 1. The higher the bus factor means you can continue working without dependence of on specific people.

 

Distribute all the knowledge among team members 

 

Responsibility Rotation is a good method which will spread the knowledge among the team members. Task and responsibility rotation should happen on a daily/weekly basis, to make sure that all team members are in-sync and can take over if needed. 

 

Document all processes and keep them up-to-date

 

Process documentation and reducing complexity of workflows can help to raise your bus factor. Documenting your standard operating procedures lets you lay out instructions for exactly how duties should be performed. If a task needs doing more than once, it pays to write a process for how to complete it. If your documentation is good enough, your bus factor should no longer be an issue for recurring tasks.

Team Visibility matters 

 

Following a visible software development lifecycle doesn’t just save time, but it also helps the team to find errors collectively. A visual tool can help the team not only to create, but also organize their work and gain better visibility. You have a visibility, now what? Visibility is a simple concept. However, it’s difficult to achieve. Once you have utilized tools to gain visibility, you can identify gaps and prioritize the right work.  

The value of a Complimentary team 

 

Teams are more likely to have skill sets that complement one another, making up for shortfalls in any one individual. Being able to position members with cross-functional competencies within the team is one of the critical issues for DevOps transformation processes. It is nearly impossible that each member will have every competency needed at the top level. The best approach is to ensure that all team members have a basic level of knowledge on different topics, as well as complementary areas of expertise. 

How are we dealing with the “Bus Factor” 

 

How do we make sure that our clients are protected if some of the team members working on their project is leaving the company or going on a sick leave? At Zetta systems, we protect our clients and partners by providing DevOps/SRE/SecОps as a service and increasing the “Bus factor”. We make sure our engineers are onboarded properly and no less than 5 people work on a project even if there is work only for 1 or 2 of them. The result of this strategy for our clients is more people working on their project without affecting the initial price agreement. With a proper knowledge transferring and regular rotation we make sure that no knowledge will be lost in case someone leaves and the performance will not be affected.