In most organisation these days we acknowledge that self organising teams are a good thing. This hasn’t been the case over time. Every team wasn’t born as a collection of empowered decision makers, they’ve all been on a journey. This journey begins when that team first forms.

Despite what some people have you believe, this isn’t a simple journey. Below is an example that challenges the boundaries of a self organising team.

Scenario: New team from scratch
Imagine the scenario: a new team has been recruited to deliver a Minimal Viable Product (MVP). The MVP has a reasonable timeframe but not one which allows weeks on end to define our way of working (also known as Team Approach).

By way of working (or Team Approach) a very simple example would be:

• we will timebox and use Scrum events (such as Sprint Planning, Demo, Retro)
• use some features of a Kanban board such as Queues and Policies
• use some fundamental good XP Practices such as pair programming, continuous integration and TDD
• and estimate using story points on a relative scale.

Being Agile means in defining our way of working that we will make some assumptions and take a stab at our team approach. We will continuously review and improving it as we go (often called inspect and adapt) which is much like the delivery of a product to end users.

As a leader, I actively want to encourage every person in the team to have a voice, ask questions, healthily challenge ways of working so they feel comfortable we are on a level playing field. That is a belief system, a set of values I want to help create, which is called culture, illustrated in the sketch below:

But what do you do in this scenario if a member of the team goes off at a tangent frequently which causes a big net time loss for the team?
1. Do you think oh this is Agile let him continue everyone has to have a voice?  OR
2. Do you fight your conscience and do the Waterfall thing and say we’ve spent too long on this point so we’re doing it this way?

The Answer
The answer for me is neither 1 or 2 (above). Agile values working software and focuses on just enough documentation and so similarly here we value starting the work and focus on just enough time discussing and defining our approach.

MVP is a progression of Lean which focuses on cutting waste out. To deliver an MVP therefore we need to remember that any debates (no matter how healthy) take time away from focusing directly on our delivery.  Therefore in this scenario I would say something to the team like ‘It’s really important that we debate and discuss the way we work and everyone has a voice. But can we keep what we are saying to the bare bones so we can share ideas and keep our feedback loops but also move on quickly so we can focus on doing it rather than talking about it.

My point here is I think the boundaries of self organising teams are understood pretty well but in practice aren’t summed up by a few blanket statements. They always have a degree of customisation based on the organisation, people, team and environment you are in.

This is of course just one example of self organising team boundaries and I would be very interested to hear other people’s own examples and experiences.