What activities do you suggest when starting a new team?
When forming a new team, you want to make sure you can get them started off on the right foot. There are several different ways to do that and the ones you pick are going to depend on a variety of factors, including (but not limited to):
- Do the team members know each other already?
- Is there an established way of working in your organization?
- Where is everyone located?
Just as getting a team off to the right start can give you a jump ahead on a project. Getting a bad start can cause permanent damage to the functioning of your team.
Here are some of the things that I consider when helping a new team start-up.
Get to know each other, as people
When you form a new team, there’s a fairly good chance that not everyone knows each other. It could be that you work in a large organization with several teams and the people you have on your team now haven’t had the chance to work with each other before.
It could be that this is the first cross-functional team that people have been on, so there may be people from different parts of the organization who aren’t used to working with each other on a day-to-day basis.
It could be that you brought in new people, either as new hires or consultants, that people at your organization haven’t worked with before.
It could be that some members of the team work at a different location.
It could be that the team members have worked together for a while, but they’ve never truly formed as a team. (They’ve been a workgroup).
I’ve experienced every one of those reasons for people not knowing each other. I’ve found that the sooner you help people to realize that everyone on the team are people with lives and families and mortgages and car payments and kids and pets, the smoother the interactions will go.
This is all about giving your team members the opportunity to interact with each other, in person, and share stories about themselves that have nothing to do with the work you’re doing. I’ve found that the best way for people to find out about each other is to cook a meal together, but that can be too much exposure right away.
Start off with setting aside a particular day where the team eats lunch together. Food is a very personal thing and ordering food for everyone can be fraught with peril. To start off with, just set aside the time and space (such as the team room) for people to sit together and talk about something other than work for a while. If you need to, provide some conversation starters, but don’t overdo it.
If the work of your team is such that you all need to travel to a location for a piece of the work, take the opportunity during those trips to get the team together outside of work. This is best done where everyone is traveling. Otherwise, the people who are at home base will have other responsibilities after work, and you have to respect that.
The key is you have to give people the chance to meet in person when the team is formed. If you don’t have the budget to do this, you need to ask yourself whether you’re really serious about the success of the team.
A few days given to team members at the beginning to get to know each other will ease communication the rest of the time you’re working together. Skip that and everyone will be just a voice on the other end of the phone line.
Establish your team’s methodology
Before I go much further, I should note what I mean by methodology. I go by Alistair Cockburn’s definition, which is: a methodology is the set of conventions a team agrees to when working together.
You certainly want to adhere to any corporate standards that exist (and are relevant to the work), and you can certainly refer to one of the many frameworks that exist out there (Scrum, XP, Kanban). At the end of the day, your team should agree to what their own methodology will be.
Some of the discussions that will help with that include:
- Establish working agreements
- Create a glossary of common terms and agree to their definitions.
- Decide on a definition of done
- Decide if a definition of ready makes sense in their situation and identify that.
- Decide whether you should work in an iterative fashion or use a flow approach. Don’t get into any philosophical battles on this point. Pick one and try it out. If it doesn’t work, you can always change it.
If your team is new to Agile, have the entire team go through training. Together.
Even if some members of the team are very familiar with Agile, it’s good for the entire team to hear the same thing. Hopefully whoever is conducting the training will give the team plenty of opportunities to discuss the above items as part of the training.
Because Agile is value– and principles-based (and was never intended to be prescriptive), there are many different ways to interpret how to live the values and principles. Different members of your team will have different perspectives on how things should go. That’s fine, just make sure that the team agrees as to how you’re going to operate as a team.
Build a shared understanding of the work you’re trying to do.
It’s important for the team to agree on how you’re going to work together. It’s equally important to make sure everyone understands why you’re working on what you’re working on. You’ll also want to find out if people disagree with what you’re working on and understand the basis of those disagreements.
When you want to build a shared understanding, you may want to try collaboratively establishing a problem statement and identifying outcome-based metrics.
You may also want to go one step deeper and get a better understanding of the stakeholders you need to deal with. You can do that while identifying the outside entities that your product will need to deal with by putting together a context diagram.
Make activities useful and avoid forced fun
Those discussions to establish your team’s methodology and build shared understanding are extremely important. They can also seem a little dry. So by all means, find a way to make the discussions interactive and engaging.
Just don’t overdo it.
Make sure every activity you do has a clear purpose. If the only reason you’re considering an activity is because “it will be fun,” stop. There’s a good chance that one or more members of your team won’t find it fun. They’ll find it annoying because it feels like you’re taking up time that could be better used doing something else.
I’m not saying don’t use engaging, fun activities, just make sure they have a point. And make sure you share with your team what the point was.
And be careful when planning excursions outside of the normal time frame that people are working. It’s one thing if everyone is away from their home base. They may appreciate the opportunity to hang out with the rest of the team. But if they are at home, any trip to a bar, ball game, or bowling alley could very easily turn into forced fun and often doesn’t help with team dynamics.
![[Case Study] Lessons from descaling 25 Scrum teams](https://www.agilealliance.org/wp-content/uploads/2024/12/descaling-teams-1200x630-1-150x150.jpg)
![[Case Study] Lessons from descaling 25 Scrum teams](https://www.agilealliance.org/wp-content/uploads/2024/12/descaling-teams-1200x630-1-300x158.jpg)
