Skip to content

Self-Organising Teams

This topic scares me. Its the pot of gold under the rainbow – yes, that’s right, the “mythical” pot of gold :)

I’ve often thought (possibly out loud) that my team should make up their own minds and complained that they don’t make any decisions – just sit around and wait for me to decide or tell them what to do. All of this is more a sign of my failing them than them failing as a team. I never empowered them to make decisions – even when I thought I was. (wow- truth hurts!) Honestly I don’t think I thought “self-organising” was really possible until I started my first job as a scrum master.

At the heart of agile is –> empowering organisational culture.  This is done via self-organising teams. A simple term that is SO crucial to success. Does this mean there is no space for management? No, but it does mean that there needs to be a shift in mindset amongst managers. Self-organising does not imply that the team can do what ever it wants. Self-organising is about the team determining how they will respond to their environment. It requires an appropriate level of direction, some delegation and trust.  There should still be leadership providing guidance and a behavioural boundary for the team to work within.

Some people have called this light-touch leadership – decision making is delegated to the lowest level possible and as many decisions as possible are delegated to the team. Characteristics include: articulating goals, facilitating interactions, improving team dynamics, supporting collaboration, and encouraging experimentation and innovation (from No More Self-Organizing Teams).

I wish there was a recipe:

  • 250g people
  • 3 tbl spoons attitude
  • 8 cups open mindedness
  • 3g magic powder
  • Mix it all together, bake at 150 C for 50min and VOILA! 1 Self-organising team!

HAHA – in reality it is frequent inspection and adaptation – very agile sounding, right? :)

The self-organised team does not appear magically overnight, it needs to be created or coached into existence. In researching this – I realise why I (and I’m sure many others) find it so difficult to do. There are no steps, or best practices (like I joked above – no recipe!). Some people have blogs or have written articles about their experiences and suggestions and that is what I used for this blog post.

In general, teams seem to go through 4 stages: forming-storming-norming-performing. Any change to the team will take then back to stage 1 (forming).

[NOTE: i find it funny how often I can apply this line “…we have been here before and we will be here again…” this concept of forming-storing-norming-performing was first proposed in 1965!]

As a coach for the team you need to be aware of what phase they are in and provide appropriate guidance and support.

  • Forming – need to be more directive
  • Storming – must be accessible, more guidance in terms of decision making and professional behaviour
  • Norming – be participative (as opposed to directive), allowing team members to take responsibility for decisions and behaviour
  • Performing – almost always participative.

Joseph Pelrine has a few problems with the above stages, and he makes very valid points. In this presentation (warning- first 20 min are slightly boring) he says that we should look at coaching as cooking chicken soup. To make chicken soup we need a variety of vegetables, chuck them in a pot and add heat. If we just leave it – it will turn to mush and burn. If there’s no heat it will start to congeal and eventually solidify.

His stages are:

  1. Burning: stress is very high, people are making ‘first fit’ decisions
  2. Cooking: creative team, all members gelling – awesome team
  3. Stagnating: no energy (heat), no cooking happening, start to drop responsibility (late for meetings, no unit tests etc)
  4. Congealing: disinterest on team. No flexibility.
  5. Solidified: frozen bureaucracy, no questioning or challenging, head down 9 to 5.

So how do you move between stages? You add heat. And what exactly is heat?

The method he explains in the presentation is PV=nRT.
  • P- pressure: the number of tasks
  • V- volume: the size of the tasks
  • n- no. of molecules: the number of team members
  • R- is a constant – so we ignore this
  • T- is temperature – HEAT.

To increase the temperature or energy on the team, you need to increase the pressure and/or volume and/or decrease the team members.

Very nice :)  I like that there is a formula!

Here is an presentation on Self-Organizing Teams. It talks about the evolution of teams, and ways for coaches to influence team evolution.

  1. Select the external environment. Approach to innovation, expectations around multi-tasking and focus.
  2. Define performance. What message is sent about performance? Sustainable pace? Exploration of wild ideas? Meetings more important than deadlines?
  3. Managing meaning. Mostly comes from stories, myths and rituals that are repeated.
  4. Choosing people. Adjust team size, location, gender, background, motivation, scepticism..
  5. Reconfiguring the network Change/challenge communication paths
  6. Evolving vicarious selection systems. Variation-selection-retention, retrospectives, compensation?
  7. Energizing the system. Igniting purpose, Vision, opportunity, training, conferences, brown bags

I found a site that decided to write up the practices of a self organising team as they saw it. Here are 3 of their “practices”: (from Exploring Lean and Agile )

1) As a team member, when I complete my work, on a task, I will either help another team member, or start a new task, depending on what will most likely allow us to deliver the maximum value in a Sprint.

2) As a team member, I will provide honest and open feedback to my peers, to the ScrumMaster, to the Product Owner, whenever that feedback will help the performance of the team, even when I feel uncomfortable doing so.

3) As an agile team, we will meet together to define a set of rules and practices that we will use to guide us in our work. We agree to follow these rules and adjust them over time as necessary.

I think these are awesome. I like that there are only 3 and that they are easily understood by all. I like that they sound almost like a team declaration of independence given in user stories.