Skip to content

The evolution of a team – part 4

Jan 21, 2016 - 5 minute read

Template Blog
Paweł Słowikowski
Scrum Master by trade, Trainer by choice, Human Being from birth. Interested in agile methodologies and leaning towards Lean. More than 8 years of experience in a multi-cultural IT projects, including 5 years as a Scrum Master and 1 year as an Agile Coach. Over 300 hours as trainer of Agile methodologies and soft-skills. Currently supporting front-line agile projects in Objectivity.
See all Paweł's posts

2988 HC Digital Transformation 476X381

Share

Ok. Maybe we need some ground rules.

“Most conduct is guided by norms rather than by laws. Norms are voluntary and are effective because they are enforced by peer pressure.” ― Sir Paul Collier, CBE and Professor of Economics and Public Policy in the Blavatnik School of Government at the University of Oxford.

team building - norming

From my perspective and experience, many groups/teams will never reach the norming phase. There might be multiple reasons for that – their composition is changing too frequently, people are not talking openly about their values (or don’t care about defending them in the work place – because they are not engaged enough), an external leader is killing all the conflicts before they can start to touch something important or even the company (or social) culture might prevent that. Therefore most of the groups will be stuck in the constant Forming/Storming cycle. When you reach this stage with your team though, congratulations! You’re not far from the true Performance now.

If the group manages to find its way through the inevitable conflicts of the previous stage then members’ trust, commitment to the group goals, and willingness to cooperate will increase significantly. Communication will also become more open and task-oriented. This third stage of group development, which is also referred to as the Trust and Structure stage, is characterized by more mature negotiations about roles, organization, and procedures. Furthermore, it is a time in which members work to solidify positive working relationships with each other [Wheelan, Davidson, Tilin, GROUP DEVELOPMENT ACROSS TIME Reality or Illusion?].

Group norms will be distilled and introduced by the team itself in order to clarify the means for effective communication, work split and distribution, meeting facilitation and other processes. This means that the self-organization will finally start to kick-in.

Don’t kill it!

Support the team and provide them with enough space so that they can create their own rules and norms – but don’t forget to clearly state the existing boundaries and frames of the project.

I can give you an example on how NOT to do the Norming with the team. A while ago, I was assigned as a Scrum Master to an already established team. The first thing I noticed was that they had problems communicating with the outside world and participating in meetings (many of the team members arrived late, had a lack of engagement etc.).

I touched on these topics during retrospectives. We then went through a series of activities (such as ‘Communication Octopus’) to write down a set of basic rules for the team to follow. I felt pretty confident that this is what they needed – after all I didn’t impose any rules on them, they wrote the rules themselves. Unfortunately, after a couple of weeks, the team was back to their original ways of working. It turned out that there were indeed some problems, hidden deeper within the team (like having one of the team members constantly dodging responsibility and work and others having less-than-zero communication skills). The situation required individual discussions and finally a whole team interworking training session to bring that problem to light (and basically restart the Storming phase), before we can begin to solve it and move on. What I did in the beginning was to just address the tip of the iceberg.

This phase also has a potential dark side to it. Since the group might be so tired after the Storming phase, the group might develop norms that suppress any kind of conflict and encourage conformity. There’s nothing wrong with this – after all, the people are tired of fighting – but if taken to the extreme (for example attacking people that think differently than the rest of the group), it may lead to dangerous behaviours such as Groupthink [Janis, Victims of Groupthink: a Psychological Study of Foreign-Policy Decisions and Fiascoes]. When not addressed in time (by a leader for example), it can lead to a regress in team development. As a leader, you can remind the team that there are positive sides to conflict that revolves around daily tasks and new ideas on how to solve challenges. Such conflict inspires creativity, understanding and leads to better solutions.

Group roles will also solidify. The roles assumed in this and later stage might be different to those in the previous stages. According to Jedliński, only when group members know and accept the roles (formal/informal) they play in a group, can they then as a whole start to move in a common direction as a team.

One more thing I tend to agree with, is the recurring models here – this phase might repeat itself frequently, especially when the team encounters different difficult situations, changes the environment they work in, the project or when they rotate team members. The team may also just evolve and become more mature, outgrowing their previous rules, norms and agreements. This may lead to a situation where a new set of team rules might be established by the team members.

How to recognize this phase?

  • Communication starts to be less violent and emotional. People start to talk more about tasks and common goals.
  • Conflicts more often end up with ‘ok, so let’s agree on something, so we can work normally’
  • ‘We have to do something about this situation’ coming from the group
  • Ok, I understand and respect your point of view. Maybe we can do an experiment to see which solution is better?
  • Team members, who are still mentally in the Storming phase (quarrelling, conflicting and focusing on their individual goals instead of group goals) might (and probably will) be ‘pacified’ by the rest of the team – either by the means of feedback and influence or, in extreme situations, by removing then from the group.

Some dos and don’ts to help you effectively support the team in Norming:

Do Don’t
  • Run workshops to establish ground rules (team contract for example) to solidify the formal and informal norms within the team
  • Check whether the established rules are accepted by every team member
  • Begin the process of shaping the common goal/purpose for the emerging team. You can discuss:
    • Vision
    • Business needs
    • Individual needs and goals
    • Alignment of individual goals with the organizational goals
    • Engagement
    • Commitment
    • Delegation matrix
    • Support, meeting facilitation
  • Reminding the team about the norms that they agreed to follow. Reflecting to the team the instances when those rules and norms are broken and asking them what we should do about it.
  • Retrospectives that will support establishing and filtering the rules and norms
  • Impose your own rules and way of work on the team
  • Dismiss or depreciate rules established by the team
  • Be the only person that cares about upholding any particular rule (it might be the case when the team doesn’t need this rule anymore)
  • Abuse the trust that has been slowly developing between you and the team.
  • Direct, coordinate work, be a task leader (it is not the initial phase anymore)
  • Agree or commit something with the outside world in the name of the team
2988 HC Digital Transformation 476X381
Paweł Słowikowski
Scrum Master by trade, Trainer by choice, Human Being from birth. Interested in agile methodologies and leaning towards Lean. More than 8 years of experience in a multi-cultural IT projects, including 5 years as a Scrum Master and 1 year as an Agile Coach. Over 300 hours as trainer of Agile methodologies and soft-skills. Currently supporting front-line agile projects in Objectivity.
See all Paweł's posts

Contact

Start your project with Objectivity

CTA Pattern - Contact - Middle