Agile Teams pochen darauf, und Manager können es schon nicht mehr hören: Selbst­organisation. Kaum ein Organisationskonzept wird so missverstanden wie dieses. Stolze agile Teams verbitten sich Mikromanagement. Führungskräfte zweifeln und sagen „Ja, schön, aber bei uns funktioniert das ja sonst nicht!“ Dabei kann mit ein paar Vereinbarungen alles so einfach sein. Der Artikel zeigt Ihnen, was Selbstorganisation ist und wann sie funktionieren kann. Leser erfahren, wie Teams und Management gemeinsam System in die Sache bringen, sodass sich die Menschen im Alltag wirklich auf die Arbeit konzentrieren und der Kreativität freien Lauf lassen können.

Ein Team und sein Management: immer wieder ein schönes Spannungsfeld, in welche Organisation man auch schaut. Führen, Steuern und Organisieren sind Begriffe, die in dem Zusammenhang immer wieder zu hören sind. Klarheit herrscht meistens nicht. „Unser Chef soll uns nicht so hineinregieren, wir machen das schon!“, hört man von den Teams. „Die Leute machen einfach irgendwas, und wenn ich nicht ständig nachfrage, dann läuft es aus dem Ruder“, heißt es vom Management. Beide Parteien sind damit unzufrieden, denn entgegen landläufiger Annahme macht es den Führungskräften nämlich keinen Spaß, hineinzuregieren. Sie tun das, weil sie glauben, es zu müssen.

Prozessframeworks und Methoden aus Agile und Lean setzen auf Selbstorganisation. Cross-funktionale, selbstorganisierende Teams sollen es sein. Über den Begriff Selbstorganisation herrscht zwischen Management und Teams meist keine Einigkeit. Sortieren wir also erst einmal: Was ist eigentlich Selbstorganisation?

Organisieren bedeutet nach Herkunftswörterbuch [1] ursprünglich „planmäßig ordnen, gestalten, einrichten, aufbauen“. Wir gestalten ein geordnetes System aus Personen und Dingen, die miteinander in Beziehung stehen. Beispiel: Ein Team mit seinen Prozessen, Methoden und Tools, die dazu führen, dass seine Mitglieder die gewünschten Ergebnisse erzeugen können.

Selbstorganisation findet statt, wenn diese Ordnung nicht durch Einfluss von außen entsteht, sondern aus dem System selbst heraus: Das System organisiert sich selbst. Selbstorganisation bedeutet naiv betrachtet „wir als Team bestimmen selbst, wie die Dinge hier bei uns laufen“. Dahinter steckt nicht nur die Organisation des Alltags, sondern zwei weitere Aktivitäten, die häufig verwechselt werden, nämlich führen und steuern. Was ist der Unterschied zwischen Führen, Steuern und Organisieren?

• Führen bedeutet, die Aufmerksamkeit der Teams in eine bestimmte Richtung zu lenken. Führungskräfte stellen das, was in der gewünschten Richtung liegt, besonders heraus und versuchen, alle Einflüsse zu reduzieren, die von dieser Richtung ablenken. Beim Fußball macht das der Kapitän der Mannschaft. Das Ziel ist natürlich der Ball im gegnerischen Tor. In der Softwareentwicklung ist der „Kapitän“ derjenige, der das gewünschte Ergebnis vertritt (z. B. der Produktmanager). Sein Ziel heißt lauffähige Software und angemessene, nützliche Dokumentation.

• Steuern bedeutet, zu beobachten, wann aufgestellte Regeln verletzt werden und diese Regelverletzungen zu ahnden. Beim Fußball macht das der Schiedsrichter. Er achtet auf Einhaltung des Zeitplans, auf Fairness und auf Besonderheiten wie die Abseitsregel. Auch in der Softwareentwicklung gibt es dafür vorgesehene Rollen, zum Beispiel den Projektleiter oder den Scrum Master.

