Avoiding knowledge silos within teams

gargargar

I was looking for people's experiences of how to avoid knowledge silos in development teams. I have worked in a number of differing sized teams and have not really seen a good solution to this. There is always someone who looks after the payments engine, or reporting or the order module, you get the idea. As a developer I, like most others, don't want to get involved in someone elses area as I have my own problems. In a team sense this leads to key men on certain parts of the system.

Has anyone had a good process for getting around this? I have been involved in show-and-tell fridays where people talk through their designs etc but it still didn't really cover it.

D Hayes

How about an internal wiki with each developer in charge of their own section on it?

c_man

Wikis can be good. However I have yet to encounter one that is both kept-up-to-date and explains the code well

The way we've gotten over the problem of silos in my team is pair programming/debugging. Of course it slows down the team member with the knowledge to begin with, but it pays dividends after a while.

gargargar

I have been involved with orgs that used wikis, but like c_man they were never kept up-to-date.

Pair programming is something I haven't tried (other than when troubleshooting an issue). I suppose you need to sell it to management first. Do you use it all the time of when a hand over is happening?

c_man

Pretty much all the time, though we've only been properly doing it since before Christmas but it's part of our day-to-day now. Now to clarify, we don't spend 100% of our dev time doing it but it is somewhat unusual to have a user story (sigh agile) being developed by only one person now.

Usually two devs will pair on a story. The pair themselves will decide about how to implement it. For example maybe link up for all of day one; two programmers one keyboard ( ). Now from this perhaps two parallel tasks might be identified for the next stage. Since both parties know what's expected of each other, they might separate for those bits and combine them at the end. Or it might be something totally different. The key is that the details are left up to us.

FYI, the main reason we pushed for this was to break down the knowledge silos. It seems to be working and I have to say I enjoy it. Bit of a change.

bpmurray

You have to take away personal ownership of code: anyone can make changes to any part, assuming they follow the correct process with reviews, etc. Rotate functional ownership too. I'd always want redundancy in people (afraid of the old run-over-by-a-bus problem) and documentation, although the latter is pretty thin on the ground.

L.Jenkins

D Hayes wrote: »

How about an internal wiki with each developer in charge of their own section on it?

I don't know how many times I've put that idea forward in my own company.

CreepingDeath

One way of avoiding developer knowledge silos (intentional or not), is to rotate developers around different modules of the product, say every 6 months or more.

It protects the company from key people leaving with little or no handover, gives everyone broad exposure of the product and it's technologies, helps keep developers challenged etc.
Also career wise, if a developer pigeon holes himself into just working on databases, or EJB's, or the front end then it limits them too.
You end up with developers who understand the whole picture of the product/system, which in turn would help them progress career wise up to management/architecture/etc.

Manach

However on the flip side, becoming a generalist risks being a dabbler or dilettante. Learning just enough to do the simple tasks rather than understanding the deep core meaning of the skill set. For instance, one job had career progression had career progression linked to a smorgasbord of IT buzzwords that one had to be familiar with, to the detriment of actually getting the product to customer.

Phoebas

I find code reviews can be a useful tool to help prevent knowledge silos.
Also holding development show and tells or brown bag sessions can help.

gargargar

bpmurray wrote: »

You have to take away personal ownership of code: anyone can make changes to any part, assuming they follow the correct process with reviews, etc. Rotate functional ownership too. I'd always want redundancy in people (afraid of the old run-over-by-a-bus problem) and documentation, although the latter is pretty thin on the ground.

CreepingDeath wrote: »

One way of avoiding developer knowledge silos (intentional or not), is to rotate developers around different modules of the product, say every 6 months or more.

It protects the company from key people leaving with little or no handover, gives everyone broad exposure of the product and it's technologies, helps keep developers challenged etc.
Also career wise, if a developer pigeon holes himself into just working on databases, or EJB's, or the front end then it limits them too.
You end up with developers who understand the whole picture of the product/system, which in turn would help them progress career wise up to management/architecture/etc.

These sound good. I suppose then you lose productivity while the various people get to know their new code.

I think I would go for the 6 monther rather than no one owning code as I would imagine you need to have ownership, in some sense, to get the initial build done?

gargargar

Phoebas wrote: »

I find code reviews can be a useful tool to help prevent knowledge silos.
Also holding development show and tells or brown bag sessions can help.

