DEV Community

How would you plan handover when someone in your team leaves?

Ben on September 05, 2018

In the real life, it is very common that someone will leaves your teams.

What would you plan the handover?

Collapse
 
rhymes profile image
rhymes

I'm the one leaving a client's team so I can tell you what I'm doing: writing lots of documentation, walking through other devs to the code I was responsible of, doing and documenting load testing, answering lots of questions, handing over any passwords I might be the only one having (we found out there were none fortunately).

In general, when you have a team, what you want to avoid is having too much knowledge concentrated in one human being, to lessen the bus factor

Collapse
 
imben1109 profile image
Ben

How about a senior, or leader leaving a project?

Collapse
 
rhymes profile image
rhymes

That's me, a senior dev, even if I don't like the term. That's why we have to make sure that others have knowledge of code I was responsible for. In theory this shouldn't have ever happened but it's a small team.

Thread Thread
 
imben1109 profile image
Ben

It is supposed to be. How do you ensure the knowledge have been shared?

Thread Thread
 
rhymes profile image
rhymes

We're human beings, you talk to the other person you're sharing the documents and knowledge to :-)

Thread Thread
 
imben1109 profile image
Ben

You mean the leader should encourage sharing in the team. Right?

Thread Thread
 
rhymes profile image
rhymes

Sharing should be a basic policy, otherwise you create silos and silos are bad for business, especially if you have high turnover. A leader should not only encourage sharing but also make sure this sharing actually happens :D

Thread Thread
 
imben1109 profile image
Ben

Yes. I agree.

But some old guys do not want to share. The worst case is they do not know.

Thread Thread
 
yucer profile image
yucer

You can offer him a contract as consultant for a time. By hours, just in case that a problem appears.

But I think that the best solution is the preventive one.

Encourage pair programming, or a second developer for every stuff developed.

In some newspapers they use to have peer-review, all the stuff developed for one should be reviewed for another random workmate. You may assign a review partner for every developer.

In general I don't advice to outsource tasks that can not be reviewed and fully understood by an internal developer.

For the people that go away, you can involve the substitute a period before it leaves. The first tasks could be documenting the existent code. If some question arises there is time for direct explanation.

Collapse
 
jhotterbeekx profile image
John Hotterbeekx

Make sure there are no single responsibilities in your team, if you do this a person leaving shouldn't cause any issue. To give you an example, in our team we try and make sure that everybody touches most parts of the system, so there is always someone with the needed knowledge available. When we introduced a dev-ops role within our team it was only to learn the knowledge, after that everything this person started doing for dev ops was paired with another developer and after a while others were pairing with each other. So eventually the only responsibility left is to make sure things happen, not doing them. This makes planning holidays a lot easier as well :)

Collapse
 
imben1109 profile image
Ben • Edited

Sadly. No enough resource. ><

The biggest challenge is time. Sharing require time. But we often have another task.

Maybe the leaders need to find a balance.

Collapse
 
yucer profile image
yucer

Don't underestimate the productivity of pair programming. People in duo advances faster than alone.

You can test it yourself first.

Thread Thread
 
imben1109 profile image
Ben

Maybe I should find a chance to test it.

Could you tell me what is pair programming in detail?

Thread Thread
 
yucer profile image
yucer • Edited

I mean this:

"Knowledge is constantly shared between pair programmers..."

Collapse
 
jfrankcarr profile image
Frank Carr

In my experience, there is very little handover when it involves an employee. The parting is usually the result of some kind of interpersonal conflict in the organization. It can be conflicts between team members, bad/toxic management or something else. It usually goes...

Developer: "Here's my badge, phone and laptop."
HR Rep: "Buh-bye. Don't let the door hit you in the rear on your way out."

When the handover is with a contractor, things are usually better since a time or project limit is a known factor. In that case, cross-training is frequently part of the contract deliverable.

Collapse
 
alexiaint profile image
Alexandra Titova • Edited

We usually allow at least two weeks for a new engineer to work together with an engineer who is leaving the team, to make sure the transition goes smoothly. However, it's much more complicated when you want to change the entire development team. For cases like this you need a project transition plan and checklist.