• Organisieren betrifft das tägliche Tun, die Regeln und Prozesse, mit denen wir unsere Ergebnisse erzeugen. Wie viele Meetings gibt es, wer macht was, in welcher Reihenfolge? Wo gibt es welche Informationen, wie legen wir sie ab, wer spricht mit wem? Woran erkennen wir Dinge, die fehlen oder nicht gut laufen? Wann ist unsere Software fertig, was bedeutet überhaupt „fertig“?

In selbstorganisierten Teams „halbiert“ man die Aufgaben „Führen“, „Steuern“ und „Organisieren“:

• Was strategisch wichtig ist und Weitsicht braucht, erfolgt durch jemand Bestimmtes, eine dafür ausgezeichnete Person oder Rolle. Diese Person wirkt manchmal wie ein Dirigent im Orchester.

• Was operativ wichtig ist und detaillierte, lokal verfügbare Daten braucht, macht das ganze Team. Die Teammitglieder wirken wie Tänzer in einem Ballett, die aufeinander achten und reagieren.

Alle Mitglieder des Teams wirken beim Aufstellen von Regeln und Prozessen mit. Sogar Führung kann halbiert werden: Im täglichen Stand-up-Meeting eines selbstorganisierten Teams könnte ein Teammitglied sagen: „Diesen Fehler machen wir jetzt das zweite Mal. Das muss jetzt anders werden! Wer hilft mir, dann nehmen wir uns endlich mal eine Stunde Zeit, um das gemeinsam zu ändern.“

Vorteile von Selbstorganisation

Selbstorganisation ermöglicht schnelles Entscheiden, lokal auf der Ebene des Teams. Man muss nicht mit jedem bisschen zum Chef gehen. Die Entscheidungen fallen kundenorientiert, schnell, mit weniger Reibungsverlusten zwischen hierarchischen Ebenen. Die Kommunikation wird einfacher und kostet weniger, wenn zentrale Instanzen nicht mehr oder nicht mehr so oft benötigt werden. Störungen können lokal vom Team behandelt werden, ohne sich groß in der ganzen Firma zu verbreiten.

Wenn die Teams auch noch gemischt-funktional aufgestellt sind, also jedes Team nicht nur Entwickler, sondern auch Analysten, Architekten, Datenbänker, Oberflächengestalter und Tester hat, haben sie alle Kompetenzen lokal vorhanden. Damit agiert das Gesamtsystem deutlich stabiler, die Teams können dauerhaft mit hoher Qualität und Leistung liefern.

Eine selbstorganisierte Aufstellung kommt der Motivation der Leute zugute. Jeder merkt, dass er Einfluss auf das Geschehen hat und empfindet mehr Sinn in seiner Arbeit. Solche Teams können sich leichter an Veränderungen anpassen, weil sie selbst ihre Regeln ändern können, wenn es nötig ist. Durch die kürzeren Entscheidungsprozesse ist häufigeres Liefern von bereits lauffähiger Software möglich. Der Kunde kann daraufhin häufiger Feedback geben; man merkt, ob man auf dem richtigen Weg ist. Das nimmt Risiko aus dem gesamten Vorhaben.

Am Rand zum Chaos

Selbstorganisation wirkt auf manche Menschen wie Chaos. Ungeübte empfinden Angst und fühlen sich überfordert durch die ungewohnte Freiheit. Sie bräuchten mehr Leitplanken, doch Mikromanagement ist ja unerwünscht. Auch die Führungskräfte haben es nicht gerade leicht. Wenn Teams selbstorganisiert arbeiten und sich selbst neue Regeln geben, kann eine Führungskraft unsicher werden: „Moment mal, diese Regel verstößt aber gegen das, was wir offiziell gesagt bekommen!“ Selbst erfahrene Führungskräfte geraten dadurch in ein Dilemma: laufen lassen oder intervenieren?

• Lässt die Führungskraft das Team zu lange laufen, können Konflikte verschleppt werden, und es kann Beliebigkeit entstehen.

• Interveniert sie zu früh, kann es sein, dass sie aus einer Mücke einen Elefanten macht und das ganze System übertrieben reagiert.