Yeah actaully this is a good way. It also keeps you honest as you can't put too many hacks in

L.Jenkins

CreepingDeath wrote: »

One way of avoiding developer knowledge silos (intentional or not), is to rotate developers around different modules of the product, say every 6 months or more...

That would be one of the best solutions to the issue. One of the members of my team is moving on to other projects. Myself and another colleague are going over what he has done in the past to get up to speed quickly. He'll still be around, but have as much time to dedicate to the work being left behind.

CreepingDeath

Itzy wrote: »

That would be one of the best solutions to the issue. One of the members of my team is moving on to other projects. Myself and another colleague are going over what he has done in the past to get up to speed quickly. He'll still be around, but have as much time to dedicate to the work being left behind.

"D Hayes" idea of an internal Wiki is a good inexpensive approach too, and not mutually exclusive, you can do both.
We use "Confluence" as an internal Wiki, its simplicity is its power to
allow people to create and edit shared pages fast.

In my case, I found (my) knowledge silos bad for me as a developer, as I'd get hounded for support from QA, documentation, services, customer engineering and customer support.
Now, everytime anyone asked a question I update an ever increasing "Frequently asked questions" section of the confluence page.
It really helped to reduce the number of people interrupting me every day.
It reduced my workload and helped share knowledge.

Now, when people ask for support I can give a shorter quicker response.
I won't say it's an "RTFM" reply, but it's usually a quick explanation and a URL pointing them to my confluence page.
When the same culprits keep getting a "Read FAQ #2", "Read FAQ #6" type replies, they soon learn to do a little groundwork before escalating the issues to me.

It's more aimed at people who use my work, than alter it.
But I have written pages introducing people to the main classes in my modules, JUnit test cases that you need to ensure pass, business/budget/architectural limits that affected it's design etc.

L.Jenkins

CreepingDeath wrote: »

It's more aimed at people who use my work, than alter it.
But I have written pages introducing people to the main classes in my modules, JUnit test cases that you need to ensure pass, business/budget/architectural limits that affected it's design etc.

I have a couple of Servers at my disposal, so setting up a wiki, wouldn't be all that much of a stretch.

Saint_Mel

1st thing you have to get sorted before any of that is to get buy in from all developers ... or strong team leads etc. to ensure it happens.

You'd be surprised how many people would rather not part with their knowledge. Some see it as protecting their own job

beauf

CreepingDeath wrote: »

...I update an ever increasing "Frequently asked questions" section of the confluence page...

Whats a confluence page?

beauf

CreepingDeath wrote: »

One way of avoiding developer knowledge silos (intentional or not), is to rotate developers around different modules of the product, say every 6 months or more.....

I really like this. But there's an overhead of a learning curve every-time you do this. I've never seen a project lead or management in general buy into such a rotation. Once someone has a year or more on one area, they have a lot of knowledge, which cause's inertia. You'd start it early in a project. On a complex project, there would have to be some of knowledge transfer to documentation.

moycullen14

Is this really such a big issue?

It's the sort of thing that we feel we should obsess about but in reality the cure is often worse than the disease.

Someone develops deep knowledge about an area of code/system/business practice, whatever. Why is it necessary to insist that this information is disseminated to others on a team just for the sake of it?

If he leaves then someone else will have to get up to speed with it. Do the transfer then. Why waste time any money duplicating expertise?

If he stays then what is the point is duplicating the knowledge when the 'expert' will be on hand.

If everyone knew just enough to do their job effectively we would be a lot better off. I've lost count of the number of people I've come across who are knowledge junkies. They need to know everything before they can do anything.

Raging_Ninja

moycullen14 wrote: »

Is this really such a big issue?

It's the sort of thing that we feel we should obsess about but in reality the cure is often worse than the disease.

Someone develops deep knowledge about an area of code/system/business practice, whatever. Why is it necessary to insist that this information is disseminated to others on a team just for the sake of it?

If he leaves then someone else will have to get up to speed with it. Do the transfer then. Why waste time any money duplicating expertise?

If he stays then what is the point is duplicating the knowledge when the 'expert' will be on hand.

If everyone knew just enough to do their job effectively we would be a lot better off. I've lost count of the number of people I've come across who are knowledge junkies. They need to know everything before they can do anything.

That's the nasty contractor's attitude right there. That's the sort of mentality that leads to people having to spend twice as long fixing the mess that was created as it would have taken to do it right the first time round.

