Adding a new team member
Adding a new team member to an existing team always introduces challenges. The introduction changes the makeup of the team, and if the team had jelled, it has to do so, again, with the new member.
Also, the new member has to learn about the team and its work. There are many tacit assumptions held within a team. It’s impossible to document them all and, even if you could, both reading such a document and keeping it up to date are daunting herculean tasks.
So how do you maximize the integration of a new team member with a minimum amount of work? Here’s a way that one team with whom I worked approached the problem.
First, they brainstormed a list of topics that a new team member needed to know. It included things like how they used the story wall, who had what role on the team, the architecture of the system, the team working agreements, and the local Agile practices. These topics were written on index cards, one to a card. When a new team member came on board, they setup a section of wall with Backlog, In Process, and Done columns, and put the index cards in the Backlog column, in a rough approximation of the order to learn them.
Existing team members put post-it notes with their names on the cards they were prepared to help with. It was the new team member’s responsibility to work through these cards, one or a few at a time. The would take a card, put it in the In Process column, and ask the person named on the post-it to help them learn whatever the card mentioned. Sometimes this took a few minutes, and sometimes it took several days to go over the topic on a card. As each card was completed, it was moved to the Done column.
The very last card was “update the new member backlog cards.” Since the newest member had just gone through the process, they were in the best position to update the deck, adding, removing, and reordering cards as appropriate. This put the deck in the best possible shape for the next new member, while the memories were still fresh.
Ever since I learned this approach from George I’ve been using it. When a person joins the team they need to build relationships and learn new facts. It feels welcoming when its your entire new team that shares the responsibility for both. Icing on the cake when its on a card wall and you are doing it in an agile way.
I’ve added doing a retrospective/graduation on the end of mine. 🙂
What a great idea, Mike!
George, would you share a list of items? Just as a seed for teams, an example would be really useful right about now.
Great concept!
David, I don’t have a generic list. The team can generate a better one than I could give you. Perhaps these questions could help seed the team:
* What do I want my teammates to understand?
* What did I find unclear or confusing when I joined this team?
Or these categories:
* Things about the software we’re building (the card in the picture says “architecture”)
* Things about the way the team works, internally
* Things about the way the team interacts with others in the organization
As you go through this the first time, the team (including the new member) will realize what additional cards they need. Add them as they come up. (And discard ones that no longer seem necessary.)
It’s easier than it seems.
This is a really great idea!
I will have this task again next week and it is always a big challenge not to omit anything and to put in the right order. But I think this article shows me the way how I can solve most of my problems – and the problems of my new colleague too. With the cards he will be able to go back and remember everything he hears.
Thank you for sharing.
George, this is the post I asked you about last fall. Thank you for finding it!
Yes, it is a great idea, but does it work for a new member that already knows the team because he/she works indirectly with it? In this case, the new member has a certain knowledge about the new team …
Darkflower, certainly it works for new members that already have certain knowledge. Where that knowledge helps them, they will quickly move the card to done. And they will discover what they didn’t know. In some cases, they will discover what they didn’t know but thought that they did.
We’re doing this for the first time. Can’t wait to see how it works out, but the team was certainly more than happy to contribute.
This question recently came up on Twitter. As I responded there, there are 3 things I especially like about it:
1. The team created the cards.
2. The team put their name on cards to indicate willingness to pair on that item.
3. The newcomer updated the cards after they were done.
By the way, there was no time limit on completion. It’s more important to attend to doing things well.
The very last card was “update the new member backlog cards”.
How would the new member know if the set of cards or ToDo is the right set unless he works in the team for a while?
Ankit, they know what they know. Nothing is every complete and finished. By going through the deck, they’ve undoubtedly hit things that jump out at the new team member but existing team members take for granted.
Certainly the team will want to review the cards again when the next new team member comes along. Things will have changed. And things can change while a new team member is working through the cards. The cards can be changed to follow what’s important at any time. But no one is likely to pay attention to them during the long periods when the team is not hiring.
And the learning doesn’t stop when you’ve completed the cards. The whole team should be learning, all the time.