Whether you are forming a new agile team or mixing people in an already existing team you start somewhat afresh. In an existing team the balance and group dynamics changes, in a new team people are experiencing each other for the first time and checking what the boundaries are. I don’t want to get into details of what can possibly happen — it’s best if you dig into works of Bruce Tuckman and his four-stage model or Gustave Le Bon’s “The Crowd”. The former indicated that the team goes through the stages of Forming - Storming - Norming - Performing. I would like to concentrate on the very initial stage of “Forming” the team in the first weeks of it’s existence.

There are few things I learned when entering a team. One of them is that it’s better for people to start sitting together. Let them do it at the very beginning. This indicates that something different has started, that allows them to concentrate on the future, mitigate the risk of misunderstandings or get to know the character of people they are going to work with.

Below you will find a set of exercises and techniques that you can configure at your will. They might assist in the initial stages of building a team. In order to get to know each other, find common ground and seek the ways you can work together, constantly verifying them as you go. In today’s hectic world change is inevitable. Those who don’t change die. Therefore you will probably use these exercises multiple times just to keep up with the changes. That’s a good thing. You can use them in various configurations — doing all in one day (which may be tiring), everyday in small chunks (one exercise at a time) or once or twice per week. Anything that suits you best. Nevertheless, it’s best to start with getting to know the product, then get to know each other as the product starts to create a context in which we all operate. Afterwards we find out how we are going to work and finally we can contract on the roles. Still, it’s your call. Break the rules and see what happens. In the brackets you’ll find the approximate time required for a particular exercise session.

Agile chartering & backlog creation (60–90 minutes)

Agile chartering is a simple technique useful for building the basic knowledge of the product. It answers three simple questions which may, at times, turn out to be difficult:

Why are we building this product?

How will we know if it is successful?

Who is the project community?

Doing this together with the Team and stakeholders will shed light on the vision that each of them has. It’s an opportunity to find common ground in terms of perceiving a product and it’s success as well as acknowledge who the parties of interest are.

The session should start with a person responsible for the product (like a product owner in Scrum) or business sponsors explaining in a few statements the product and it’s value. If other participants know a thing or two about it — they are welcome to share as well. It may be worth doing a brainstorming session for each of the questions and closing each discussion with understanding the goals, vision and arguments that come with it before going to the next question. This approach will also make answering consultative questions easier and encourage building on what was already agreed. These conversations will happen regularly if working in iterations. This exercise will help you to start with what is already known and change as you go.

On the basis of the above information, the Team can start building a repository (a backlog in Scrum) however it looks and however you call it does not matter at this stage. It’s probably going to be high level and not very detailed. Just go with it and add more as you discover more.

Getting to know each other (30–60 minutes)

When getting to know each other it’s worth to answer few simple questions that break the ice and shed some light on our expectations as well as talents.

• What are the skills that we have? What are we good at and how can we help others thrive? Using Team Competency Matrix can speed up the work and create a draft of the development plan for the team members. If you want to work in agile you should have a team that is multifunctional so you are not dependent on others. And this is where skills come in handy.

• Which skills do we need? Contrary to the above we are narrowing and focusing on the fact that our team is cross-functional and enables us to deliver without addressing things outside of it. The latter can slow down the work and create unwanted dependencies. Still, if we encounter such, is this something we can cope with or do we need to hire someone to fill in the gap?

• How would we like to work? What methodology, techniques, frameworks or any other tools would we like to use? This is high level brainstorming regarding what the team is going to end up with, hopefully, an agreed method of working. If there are several ideas, maybe let’s try just some of them in an experiment. You’re going to dig in deeper into how you would like to work in the next session.

When talking about the above it’s worth having few examples of your own up your sleeve. Something to start the conversation as some of the questions might seem a little vague or too general. Let me give you an example.

I can help you with moderating, assist them in creating a development plan, coach them, give feedback, pay attention to the value they create, challenge them, cooperate with the organisation to foster change that benefits all and many other. I would like us to work in Scrum because I find it valuable. To my mind it is effective due to it’s simplicity, reducing the complexity of work and focusing on the most important things. It also leaves a lot of space for choosing the best tools that we, as a Team, find useful.

Setting up working rhythm (up to 90 minutes)

