Your Scrum team is made up of six individuals carrying out a critical project for the organization and each week you deliver an increment. The current sprint is the 10th one, and today is Wednesday. You have to deliver a major version before the weekend. You can feel the stress getting higher and higher since there are an important number of items to complete. At the end of the day, everyone is reassured; even if an additional effort has been necessary. You are confident that tomorrow you’ll have time to do what is remaining.
Thursday morning, there is a bad news: both Jean and Jacques are sick. They will be absent from work. However, their skills and presence are essential to carry out the last tasks required to deliver the newest edition of the software application. Thus, the sprint goal will not be achieved, and the client will not be particularly happy.
Does it sound familiar? Does the absence of your colleagues compromise your projects? If so, to what extent? Does success lay on all team members? Do you take the bus? Why?
The Bus Factor (also Truck Factor or any other vehicle) is a term used in software development, and I think we should talk about it more often. Whether we are very Agile or not, it concerns everyone.
Think about the context in which you are currently working. What are the consequences of any unforeseen situations on your environment, project, or processes that compromise your work or that of your colleagues when they occur? Imagine that your team is traveling by bus and they have an accident. Result: many of your teammates are no longer able to carry out their activities for days, weeks, or even months. The Bus Factor is the maximum number of team members that, when absent, compromises the viability of the project.
For you, what does the factor amount to? 1, 5, 10…? If the number is low, it is bad news! And even worse when we talk about small-size teams…
Jacques is the database administrator with full powers. Jean is the team’s unique computer graphics designer. They are experts in their own field, and the team depends on them on a daily basis to put across the project. Their teammates appreciate them, and they currently cannot accomplish Jacques and Jean’s tasks nor acquire the same skills. What is the Bus Factor of the team?
Two? Nope! One; yep! The absence of one of these two team members is enough to interrupt the team’s progress. Two would be a valid answer if these two individuals could replace one another.
Who are your pillars, your champions? They are easy to identify given their skills, their level of expertise, and the unique permissions they have in the team. The objective is not to do without them, but not to depend on them; thus, to increase the Bus Factor.
Reducing risks and their impact
It is far-fetched to wish that everyone in the team may carry out any task required for the project. Without having a team filled with non-specialists, promoting pluridisciplinarity, disseminating knowledge, and sharing different hats between team members greatly reduce the impact of the Bus Factor, no matter the level of expertise.
Here are great ways to arouse curiosity and consider new paths: develop new secondary skills, share one’s knowledge via different supports such as wikis, and organize pair programming or mob programming sessions alternately acting as navigator and driver.
Similarly, if skills are lacking in your team or if it is difficult to share them sustainably, training is a good investment on the long term. While it can increase the Bus Factor on the short term, training can be given to any team member who is available, less solicited.
The team is best suited to determine what they have to execute as well as how to do it to achieve desired results. It is counterproductive to force them to take part in numerous time-consuming meetings. Since it is short and limited, the daily scrum meeting allows the team to get feedback on their synergy and progress as well as to develop effective short-term action plans, no matter the context.
Do not refrain from sharing information! Way too often, valuable information is known by only one individual, which can compromise the work of one or several contributors! Make information visible; do not bridle communication.
Secure the team
This one is not easy. Team efficiency depends on the availability of their members and their assignment to a single project. However, is it the case? What do you do to protect your team from any external disturbance and solicitation disrupting the project?
Not only it is impossible to immunize the members of your team against the flu, fatigue, accidents…, but there also are impediments at work (e.g., “meetingitis”, hardware problems, administrative procedures and access policies). Make a list and perfect their resolution process. Unfortunately, there is nothing you can do regarding traffic problems!
At last, flexible work hours and a flexible organization could be great solutions to offset the factor on an individual basis. Being absent from the office does not necessarily mean incapacity to work nor non-productivity. If one of your colleagues is forced to stay home, the communication channels are still open. It could be the perfect time to consider remote participation if both parties agree. Working from home allows to prevent certain external solicitations; therefore, it increases efficiency.
Because recruitment is pricey and increases complexity, seeking for new members and welcoming them in the team should only be considered if none of the solutions above are feasible or beneficial. Furthermore, it is important to know that it would only superficially increase the Bus Factor of 1 for a critical skill.
What do the others think about the idea of recruiting a new team member? What if he-she does not like his-her new job and leaves the team before the end of the project? You should measure the impact of your decision on the medium and long term.
Therefore, which indicators were lit on your dashboard while reading this blog post? How do you envisage to react? Is your seatbelt properly fastened?
Enjoy the road!