Is a self-organising agile team a self-managing agile team?

The Agile Manifesto highlights that “the best architectures, requirements and designs emerge from self-organising teams”.  Scrum also reinforces that the Development Team (the people developing the Increment) are also self-organising:

“Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team”

I’ve heard many Scrum Masters reinforce the “self-organisation” aspect of agile. But what does it really mean to be a self-organising team?

What is “self-organisation”?

The term “self-organising” was first used by Immanuel Kant (1790) [1]. He argued that systems and their components exist as both in isolation of each other and as part of a whole — one can not exist without the other and yet each has their own operational function and rules. Importantly, each has its own process where order emerges from interactions between its own parts, and that these interactions are spontaneous, not needing control by any external agent [2].

This is something that Scrum reinforces wholeheartedly:

“They are self-organising. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality (p9)”

There is a subtle subtext here, though, that is often misunderstood. The role of the Product Owner in Scrum defines what the Development Team will work on so that the delivery of value is optimised. This means that the Development Team don’t get to identify what they will work on — this is the Product Owner’s job.

The team is solely dedicated to delivering work from the list managed by the Product Owner – a contrast from people spread across several project teams delivering different work managed by different project managers.

Allowing the Product Owner to prioritise a single list, and having a team dedicated and committed to each other to deliver, is a form of deliberate constraint that promotes and encourages self-organisation as no one tells them how to do their work.

How does self-management differ?

Self-management, unlike self-organisation, includes governance. That is, “the taking of responsibility for one’s own behaviour and well-being [and] the distribution of political control” to its members [3].

In terms of governance, it’s the Scrum Master’s responsibility to promote and support the Development Team to do good Scrum, by

“helping everyone understand Scrum theory, practices, rules, and values (p7)”. Importantly, for the Scrum Master to do this, he must acknowledge that Scrum’s roles, events, artifacts, and rules are immutable” and that “Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices (p18)”, including “how to turn Product Backlog into Increments of potentially releasable functionality” (p7).


Every natural system has a set of controls and constraints in which self-organisation occurs: chemical, physical and biological. No natural systems can operate outside the Laws of Thermodynamics. People in enterprises are the same: there are governance controls that establish a set of constraints in which people must operate, whether HR, an organisation’s global policies, compliance rules, legislation and even local policies for teams.

Agile teams also operate within a set of constraints:

  • The 4 values of the agile manifesto.
  • The 12 principles of the agile manifesto.

Scrum teams also add further constraints to the way people behave:

  • Scrum’s values – focus, openness, respect, courage and commitment.
  • Scrum’s events, artefacts, roles and rules.

For Development Teams in Scrum, self-organisation means that no one should be telling them how to interact in order to best deliver items from the Product Backlog, but they must do so in a way that respects the governance constraints of the role of the Product Owner and the Scrum Master, the values of both Agile and Scrum, in a way that optimises for the whole organisation not their local needs.


– – – –

[1] German Aesthetic. CUP Archive. pp. 64–. GGKEY:TFTHBB91ZH2.

[2] Camazine S, Deneubourg J-L, Franks N, Sneyd J, Theraulaz G, and Bonabeau E (2001). Self-Organization in Biological Systems, Princeton University Press, Princeton, NJ.

[3] Oxford English Dictionary. Online at:

[4] Schwaber, K. and Sutherland., J. (2017) The Scrum Guide. The Definitive Guide to Scrum: The Rules of the Game.

About the author

Related Posts:

Better together: Agile + Lean UX

How do you make Design Thinking, Lean UX, and Agile work together. Sprint 0? Design Sprints? Upfront design and planning tends to delay the delivery of value, so there must be a better way to use Scrum but also engage in discovery work at the same time without devolving into parallel design work. Integrating design, user research, and experimentation into Sprints is the key.


How do I run a Sprint Review?

The Sprint Review is one of five events in Scrum. It’s purpose is to inspect the Increment of work, get feedback, and then adapt the Product Backlog. And while many people refer to the Sprint Review as the “demo” or “showcase”, this is only one aspect of the Sprint Review.


How do I run a Daily Scrum?

Many people use the Daily Scrum to provide a status report to the Product Owner or Scrum Master, and even to stakeholders, but this event plays a more critical part in ensuring that the team continues to stay focussed on their goal and adapt their work so they improve their chance of achieving it.


Measuring agile culture with Agile IQ

Agile IQ® is an effective way to measure agile culture. Overall, it’s an effective leading indicator of the changes to mindset, behaviour and culture that’s needed to ensure that your investment in your agile enterprise is on track to deliver the results you need.

search previous next tag category expand menu location phone mail time cart zoom edit close