Say, one Employee is leaving the company in one week. What all we must demand from this employee before he leave?
What else?
If you have to demand source code from an employee one week before he leaves, you're already in so much trouble that no answer to this question is going to help you :-)
My answer comes from the other side: what I do before leaving, to make sure the team isn't screwed.
Second Owner I always make sure that everything I own has a second owner. When I'm getting ready to leave a job, I find a new second owner for each of those things. If I forget something, at least it won't be completely orphaned.
Future plans I'm always thinking about what we should do next; when I'm getting ready to leave, I start writing them all down.
How to do my job There are always responsibilities I've taken on that other people don't know much about. Before I leave, I write them all down and send that info out to the team.
I also ask around, to see what people want from me before I go. It doesn't net much, as other people don't know as much about what I'm doing as I know, but sometimes there's something important that I missed.
I start this process as soon as I know I'm going to leave, even before anyone else knows my decision. In one case that was 6 months before I left.
From the original question:
Comments in source code aren't likely to answer some question you were otherwise stuck on. Asking someone to go back over their code and make sure it's "well commented" is going to take a lot of their time but not get you much value.
Pair programming is extremely effective in spreading knowledge around, especially when it's ** Promiscuous Pairing**
If you don't have source code for their work, you've been doing it wrong since the beginning. All source should be in source control from the beginning.
If they're writing a tool you consume: Every binary should be documented with info about where it came from, where the source code lives, which revisions it was built from, how to build it, etc. This is the same as if you release software to your regular users.
If you are dependent on a bunch of machines that someone was responsible for, they should all have second administrators from the start, in case the primary administrator is unavailable. For critical systems, have a 3rd admin, too.
In the end, though, the team is still somewhat screwed: they don't have me, and I'm hard to replace.
There are two things that irritate me a little in your question:
we must demand
Somehow this seems like a bossy approach towards a high profile employee such as a software developer (or employees in general). I don't think we must demand anything but guide our employees in a collaborative manner towards such goals.
in a week
If we start thinking about knowledge transfer one week before somebody leaves we have already lost the case! Badly! Knowledge transfer starts from the moment the employee joins the company and continues until she leaves. Moreover knowledge transfer should not be left to employees to plan but should be pre-concepted, organised and guided by superiors in a holistic sense. Knowledge transfer is a way of thinking and working.
“Knowledge transfer” is not something a good team should be planning at the stage of a developer actually leaving. Now it’s time to be looking at handing over current work in progress and any responsibilities specific to the employee.
By knowledge transfer is meant something different and unless you pay the employee specifically to train and consult they don’t really have a duty of sharing their knowledge beyond what is necessary for completion of their tasks. Company normally owns the Intellectual Property (IP) employees create throughout the employment, and not whatever is inside employees heads.
From business point of view it is fairly impractical to let employees keep IP they create for the company only inside their minds or any other closed, loosely organised, inaccessible or unaccountable form. People might be unavailable for all sorts of reasons and a simple accident, illness or personal circumstances can have a huge impact on your business, unless you provide an easy, organised, backed up way of keeping key IP outside people minds and always up to date.
Savvy company will have any important and specific knowledge not available on the market either written down or recorded in some other way or duplicated within workforce.
Simple ways for management to help keeping any key knowledge “externalised”, up to date and accessible:
As far as the checklist concerned at the point of someone preparing to leave it should include the hand over of exactly two things:
To me the most critical part of transfer of knowledge when someone leaves is to immediately assign someone to work with him on the current project(s) he is handling. Knowing what he knows about the current project and where it is right now and what still needs to be done is the most helpful especially if the new person has an opportunity to ask qustions about why he did such and such this way before taking over the project.
Other older project knowledge should already be available in source control and other systems already in place. Files should already be in a standard location for instance.
A professional who is leaving will try very hard to organize information for you before he leaves to make sure you know everything you need to know. Someone less than professional may not do a good job of telling you what you want no matter how you ask. Pair programming for the next week, will make sure most of the currently time critical info gets transferred. The professional will welcome the chance to explain his choices before he leaves, the other type will find it harder to hide what he was doing that he doesn't want you to know about becasue he's going to have another person in the guts of his program asking questions.