Have you faced this scenario ? There is a feature that is supposed to be enhanced — let’s say the Payments Module. The story is fairly complex, and involves lot’s of nuances that need to be considered in the payments module. Nobody really knows how it works, and is scared to touch the complex, dirty, and confusing code. Except the expert. This individual, let’s call him Mr. Payment Expert, had originally worked on the payments module along with another dev. Now the other dev has left, so he works on any changes that come on the payments module.
When it comes to story sign-up, it seems natural that he should pick up the payments module changes. Surely this is the best course of action?
Not at all! This, my friends, is an anti-pattern.
The Bus Factor
Consider what happens to the team if Mr. Payment Expert gets hit by a bus, and is hospitalised for a few weeks? The team would be in deep trouble. Nobody would know what to do with payments. Therefore, the bus factor of the team is really high.
The bus factor is a symptom of a Knowledge Silo. It tells us that there are pieces of knowledge that only 1–2 people in the team know, and that creates a big problem both ways. It is a problem for the individual, because they are forced to work on that feature when some work comes up in that feature. This way they are stuck, and are unable to learn about other parts of the system, nor are they able to switch teams to that amazing project they had been waiting for. It is a problem for the team, because nobody else is able to get context, and has to wait on Mr. Payment Expert to do the changes that need to be done. Mr. Payment Expert has become a bottleneck.
Sometimes, the knowledge silos get very painful. For example, there was a team which had a manual, complex, and untidy deployment process. Only one person knew how to do it. So they were stuck doing the deployment every time they had to go live, and everybody would have to wait on them, because they were now the bottleneck. This went on for years! Finally someone else started getting context, and helped automating almost everything. This saved time for the entire team, and brought major relief to the original deployment expert.
Ideally, the team should try to minimise this. There should be multiple people in every team who know about any one module or feature. So even if Payment Expert gets hit by a bus, the team should be carry on with minimum impact.
How to minimise the Bus Factor?
The only way to minimise ‘knowledge silos’ is by having multiple people gain knowledge of the part of the system where there is a knowledge silo . A few ways to achieve this —
- Pair Programming: Have Mr. Payment Expert pair with someone else on this story. Let the other person drive the story, ie. do all the typing. Mr. Payment Expert can be a guide just keep explaining what to do. Even if it slows things down, and requires spoon feeding, it is a small price to pay for what is achieved as a result — another person who now knows about the feature.
- Small enhancements done by others: Prioritise bugs / small enhancements in the Payments module just to help in context sharing. Other people in the team can take up these enhancements and get their code reviewed by Mr. Payment Expert. This way, multiple people get some context on the Payments module.
- Code Walkthrough: Every time someone works on something that nobody else has context of, get them to do a walkthrough of the changes they did, and why they chose the particular approach.
Conclusion
The Knowledge Silo seems like an insignificant anti-pattern, something that a team should find easy to avoid. However, it is very easy to fall prey to this anti-pattern, and the downsides are significant.
So every time you come across a complex feature on your team, see if your team is creating a knowledge silo, and work proactively to minimise it.