moycullen14

Raging_Ninja wrote: »

That's the nasty contractor's attitude right there. That's the sort of mentality that leads to people having to spend twice as long fixing the mess that was created as it would have takenjoyed to do it right the first time round.

Well, it's all about perspective, isn't it?

Even us contractors have a view on the world that may not conform to your's. That doesn't make either the contractor or view 'nasty' - I'm not sure which noun the adjective was applied to - vague specification. Oh, well.

I was a little surprised that two pages in no-one had taken a contrarian position on the OP.

Knowledge silos are a sympton of bad design, poor implementation, over-complexity - they are not a cause.

beauf

moycullen14 wrote: »

...what is the point is duplicating the knowledge when the 'expert' will be on hand....

The expert is often not on hand.

CreepingDeath

beauf wrote: »

Whats a confluence page?

Basically Wiki for developers.
It's a product, used a lot in development, usually with other products also sold by the same company - Atlassian
Confluence = Wiki
Jira = Bug Tracking
Crucible = Code reviews
FishEye = Code tracking

beauf wrote: »

I really like this. But there's an overhead of a learning curve every-time you do this. I've never seen a project lead or management in general buy into such a rotation. Once someone has a year or more on one area, they have a lot of knowledge, which cause's inertia. You'd start it early in a project. On a complex project, there would have to be some of knowledge transfer to documentation.

True, and it's not for everyone.
So maybe the project/team leads stay in place, and the more junior members are rotated around.
If you can't specialise then diversify.

There have been times I wasn't happy looking at another module in our product, but was glad afterwards that I learnt something new.

jester77

Pull Requests. No one should commit directly to the main branch, create a pull request and assign at least one person to review it and when everyone gives the OK, only then can it be merged. Prevents knowledge silos and increases quality.

Saint_Mel

moycullen14 wrote: »

If he leaves then someone else will have to get up to speed with it. Do the transfer then.

Depending on the complexity and legacy of the system, that is probably the worst time to try a bit if knowledge transfer. Person A under pressure to learn part of the system and being taught by Person B who is going through the motions on their months notice.

MaggotBrain

A team meeting to discuss the issue of spreading the knowledge. This will encourage ideas and more importantly buy-in.

A strict code submission process. Pull requests for example.

360 review of code for every PR, not mandatory but encouraged. From manager to newbie. This works extremely well. Nobody is afraid to comment on an architects/seniors code. If it is an open process nobody resent silly comments and it encourages discussion.

In agile, a release demo for team eyes only. Mandatory demo of new features to be given by developer.

Wikis are good but someone's got to run the show.

Release build spread around from newbie to senior.

Bug hunts keeps everyone on there toes.

I've worked on many disfunctional teams, most issues come from the PMs style of management. Sometimes your hands are tied before you even begin.

beauf

MaggotBrain wrote: »

...I've worked on many disfunctional teams, most issues come from the PMs style of management. Sometimes your hands are tied before you even begin.

+1. A lot of a PM habits (and developers) are engrained over years. Often not sharing information is one of those habits. As an internal employee you get locked in silo. Whereas a contractor comes in and is given access to everything. So arises a curious situation where information sharing that was blocked by management style. Is unblocked if you go through the contractor on a project.

Maybe no one else has experienced that.

gargargar

moycullen14 wrote: »

Is this really such a big issue?

It's the sort of thing that we feel we should obsess about but in reality the cure is often worse than the disease.

Someone develops deep knowledge about an area of code/system/business practice, whatever. Why is it necessary to insist that this information is disseminated to others on a team just for the sake of it?

If he leaves then someone else will have to get up to speed with it. Do the transfer then. Why waste time any money duplicating expertise?

If he stays then what is the point is duplicating the knowledge when the 'expert' will be on hand.

It's a fair point. I see two main issues

1) This person may be over this area for 1-2 years and if they are senior enough they may be building and designing it away without review. Then when it comes to a handover it is a nightmare.

2) Holidays. It is awful getting pulled into a critical fix of someones elses code. When you are under pressure to fix but don't know how it works. Even the best designed systems can be very complex.

You are correct in that you need to look at the costs vs the benefits.

moycullen14 wrote: »

If everyone knew just enough to do their job effectively we would be a lot better off. I've lost count of the number of people I've come across who are knowledge junkies. They need to know everything before they can do anything.

Think you have lost the run of yourself there ...