Starting Strong – 5 Ways to Establish Good Team Dynamics & Norms

You just kicked off a project, and it went well! Everyone is happy, hopeful, and on the same page. But how do you keep that momentum and camaraderie going?

As a Delivery Lead, here are five things I try to do at the beginning of every project.

1. Run a Team Norms Exercise

This exercise can be used to discuss common scenarios your team might encounter. You might say, “Amy usually leaves at 4:00 p.m. on Wednesday, but she starts 7:30 a.m.” Or, “We expect teammates to update their calendars a week before they take time off.”

As noted in this post, it’s a good idea to establish team norms at the beginning, rather than letting them develop over time. Therefore, I recommend running an activity like this at the beginning of a project.

It’s also beneficial to review your guidelines at a few different points during the project to make sure they still make sense for the team. Items discussed when the team is new may evolve over time and need adjustment, just like the software itself.

2. Discuss the Tools and Process for Communication

This topic might be discussed at kickoff, during your team norms activity, or in its own session. The world we live in allows for a lot of different ways to communicate with each other. I find it beneficial to know my teammates’ preferences, such as, “I check email last,” or, “If it’s high-priority, text or call me.” Some team members may prefer a chat tool for more constant interaction and collaboration.

You should discuss not only which tools to use but also which tools are best suited for particular kinds of information. For example, quick discussions may work in chat, but status reports should be emailed. Make sure everyone has access to the tools and gets in the habit of checking them regularly.

3. Repeat the Purpose of Each Sprint Meeting

It might seem like everyone knows what sprint planning, sprint review, and retro are, but some team members may not have participated in one, and they may feel silly saying so in a kickoff. For the first few iterations, you can start sprint meetings with a quick reminder that, “As a refresher, the goal and purpose of this meeting is…” (Actually, this is a good practice for any meeting you are running, not just sprint meetings.)

After a while, you can stop doing this, but reiterating the purpose of a meeting never hurts and keeps everyone on the same page.

4. Have the Development Team Invest Time in Their Own Practices

Depending on the various skill levels represented in your team, some developers may be more or less used to Agile processes like pairing. I’ve seen a lot of teams fail based on assumptions like, “I thought he knew how to use xyz.” To avoid these issues, the dev team should spend some time together to set their own norms.

A dev-focused team norm activity can help unearth these types of items in a comfortable, safe format. If it’s feasible, holding these meetings in person is best.

5. Be a Good Human

Starting a new project can be hard and stressful. I always encourage people to give others the benefit of the doubt, especially at the beginning. If someone didn’t do something you expected, it’s easy to get annoyed, but that team member may have just forgotten or didn’t remember the process.

Instead of stewing on it or writing that person off, talk to them directly. If you do this in a non-threatening and objective fashion (maybe by explaining how what they did conflicted with a team norm), it can open up a good dialog and nip the issue in the bud.

One of the main concepts of Agile development is that the process is owned by the team. This concept also carries over into team dynamics. Dedicating more time upfront to defining team dynamics and logistics may sound like unnecessary overhead, but it’s well worth the investment.