Onboard New People Without Losing Scrum Team Magic

March 7, 2024 by Mark Levison Leave a Comment

Agile teams have been struggling since the earliest days with how to bring new people on to a team. In one of the first Agile books, there was a story of Alistair Cockburn walking a new hire through the team’s flip charts and telling the story of their work. I haven’t seen a team use flip charts in a long time, however Alistair was onto something. Most of the writing around Onboarding covers the obvious traditional stuff: mission, values, culture, etc. I won’t cover that. I will focus instead on the challenges of bringing someone new onto an effective Scrum team, specifically.

Make onboarding a priority, one that trumps regular work. Helping the new person get up to speed helps the whole organization. As a minimum, I’m going to assume that the team was involved in the interviewing process so they already know the person. Right?

Challenges of New People in Scrum

Why it’s hard to bring a new person into a high-performing team:

• A good team will have built trust and a high degree of Psychological Safety. With a new teammate, everyone’s guard goes back up. No one is at fault –  people simply don’t know how much to trust the new person.
• A good team will also have built a mind of its own. Not literally an external brain (although that might be fun), rather, they have a shared mental model of how they work. This model includes knowing who to ask a particular question of, and what we can trust someone to do well. The model even includes shared language (e.g. abbreviations or words with special meaning). This shared mind is part of what makes a team high-performing. However, the new team member doesn’t have access to this model, so they don’t know who to ask for something nor do they know understand the shared language.

How to help new hires join a Scrum team

• Review the Product Vision and Strategy with the new team member. Hint: this shouldn’t just be the PO and the new team member. Instead, the whole team takes a couple of hours to run through any of the common vision activities (Product Box, Remember the Future, …). This is an activity to make sure everyone on the team understands the Vision and Strategy.
• Take the time to walk through the Working Agreements. Don’t just read the list – talk about how they came into being and what problems some of the more interesting ones solved. Consider doing it in the next Retrospective with the intent to make them better.
• Make sure there’s a shared understanding of the Definition of Done (really just a working agreement). A simple way to do this is to take a few items from the Sprint or Product Backlog and review what the team will do to prove they meet “Done”.
• Some teams have Decision Making rules as part of their working agreements. If your team doesn’t, now is a great time to add them.
• Define Boundaries. All teams have boundaries, but where do they stop? Who is and isn’t part of the team? Who else do they rely on? When do they rely on others?
• Share the team history. Maybe not with flip charts, but take the time to tell the story of the team. How was it formed? Who was originally on it? What was the original Product Vision and how has that changed? Understanding a little bit of how a team evolved helps you understand how they work together and the product(s) they’ve built.
• Try Appreciative Interviews as a way of sharing how and why this team is successful. Consider doing these for a few Sprints. It’s a great reminder, and validation, for existing team members as well.
• Try Pairing or Ensemble Programming. In our Engineering Practices, we make the case why these should be in common use. With a new person on the team, it helps the new team member learn both the toolset and the code more rapidly. Even if the team member is non-technical, I would still recommend pairing to help learn about the work that is going on around them so they have a better understanding of how they can contribute.
• Consider a Personal Manual or Readme. Some teams publish and maintain an overview of how they like to work and interact with the world.
• Share how the team works. This could be things like the meeting schedule (including: Backlog Refinement), and how they feel about Estimation (No estimates? T-shirt sizing? Story points? Gummy bears?)
• Back Channels. When the team needs to get things taken care of, what informal networks exist outside of the formal company hierarchy? (All companies have informal networks, not always for healthy reasons.)
• What else does your new team mate need to know beyond the team? What is the company culture?

These shared review activities start to rebuild the team cognition, and the work activities build trust.

Note: avoid personality surveys. Most of them are pseudo-science and none are useful in helping teams work together. (e.g. Myers Briggs, DISC, etc.)

If you’re the new person on an Agile team

• Ask questions. What does Agile mean for this organization? What do leaders expect? What do team members think?
• Empathize. If you’re replacing someone on their team, practice empathy. The former member might be missed or loathed. Either way, their leaving will have affected the team. Also, stay neutral. Don’t be tempted to voice opinions on something that didn’t involve you.
• Listen, Listen, Listen. Whatever your role, spend most of your first few weeks listening.
• Socialize. Pre-pandemic, one of my favourite coaching tools was to invite a team member for coffee. Walking out of the office levels any power differences and promises an informal conversation. In the world of remote work, have a 1 to 1 zoom conversation over coffee.
• Document. In the first 3-4 months, note the things you wish you had known when you started. You will make the next person’s onboarding process easier.

Someone will complain that all of this takes time. Yes, it does. However, not putting in the effort up front will cost more later as the team struggles to work well with the new team member. And if we can’t keep our new hire, then we will pay the same price again later in the year when we need to replace with yet another new person.

Geeky research moment…. a 2022 study[1] found that organizations that had deeper onboarding processes (months instead of one week) had better performance from the new employee and longer retention. So for the first few Sprints, allot between 15–20% of the team’s time to making the new person feel like part of the team. It will pay off.

See also: Scrum By Example – New People on the Team