At this stage we are digging deeper to setup the minimum details that we need to start doing the work. We will have plenty of chances to verify our approach and improve on the way. In agile at least that’s one of the advantages. We are answering the questions: how do we want to work? In what rhythm would we like to operate and why? In this step it’s good to define the agile framework or methodology you would like to use in more details. Establish repositories (Jira, Confluence or any other that you want to use) on the meeting, if possible, and agree on how it is going to be verified if what we are doing really works for us. This may take longer than expected if an introduction about the new (to some) framework needs to be carried out.

I start with five things and then check along the way:

• Why do we want to use a particular approach (what motivates us)?
• What is our mutual understanding on how this approach works?
• What rules should we follow?
• What are the success criteria stating that we are going in the right direction (that this works for us)
• How often do we want to do a “check point” to see if this is what we need? (in Scrum this can be done during Retrospectives)

You can find a sample of such analysis in a Scrum-ban* experiment we’ve conducted. Another approach could be looking at what we want to accomplish? Then following up with what do we need to accomplish this? and / or how will we accomplish this?.

Contracting (45–60 minutes)

It’s one of the most important things when people in a group meet and are supposed to work together. If you don’t have the time to do any of the other steps described — do this one. I do contracting in two steps. Setting up expectations between Team members in terms of their roles as well as in terms of conflicts that may arise when we work together and / or with other teams. It’s important to review the rules that we set in motion once in a while (eg. each 2–3 months) to check if they are still valid and / or if there is anything we want to add.

Contracting roles

Whether it’s Scrum or something else, all of us work in roles. Some of them have been exercised and some might be new. It’s good to name them and relate to the rules in terms of our understanding and expectations. A good thing to do it is to use a simple matrix.

It can be done in a way that each member writes his expectations on sticky notes and places them on the matrix. 10 minutes should be sufficient time to clear one’s mind and write a sufficient number of things down. When all participants have done it, it’s time for reading aloud and clarifying / responding. In my role as an Agile Coach I treat this as a point where we can share how I perceive my role and what I can, cannot and won’t do, always giving explanation why I think that way. Another thing is that you can, instead of “x” (as seen on the above photo), share your expectations towards yourself in your role.

I had a team once that was working on a tight deadline. It was not really Scrum but the pace was so hectic that I gave up on this exercise and concentrated at the work at hand. This has led to a couple big misunderstandings in terms of what they expected me to do (as a Scrum Master back then) and what I thought their knowledge on Scrum roles were. This does not take huge amounts of time and can give you much more than you’d think in the long term when it’s sorted out.

Contracting conflicts

A sample contract for dealing with conflict. This can be customised to the teams needs.

Conflicts are inevitable in team building and, in general, in communicating with others. We filter the surrounding environment by our expectations, views, values and so on. People do not have the same exact combination of them and this may lead to misunderstandings. Setting up the way we are going to deal with them will help out when in a difficult situation or an emotional state. In such situations our prefrontal cortex (responsible for logical thinking) is not working at it’s full potential. There is a correlation between emotions and logical thinking — the more emotions we experience the less logically we think. This can lead to narrowed thinking and bad decision making and therefore the contract comes in handy. The “U model” (mentioned in the photograph) is one of the techniques that can be used to better understand the other side. It involves three stages:

• Active listening (paying attention to what is important to the speaker, what are his /hers emotions and what problem is he / she experiencing).
• Reflecting on what the other person said (taking into account the filter from the first stage).
• Using coaching questions to foster change and help find a solution to the situation.

Do a sidewalk test

Nothing connects people more than afternoon fun. The informal atmosphere of getting a beer, racing karts, playing squash or doing anything else that people might want to check out together can break the ice. It’s good to unwind and go out as a team. I would recommend doing it after 1 or 2 weeks of working together so people can first settle a bit in the new setup at work. One of the ways to check on how are people feeling with each other would be Atlassian’s “sidewalk test”:

“If you are walking downtown and you see someone you work with and want to cross to the other side of the street, that’s our culture test” — Jay Simons, CEO Atlassian

What you’ve read above is what I believe is worth remembering. Do not treat this as constans once you’ve done it. Review your findings as the team grows. Some of the exercises you might want to skip, others may be put in different combinations. There is a logical key in the order I placed them but do not follow the rules just to follow the rules. Break them, experiment and.. Do share here what you’ve come up with so we can all learn!