How To Kickstart A Great Scrum Team (10 practical things to do)
If you like to listen instead of read, you can also listen to this episode on our podcast.
In this post I would like to share my experiences on how to best Kickstart, Lift-off or Launch a (new) Scrum Team. Over the years, and many, many teams later, I’ve learned that a good start makes for half the work. Sending people to a Scrum Training, putting them together as a new Scrum Team, and expecting general awesomeness to follow is unrealistic. Scrum is all about self-organizing teams that frequently deliver working software. Just putting people together is not going to make them a team nor self-organizing. Teamwork is all about collaboration, (psychological) safety, and playing on each other's strengths. That’s why I’ve learned to spend a lot of time on team-building activities when I coach new Scrum Teams.
Understand team development (and your role in it)
It helps to understand how teams develop. The Tuckman Stages of Group Development is a useful model in this regard. Developed in 1965 by the psychologist Bruce Tuckman, it describes the phases that most teams progress through in order to become gel into an actual team. Tuckman built his model on 26 studies on how small groups develop, and identified five phases:
- Forming phase: In this first phase, the team is mostly concerned with their reason for being. Why are they together? What is the purpose of the team? What tasks is the team supposed to pick up? In this phase, people are usually not familiar with each other yet. The sense of safety that comes with familiarity is still missing, meaning that criticism, irritations, doubt, and uncertainties are not yet openly voiced. Instead, people tend to focus on the task at hand and what is expected of them. In this phase, people don’t generally feel part of a team yet. During this phase, the best role for the Scrum Master or Coach to take is that of teacher. Make sure that people know what to do and provide clarity on purpose and (initial) structure;
- Storming phase: When a sense of familiarity and safety starts to form within the team, people become more comfortable with each other. The openness to voice doubts, worries, and frustration grows. The first conflicts emerge. Initially, conflicts will focus primarily on tasks (‘who will do what?’, ‘how will we do this?’), not on each other. But as familiarity increases, small irritations between members (you included) will surface. This is a natural result of differences between what members expect from themselves, each other, and the team. Be mindful that conflicts can be active (people are voicing them) or passive (resistance or withdrawal). Although this is not always a fun phase to be in, it is a critical phase in the team’s development. If sufficient opportunity is given to constructively resolve conflicts, the team will learn to trust each other. Trying to shortcut this phase by covering up conflicts or ignoring them is the worst thing you can do. The best role for the Scrum Master is that of coach. Don’t resolve the conflicts for the team, but help them identify conflicts and resolve them themselves;
- Norming phase: When the conflicts that emerge during the storming phase can be dealt with in a constructive and safe manner, the team moves into the norming phase. The focus of this phase is to find a balance between what members expect from each other and the team. This has to do with aspects of the work (e.g. quality, speed, thoroughness) and how people behave (social norms). In other words, the team is agreeing on the norms, values and rules that govern their work as a team. During the ‘norming phase’, discussions become more task-oriented. This is much like what happens in the first phase, but in a way that is more mindful of the norms that the team has established. This is the phase where people start to truly feel part of, and loyal to, the team. The best role to take as a Scrum Master is that of mentor. Using the Scrum Framework and your knowledge of Agile Software Development, you can help the team to work out a productive mode of working;
- Performing phase: Now that there is safety in the team, and a shared sense of what is important and what is not, the team can work constructively together. In this phase, people become more flexible in their roles and what they do. This is the phase where self-organization becomes most evident; a team member that stands in for an unavailable Scrum Master or developers that pick up tasks outside their comfort zone. The fear of failing and making mistakes has mostly dissolved. Although task-oriented discussions are (and will remain) common, the general atmosphere within the team is positive and constructive. The best role for the Scrum Master is that of adviser. The team is perfectly capable of solving most problems on their own, but help them find the best solutions;
- Adjourning phase: All teams eventually dissolve. Perhaps the purpose of the team has been achieved, or the team is disbanded for other reasons. Especially for long-running teams, or teams that have worked together intensively for even a short period, this can be traumatic and painful. In this phase, it is important to use rituals and events to say goodbye to the team. The best role for the Scrum Master is that of facilitator. Provide opportunities for people to express emotions that are associated with departures and help them make sense of it;
Now, I have to mention that the empirical evidence for this model is limited. If you research how teams develop, the stages are usually not nearly as discrete as Tuckman suggests. And neither is the order by which teams move through it. Still, the Tuckman Model helps us by emphasizing how “time” is one of the most important ingredients to successful teams. You can’t just put a group of people together and expect them to be a team; it takes time for them to sort out how to work together.
All teams progress through these phases. Some faster, some slower. Some teams get stuck in a particular phase — usually the ‘storming’ or the ‘norming phase’ — when key conflicts remain unresolved. Changes in team composition, even if it is just a single person, generally regress back to the ‘norming phase’. A powerful reason not to mess with team composition too often. How much time a team needs to progress through the stages greatly depends on team composition and external factors, but it certainly isn’t a matter of hours or even days. My experience is that teams need at least three or four sprints to arrive at the norming phase, and a couple more to arrive at the performing phase — provided they are supported well in this process.
The Tuckman model is very helpful when you start a new Scrum Team. It helps you understand what is going on in a team, and what the team needs to proceed. Try not to rush a team through the phases. Be observant and attentive to what is happening in the team during Scrum Events. You will notice when the team is ready to move to another phase as the nature of discussions and conflicts changes. Below, I offer 10 helpful tips that I have found useful:
1. Reserve time for the Kickstart
A Kickstart is not something you should do in the final two hours on a Friday-afternoon. It is the moment where the foundation of a team is being laid. I tend to reserve two to three days for a Kickstart. The first day is mostly spent on a Scrum Training to refresh the principles of Scrum (more on this below) and on how to best apply Scrum within the context of the team. The second day is spent on team building. I play a variety of games to get to know each other and to help the team create safety and familiarity. The second part of the day is focused on setting up a team manifest. This helps to trigger the kind of discussions and conflicts that are part of the ‘storming phase’. The third day is spent on setting up a Product Backlog and starting the first sprint.
Spending three days on a Kickstart is intense and a serious investment. But it does send an important signal; we are serious about this, and we’re taking time to become a team. Without exception, teams that spend this amount of time on starting up have a much smoother ride down the road and move to the performing phase far more rapidly.
2. Getting to know each other is half the work
It doesn’t matter if people are entirely new to each other, or if they’ve already worked with each other for a long time. Spend some time during the first session as a team to get to know each other. Sometimes I ask people to introduce themselves as the superhero they’d like to be, to visualize their strengths with LEGO, or to create a personal profile card and avatar. This works well independently of how well people know each other. The key here is to break the ice and to get people out of their comfort zones. It also helps people feel less restrained during the remainder of the sessions. Make sure to facilitate these exercises in a lighthearted, fun way so as to make it non-threatening for people to participate. It's perfectly fine if these exercises feel a bit awkward. It's better to cut through the awkwardness now, than having people feel restrained to participate later.
3. Teach Scrum
A Scrum Team should not have only two members that have actually read a book on Scrum or participated in a course, while the rest doesn’t really have a clue (‘Something with meeting every day for 15 minutes’). Scrum is so popular these days that people often have very different interpretations and misconceptions about what Scrum is and what it isn’t.
That is why I always start with a Scrum Training when I help start a new Scrum Team. For teams entirely new to Scrum, the training is more thorough. But I always spend at least a few hours on it. Teams that believe that they know exactly how Scrum works can prepare a pitch and explain how and why it works to me (a great idea by Barry Overeem). For all intents and purposes, this training is highly interactive. We play games, go through a variety of exercises and cases, and create ample room for discussions. Sidestepping disagreement, criticism, or doubts during this phase is bound to damage trust and openness in the team. Voicing disagreement is a sign that people care and feel involved. I’d be worried when the team doesn’t care enough to voice criticism or disagreement.
To trigger some productive conflict — which is difficult in the initial phase — I often use a Shift & Share with open-ended questions like ‘What is appealing about Scrum to you? What puts you off?’ or ‘How can we make Scrum work for us?’ and ‘What risks and opportunities does Scrum present for you?’ to trigger discussions. I take all criticisms seriously and respond to it as best as I can or invite people in the team to respond.
A Team Carousel in progress (by Christiaan Verwijs)
4. Formulate a Team Vision
You can help a team move through the norming phase by having them think about what it means to be a good team. One exercise that works really well is to have teams imagine the worst possible team and the best possible team. Based on a number of characteristics (like ‘communication’, ‘leadership’, and ‘quality’) I let them pair up and brainstorm typical behaviors and things you’re likely to hear when working with these teams. The pairs then present their findings, and we discuss what this means as a team. Not only is this a fun exercise to do, but it also helps teams become aware of productive and unproductive behaviors. It helps them think about what it means to be a good team, how people work together in these teams, and what kind of behavior you’ll see in case of conflicts and stressful periods. Basically, the team creates a vision of what it means to be a good team. But also the opposite.
I tend to do this exercise as part of the Kickstart. Although teams will likely not arrive in the norming phase during that short time frame — where norms are important — it does help them think about what's important to them. An example of the exercise is shown below. The post-its on the outer left contain themes (‘collaboration, ‘communication’, ‘motivation’), while the other two columns contain typical behaviors and sayings for respectively the worst and the best team as brainstormed by the various pairs.
An alternative exercise is to have the team formulate a Team Manifest. Barry Overeem has written an excellent post on how to do this. My experience is that this exercise works best with teams that are comfortable enough with each other to express disagreement. If this safety is not yet present — which is often the case with new teams — the manifest will just contain a lot of open doors (a ‘politically correct Team Manifesto’). But it will not describe how people really feel. Therefore, this exercise is better reserved for when the team actually hits the norming phase. It is then that creating a manifesto has the most value.
5. Create a Team Contract
When you begin with Scrum, it is helpful to create clarity. How are we going to work as a team? Who is responsible for what? When are the Scrum Events? Clarity in roles and tasks is important for teams that are in the very early stages of formation (forming & storming). Because the team does not yet offer a perfectly safe environment, members need to know what is expected of them. This is why I often help teams to formulate a Team Contract during their Kickstart. Using a couple of prepared sheets, I ask the team to (with my help) agree on a set of working arrangements:
- Who are the members of the team? What do they bring to the team?
- How are the roles distributed? Who is the Scrum Master / Product Owner, and who’s part of the Development Team? People not on the sheet are not part of the Scrum Team, and therefore do not participate during the various Scrum Events unless specifically invited;
- When and where are the various Scrum Events? Who is expected to be there?
- What happens when someone’s late to a Scrum Event, or unable to join altogether?
- When are we — as a team — happy with a Sprint?
During the exercise, I generally move to the back of the room and let the team fill in the sheets together. This is an excellent way to observe team dynamics and get a sense of the phase a team is in. An example of a Team Contract is shown below. The sheets (I usually have two) are put on a visible spot where the team is working:
Example of a Team Contract (by Christiaan Verwijs)
6. Pick a Team Name
During the norming phase, teams start developing an identity. This identity consists of norms, values, and principles on how people want to work together. A very simple but powerful exercise is to have teams come up with a name for their team during the Kickstart. I usually ask pairs to come up with as many good names as they can think of, and then let the team dot-vote on the best name. Although picking a name is always useful to promote a team identity, it works even better when there are more teams close to the team’s proximity. Teams start taking pride in their name.
This naming-exercise works because it taps into something that social- and organizational psychologists call ‘mere group membership’. People more easily associate themselves with a group if you give them something small to identify with. Especially when there are other teams close by.
I once coached two teams who picked the names ‘A-Team’ and ‘Team Bae’, respectively. Although not highly original, it didn’t take long for fancy posters with the name to appear in the rooms of the teams. ‘Team Bea’ then decided to decorate the poster of the ‘A-Team’ with the addendum ‘From A to B(eter)’. Another team I coached picked the name ‘Rubber Duckies’ after multiple rounds of heated dot-voting. A few sprints later the team got an actual rubber duck for their team room (a much larger one than the picture). These are small examples of the power of picking a name for your team.
A fun exercise that I often do as an extension of picking a name is to have teams create a team poster to pitch their team to potential new members. Teams decorate the poster with quotes, imagery, and slogans that exemplify their team. I provide the team with magazines, newspapers, lots of paper, pencils and glue and let them go at it. It's a great way to end the team building that is part of kick start (usually the second day) on a high note while making them think about what makes them a great team to be a part of. The posters tend to end up in team rooms. Needless to say, we always have a lot of fun with this exercise:
A team presenting their team poster to their Product Owner (by Christiaan Verwijs). I’ve blurred the faces out of respect for people’s privacy.
7. Set expectations
A good Scrum Team does not form within 1 or 2 sprints. It takes time to learn how to best work together. Except for a good Kickstart, there is no way to speed up team formation through artificial means. Make sure to manage the expectations of the team and the people around the team, so that the initial motivation does not drop when reality hits. The first few sprints are generally quite tough.
When teams start they begin in the ‘forming phase’. This means that they are task-oriented and usually quite optimistic. The kind of psychological safety to express doubts and worries is not yet present, which often leads to artificial optimism. During the first sprints, this safety will start to form as people work together more closely. Conflicts, irritations, and frustrations will start to emerge. This is only natural, as people get to know each other better (and start getting irritated by things) and the difficulties of development hit the team. Once teams move into the ‘norming phase’, more time will be needed to help the team formulate norms, principles, and values. It is only when a team hits the ‘performing phase’ that teams can be fully productive. This is usually three to five 2-week sprints down the road.
8. Retrospectives, retrospectives, retrospectives
The Sprint Retrospective is sometimes seen as a good opportunity to complain about things that are not working. This is not a productive, helpful use of this important Scrum Event. Instead, the Sprint Retrospective is the Scrum Event where a team grows. Don’t skip Sprint Retrospectives. Prepare them well and try different approaches. ‘If you always do what you’ve always done, you will always get what you’ve always got’ certainly applies here. Different formats for Sprint Retrospectives help (new) teams reflect on themselves and their process through different lenses.
With new teams, I often start with a plus/delta format. I ask members to write down at least two pluses (things that went well) and two deltas (things that can be improved) individually and in silence, and then let everyone present their post-its and put them on a board with two columns (plus and delta). Depending on the number and the grouping, we either discuss all post-its or dot-vote on what to discuss in more detail. We distill two or three concrete improvement actions from this format for the team to work on during the next Sprint. I bring along the two or three improvements during the next Sprint Retrospective to see how things went. As the team progresses, I use other formats like the Agile Speedboat, the Retrospective Radar, or one of the other cool formats from the Agile Retrospective Wiki. This is also an excellent opportunity to use a variety of Liberating Structures, like TRIZ, Appreciative Interviews, 1–2–4-ALL, and What, So What, Now What.
9. Involve management to support the Kickstart
A Scrum Team will be dealing with a lot of complexity, both internally and externally. When kickstarting a new Scrum Team, it helps to ask management to come and show their support for the process. This can be done at the start of the Kickoff, or at the end- or even throughout. A key message that I always give is that support is not a one-way street. Telling a team that you support them is not the same as actively asking a team, and listening to them, to see how you can best help them. Also make sure that the people who come show support know what Scrum is, and what is going to happen. Otherwise, you risk conflicting messages. Like the manager that took the stage to state in no uncertain terms that ‘From now on we’ll start working in a way to always hit budget and deadlines. And good luck with your kickstart’.
10. ‘Bring it to the team’
The final tip is the most important one. As I mentioned in the introduction, Scrum Teams are self-organizing units that deliver working software. Self-organization is a fairly abstract, vague term. What it boils down to is that a team becomes increasingly capable to solve problems on their own. The role of the Scrum Master, or the Agile Coach for that matter, is not to solve the problems for a team but help the team solve the problem themselves. Every problem presents the opportunity for a team to grow in their ability to do so. This is why the principle of ‘Bringing it to the team’ is so critically important. Instead of organizing work for the team, or solving problems for the team, let the team come up with solutions themselves. The value of a good coach or a good Scrum Master is that he or she is capable to ask the kinds of questions that are needed to help a team understand what the problem actually is and to identify workable solutions.
A simple example of this principle is something I experienced a few years back. I facilitated an Agile Transition (with Hans van der Burgh) with five Scrum Teams. Management really wanted to start with continuous delivery and was eager to appoint one person to take responsibility for researching what potential this held for the company. This is a common, and quite frankly understandable, strategy in more traditionally-oriented organizations. People are made responsible for a problem by giving them a ‘hat’ (like the Quality Code Hat or the Continuous Delivery Hat). This runs counter to self-organization. So we suggested an alternative approach and asked the teams to come up with the best way to explore continuous delivery. The teams decided to organize several workshops on the topic, with each team sending one or two members as representatives. The workshops resulted in input for the shared Product Backlog and — most importantly — shared learning. This particular approach was then adopted for other concerns, like increasing code quality and automated testing.
Concluding thoughts
Kickstarting a new Scrum Team is no small affair. Although there is certainly an investment in time and money involved, a good Kickstart will help a Scrum Team become Awesome more quickly. In this post, I offered ten practical tips on how to best facilitate a Scrum Kickstart. This is based on my own experience. I’m very interested to hear your tips and thoughts. How do you start a new Scrum Team?
