Sharing is Caring: Techniques for Overcoming Knowledge Silos in Software Development

One of the most common problems in software development is the unconscious creation of a treasury of knowledge and decision-maker in the form of one person. This can be a developer, architect, manager, or any other role without whom we cannot move on:

• PRs are blocked because this guy has to approve it
• No one can work in the concrete area because only John knows it
• New deployment cannot be released because only Mark can approve it
• The decision of where to go has to wait 3 weeks because Susan is on holidays
• Do not touch it! There was one guy 2 years ago who knew about it but he does not work here anymore. It somehow works! And now we pray that it does not break.
• and so on

All of the above is usually caused by mistakes that we do as a team (except when someone has a huge ego – fortunately this is a rare case). How to avoid it? What actions to take to share the knowledge with the entire team? Based on:

• My experience – as a software developer, tech lead, and/or architect
• Teams that I had the pleasure to work with (and which have continuously developed – it was not always great at the beginning)
• Teams in which I have seen problems from outside as a consultant or just an observer
• General observations

I divide the solution into 5 areas that I think are the most important – there is more to be defined but that’s a topic for a book 🙂

Swarming

Quite often I have encountered the following approach in teams that I have worked in or observed:

• There are several user stories and tasks in the backlog to be implemented (does not matter if it was Kanban, Scrum, Scrumban, or XP)
• Each developer takes 1 of these
• Starts working on it
• The amount of work starts growing and the person is overwhelmed – whenever I do the analysis alone, it is never that accurate when done with more devs and then the real work is more than expected
• The developer is alone with his problems – of course, he might ask for help but this will be a side job for someone else, usually without full focus
• When the feature or task is ready, then it is reviewed – if the branch was not split into multiple smaller ones, then both the author and reviewer are demotivated (more in the section of short-living branches) because there are several ping-pong rounds ahead of them
• There are a lot of opened user stories and tasks but almost none is finished

The solution to reducing the above impact is to invite other people to work on the user story or task. Let’s look at this definition:

Swarming is where an entire team looks at the same feature and works on it together by splitting and parallelizing the work

Should the entire team be involved in just one item or is an “item team” defined? From my observation, it worked best with at least 3 people involved (if there are only 2 guys where 1 has very strong skills, another might be biased) – this way if you have more people in the development team, they can be shifted towards other features. However, I do not set a maximum – if you decide to involve all 6 folks and there is plenty of room in the user story or task to divide it and parallelize the work, then why not.

How such a split could look like?

The first guy prepares domain logic, another API, and the third infrastructure. This way you have 3 people fully involved in delivering the feature – quick code reviews, deep discussions about possible solutions, problems, and so on. The knowledge is somehow shared through collaboration on one item.

Great. Is it? No, it can be far more optimized!

Pair & mob programming

This brings us to my favorite point – if you want to share the knowledge, do it just in time (JIT)! What does it mean? To not wait with the code and explanation until the creation of PR, you can share it with one or more people while writing it. Let’s look at the definitions:

Pair programming is where two people looks at the same feature, its code and works on it together by sharing the same machine

Mob programming is where an entire team looks at the same feature, its code and works on it together by sharing the same machine

If you take a closer look, you will see that both are about programming in a group of people (2 or more) while focusing on one area and using one machine – one guy writes the code and the others think and look at it (you switch the “coder” from time to time). Nowadays, when most of the development is done remotely, you can use features like Live Share or Duckly in your IDE – this way you do not need to share one machine (btw. who likes someone else’s machine? :D).

This way, the knowledge about the area will be split to at least 2 people without much effort – it is going to be a natural consequence of coding together.

Bonus point: With both above methods, you can get rid of code reviews on PRs as it is done during coding (multiple people involved). This way you might at some point get rid of PRs – of course, if you still want to follow them, then code review will be just a matter of approval of PR (3 seconds or less).

Short-living branches

If you would like to read a full article about this topic, I invite you to read one of my articles where I describe short-living branches in deep. However, in a nutshell, it is all about the creation of branches that live not more than e.g. 2 days (or 2 hours – up to you and your team). The shorter they are, the easier it is for a developer to decide to take it for a review (and this way unknowingly he would learn more and more about specific areas = knowledge sharing). Why so?

When I have a PR in front of me that contains 85 changes in 78 files, intentionally I would pretend that I do not see it – it is a lot of work to do the code review for it – or I will write LGTM! (Looks Good To Me) without a deeper glance at it. I will certainly not gain in-depth knowledge of the subject in this way.

But when I see a PR that contains 7 changes in 4 files, I will be happy and perform an extremely good code review. And this way I will gain a lot of knowledge in the concrete area.

Carousels

The second topic that I described deeply in another article. Long story short – organize in a team continuous meetings for developers only that are optional to join and where you all focus on current problems that you have during development. It can take e.g. 30 mins every morning.

Think about solutions – in the majority of cases, there will be someone else who had such a problem before. And if not, you will be all involved in brainstorming the solution – you can vote then on one of the ideas. If there is a draw (rare case), then go again with the advantages and disadvantages. Repeat the voting and if no one was convinced to change their mind, then toss the dice. Here you are – you made a decision as a team and you will have to face the consequences together. This provides huge benefits in the long term. The knowledge is shared as the team is involved in finding solutions to many different problems.

Organize management teams

Like in development where we usually work as a team, it would be a great idea to organize business teams! Quite often there is a situation where there is only a single person who can e.g. accept the cost of a tool that the development team wants to introduce in the product. Usually, it is not a big deal (unless the cost is extreme or the release is blocked) but imagine a situation where this person goes on 3 week holiday.

We do not want to call him and ask for approval as this is not cultural. So, we have to wait 3 weeks. A very long time during which we need to find different areas to focus on or if it is critical for our business, call the guy (:D). And it is a lesson for the future – try to omit the “single point of failure” also on the management side.

Always try to organize a team instead of having a single approver – this way, there will be always a group of people that will think about the problem and in the end, take a decision. It is more in the direction of choreography, where there is no orchestration from the “Head of Team” who defines deputies. All members of such a team should feel the same power of making decisions. However, to achieve it, the existing silos have to be broken step by step.

Summary

All in all, in order to build the above habits we need to trust each other, have the conviction that we are all in this together, and strive to make our product the best it can be. There is no room here for people who want to keep their knowledge to themselves only (for various reasons) or those who place their own interests above the common good.

You do not need to start all habits at the same time. Choose one that fits your team best, integrate it and then continuously improve by adding something new. At the end of the day, it’s up to you to be happy with how you work on a daily basis!