My favorite part of being an agile coach is standing up a new team, whether it is a Scrum team, a Kanban team, or a Release Train team. It involves bringing together a group of individuals and getting them to operate as a single unit, towards a single purpose. And, it involves finding creative ways to bring people together.
The task of setting up a team varies based on the situation, the individuals, and the organization. But regardless, of the specific situation, I follow a 3 step process to standup a new team: make the group a team, make them an agile team, then make them a [insert framework here] team. My reasoning is quite simple: a Scrum team that is not also agile is missing the point of Scrum, and an agile team that does not operate as a team will struggle to function effectively.
In Part 1, we’ll discuss how to setup a team. In Part 2, we’ll cover how to make a team an agile team and how to make an agile team a Scrum Team, a Kanban Team, an XP Team, or even a Release Train Team.
Create a Team
When it comes time to kickoff a new team, I look to establishing the group’s identity, setup ground rules, define processes for collaborating, and for the team to learn about one another. It is this final piece - learning about one another, that becomes crucial to establishing a team. But all of these elements are necessary for setting up a team for success.
Group Identity
A group’s identity can be as simple as establishing a team name, or as complex as defining a mission statement, envisioning the end state, and establishing the team culture. I find that the team culture will evolve as the team grows - but a good name is a great place to start. It is the start of an identity, one that the team will build upon as they work together.
The first Scrum team that I coached picked the name “The Avengers”. From this, the team decided that each team member should pick a member of the Avengers to be their avatar. Anywhere in our development tools, it was easy to spot our team members, as we were the superhero team, working together towards a common goal. The morale of the story: find someway to incorporate the team name into the identity of the team.
Ground Rules
Any collection of people working together need to understand the boundaries of that group - the rules that define how interactions work. As human society developed and evolved, the rule of law helped govern people’s behavior and led to a well-ordered group. With a new team, we need to take time tto define how we will operate.
As we start up a new team, setting aside ground rules for how the group wants to operate jumpstarts the groups formation by codifying some of the expectations the group has on eachother. As the team starts working together, they may discover additional rules they would like to establish to frame how they work together. Feel free to add these to the list of ground rules, but be cautious about adding TOO many rules; you and the team will likely forget one or two and will decrease their value.
If your team is a multi-cultured team (meaning, not everyone hails from the same country, region, culture, etc.), you may need to discuss the different expectations of each person’s culture. For instance, some rules are so ingrained by an over-arching culture, that they are only noticible when you interact with other cultures. For example, Americans have a preference for a large amount of personal space, but going through our day-to-day lives, this isn’t noticeable until you encounter someone from a different culture that has a different view on personal space. Then, their closeness can be a bit unnerving to an American. These cultural differences will surface as the team begins to execute, but it may be worth while to discuss the groups cultural differences and decide how to resolve any challenges this presents.
Collaboration
As you move into how the team operates, you’ll begin to touch on the agile processes and practices that define the team. We’ll cover these more in part 2, but for now, let’s consider how does the team collaborate? In this part of the kickoff, I discuss:
- What are our core working hours?
- Do we want to establish some “focus time”, time where interruptions are highly discouraged?
- What tools will we use to collaborate?
- If using group chat tools, what rooms/channels do we want to establish? What will their usage look like?
- Do we have a preference for when we schedule meetings? Mornings, Afternoons, a particular day of the week?
- Do we need a team home page in our wiki/SharePoint/Blog or similar tool the organization uses?
- Do we need a email distribution list?
- How will we communicate with eachother primarily? Face-to-face, email, chat, phone, video conferencing? When are the appropriate times for each of these channels?
Based on your organization, your own experiences, or the experiences of the group, you may think of other items to consider here.
Team Member Identity
While this is the final portion in my list, I view it as the most important part. For teams to truly work well together, everyone must feel comfortable being themselves and bringing that person that person to work. Innovation requires lots of ideas to choose from. But in order to surface many different ideas, team members must feel safe in bringing them up. If a team member can be themselves, and free to pull from their personal experience, we can generate more and better ideas. But this goes for EVERYONE on the team, not just the most senior person on the team.
There are many ways for team members to share with the team who they are: you can ask questions, ask each person to talk about themselves, have team members interview eachother, or play a team-building game. Here, your imagination is your only limit to what you can do.
I have 2 go-to strategies for the teams I work with: a personality test and a team member cereal box. For the personality test, I ask team members to take the free 16 Personalities assessment and share with the team. As each team member shares, we make connections, discuss what seems most true about the assessment for us, and discuss how we relate to the other personalities. Depending on the familiarity of the group, I may ask them to send me the results and I’ll read them off to the group and ask them to guees. In this way, we surface how others currently see us.
The other exercise, adapted from Lyssa Adkins’ book Coaching Agile Teams, goes something like this: provide each team member with a blank cereal box, a piece of paper or a poster board as well as some art supplies (colored pencils, markers, pens, etc.) and ask them to enviosion themselves as a product. What do skills do they provide? What is the experiences they bring? What is this person’s brand? But also ask them to focus on what they want to become. Do they wish they knew more about testing? Front-end development? Database design?
Once everyone has designed a cereal box or poster, ask them to share with the team. As people go around the room, ask the team to ask questions and to chime in where they can help the team member gain some of the skills they want to grow. Not only will team members walk away with a better understanding of each other, but they will have some ways to build upon the team bond as the team works together and helps each other.
Conclusion
Teams are amazing groups of people, but they don’t form overnight. Through establishing an identity, establishing ground rules, determining how the team collaborates, and learning about the members that make up the team, we can establish a good foundation upon which to build our agile team.