A while back a saw a talk by someone with a name I can't remember talking about avoiding specialists. This got stuck in my mind and I have been trying to use this way of thinking in the team I work in. The idea is that having specialists is a risky business for the company. This is related to "the bus effect". What happens if the specialist (the guru) gets hit by the bus? All the places that I've worked we’ve always had them. Come to think of it, I've been one and so have probably you. This is also running in the vanes of developers. It’s much easier to do changes to your own code, that letting someone else do it.

So what can we do to address this problem? One suggestion is to have general specialists instead of pure specialists. So what does that mean? First an example of a specialist. A specialist is someone who is very good, or has a lot of knowledge within one specific area. For instance the guy that developed the framework that your application runs on. Every time there is a problem with that framework, he's the guy that has to fix it. You've tried several times to get access, but you're always told to hand it over to the specialist.

A general specialist however has divided and shared his knowledge over several areas. The most important thing here is the sharing of knowledge. It's now not only one guy that knows that specific thing within your app. I'm referring to larger bits of the app, and not small little bits, because you can't have everybody know every little thing in your system.

So how do you achieve this within your organization? To use our team as an example, we ran into a challenge when we were going to divide our Scrum team in two. We became too many in one team and were forced to split us up. In the app we're developing there was very clear layers of functionality, so the first thought was to divide the team by client and server. The advantage of doing this was that you would get extra focus on e.g. web services, business logic and database. You would also get another sense of ownership that might improve quality of the product. However, this also has a few negative effects. For instance, if you’re doing feature based development (like we do with Scrum) the client developer needs to hand over his work when he needs a new web service or some business logic. This will result in a dependency that is unwanted, and fits very poorly with Scrum.

So we decided that it's better to allow the developer to work on a single feature all the way through the layers. But will not this result in this person being the specialist on that feature. Yes, and that’s where sharing knowledge is important. Let’s say a bug is found on that feature. Who’s going to fix it? Maybe someone else than the guy who created it. Or if this feature is going to be improved, someone else might do that job. This also fit nicely with Scrum’s philosophy about choosing your own tasks and not being constrained by your knowhow within a specific area.

Trying to think of general specialist’s will help you share risk across your organization. On short term this will have an extra cost, but the company (and you) will see this investment worthwhile the next time someone quit their job or for some other reason leaves the company.