In the real life, it is very common that someone will leaves your teams.
What would you plan the handover?
In the real life, it is very common that someone will leaves your teams.
What would you plan the handover?
For further actions, you may consider blocking this person and/or reporting abuse
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
How about a senior, or leader leaving a project?
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.
It is supposed to be. How do you ensure the knowledge have been shared?
We're human beings, you talk to the other person you're sharing the documents and knowledge to :-)
You mean the leader should encourage sharing in the team. Right?
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
Yes. I agree.
But some old guys do not want to share. The worst case is they do not know.
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.
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 :)
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.
Don't underestimate the productivity of pair programming. People in duo advances faster than alone.
You can test it yourself first.
Maybe I should find a chance to test it.
Could you tell me what is pair programming in detail?
I mean this:
"Knowledge is constantly shared between pair programmers..."
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.
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.