Part 1 covered what you can do during the hiring process, and part 2 covered once you have hired someone but before they have started. This post does not cover a specific part of the new starter timeline, but instead looks at how you can use your existing processes to your advantage. Most teams have some processes they follow, this may be a framework that works towards agile software development, or other similar approaches. In all these instances there will be opportunities to use this to help a new starter settle into your team, you can even use this time of change as a chance for improvements.

Dedicated Retrospective

A ceremony you will find in most agile teams is the retrospective. These are run every couple of weeks to reflect on how things have gone and look for ways to continuously improve. It is the perfect opportunity to prepare for a new member joining the team.

I would suggest that 2-4 weeks before the new person starts you dedicate a retrospective to how the team can help the new person settle in. One format may be to ask the team “If you were joining the team today, what would be:”

• Confusing
• Helpful
• Scary

Ask everyone to write their thoughts down on post it notes, and put them up on a board under these three categories. Each person can then explain their points, and begin to group them into similar themes.

Using the dot voting technique, the team can identify which would be the most helpful, and agree some actions the team can take. This may result in documenting a process that is currently in everyone’s head, or something as simple as putting name tags on everyone’s monitors. But even just the act of having this discussion will make the team reflect on what it was like for them, and make them much more open to helping the new team member integrate.

Kaizen / Ideas Board

A Kaizen board is a type of ideas board where any team member can raise a concern or idea that the team can then chose to address. The process is that each team member studies their work and looks for small problems, and possible solutions. These then get added to a common area like a white board or wiki page. Then a group of people meet weekly to review the ideas and identify what can be actioned and who will undertake it.

The same approach could be used with a focus on a new starter. You could kick it off with the dedicated retrospective previously covered, and use the results as an initial start for the board. Then encourage the team to add to it during the weeks leading up to the new person joining the team. I would suggest that you meet to review the ideas at least weekly. A nice touch might be to print a picture of the new person and stick it up above the board (maybe take it down before they arrive, it may come across a bit creepy).

I believe this approach will mean the team is continuously thinking about the new starter all the way up to when they join. Everyone will know that person’s name and probably have done something to make their start easier.

Working Agreements

A working agreement is a short set of principles or guidelines that all team members sign up to. When someone new joins the team it is the perfect opportunity to refresh or even create working agreements within your team. They help the team:

• Develop a sense of shared responsibility
• Increases awareness of team members own behaviour
• Empowers the facilitator
• Enhances the quality of group processes

This will help the new starter understand the culture of the team, and hopefully help them become a part of it. There is an excellent resource published on the Scrum Alliance site that details what a working agreement should look like.

“Up for Grabs” Tasks

Within the open source community there is a process where tasks are tagged as ‘up for grabs’. This indicates that the task is suitable for new contributors to the project. The tasks are selected because they are less complex and the desired outcome is known.

I believe that a similar process can be used outside the open source community and within the team. Getting a new starter productive as soon as possible will go a long way to helping them settle into the team. Using this approach the team could identify non urgent up for grabs tasks in the weeks leading up to a new starter. That way they can pick these up, and are not daunted by more complex tasks.

Pair, Pair, Pair

Possibly one of the most important steps is to pair up any new starter with other team members. For example pairing a new developer with other developers will not only help transfer some of the knowledge of the code base, but also start to build relationships.

This pairing should not only be limited to like for like roles, consider pairing with all members of the team. It will help give a rounded understanding for each roles responsibility.

If the team already pairs then this should be natural to implement, if they do not then this is an excellent opportunity to encourage it. There are many studies that prove pair programming is more productive.