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?


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.


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 organisations 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.