Bus factor (Requiem for my team)

You may have heard of the “bus factor”. For those who have not, the bus factor is a measurement of risk: “The minimum number of team members who need to be hit by a bus before the project stalls”. It’s sometimes called the “lottery factor” by people who would prefer to phrase things in a more positive way.

What is your team’s bus factor? Ideally, you should have an answer like this: “90% of the team would need to disappear to put the project on hold, but if new people with similar skillsets were to join the team — we could go back to the same rate of output within a week or two”. This sounds amazing, but is it achievable? I believe it is!

Let’s look at two teams: team A and team B. Both of those teams have the same number of people with the same skills: four developers, one lead developer or tech lead, one QA, one ops, one BA, one DL and one product person. Both teams perform all the usual Agile rituals; they keep visibility of their work on a wall, which they gather around each morning. They have a feedback/therapy session every second week called a ‘retrospective’. They begin each piece of work with a kick-off. Developers normally work in pairs on the tasks, not because they are hesitant to work on their own, but because they like to engage in philosophical conversation while their code is building or deploying.

One day one developer in each of the teams is sick, maybe because they were all hanging out together in a bar the night before. During stand-up in team B, the delivery lead says: “Bob is ill today, but Steve was paired with him yesterday. Steve, can you continue and do you need another partner? ”

Steve answers: “I have no idea what state it is in, everything was on Bob’s laptop. I left early yesterday. We should wait until he is back, I will work on something else”.

DL gets very upset, because all of the important tasks at this stage in the backlog can only be done sequentially and says: “Ok, looks like we’ll have to put more people on it and start this task from the beginning”.

There is the same situation in team A, but team-A-Steve answers differently: “Yes, I would like a partner. Everything that we did yesterday is on the branch/fork, we’ve done 40% of the scope and I’m happy to continue to work on it with someone; everyone was present at the kick-off and the scope is documented”.

No stress, no drama. Same situation, but different outcomes.

Now, a second scenario: two developers, both working on the same card, got sick on the same day because they kept hanging out at that same bar. The stand-up conversation in team B the next day runs something like:

DL: “So, Bob and Steve are sick, can somebody pick up their work?”

Barbara says: “I have no idea what those two were working on, the card has no details on where the code is or even what they decided to build, so I will need to start this again from the beginning.”

There is the same situation in team A, but Barbara answers : “Oh, I can pick this up. I was present at the kick-off, and the git issue has all the information about the scope, codebases and people involved. Plus there should be commits on the branch with the progress”. No stress, no drama.

Let’s imagine now that the QAs from both teams were hanging out with the developers in that same dodgy bar. The next morning, the conversation in team B starts like this: “Ok, team we have few things ready for testing today, unfortunately our QA Jack got sick as well. Who can check the cards?”

Team B answers: “Oh, we have no idea what Jack was doing, he didn’t leave any comments on the card. We aren’t sure exactly what needs to be checked, nor what Bob and Steve did on it before their handed over to Jack”.

Team A answers differently: “Anyone can check it, all the cards have a test strategy and a scope properly documented, and Jack was present at kick-off”. Again, no stress and no drama.

Now, you probably want to ask: “What is going on in that bar? Why does everyone who enters it get sick the next day?!” But a better question to ask is: “Why are team A and B in the same company are so different ?” I’ve worked in B-teams at REA before. Hopefully these days, the majority of teams have their bus factor closer to that of team A, but not all. Some teams may say: ”We can lose 40% of developers, but if this one ops person or tech lead disappears — we are in big trouble!” So, can all B-teams become A-teams? Sure they can!

For a moment, imagine that every month one person will leave your team and one new person will join. For example, one month it might be a developer who swaps out, next month QA or BA etc. With constant change in my company we can easily predict that in two years’ time the project that you are working on will be supported by a totally different team, if it exists at all. Now, let’s think of the processes that we can set up in the team knowing that every month a random person on the team will be swapped. In that situation, the importance of efficient communication and documentation becomes obvious. You would also probably have some set of basic rules that everyone knows and follows like: Push your code on the branch at the end of the day, do kickoffs for cards and document the outcomes, work in pairs, have a clear rule on priority of the tasks.

Now let`s imagine that your whole team is re-shuffled and distributed to other projects, as recently happened with my team. All of those systems and delivery plans are other teams’ responsibilities now. Because my team was an A-team, the best team ever and because I feel very sad about the re-shuffle, let me write a little bit more about how awesome my team was.

The beauty of working on an A-team was that for the last year I experienced the lowest amount of stress I’ve ever felt at work while delivering great products with the latest tech stacks. We were constantly learning and improving our processes and having a lot of fun, our happiness index was consistently high. Because of continuous pairing I could have vacations and stay at home when feeling sick, knowing that my team would pick up any on-going tasks without delay. We were very autonomous, our process of making team decisions was very democratic and anyone could facilitate a healthy discussion about architecture and implementation details.

I hope that there are more teams like mine used to be, but unfortunately B-teams still exist. I am encouraging every team to think about its bus factor and ways to improve it. Think about bottlenecks and communication problems, they can all be eliminated with effective processes and delivery practices.

P.S: Big thanks to Erica Smith and Michael Vigilante for editing effort.