How to make team more cross-functional?

Question

The problem we have now in your development process, is that there are a few people, who don't make team more cross-functional.

So, sometimes this people can become a bottleneck for some parts of the project. They don't like using Wiki for the shared knowledge issues, they don't post enough comments to their tickets in Issue tracker systems.

Because of this problems, our management sometimes can not fire some developer(even if they want it very much), because without him we will spend so much time to understand what he has done.

I think, that this problem can't be solved with just code-review, because sometimes it is impossible to notice, that there isn't enough documentation produced for the ticket, until you will face the problem.

Pair programming can't be applied in our circumstances, because the team is distributed.

We talked a lot about this problem at our meetings, but it seems more like conceptual problem. Can we change this person's attitude? How this problem can be solved?

Answer 1

You say that you cannot fire this developer because you would spend a lot of time getting up to speed on their work. I am wondering how much time you are wasting daily due to their inability to communicate. At some point you need to address the simple fact that just because someone knows the problem domain well does not mean that they can disregard the rules and do whatever they wish.

I think you need to talk to this individual and let them know that either they begin to follow the rules or you will be forced to let them go. If you keep going in this manner you will end up losing more time in dealing with their behavior then you ever will getting someone up to speed on their code.

Answer 2

Learn to be ruthless. If people aren't following the process as defined at your shop to the detriment of the team, they need to go. Have a probationary period after you've notified the team "member" of the problems with their work. If the person still doesn't follow procedure, follow through with whatever consequences you set during the meeting where you notified them of the problem.

This isn't just a problem for now, but a huge problem for the future of your team. If this person refuses to do their part, they will refuse until they are fired. The knowledge gap that you have now will be fixable, but the knowledge gap that results if you keep this person on won't be, because it lasts until the person shapes up or is let go.

Answer 3

This sounds less cross-functional and more one of getting all team members to follow your agreed-upon process.

I would suggest going back to the beginning of your process, and get everyone involved and buy-in on how your development process works. Include the aforementioned developer who "can't be fired." If the developer who doesn't agree to participate won't be included, his vote is complicit.

If the developer won't follow processes after that, it's decision time: what is more valuable -- the developer's output (albeit outside your process) or following the development process?

I can venture a guess: nobody is irreplaceable. If your development process is important, and somebody won't participate, send them out the door. The understand-what-the-developer-did problem is a short-term issue and can be addressed/managed.