Edit page

Team changes and handovers

Projects inevitably undergo team member changes. This can be for a number of reasons. If a project has been running for a long time, it is often beneficial to introduce some new ideas to the team, and to give incumbent team members a chance to experience, and be challenged by, something different. Alternatively, the scope of the project might change, requiring a different set of skills to those provided by the existing team. It’s normal that changes need to happen. Whatever the reason, it’s critical that we ensure personnel changes and handovers:

The following guidance is intended to outline the standard steps that can be taken by anyone moving to a new project.

People joining and leaving projects #

Before the change #

Speak with your new delivery lead #

Your new delivery lead should arrange a catch up before you start work on the new project. They should be able to answer any questions you have, as well as providing the key details and useful contextual information about the project. They should also make clear to you what the expectations for you working on the project are.

Do some reading #

If you are going to be moving on to a new project, do as much reading as you can beforehand, particularly week notes and Trello. Exploring the project folder on Google Drive is also a good place to start. This will help you in familiarising yourself with the project.

During the change #

Meet with the team #

Some of the team you’ll have likely worked with before, but there may be others you haven’t. The sooner this happens the better. Take the time to speak with everyone in the team to understand what they are working on. The delivery lead will have confirmed any personnel changes with the team. The delivery lead should also confirm to the organisation about the team member change.

Familiarise yourself with how the current project is set up #

You can speak with the delivery lead (or outgoing delivery lead if relevant) to understand which ceremonies happen and when. You should also make sure you know of any particular arrangements the team have, for example, remote working arrangements, the working patterns of team members and so on. Make sure you’re clear on what the client expectations are for this. Your delivery lead should ensure you are added to all the relevant calendar invites.

Meet the client #

As you’re onboarded to the new project, you should be introduced to whoever the client representatives are. It’s important they know who you are and what role you do. How formal this process needs to be will depend on the nature of the project.

After the change #

Catch up with your line manager #

Moving to a new project can be challenging. Take the opportunity to catch up with your line manager to make sure it’s gone well and that you’re happy with the change.

When a member of your sprint team is going onto support #

In order to support our clients, we ensure there is always a developer dedicated to working on support, and that the responsibility cycles around every developer at dxw. This has implications for project sprints and client work, which delivery leads will need to manage.

During a developer’s time on support, they won’t be participating in the sprint for their current project team. That means that whilst the project should continue as normal, their work on your current project will pause whilst they are on support.

There’s a rota which is set at least three months in advance. The rota is also (eventually) automatically reflected in Productive. The support week runs from Wednesday to Tuesday to align with our standard sprint cycles.

See the support guide for more details on how support scheduling works, and how you can feed into that.


Last updated: 9 May 2023 (history)