Direkt zum Hauptbereich

Two ingredients for self-organization (no recipe possible though)

Scrum is based on self-organized teams. Self-organized teams are able to evolve and adapt quicker in today’s highly complex working environments than traditional command-and-control management structures. At the same time, self-organized teams are more robust to external disturbances, are faster and more creative in problem solving as they use the full potential of the team and not only one single decision making (and often bottle-necked) brain as seen in hierarchical command-and-control structures. In this blogpost, I will elaborate on two questions “How to actually “do” self-organization?” and “What do I need to help teams to self-organize into more than just a group of individual people?”

What is self-organization?

Birds in a swarm showing a pattern like a whale
Photo by James Wainscoat
According to Wikipedia self-organization is not directly related to team success but is merely a process where some form of overall order arises from local interactions between parts of an initially disordered system.

Self-organization can’t be imposed on teams. No one can establish self-organization or order teams to self-organize. Self-organization happens; all the time and as soon as two ingredients are given: Boundaries and goals.

The degree, direction and intensity of self-organization can be influenced and fostered by manipulating those two crucial ingredients.

Both ingredients are needed to give the team the frame and direction in which they operate. They give guidance in what to achieve and they clarify the solution space.

Ingredient #1: Have a good goal

Hand with a compass, directed to the sun, sunset
Photo by Tim Graf
A good goal motivates and gives context about the purpose and the reasons why the team is trying to achieve it. It aligns the team, helps with planning and leaves room for the team to decide on how to achieve the goal. A good goal also helps to remain on track in case distractions occur.

If no goal is set, teams don’t know the direction in which to set out and get lost. They dive head first into something, don’t make much progress as they struggle to measure and often fail as they do not know when they are done.

A goal also helps in communicating and realizing when the team is done.

In Scrum this is why the Development Team together with the Product Owner agrees upon a Sprint Goal during Sprint Planning.

The Sprint Goal gives the overarching objective of the Product Backlog Items delivered in the Sprint. It gives the reason why the Scrum Team is building the selected Product Backlog Items into the Sprint’s Increment. The Sprint Goal helps the team to decide on what to do when undiscovered work emerges during the Sprint.

A good Sprint Goal is understood, concrete and measurable. Jurgen Appelo’s Checklist for Agile Goals and Roman Pichler’s Sprint Goal template can help Scrum Teams to craft a concrete and measurable Sprint Goal.

A confidence check formulated as a fist-of-five scale question [1] during Sprint Planning can help to improve the team’s confidence and understanding further.

A good Sprint Goal is visible to the Scrum Team, often placed on the Scrum board in the team space. By referring to a visible Sprint Goal the Development Team can evaluate its progress and decide on the next actions in order to reach it at the Daily Scrum.

Ingredient #2: Boundaries

Besides goals, teams need boundaries to self-organize. Teams without (or too vague) boundaries lack alignment and suffer from too many possibilities.

Too restrictive boundaries reduce self-organization as it restricts creativity and autonomy; hence they often lead to a lack of team motivation and commitment.
Soccer field turf corner
Photo by Robert Katzki
Boundaries fostering self-organization are supportive. They are simple. Everybody in the team knows them. They are accepted as everybody sees the underlying value and purpose. Those Boundaries are well balanced, give guidance and leave autonomy for the team at the same time. Those boundaries build and support a trustful and safe frame in which information, opinion and knowledge is shared openly between the team members, so that creative collaboration becomes possible.

With its minimalistic set of rules the Scrum Framework itself is a well-balanced set of boundaries. Its rules are targeted to enable empirism, creativity and autonomy, hence promoting self-organization within the Scrum team:
  • The Scrum Events and Scrum Artifacts provide transparency and fast feedback so that the Development Team can frequently inspect results and adapt if results are out of acceptable tolerance.
  • The Scrum roles separate the responsibilities into the what to do (Product Owner), the how to do the work (Development Team) and the framework (Scrum Master).
  • Timeboxing ensures that the Development Team remains focused, synchronized within its team members and in line with its stakeholders.
  • The Definition of Done creates transparency and trust about what needs to be done in order to get the Increment released to the customer.
  • The Scrum values focus, respect, openness, commitment and courage all serve to build trust as key foundation for collaboration

