Team changes and handovers

Introduction

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. Alternately, 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:

  • Maintain the momentum of the team and the project
  • Are handled efficiently and with clarity
  • Are well understood and agreed to by the individual, the client, and the team
  • Ensure an effective transfer of knowledge
  • Work well in the context of other ongoing dxw projects

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

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 is also a good place to start. This will help in familiarising you with the project.

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.

During the change

Meet with the team

Some of the team you’ll likely have worked with before, 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 with the team any personnel changes. The delivery lead/relevant Head Of 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 is the client representative. 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 relevant line manager or profession lead

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

Below is a checklist of things that you/your delivery lead should complete when you’re moving on to a new project:

  • Familiarise yourself with the project through reading and conversations with the delivery lead
  • Meet with the delivery lead
  • Know what roles and responsibilities you’ll be taking on
  • Get added to the regular ceremonies:
    • Standup
    • Sprint planning meetings
    • Retrospectives
    • Show and tells
  • Get added to relevant Slack channels
  • Get added to Trello boards for the project
  • Know where the Google Drive folder is and where key documentation lives
  • If the project is co-located at a client’s office, make sure you understand the building arrangements. Your delivery lead should help in getting you any required pass or key.
  • Get access to any technical resources or bespoke software the team are using
  • Meet the team / client representative

When a member of your sprint team is on support

We’ve changed the way we handle support, to ensure that there’s always a developer dedicated to support, and that the responsibility cycles round everyone on the development team at dxw.

This has implications for project sprints and client work, which delivery leads will need to manage.

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

The support week runs from Wednesday to Tuesday to enable the team to adjust sprint ceremonies where necessary so the developer can join them.

There’s a rota which is set for at least one month in advance. Variation to the rota is possible, and is expected to be done by developers voluntarily trading slots to suit the schedule of their projects or their plans for annual leave.

If you have a good reason to need a change but are unable to arrange one, then we’ll make sure we can accommodate the change. A good reason might be if you have a service assessment and the named developer is participating. Having lots of work on the backlog won’t usually be a valid reason.

Some notice for changes like this is important, ideally of at least a couple of weeks.