• Interveniert sie zu häufig, gibt das Team die Selbstorganisation wieder auf, wodurch die Führungskraft die Entscheidungen wieder „an der Backe hat“.

Dadurch entsteht mehr Chaos als Ordnung. Es ist in etwa wie beim Radrennen auf Kopfsteinpflaster. Die Fahrer müssen ihre Lenker locker in den Händen halten, sodass Vibrationen sich nicht auf die Arme übertragen und Fahrer samt Rad zu Fall bringen. Trotzdem muss der Griff so fest sein, dass das Rad trotz Vibrationen die Richtung einhält. Erfahrene Rennradler haben ein Gespür für die notwendige Lenkkraft.

Was also tun? Wie können wir agil und selbstorganisiert in einem empfindlichen Gleichgewicht zwischen Freiheit und Ordnung arbeiten?

Was ist ein CAS?

Beim Finden der Lösung hilft uns ein ganz kurzer Ausflug in die Theorie der komplexen adaptiven Systeme (englisch abgekürzt: CAS). Teams und die Elemente der Organisation, in der sie arbeiten, bilden zusammen nämlich ein komplexes adaptives System. John Holland hat solche Systeme formal beschrieben [2]. Es entsteht ein Modell für solche Systeme, aus dem man dann Erkenntnisse ableiten kann. Nach Holland involviert ein CAS viele Komponenten, die adaptieren und voneinander lernen, während sie interagieren. Es zeichnet sich durch Agenten aus, die Signale senden und empfangen (Abb. 1). Die Agenten tun das simultan und erzeugen gleichzeitig eine große Menge von Signalen. (Das kommt uns aus Softwareprojekten bekannt vor, oder? Da reden auch alle Agenten durcheinander).

Agenten verwenden bedingte Aktionen. Je nachdem, welche Signale sie empfangen, reagieren sie mit Aktionen, z. B. mit dem Senden weiterer Signale oder mit echtem Einfluss auf ihre Umwelt (Abb. 2). Die Regeln dafür fassen sie in Paketen zusammen, die wie Unterprogramme ablaufen. Als Beispiel erwähnt Holland den Zitronensäurezyklus in den Zellen von sauerstoffverarbeitenden Lebewesen, vom Bakterium bis zum Elefanten. Dieser Zyklus besteht aus acht Proteinen, die in einer Schleife interagieren und dadurch die langsame Verbrennung steuern, die uns Wärme liefert.

Der spannendste Schritt in einem CAS kommt jetzt: Adaption und Evolution. Die Agenten verändern sich nämlich im Laufe der Zeit. Sie untersuchen, welche der Regeln, die sie ausgeführt haben, effektiv zum gewünschten Erfolg führten und welche nicht. Die effektiven Regeln versucht ein Agent dann weiter zu verwenden. Die ineffektiven versucht er, fallenzulassen und bessere Regeln als Ersatz zu finden.

Als Ergebnis bilden Agenten bewährte Muster heraus, wie zum Beispiel Fesselung oder Gambit im Schachspiel. Diese bilden dann Bausteine für neue Regeln, die ein Agent zukünftig anwenden möchte.

Zum Schluss fehlt uns noch der Sinn des Ganzen: Warum tun Agenten all das? Holland erklärt, dass jeder Agent eine Menge von Reservoirs füllen möchte, die seine Bedürfnisse repräsentieren. Dazu gehören z. B. Neugier, Akzeptanz, Macht, Freiheit, Ordnung und Status. Diese Reservoirs leeren sich kontinuierlich. Ist der Füllstand zu niedrig, bekommt der Agent ein „Reservoir fast leer“-Signal, auf das er dann durch Ausführen einer Regel reagieren wird.

Grenzen setzen, Feedback geben

