My main stream of work is as a contract scrum master which means i tend to spend varying amount of times with clients and teams. Most of these usually involve some kind of handover from or to a new scrum master at some point. In fact just this week I have started a handover with one of the teams I currently work with to a fellow scrum master who is a permie where my current contract is as i start to work with a brand new team. This got me thinking as to what does or doesn’t help when it comes to handovers and whether there are any areas I could improve on.

The honest truth about handovers

Pretty much every handover I’ve been involved in or witnessed has never been long enough. Whether this be in the permanent or contract world, the expectation is that you’ll be able to handover (sometimes) months or years of knowledge in a small amount of time and the person inheriting the team or role can hit the ground running straight away. From my experience this usually is not the case and the daunting task for most people in the upheaval and change of a new job is enough to keep them preoccupied. I’ve found it easier to embrace this rather than worry about it which leads me to my next point.

Prioritise the important stuff

One of the best handovers I have been involved with was with Richard Arpino. Richard was the previous Scrum master of my current clients and i inherited two teams from him.┬áDespite only having a working week together we had all of the details handed over to me that were of importance. He’d done a retro with the team prior to his departure asking what the team wanted their new scrum master to do, what to help with and what not to touch! This gave me a very quick but valuable insight into the team dynamic and what they valued. Next we ran through the members of the team, what they were like, their employment status and length of service with the company etc.

These two things were the real big ticket items to find out about the team and if they hadn’t been prioritised we may not have got to them within the week and we would have missed them.

How much does a Scrum Master need to know about a team?

Following on from the above, Richard gave me a great insight into the team, the people and the environment but that was it, it was an insight. As a scrum master working with a new team how much information is too much? I’ve been involved with other handovers where the information is way to deep and has left me with a feeling that I had to continue operating exactly as the team has previous. In the example above one of the outputs of the retro done with the team is that the new scrum master shouldn’t touch their board as they liked the way it was, this was just about enough information for me to know that changes around the board would need to be carefully thought through and something that really needed to be team driven. Diving deeper into the situation could have given me way too much previous knowledge around specific detail. In the end we made some evolutionary changes rather than revolutionary to the board.

Don’t be too precious when things change

Speaking from experience of the recent handover I have done, if you are still in the same organisation after handing over it takes some time to adjust to things changing in that team from afar! At first when hearing of tweaks to how the team worked or their board I immediately tried to suggest why it may not be a good idea. I quickly found that i was being far too precious and quite frankly unhelpful! I tried to step back and offer support or advice if asked but ultimately learned to let go and realise i was not the teams scrum master before. This has been a really helpful learning curve for me and has enabled me to reflect on my time with that particular team and assess the choices I/we made and see where they can be learnt from in future. I guess this situation is frequently avoided as in the most part you are handing over to someone who is leaving ­čÖé


How have your handovers been? Any helpful tips or nightmare situations to try and avoid?