Skip to content

The evolution of a team – part 2

Nov 24, 2015 - 6 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

HC NHS Survey Blog Ad


It’s nice to meet you. Let’s be friends

“I don’t like that man. I must get to know him better.” – Abraham Lincoln

I must refer back to my example in my previous blog post – The evolution of a team Part 1. You gather a group of people to perform a task, a project and/or a world-changing activity. We’ve all been there – either as the leader that starts it all off, as a servant-leader who is told to ‘make a performing team out of those lazy bastards nice people’ or as a team member in a totally new environment.

This initial stage, when a group (not yet a team) meets and starts to work together has received many names in literature: some call it the ‘Orientation’ phase [Runkel, Lawrence, Oldfield, Rider, Clark, Stages of group development: An empirical test of Tuckman’s hypothesis] or ‘Orientation and Dependency’ [Jedliński, Trening Interpersonalny]. Others write about ‘Dependency and Inclusion’ [Wheelan, Davidson, Tilin, Group development across time: Reality or illusion? Small Group Research]. The most widely recognised term might be ‘Forming’ [Tuckman, Developmental sequence in small groups]. Personally, I call it the ‘Sniffing each other’ phase.

This is the very start of the journey. It is during this phase that people get to know each other, they test the boundaries around them and anxiously await the outcome of this whole endeavour. This is also a time where a clear direction is needed – and it is a leader that is needed to provide it. You, as a leader will be responsible (usually) for setting the boundaries and framework for this initial phase. This is because people need to know what they should and shouldn’t do and how to start the actual work. Their safety is their (and your!) main concern. Remember, that people in the group will have different experience, skills and attitude. You should get to know them well and as fast as you can. Individual ‘small-talk’ helps here a lot – but only if you are genuinely interested in what they have to say! Start by finding out what things put a smile on their faces and a glow in their eyes.

Depending on what kinds of people you have in the group, you might want to consider different approaches on how to set these boundaries. I worked once with an already established team that experienced some changes (the rotation of one employee and a change of a Scrum Master – that was me.) Due to these changes and from what seemed to be a real lack of the Storming/conflict phase (from observation and discussion with team members), I diagnosed the team to be still in the Forming phase. However, some internal rules were already present and the boundaries were already set, so the team also had some hints of being in the Norming phase. My first steps were to build trust and relationship with the team, especially with the informal leader (previously acting as a Scrum Master). Then I followed up with observation, reflection, implemented some corrections to the processes and added some short activities to help the team to ‘open up’ (more on that in the next part of the article, where we’ll touch on the Storming phase).

A totally different experience for me was when I took care of a team that was composed exclusively of new people, fresh out of College. Most of them had little or no work experience. In that situation, I had to assume a more direct role as a leader to provide a clear set of work rules and organisation boundaries. There was more instruction, training and direction from my side than with the team in my previous example. On one hand it was easier for me to build a strong relationship with this team (which lead to mutual trust) and to lead them through changes. On the other hand it was really time-consuming to set up so many (sometimes small) things by myself.

I have mentioned the boundaries that you, the leader need to set or present to the group (that will later form into a team). I have participated recently in many discussions on the nature of self-organisation and the setting of clear boundaries is always mentioned as a prerequisite. These boundaries will ALWAYS depend on the organisation, values, project, customers and other factors. Below are examples of the boundaries and frameworks in use in one of my project teams:

  • Goals are set by the customer
  • Product Backlog is prepared by the customer (Product Owner on his side) and refined together with the team
  • Priorities are set by the Product Owner (customer) but influenced by the team (estimations, dependencies, technical insight)
  • Estimations, forecasting are in the hands of the team
  • Scrum Framework is in place – setting meetings, roles and artefacts
  • The form of these meetings are set by the team
  • Internal roles and responsibilities are established with the team
  • Holidays, Gold Cards, training and conferences are negotiated with the PM
  • Overtime needs to be agreed both with any particular team member and with the PM
  • The way to split, distribute and execute tasks is in the hands of the team
  • The way to communicate internally and externally are shaped by the team
  • Communication to the customer is overseen by the PM
  • TFS is set as a tool for Product and Sprint Backlog
  • The physical scrum board is owned by the team
  • Development and test environments are partially owned by the team and partially set by the customer
  • Coding and testing standards are partially set by the customer and our own organisation
  • The ‘Definition of Done’ is mostly set by the customer but consulted with the team
  • The ‘Definition of Ready’ is mostly set by the team but consulted with the customer
  • Continuous improvement methods and visualisation lie in the hands of the team
  • … and many others probably.

The basic symptoms of this phase are:

  • (Almost) no conflicts – people are being polite and avoid ‘difficult’ subjects in a discussion (‘You know, I like skiing’ instead of ‘What do you think about the immigrants?’)
  • The dependency on a leader to show direction – the group requires an external purpose and direction to know where to go and what to perform. If they are not provided with such goal, a leader (or leaders) will probably emerge within the group with a purpose to provide meaning and spur action [Jedliński, Trening Interpersonalny]. (‘Ok, so what do we do now?’)
  • Looking for commonalities among group members – people are drawn to others with similar interests, hobbies, social behaviours or attitude [Bryne, Donn and Griffitt, Interpersonal Attraction]. Group members will spend significant amount of time exchanging stories, past experience, interests and even personal information (to some extent) and look for similarities (‘Hey, I also worked there! Do you know Bob from the integration team?’).
  • Concerns about safety – although group members will discuss previous experiences and share some personal information with each other, they will deliberately avoid ‘exposing too much’. This is still an unknown environment, we don’t know who to really trust yet.

So what are the dos and don’ts if you are a leader in this early stages of your group’s development?

Do Don’t
  • Integrate the group, focus on finding things that the group members have in common:
    • Get-to-know each other activities
    • Get out of work together somewhere
    • Short workshops to find similarities and individual strengths
    • Icebreakers
  • Open up – start with yourself and encourage others to share some stories and experiences.
  • Set up boundaries and a framework for the process, culture and values.
  • Help the group to kick-start with tasks
  • Propagate the meaning/goal/vision of the project – start with WHY
  • Sit with the team (Management by Sitting Around – J. Appelo), earn their trust and respect through assertiveness and integrity in your actions.
  • Be more of a moderator, facilitator. Explain the goal and meaning behind every meeting.
  • Hint to the team that they will go through the stages of group development and that you are here to help them to make the journey smoother.
  • If you run retrospectives, focus more on ‘get-to-know’ activities.
  • Establish dictatorship and the ‘I am always right’ attitude
  • Assign tasks and specify how they should be completed
  • Set yourself above the group in hierarchy
  • Jump into solutions and solving problems without listening to team members and understanding the root cause
  • Push informal rules on them (other than the established boundaries of the project/organisation)
  • Extinguish every single conflict, no matter what’s the cost
  • Assign group roles (not the same as project roles!)

'Spartans' conduct team-building event with Southwestern University football team

HC NHS Survey Blog Ad
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


Start your project with Objectivity

CTA Pattern - Contact - Middle

We use necessary cookies for the functionality of our website, as well as optional cookies for analytic, performance and/or marketing purposes. Collecting and reporting information via optional cookies helps us improve our website and reach out to you with information regarding our organisaton or offer. To read more or decline the use of some cookies please see our Cookie Settings.