Interessant ist, dass solche selbstorganisierenden Systeme nur mithilfe von Grenzen wirklich funktionieren. Wenn im System keine Grenzen für die Kommunikation vorhanden wären, hätten alle Agenten dieselbe Historie. Wenn alle dieselbe Historie hätten, würden sich zu wenige Unterschiede entwickeln. Dann würde eine darwinistische Auswahl nicht stattfinden können, die zu Agentenverhalten führt, das immer besser an die Situation angepasst ist. Es kann also auch ein „Zuviel“ an Kommunikation geben – erstaunlich, oder? Das erklärt, warum sinnvoll gesetzte Team- und Abteilungsgrenzen hilfreich sind.

Die Agenten in einem selbstorganisierenden System ersetzen weniger erfolgreiche durch effektivere Regeln und passen sich so immer besser der Situation an. Was wäre, wenn die Agenten kein Feedback über Erfolg und Misserfolg bekämen? Sie könnten dann nicht entscheiden, in welche Richtung die Adaption gehen soll, und die Selbstorganisation verlöre ihr Ziel.

Selbstorganisierende Menschen

Wenden wir uns wieder der Praxis zu, nämlich den Menschen in einer Software entwickelnden Organisation. Diese Menschen verhalten sich ähnlich wie Hollands Agenten. Selbstorganisierende Teammitglieder kennen ihr Ziel und fangen an, in die Richtung zu arbeiten. Aus dem Feedback, das sie vom Product Owner oder von Kunden, Anwendern und weiteren Stakeholdern bekommen, schließen sie auf Erfolg oder Misserfolg. Auch Feedback in Form von durchlaufenden oder fehlschlagenden Tests trägt zu diesem Eindruck bei.

Im Rückblick auf das, was das Team kürzlich getan hat, versuchen die Mitglieder herauszufinden, welche Regeln sie angewandt haben und ob sie effektiv waren. Sie passen die Regeln laufend an das Feedback an und verbessern sich so immer weiter.

Was brauchen Teams, um gute Ergebnisse zu bringen und sich auf diese Weise zu verbessern? Was geben Sie Ihren Teams also am besten gleich mit? Ich schlage Ihnen aus meiner Erfahrung drei Dinge vor:

• Geben Sie Ihren Teams Erfolgskriterien, zum Beispiel das strategische Ziel oder die Vision. Diese macht klar, was Erfolg für das aktuelle Vorhaben bedeutet. Auch Werte sind eine Art Erfolgskriterium: Was ist Ihnen wichtig? Was schätzen Sie und was finden Sie als Wert weniger wichtig?

• Die Teammitglieder können aus Vision und Werten ihre Arbeitsprinzipien ableiten: „So wollen wir hier arbeiten und entscheiden.“ Prinzipien, die jeder kennt, kürzen unnötige Diskussionen ab und sparen Energie.

• Lassen Sie Teammitglieder regelmäßig aufschreiben, was gut geklappt hat. Bewährte Muster und Praktiken kann man als Schritt-für-Schritt-Prozedur beschreiben und allen, nicht nur neuen Mitarbeitern, zur Verfügung stellen.

Strategisches Ziel

Machen Sie Ihre Vision, Ihr strategisches Ziel einfach und klar. Malen Sie mit den Führungskräften und den Teams gemeinsam ein Poster, das Sie in allen Teamräumen aushängen können. Roman Pichler hat mit seinem Product Vision Board [3] eine Vorlage dafür geliefert.

Fassen Sie die Vision in einem Satz, in einer Überschrift, zusammen. Sie können darin den Namen Ihres Produkts erwähnen, das die Teams erstellen. Sie können erwähnen, wie es die Welt der Benutzer verändern wird und welche enorme Auswirkung es auf das Wohlergehen Ihrer Firma haben wird. Beispiel: ACME Communicator: die einfache, schnelle Kommunikation für unsere Kunden und die neue Cashcow für uns. Beschreiben Sie dann auf dem Poster in Stichpunkten:

• Zielgruppe: Für wen ist das Produkt gedacht, das Sie gerade entwickeln wollen? Wie sieht die typische Benutzerin als Persona aus?

• Bedürfnisse: Was brauchen die Vertreter der Zielgruppe? Was wollen die Benutzer erreichen?

