Its Purpose?
Allows new team members an opportunity to express their discomforts, concerns and puzzles about the project in a constructive environment. This strategy focuses on explaining the circumstances or reasoning of decisions and to come up with new approaches and suggestions for improving any identified problems.
Image taken from AZAdam’s flickr stream under the Creative Commons Licence.
How Did We Execute It?
I ran this session with the entire technical team. I asked them to think about things that they had questions about, or things that had been troubling them on the project. I asked for them to write each of those items on a sticky note and let them put them all over a whiteboard.
We talked about each item, trying to understand what problem they caused. We talked around some of the drivers and decisions that might have lead to each of these items and alternatives that had been tried or considered. We also highlighted some as known problems and where to find more about what we’d acknowledged about them. I asked everyone to use three votes to help prioritise which items we should talk about.
For each of those items, we talked around the current circumstance and to help understand current forces at play. We also talked around attempts that we’d made to help address them (if any) and where we’d failed and learned from them.
As the final step, we brainstormed on a number of activities we could try out to improve them (attempting to be as specific as possible). Our final board looked like the following:
Why Is It Important?
The newest people to the project have the freshest eyes to see things that aren’t obvious enough. They lack prior context and don’t necessarily understand why the team made certain decisions or design choices. It’s a bad sign if they can’t work it out for themselves very quickly as it implies code is not well refactored enough or they cannot access the right information.
After being on a project long enough, new people who can’t understand these strange peculiarities assume the existing team made foolish or unwise decisions. These assumptions sometimes manifest themselves very strongly in the way they act, and the way they say things. I’ve found they range from something like “Why would you even consider that?” to “What idiot made this decision?” Understandably, the incumbent team no longer wants to listen to the important message behind the new person’s concerns and they no longer attempt to improve the situation.
Creating a safe environment to “air grievances” allows new people to highlight potentially problematic issues, or demonstrate the lack of clarity without focusing on who caused it, or whether or not it was the correct decision. What’s done is done. Instead the team now works together to improve the situation instead of focusing on blame.
I feel it’s still very important during these sessions to cover why decisions were made as some of those factors might still be in play and influence the direction of any solutions developed during this session.
What I Might Try Next Time
If I had lots of people joining incrementally, running this session continuously might not be as beneficial for the entire group, so I might run it individually with new participants. I would also use this strategy even out of the context of on boarding, as I ran it semi-intentionally as a technical retrospective (without calling it as such).
