I spoke before on this blog about BUS FACTORS and how to get rid of them. A bus factor is calculated the the amount of people on your team or project who need to get hit by a bus before the project comes to a halt. There is something that only THEY know how to do.
I am revisiting this because there are many ways to get rid of it. Today I cover a couple. But first, a true story.
In one of the projects I was consulting for a few years back, we had four teams and many bus factors relating to many things. One of them was related to the search technology the project was using at the time (sharepoint search…shudder!)
One day I saw the architect* running around like a headless chicken trying to figure out how to fix a problem. I asked him what’s wrong and he said “the search guy is out on vacation this week and not answering his phone. I have no idea how to fix this”.
It took a couple of hours until he found an external company that once provided these services to the project, and got them on the phone to ask if they knew how to fix this problem. Of course they did. They coached him on the phone what to type to reset some indexes.
I was sitting in the next seat listening to him typing word by word into the terminal, pressing enter, and then saying “ok now it works thanks”.
Then he hung up.
What a great loss of knowledge! Instead of using the opportunity to LEARN something about the problem, its causes and WHY what he typed fixed it, he simply made himself a remote controlled robot for the person on the other side of the phone.
I coached him to do the following next time:
When you find the situation has been solved, ask the following questions on the phone:
What I coached him to do was what I call “PULL Based Learning”. Before I discuss that, let’s talk about why it is important to learn this pattern.
One of the best ways to remove bus factors, is by pairing. Pairing is an act of active learning where knowledge is constantly back and forth. A person asks a question “How did you do that?” . that is an act of deliberate learning.
But pairing is also hard to achieve in a culture where pairing was never a “thing” people do. If you cannot get enough people to pair, or the bus factor is happening when a person from a DIFFERENT team knows something that your team replies on, it’s time to start encouraging active knowledge gathering, or active learning.
Active learning comes in two forms, or two directions:
So pulling or pushing depends on who initiated the knowledge transfer. If you find that you have many bus factors, it is important that you teach and coach people how to work in BOTH directions:
This also means you might need to get an upper level manager to send an email or have a group meeting letting all developers know that “it is OK to do pairing, ask for help, request someone to join you to learn new things – even if it means tasks take longer than estimated. it is OK to estimate tasks longer because you want to build these things into your iterations”.
In cultures where hierarchy matters a lot, this could be the beginning of the breakthrough you might be looking for – giving people permission to learn and teach is usually the thing most cited (by people I ask) as the reason why they are not doing it.
Having only a single direction knowledge sharing culture is very ineffective.
In a project full of consultants, who love teaching, but also full of people who hate learning, knowledge will not be shared very often, and if so, with a tea spoon instead of a fire hose (which is usually what you need to start with in extreme cases)
In a project full of people wanting to learn, but having all the people with the knowledge be in a different building, company or country, mostly unavailable, knowledge will not be shared.
There has to be a knowledge HANDSHAKE for knowledge to actually flow through. otherwise we are talking about tear drops in the ocean.
* Remember that having a non coaching architect is having a bottleneck
** Maybe you should think about increasing the amount of opportunities?