Michael K. Spayd

In Scrum, a team is supposed to be self-organizing, but do we actually know what that means? Self-organizing is a principle found in both nature (chemistry, biology) and computing (robotics, AI). According to Wikipedia, it means the following:

...a process where some form of order arises from local interactions between parts of an initially disordered system. The process [does] not need control by any external agent...The resulting organization is wholly decentralized, distributed over...the [whole] system...the organization is typically robust and able to survive or self-repair substantial perturbation.

Self-organizing is not “do whatever you please,” but rather occurs when there are constraints that a group of agents with professional freedom can collaboratively create around. When we are given lots of constraints—detailed process rules, tightly orchestrated schedules (for example, project plans)—our behavior becomes less intelligent and more bureaucratic (as in a traditional waterfall). When we have just a few, simple constraints—for instance, ones derived from long-term experience and a modicum of wisdom—the resulting self-organization can become emergently brilliant.

For Scrum Teams, the constraint against which they self-organize is the 19-page Scrum Guide, which is itself born of the experience of probably hundreds of thousands of iterations. If teams instead self-organize around their company’s version of Scrum—which is unconsciously designed to hide or protect the open wounds of a dysfunctional system—the result is likely to be less than successful since it is not guaranteed by a lineage of competent practitioners.

Perhaps your organization frequently overrides the decisions of Product Owners rather than taking the Scrum Guide to heart: “For the Product Owner to succeed, the entire organization must respect his or her decisions.” Or perhaps your Daily Scrum has become a 40-minute status meeting: “The Daily Scrum is a 15-minute time-boxed event for the Development Team. At it, the Development Team plans work for the next 24 hours.” The Daily Scrum should be the most exciting, action-packed, and informative 15 minutes of your day! If it is not, you may be organizing against the wrong constraints.

Many years ago, I distilled the Tao of Scrum: a very brief, mock Taoist version of the Scrum Guide. I reprint it here, as a possible inspiration for self-organizing around.

Underlying Tao

The Way is Transparent. The Way should be Inspected. What is Inspected should be Adapted to.

People

The Product Owner decides the what of the Way.

The Team decides the how and how much of the Way.

The Scrum Master serves the Way and tells others when the Way has been lost.

Events

Release Planning defines what users of the Way will find of value and by when.

Sprints are the Way of the Team and do not vary in length.

Sprint Planning defines the Way for this week and for next.

The Daily Standup helps the team Adapt to the Way for today.

The Sprint Review helps the users of the Way Inspect what has been done in two (to four) weeks’ time.

The Retrospective helps the team decide the Way forward by Inspecting the Way that is past.

Tao of Things

The Product Backlog is the Way in order.

The Sprint Backlog is the how of the Way for two weeks’ time.

The Sprint Goal is the Way of the Sprint Backlog and the Team.

The definition of Done must be agreed upon by all who follow the Way.