• Produkt: Welche Features hat es? Was ist daran so besonders? Was ist anders als bei der Konkurrenz? Oder, wenn es keine Konkurrenz gibt, was ist einfach anders als vorher?

• Wert: Was macht das Produkt wertvoll für den Kunden? Was kann er jetzt tun, das er vorher nicht konnte? In welchen Situationen kann er welche besonderen Vorteile damit erreichen?

Lassen Sie all das gemeinsam erarbeiten, erstellen Sie es nicht einfach am grünen Tisch. Hängen Sie das Poster am Schluss in der ganzen Entwicklungsabteilung aus, sodass es für alle sichtbar ist.

Werte

Finden Sie mit Ihren Teams heraus, welche Werte Ihnen und den Mitarbeitern wichtig sind. Was schätzen Sie, und was finden Sie nicht so wichtig? An welchen Werten soll sich die gemeinsame Arbeit orientieren? Was ist für den Umgang miteinander wichtig? Welche Werte gelten auf übergeordneter Ebene?

Wichtig ist, dass Sie herausfinden, ob die Werte im Team geteilt werden und nicht jedes Teammitglied wiederum andere Werte verfolgt, die mit den anderen nicht kompatibel sind. Werte können Sie nicht von oben anordnen oder von außen verändern. Es handelt sich um längerfristige Grundüberzeugungen: Man hat sie oder man hat sie nicht. Tabelle 1 zeigt einige Werte als Beispiele.

Arbeitsprinzipien

Finden Sie mit Ihren Teams gemeinsam heraus, welche Prinzipien für die Arbeit gelten sollen. Arbeitsprinzipien sind Richtlinien, die so gut begründet und dokumentiert sind, dass sie im Alltag nicht mehr hinterfragt werden müssen und deshalb helfen, Entscheidungen zu vereinfachen und zu beschleunigen. Sie gehen aus den Werten hervor, die die Firma hat und die jeder einzelne Mitarbeiter im Team hat. Tabelle 2 zeigt als Beispiel einige Prinzipien, die ein Kunde von mir kürzlich in einem Workshop mit seinen Teams und mir herausfand.

Arbeitsvereinbarungen

Kennen Sie die Prinzipien, nach denen Sie handeln wollen, können Sie anschließend Vereinbarungen für die gemeinsame Arbeit treffen, die mit diesen Prinzipien und mit den Werten im Einklang stehen. Diese Vereinbarungen bestehen aus einfachen klaren Sätzen. Beispiele:

• Für jeden gefundenen Fehler schreiben wir zuerst einen automatisierten Test, der den Fehler eindeutig reproduzierbar hervorruft. Erst dann fixen wir ihn. So verhindern wir, dass er unentdeckt nochmals auftaucht.

• Wir definieren „fertig“ für unsere Storys so: Die dokumentierten Akzeptanzkriterien sind erfüllt, und der Product Owner hat die Story abgenommen.

• Jede Woche findet das Team mindestens eine Gelegenheit, um Pair Programming zu üben.

• Neue Technologien, für die man mehr als eine Woche Zeit benötigt, um sie einsetzen zu können, betrachten wir als fragwürdig.

• Alle Teammitglieder machen beim Storyschreiben mit und helfen unserem Product Owner beim Füllen und Sauberhalten des Backlogs.

• Wir geben kein stilles Veto ab, sondern melden uns laut, wenn wir anderer Meinung sind.

• Kernarbeitszeit unseres Teams ist 9 bis 16 Uhr. Unser Stand-up ist um 09:30 Uhr. Für sonstige Meetings nehmen wir die Zeit zwischen 13 und 16 Uhr, und alle Teammitglieder stehen während dieser Zeit für Kommunikation zur Verfügung.

How-tos (Prozeduren)

Für ihre Arbeitsschritte sollten Führungskräfte und Teammitglieder How-tos erstellten, also beschriebene Arbeitsprozeduren, die man als neues Teammitglied oder als jemand, der es einfach lange nicht getan hat, Punkt für Punkt durchführen kann, ohne groß nachfragen zu müssen. Das reduziert den Einarbeitungsaufwand und sorgt für Sicherheit beim Ausführen schwieriger Arbeiten. Beispielthemen für solche Arbeitsprozeduren könnten sein:

• Entwicklungsumgebung X installieren

• Kontakt zum Code-Repository aufnehmen

• Code committen

• Eine Story live stellen

• Ergebnisse des Continuous-Build-Tools interpretieren

• Eine neue Komponente anlegen

• Architekturdokumentation ergänzen und veröffentlichen

• Ein User-Story-Gespräch mit dem Anwender führen und Ergebnisse im Team veröffentlichen

• Was kommt ins Wiki und was kommt in geschriebene versionierte Dokumente?

• Consumer-based Contract Test schreiben und veröffentlichen

• Zeitbudget mit dem Kunden aushandeln

Das How-to für jede Arbeitsprozedur kann im Wiki liegen und sollte mindestens die folgenden Fragen beantworten:

• Worum gehts?

• Für wen machen wir das und warum?

• Wer (Rolle) macht das normalerweise?

• Aus welchem Anlass (Zeitpunkt oder Auslöser)?

• Checkliste: Ergebnisse und deren Qualität

• Notwendige Tools, Zugriffsrechte und sonstige Voraussetzungen

• Schritt-für-Schritt-Anleitung

• Spezialitäten oder Risiken

Testen Sie Ihre How-tos einerseits mit Leuten, die eine bestimmte Prozedur noch nie gemacht haben, und mit erfahrenen Leuten, die es im Schlaf können. Erstere werden die Lücken finden, Letztere werden Ausnahmen von der Regel kennen und dadurch wertvolle Schritte zur Prozedur beitragen können.

Halten Sie die Qualität Ihrer How-tos hoch. Wenn eine Prozedur trotz des vorliegenden How-tos einmal nicht funktioniert, soll derjenige das How-to sofort anpassen, bei dem es nicht geklappt hat.

Mit strategischem Ziel, mit Arbeitsprinzipien und Arbeitsvereinbarungen und schließlich mit dokumentierten Prozeduren (How-tos) haben Sie einen schönen Werkzeugkasten, mit dem selbstorganisierte Teams bestens zurechtkommen.

Fazit und Ausblick

In diesem Artikel habe ich gezeigt, welche Vorteile es hat, wenn Ihre Teams selbstorganisierend arbeiten:

• Schnelle Entscheidungen im Team sparen Aufwand für den Chef

• Mehr Kundenorientierung, weniger Reibungsverluste in der Hierarchie

• Sinkende Kommunikationskosten

• Robuste, störungsresistente Teams

• Bessere Motivation bei allen Beteiligten

• Leichtere Anpassung an ein sich änderndes Business

• Weniger Risiko durch häufiges Feedback

Führungskräfte sind sich jedoch oft unsicher, wie stark sie eingreifen sollen, ohne die obigen wünschenswerten Eigenschaften zu verlieren. Als Denkmodell kann die Theorie der komplexen adaptiven Systeme helfen, aus diesem Managerdilemma herauszukommen. Wenn Sie Ihren Teams dabei helfen wollen, selbstorganisierend zu arbeiten, hier noch einmal die konkreten Schritte, die Ihnen nützen werden:

• Den Teams das strategische Ziel als Erfolgskriterium mitgeben

• Mit den Teams über Werte sprechen und Arbeitsprinzipien herausarbeiten lassen

• Bewährte Praktiken als Schritt-für-Schritt-Prozeduren (How-tos) aufschreiben lassen und allen zugänglich machen

• Häufig Feedback geben, sodass Erfolg offensichtlich werden kann

Wenn das alles gut klappt, wohin dann? Ist ein komplexes adaptives System erst einmal sauber zerlegt und dokumentiert, kann man es immer weiter verbessern. Verbesserung wird immer einfacher, wenn man sie übt. Als Führungskraft arbeiten Sie am System, während Ihre Teams größtenteils im System arbeiten. Ich helfe Ihnen auf Wunsch dabei.