The Scrum Framework defines these boundaries and at the same time leaves a lot of room to the Scrum team to choose how to exactly apply the rules. Often, the Development Team chooses to implement additional strategies and tactics to optimize their working model.

There are more boundaries to teams: budget, organizational, management, market boundaries and other.

As Scrum Master, I often see teams working in environments with highly restrictive boundaries hindering the team in its autonomy and flexibility, and thus in its ability to self-organize.

As Scrum Master we can’t impose self-organization on teams but we can work on the boundaries, which restrict teams in their ability to self-organize.

Work on the boundaries

Start with making the boundaries visible. Ask the team: “What are our current boundaries and how do we perceive them as a team in delivering the Increment?”

Concentrate on the most hindering boundaries. Describe their impact. Ask the team what needs to change in order to perceive them more supportive and less restrictive. Helpful questions could be: 
  • What would make our boundaries more supportive with regards to openness and transparency? 
  • What would help us in delivering the Increment?  
  • How could we change the existing boundaries in order to speed up decision-making?
Tools which I find helpful in answering these questions are use case diagrams, cross team dependency boards or management 3.0 delegation boards to illustrate the team’s areas of decision authority.

Next, let the team formulate the expected benefits if the boundaries change. What would be a concrete small, measurable and promising next step for the team? Discuss who can help in pushing the boundaries.

Then make the boundaries, the impact, the proposed experiment and the expected benefits visible to management. Search for and implement together with management experiments in order to change the most hindering boundaries. Measure the outcome, inspect & adapt accordingly. Be aware of the local optimization vs. global de-optimization trap - another topic itself, which I will address in another post.


Scrum is based on and helps with self-organization, just as the Agile Manifesto mentions: “the best architectures, requirements, and designs emerge from self-organizing teams“

Self-organization cannot be imposed on the team; it happens in teams all the time anyway. The degree to which this self-organization is perceived as “successful” depends on
  • whether a good goal is set and 
  • whether supporting boundaries exist
If we want to have truly successful autonomous self-organizing teams we should work on these ingredients. As Scrum Masters, agile coaches or managers we can’t work on teams to make them self-organize but we can help teams to set (and achieve) good goals, and we can collaboratively work on the boundaries that restrict or encourage self-organization.

How about you? Where have you seen goals and boundaries fostering or restricting self-organizing teams? Which tools do you use to visualize and push boundaries?

Further Reading


  • [1] Such as “On a scale of 0 (not confident / understandable / measurable at all) - to 5 (very confident / …)”


Beliebte Posts aus diesem Blog

Optimieren wir uns zu Tode?

Als jemand, der mehr als fünfzehn Jahre in der Welt des IT-Service-Management-Prozessmanagements verbracht hat, musste ich das Buch von Guther Dueck aus dem Jahr 2020 Heute schon einen Prozess optimiert? Das Management frisst seine Mitarbeiter lesen/1/. Typisch für ihn bietet Dueck uns einen provokanten, teils vernichtenden, jedoch humorvoll geschriebener Weckruf. Er behauptet, dass das moderne Management von “Pacesetters” und “Controllers” dominiert wird. Sie sind so sehr auf Optimierung und Profit fokussiert, dass sie den Willen zu Innovation und Unternehmertum abtöten. Jedoch ohne mehr Kreativität und Tatkraft werden wir die Herausforderungen der Digitalisierung, des Klimawandels etc. nicht bewältigen. Ein agiles Mindset kann helfen.

Kategorien in Outlook - für das Team nutzen

Kennen Sie die Kategorien in Outlook? Nutzen Sie diese? Wenn ja wofür? Wenn ich diese Fragen im Seminar stelle, sehe ich oft hochgezogene Augenbrauen. Kaum jemand weiß, was man eigentlich mit diesen Kategorien machen kann und wofür sie nützlich sind. Dieser Blogartikel stellt sie Ihnen vor.

Das neue Outlook - One Outlook - erster Eindruck

