A monster is in town and brought mayhem upon this cursed land! Fire-breathing, sulfur-spitting and peasant-munching it’s marauding through forests, villages and even cities. But fear not as there is a hero in shining armor, well suited for every encounter. This hero will free us all from that beast, riding as fast as the wind and striking as hard as a thousand human beings. The blow will be deadly for the monstrosity. It’ll tumble and break as we’re free again - waving behind our saviour, as we’re unable to help and save ourselfs…

What reads like a rather cheesy plot can be a huge problem when creating software. Whenever a project is being worked on, there might arrive the time when the things learn to fly. A lot is happening, a lot is being developed and maybe every member of a team is becoming an expert on a specific field of knowledge. This is when the bus factor comes into play. The bus factor determines how many people could leave the team before then project is in danger - the higher the bus factor the better. If a lot of people are busy or even caught inside the resource utilization trap), knowledge might not be passed down as it’s supposed to be and - more important - healthy for the project. This can also lead to the formation of heroes. Heroes are people who appear to be able to solve even the hardest problems in very little time. When things go south, heroes jump in and get the systems running again. Sounds great, eh?

Sadly, it’s not.. This role is the avatar of a bus factor of one - if this hero is on vacation, ill or even leaves the company, hell can break loose. But not only can heroes be a sign of potential problems in the architecture and/or management, they’re also a high, strong tower filled to the roof with large books of knowledge. Some of these towers try to keep knowledge for themselves to ensure their position and power - if this is the case, we’re dealing with a fully blown dysfunction. But there are also those who like to share their knowledge, and even lead as some kind of lighthouse of wisdom. But again, are several problems with that, e.g. is the lighthouse only able to transport a specific amount of knowledge at any given time and, more importantly, it’s only one tower with strong walls and when it burns down, every last bit of not yet shared knowledge is lost. So the books of wisdom must be copied, which takes time and an awful lot of effort and time.

Keeping the bus factor high is a huge deal in software development projects. Especially if there is a lot of work to do. To ensure every topic being able to be solved even if the person working on is away, it’s really useful to share knowledge. This can happen via pair programming, good documentation, a great agile culture and comprehensive Daily Scrum meetings. But why stop there? Share your knowledge in bite-sized chunks and often, very often - not only with one, but with at least two people in your team, rotate them if possible. This ensures that every task can be dealt with, even if you’re sick or on leave. If two additional people know about every topic, there a good chance that nearly no information is lost because everyone remembers (or forgets) different things. You’re the head of your task, but if your head is not there, two more heads are there to show up.

Backup is key. Defeat your heroes using the hydra, growing two sources of knowledge from every source put in.