DevOps keeps the bus factor high (and the leather pants factor low!)

A while back, I wrote an ebook to help people work on the one part of the DevOps puzzle you can't buy, outsource, or ignore - the DevOps mindset. During my research, I found an idea that really made me laugh  - even though it probably shouldn't. It was in the middle of coronavirus lockdown though, so I have my excuses.

That idea was the bus factor. 

The bus factor - variously known as the truck factor or the lorry factor - is a scenario or set of circumstances that are best avoided if you're part of a team. The idea is closely linked to redundancy, but in this case, the desired redundancy is people and not machines. 

If you have a team where everyone has a job, but only one person knows how to do a specific job, then the absence of one team member will bring the whole team to its knees. This is the epitome of a single point of failure, and something that should be avoided at all times.

In case you're wondering where the term the bus factor comes from, we explained it in Plan Now, Win Later:

How do you calculate the bus factor?

Luckily, you won't need any complex calculations or audits for this one. Simply take the project in question and figure out how many people need to be absent before work cannot continue. If that's just one, then you have a bus factor of 1 - and that's a dangerous thing. If it's more like 3 or 4, then you're doing pretty well!

Why should you fear a low bus factor?

Think of the bus factor as one of the many canaries in the mineshaft that will alert you to the presence of unhealthy organizational patterns in your team. Since one of the mainstays of DevOps is butter-smooth organization and progress, you can see why the bus factor is something you want to increase.  

We've also got a bit of bad news. Dysfunctional organizational traits rarely happen in isolation, so if you realize that you've got a terrible bus factor then there's a real risk that you've got other problems too.

Like what?

Well, are you sure you don't have a department of pingpong players? Definite that the Ikea factor, loss aversion, and the sunk cost fallacy aren't swaying your teams' actions? If you see one, check for others - this article is a good place to start.

Close, but no banana

Until now, we've really been looking at the traditional bus factor - the single person of failure. There are more variations of the problem, however.

The hero complex

The hero complex is, once more, a single person of failure, but the difference here is that rather than the professional skills they bring to the job, it's the integral role they play in the way the team thinks and acts. Very often, this person is known as "the rockstar" and, just like leather pants, that's not a good thing.

The rockstar might not be the only person who can do a job, but they are the single person that the rest of the team rely on, turn to, and trust. When they're absent, the team loses its mettle and direction, and ends up almost as useless as one that is missing its main dev.

Look in the weeds

Ok, so far we've looked at the problems a missing person might cause, but that's because that specific person and their knowledge, experience, or personality is missing. But it can also cause serious problems when the absence of a person means more mundane things. If John goes MIA, you might not miss his mediocre coding skills, but that essential password, missing 2FA, or release approval will bring your team to a halt nonetheless. 

How to prevent a low bus factor

Ok, now that we've thoroughly scared you, you may want to know what specific aspect of DevOps thinking might protect you? Well, the number one thing that will protect you from this chaos is...cross project collaboration!

Cross project collaboration 

Easy in theory, hard in practice, this is essentially what DevOps is all about, except instead of breaking down silos between developers and ops engineers, you'll most likely be breaking down the silos between devs and..other devs.

This kind of bus factor often rears its head in smaller teams, where there is only one frontend person, one Android developer, and one iOS developer, for example. When Daria the frontend dev gets run over by a bus, there is no more frontend for a while. If there's no contingency plan, that will hobble your app completely.

Now, it's true that Daria has been hired for her expertise in frontend development, and it makes sense that she's especially skilled at it. That said, ensuring the whole team can at least manage the basics across the stack means that easy tasks and jobs can keep moving, preventing a massive backlog from developing in Daria's absence.

So, this is fine in theory, but how to you ensure that your whole team has full stack experience in practice? Some teams are actually quite resistant to the process, while others are open but don't exactly know where to start.

Here's our best advice:

Get buy in

You'll be fighting a losing battle if your team is completely against the idea of working across the stack. Hopefully some bus factor disasters of their own will be enough to convince them to make a change, but if not, go slowly and try to lead by example, rather than pushing them in head-first. 

Reduce barrier to entry

Make sure that across all projects, you've made it as easy as possible to get started. This can mean taking a look at the technical set-up and making sure it's very smooth, ensuring documentation is up-to-date and relevant, and generally keeping everything as simple as possible.

Lead by example

Obviously, you can help by leading by example and lending a hand where needed - just bear in mind that you can set all the examples you like, but if the practical things aren't in place, you'll be fighting a losing battle. 

Dedicate time to other people's projects

There are various ways to approach this, but the most popular way is usually peer or group programming. Remember, at the start there's no need to be doing anything heroic with the code - just take the opportunity to fix a bug or get familiar with new code. Once people are situated and have set themselves up as they need, they'll find it much easier to go forward alone.

Reassign people to better distribute power

If you've detected a bout of hero worship on your team, consider redistributing your rockstar - or the people around her - to make it harder to rely on her for wisdom, leadership, or inspiration. People will soon see they can rely on their own judgement quite nicely.

Automation is your friend

Less a practical tip and more a general reminder about automation, once you have solid automation in place (helped by a tool like Cycloid, for example), the bus factor becomes much less threatening. Once it's in place, you won't need your rockstar - or Bob, John, or Daria - to ensure the job gets done.

Summing up

There's one overarching message you should take from this article - cross project collaboration is key. It's important in the world of DevOps, important in resilient tech teams, and key when it comes to increasing your bus factor.

Whether your bus factor is acceptable or not, get started on encouraging your team to get some cross-stack skills. Even if you've already got them, cross-project collaboration is an active initiative that needs to be nurtured, and this might be the perfect time to take another look.

Join 2,935 other proactive DevOps fans by signing up to the Cycloid quarterly newsletter.