Microsoft hat ein Problem: Outlook ist nicht gleich Outlook. Da ist das gute alte Outlook in der Desktop-Version. Das ist das, womit fast alle von uns im Alltag arbeiten und worüber ich hier schon oft berichtet habe. Outlook auf dem MAC sieht aber anders aus. Outlook auf Mobilgeräten sowieso. Dann gibt's noch Outlook im Web. Kein Wunder, dass Microsoft das alles entwirren, verschlanken und vereinheitlichen möchte. Gelingt es? Hier die interessantesten Funktionen des neuen Outlooks . 

Outlook-Aufgabenliste: bitte nicht die Aufgaben des ganzen Teams!

Am Tag der Arbeit kommt eine Lösung, nach der ich schon so oft gefragt wurde: Wie schaffe ich es, dass meine Outlook-Aufgabenliste nur meine eigenen Aufgaben anzeigt und nicht auch die E-Mails, die meine Kollegen gekennzeichnet haben oder Aufgaben, die einfach in einem gemeinsamen Postfach stehen?

Microsoft Teams: Die neuen Besprechungsnotizen - Loop-Komponenten

  Haben Sie in letzter Zeit in einer Teams-Besprechung die Notizen geöffnet? Dort sind inzwischen die Loop-Komponenten hinterlegt. Die sind zwar etwas nützlicher als das, was zuvor zur Verfügung stand. Trotzdem ist noch Luft nach oben. Und es gibt sogar einige ernstzunehmende Stolperfallen. Hier ein erster, kritischer Blick auf das was Sie damit tun können. Und auch darauf, was Sie besser sein lassen.

E-Mail-Vorlagen gemeinsam nutzen (Outlook)

Mittlerweile wird praktisch alle Routine-Korrespondenz in Outlook erledigt. Was liegt da näher, als ein gutes Set von Vorlagen zu erstellen und diese gemeinsam in Team zu nutzen? Leider hat Microsoft vor diesen – an sich simplen – Wunsch einige Hürden gebaut.

Und jetzt alle zusammen! Teams - OneNote - Aufgaben - To Do

Ein Meeting jagt das nächste. Sich da nicht zu verzetteln, wird  im Zeitalter virtueller Besprechungen  noch anspruchsvoller. Kein Wunder, dass  im Zusammenhang mit Microsoft 365  zwei Fragen besonders häufig auftauchen: Wie dokumentiert man Besprechungen gut? Was hilft, offene Aufgaben nachzuhalten? Eine gute Lösung: Das in MS Teams integrierte OneNote-Notizbuch als gemeinsame Plattform auch für den Aufgabenüberblick zu nutzen.

Nie wieder Ärger mit Besprechungsserien in Outlook

Erstellen auch Sie Besprechungsserien in Outlook? Ärgern auch Sie sich manchmal darüber, wenn Sie etwas zu ändern haben? Falls nicht, versenden Sie entweder keine wiederkehrenden Outlook-Besprechungen (Serienterminen). Oder Sie ändern nie etwas daran. Dann ist dieser Artikel nichts für Sie. Lesen Sie aber bitte weiter, falls Sie sich schon immer mal gefragt haben, ob es eine Lösung gibt? 

"Denn sie wissen nicht was sie tun ...! Freigeben und teilen in OneDrive und SharePoint und per E-Mail

Neuerdings können Sie bei Ihren E-Mails entscheiden, ob Sie den Anhang als Datei (Kopie) anhängen wollen oder einen Link senden. Doch was kann dieser Link? Wie sicher ist er? Wer kann was damit tun? Lesen Sie hier was sinnvoll ist und was weniger.

Das Ubongo Flow Game

Spiele bieten eine gute Gelegenheit, zeitliche Erfahrungen zu verdichten und gemeinsam zu lernen. Karl Scotland und Sallyann Freudenberg haben im Mai 2014 das Lego Flow Game veröffentlicht. Wir haben die Spielidee übernommen, aber das Spielmaterial gewechselt. Statt Legosteinen benutzen wir Material aus Grzegorz Rejchtmans Ubongo-Spiel. Hier präsentieren wir die Anleitung für das Ubongo Flow Game.