Aligning with your software development team on what the team norms are can have a huge impact on productivity and camaraderie. Agile teams often have processes for aligning on norms gradually over time, such as sprint retrospective meetings. It’s less common for teams to set aside time for the explicit purpose of discussing and documenting team norms. We get so caught up in work that we’d rather get shit done than…well…just about anything else.
Folks who play tabletop role-playing games know about this problem, too. In a group that will be playing a campaign for months or years together, it’s valuable to get alignment on how things are going to work early on so that everyone can let their guard down and enjoy the game. The way this is done is through a meeting called ‘session 0’.
Session 0 checklist
There are great session 0 checklists for role-playing games. They have sections dedicated to team building, scheduling, a framework for play, and house rules. This could be a great structure for setting expectations within a dev team, too!
It’s important to know what every individual is bringing to the table. The team can help build each other up if they know where everyone’s strengths are. Here are some ideas for items to go over with each member of the team.
- What’s one thing you love about being a dev? Can you tell a story of something awesome that happened at a previous job? What’s a technology you’re stoked to work with?
- What’s a strength that you bring to the team? What are strengths that the rest of the team sees in you?
- Is there a weakness you’re working on improving?
- How do you like to collaborate? Do you like pair programming?
Scheduling meetings can be difficult without knowing everyone’s availability. Here are some important things about scheduling to align on.
- What are the team’s core hours? What time zone is everyone in? What time of day do team members like to work? Team meetings should only be scheduled during core hours.
- How long do meetings need to be? How many meetings is ‘too many’?
- When anyone is going on vacation, how should they make sure the team knows? Create an ‘out of office’ event in their calendar, decline meetings, and set up an auto-responder on their email?
Framework for play
Every team is going to have different kinds of work and different constraints. The team should define the structure for their approach to working on projects, maintenance, and handling emergencies.
- Do we use an existing methodology for organizing work? Scrum, XP, Kanban, or Shape Up?
- How are issues organized in the backlog?
- How are bugs prioritized? How does the team know if a bug requires them to drop everything? When do we need ‘all hands on deck’?
- Do team members play specialized roles? Is there an on-call rotation?
Devs have pet peeves. Write down the rules, and align on the consequences of breaking them.
- What coding style guide does the team follow? Is it enforced by a linter? Is there a tool that automatically formats code so devs don’t have to? Is there a CI check that rejects code changes that are incorrectly formatted?
- What’s the maximum length of a pull request? Does the team wait for a pull request to be broken down before reviewing it?
- How quickly is a pull request expected to be reviewed after it’s created? How quickly should review comments be responded to? What are the expectations of a team member who is waiting for their work to be reviewed? Are devs allowed to have more than one ticket in flight at a time?
Make it a regular thing
Session 0 and the documentation that comes out of it doesn’t need to be a one-time thing. The document can be reviewed and revised as the team makes changes to how they work. When new team members join, have another session 0 to realign on how things work.