Getting a good project handover

This post aims to be a checklist for anyone about to start a new project. It covers the topics you should discussing with the outgoing team, as well as practical things you can do to ensure you ramp up quickly.

I’ve just started working for a large organisation, and the code base and process are all new to me. My role on the team is Tech Lead, which involves responsibilities from several members of the previous team. This has resulted in me needing to get handovers from several people to ensure that I (and more importantly my team) can do the work that the outgoing team were previously performing.

Things to learn from the outgoing team

This section contains a big list of questions. It you are doing a handover right now, read through it all. Otherwise, save some time and just read the headings.

• Development process

When are standups, and who goes? How is JIRA configured, and do you have access? What are your expected working hours? What is the git branching strategy? Who has ownership of the code and it’s quality? Are there other teams working on the code? If so, what are they working on? Who is in charge of solving merge conflicts? Who does testing? How is regression testing done?

• Building code

How do you get the code? How to you build the project? How do you run it on your local machine? What requirements does it have (DBs, other services, etc.)?

• Bug tracking

If you find a bug, what should you do with it? If someone else finds a bug with your code, how will you find out about it?

• Releasing code

Who releases code to test environments? Who releases code to production environments? If there’s a problem with either of these processes, who deals with it? What do I have to do to make sure the code I’ve worked on gets onto the environments it needs to be on? How long is the release cycle?

• Testing (unit/integration/functional/security)

What different test suites are there? How are they run? Are there any other teams that need to be communicated with about testing? Is there an automated build (e.g. Jenkins) that runs the tests? How often are the tests run? Are there any machine requirements for running tests? Who performs any manual testing?

• Code review

Who does code review? Is it mandatory? For all changes? What review tool is used? Who’s work should I be reviewing?

• Test environments

Where are the test environments? How do I connect my code to them? How do I change test data on them? How often are they updated? How do I ensure my changes end up on them?

• Design and architecture

Who does the design for new work? What’s the high level picture of the whole stack? What’s the low level picture of my specific component? Who can I talk to with specific questions about how other parts of the system work/fit together? Which components are painful to integrate with? What are the pain points in my component?

• Previous work

What has my predecessor been working on for the last 2/3 releases (or 2/3 months)? Do I understand the business requirements their work was aiming to address? Do I understand how the code they have written works? What are the pain points in the work they’ve done? If they could do the work again, what would they have done differently? Are there written up designs of all the work they’ve done? What coding remains on work that is in progress? What work remains on code that is not released yet?

• Upcoming work

What work would your predecessor have been working on next, had you not arrived? What is stopping that work from starting immediately? What external factors are stopping that work from being completed? Who are the stakeholders for the upcoming work?

• Forms/documents

Which forms/documents have to be filled in? Who do the forms need to be sent to? In what situation would you need the form? Who does the form get sent on to? Do you have a copy of the form, or someone you can request the form from?

Methods of learning quickly and thoroughly

This section aims to help you uncover things that may have been missed out (even if you can answer all the questions above). They're techniques to help you gain a more in depth understanding.

• Make a small change

Try to pick up a minor task/bug/defect/refactor, complete it, and get it deployed (preferably to live). This process will answer a large number of the most important questions from the previous section. It will also uncover any process areas on the project that are painful to work with. Knowing this early will allow you to compensate for them in future work.

• Replay sessions

Once you think you’ve answered all the questions in the previous section, sit down with someone (e.g. a project manager) and talk them through all of the tasks that you have learnt about. Get them to ask you probing questions about the work to check to see if you have missed anything. Do this before the outgoing team leave, so that there is time to find out the answers to the questions that arise.

• Design something

Pick up a new task and design it. Talk to existing team members who have done design work on the project already, so that they can advise you on pitfalls you may have fallen into, or advise you of areas of code that you may not yet be aware of.

• Write tests and refactor

This is an excellent way to really understand the code that you will be working with. Writing tests is a brilliant way to prevent regressions in the code base, so is a good way to add value. It has the dual effect that it makes refactoring much safer. Refactoring will also add value to the code base by making components smaller and functionality more focused. You will not be able to refactor code without having a moderate grasp about what it is doing.