One of the most common problems in software development is the creation of a treasury of knowledge and a 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 we make as a team - except when someone has a huge ego, but fortunately, this is rare. How to avoid it? What actions should be taken 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 complete 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, why not?

What does such a split 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, etc. 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 look at the same feature, its code and work 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 - who likes to work on someone else’s machine? :)

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

Bonus point: With both methods, you can get rid of code reviews on PRs as 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 (and later trunk-based development)

It is all about creating branches that live not more than, e.g., 1 day (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 containing 85 changes in 78 files, I would intentionally pretend that I do not see it – it is much 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. In this way, I will gain much knowledge in the concrete area.

Eventually, you might shift your focus to trunk-based development. Such an approach might give you more opportunities.

Carousels

Long story short – organize continuous meetings for developers that are optional to join and where you all focus on current problems that you have during development and brainstorming. It can take, e.g., 30 mins every morning, but it is not a status meeting.

Think about solutions – in most cases, someone else will have had such a problem before. 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 over the advantages and disadvantages again. Repeat the voting, and toss the dice if no one is convinced to change their mind. Here you are – you decided as a team and will have to face the consequences together. This provides huge benefits in the long term. The knowledge is shared as the team finds solutions to various problems.

Organize management teams

Like in development, where we usually work as a team, organizing business teams would be a great idea! Quite often, there is a situation where only a single person 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 a 3-week holiday.

We do not want to call him/her 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. And it is a lesson for the future – try to omit the “single point of failure” on the management side.

Always try to organize a team instead of having a single approver – this way, there will always be 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 in making decisions. However, to achieve it, the existing silos have to be broken step by step.

Summary

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 continuously improve by adding something new. At the end of the day, it’s up to you to be happy with how you work daily!

FREE Case Study: How did we achieve great team habits where every developer was involved in product decisions? Book an appointment with me to know more!