Code bubbling - Von der Software zur Schaumware

Was passiert mit Code unter Druck? Er wandert ins UI. Das ist eine Erfahrung, die ich gerade in der letzten Zeit immer wieder gemacht habe. Wenn ich mir Code in Projekten oder auch in Übungsaufgaben ansehe, dann findet der sich in umso größerer Menge im UI oder UI-nah, je höher der (Termin)Druck im Projekt ist. Wie Bläschen in der Limo wandert er nach oben in die Präsentationsschicht (wenn man in Schichten denken will).

Ist ja auch klar: Wo keine Zeit ist, da fehlt Muße zum Denken. Ohne Denken, keine Planung. Ohne Planung, keine Vorstellung darüber, wie Code organisiert sein könnte.

Die einzige Struktur die zwangsweise jedoch immer vorhanden ist, ist die Struktur des UI. In Ermangelung von Alternativen trägt man also Code in die durch das UI vorgegebenen Strukturelemente (Steuerelemente) ein.

Das UI wird damit quasi zur Blume der Software: Dort schäumt der ganze Code, für den man in Ermangelung anderer Strukturelemente grad keine Zeit hatte, einen geeigneteren Ort zu finden.

Aber wie mit dem Schaum im Glas ist es schwer, den Code im UI in tiefere Schichten zu drücken. Ist er erstmal dort oben, dann bleibt er dort auch. Der Schau auf dem Bier verschwindet irgendwann zwar von allein, die Codeblasen im UI jedoch nicht. Und je länger der Druck im Projekt anhält, desto mehr Code, der eigentlich tiefer angesiedelt sein sollte, blubbert nach oben.

So ist es denn kein Wunder, dass manche Software eigentlich Schaumware (neudeutsch: foamware) ist.

Schade . Denn zumindest minimale Strukturen unterhalb des UI zu finden, in und an denen Code auch unter Druck geeigneter und vor allem leichter testbar aufgehängt werden kann, ist gar nicht so schwer. Sogar mit ein bisschen "mechanischem" Separation of Concerns ist da schon einiges zu erreichen. Denn eines ist gewiss: Code in einem Eventhandler eines Steuerelementes ist nie eine gute Sache, wenn der Code nicht unmittelbar mit dem Steuerelement oder seinen "Geschwistern" im UI zu tun hat.

Prost!

Blaues Wunder VSone 09

Das war sie wieder, die VSone 2009, die Frühjahrsentwicklerveranstaltung von ppedv. In München, am gewohnten Ort im Forum des Deutschen Museums - aber mit viel mehr Teilnehmern als in den letzten Jahren! Knapp 500 sollen gekommen sein. Es war eine gemütliche Atmosphäre in der Kinolobby unter dem ehemaligen IMAX-Kino.

Das Vortrags- und Workshop-Programm war gewohnt vielfältig, die Sprecherriege gemischt. Aus dem fernen Seattle war aber sogar Chris Sells angereist, um Microsofts Oslo vorzustellen.

Wer allerdings geglaubt hatte, zwei Tage lang eine ruhige Kugel bei Technologievorträgen schieben zu können, der erlebte sein blaues Wunder! Am Abend des ersten Konferenztages gab es kein Halten mehr: die Karneval-Narren waren los. Ja, sogar in München. Neno Loje, mich, Jürgen Kotz und Christian Wenz traf es wie alle anderen Teilnehmer. Auf der Abendveranstaltung galt "Hutpflicht":

Entschädigt für diese "Verunstaltung" unserer Charakterköpfe wurden wir dann jedoch zum Glück durch schmissige Darbietungen der Tanzgruppe des Karnevalsvereins Dorfen. Soviele Frauen waren bisher selten zu sehen auf Entwicklerveranstaltungen ;-)

Diesermaßen motiviert, waren die restlichen zwei Tage dann eine Kleinigkeit. Die Teilnehmer konnten sogar meinen Vortrag über die Concurrency Coordination Runtime (CCR) ohne Powerpoints ertragen und waren am Freitag von 9h bis 17h superaufmerksam in meinem Workshop zum Thema Anwendungsarchitektur und Parallelprogrammierung. Als im Workshop dann auch noch die Premiere des Xcoordination Application Space tadellos lief, war ich endgültig überzeugt von der VSone als gelungener "Kessel Buntes" Veranstaltung für .NET Entwickler und Sharepoint-Profis.

Beispielcode und Flipchart-Fotos des Workshops können hier heruntergeladen werden: http://www.ralfw.de/download/VSone09Workshop.zip. Es ist auch eine Vorabversion des Application Space dabei. Dessen Zweck ist es, Anwendungen sehr, sehr einfach von synchronen lokalen Komponenten über asynchrone lokale bis zu verteilten asynchronen Komponenten zu skalieren. Der Application Space ist Architekturinfrastruktur, die es wesentlich einfacher machen soll, in die Multi-Core- und Multi-Tier Programmierung einzusteigen. Aber davon ein andermal mehr.

Semantische Kontrakte mittels Tests definieren

Im Kern komponentenorientierter Softwareentwicklung steht die Entkopplung von Codeeinheiten durch separate Kontrakte. Die Definition, was eine Codeeinheit tun soll, ist zu trennen von den möglicherweise vielen Implementationen dieser Definition. Typischerweise werden Kontrakte als Interfaces und Implemenationen als Klassen realisiert:

Kontrakt:

public interface ITaschenrechnerRechenwerk
{
    int Add(int a, int b);
   ...

Implementation:

public class TaschenrechnerRechenwerk : ITaschenrechnerRechenwerk
{
    public int Add(int a, int b) {...}
    ...

Gerade wenn solche Kontrakte in einer eigenen Assembly unabhängig von jeder Implementation vorliegen, lassen sie sich wunderbar an Dienstleister in nah und fern versenden. Der Dienstleister muss in seiner Implementation nur die Kontraktassembly referenzieren und das Kontrakt-Interface implementieren. Fertig ist die kontraktkonforme Realisation. Wenn Sie so eine Realisation geliefert bekommen, können Sie sicher sein, dass sie zum Rest Ihrer Anwendung passt, die sich auf den Kontrakt verlässt.

Oder? Ist es wirklich so einfach?

Syntaktischer Kontrakt

Formal ja. Durch das unveränderliche Interface, dass der Dienstleister nur implementieren muss, ist sichergestellt, dass seine Realisation kompatibel ist. Allerdings ist sie nur syntaktisch kompatibel. Eine Client-Klasse kann ohne Kenntnis dieser konkreten Realisierung implementiert werden:

Client:

public class TaschenrechnerClient
{
    public void Run(ITaschenrechnerRechenwerk tr)
    {
        double r = tr.Add(2,3);
        ...

}

ITaschenrechnerRechenwerk tr = ...;
TaschenrechnerClient tc = new TaschenrechnerClient();
tc.Run(tr);

Ob tr eine Instanz von TaschenrechnerRechenwerk oder XYZ zugewiesen bekommt, ist TaschenrechnerClient egal. Das Interface stellt sicher, dass Client und Service-Implementation dieselbe "Sprache sprechen", dass sie zueinander passen. Mit einem Interface sorgen Sie nur dafür, dass eine Implementation "runde Hölzer" für "runde Löcher" bereitstellt. Das Interface beschreibt die Form einer Stecker-Steckdose-Kombination.

Semantischer Kontrakt

Was leistet aber ein Service, der die syntaktische Defintion erfüllt? Nur, weil ein Stecker in die Steckdose passt, heißt das noch lange nicht, dass an der Steckdose auch eine geeignete Spannung anliegt. Ein Service muss nicht nur so aussehen wie gewünscht, sondern auch leisten, was erwartet wird. Zu einer Komponente gehört deshalb nicht nur ein syntaktischer Kontrakt, sondern auch ein semantischer.

Der semantische Kontrakt baut auf dem syntaktischen auf und beschreibt die Erwartungen an den Service. Eine ITaschenrechnerRechenwerk-Implementation soll nicht nur eine Methode mit Namen Add(), double-Resultat und zwei double-Parametern bieten, sondern eben auch tun, was man von einer Methode mit Namen "Add" erwartet.

Wie aber lassen Sie den Dienstleister wissen, was sie von einer Kontraktimplementation in semantischer Hinsicht erwarten? Trotz aller Bemühungen um formale Spezifikationen haben wir noch kein Mittel, um semantische Kontrakte so einfach wie syntaktische zu beschreiben. Sie werden also nicht umhin kommen, der Kontrakt-Assembly mit dem syntaktischen Kontrakt noch eine Beschreibung der Semantik beizulegen. Das könnten Sie in Form von Kommentaren in den Sourcen des syntaktischen Kontrakts tun oder mit einem separaten PDF-Dokument.

Und dann? Wenn Sie eine Implementation vom Dienstleister bekommen, was tun Sie dann? Wie stellen Sie sicher, dass die nicht nur den syntaktischen, sondern auch den semantischen Kontrakt erfüllt? Das müssen Sie testen. Oder Sie verlassen sich darauf, dass der Dienstleister es genügend getestet hat. Vielleicht liefert er ja einen Unit Test Testbericht mit und auch noch eine Angabe zur Codecoverrage des Tests.

Reicht das aber? Nein. Denn das sagt nur aus, dass der Code des Dienstleisters den Tests des Dienstleisters genügt. Darauf dürfen Sie sich nicht verlassen. Vielleicht hat der Dienstleister ja Ihre Beschreibung des semantischen Kontrakts falsch verstanden. Dann hat er wunderbare Tests gebaut, die alle fehlerfrei laufen - aber leiden testen sie das Falsche.

Tests als semantische Kontrakte

Wenn Sie sich wirklich auf einen Dienstleister verlassen wollen - der kann ja sogar im eigenen Team sitzen -, dann statten Sie ihn nicht nur mit einem unzweideutigen syntaktischen Kontrakt aus, den er nicht mehr interpretieren, sondern nur noch implementieren muss, sondern auch mit einem solchen semantischen. Auch ohne spezielle Spezifikationssprache geht das: mit Unit Tests. Es ist ganz einfach.

Als erstes definieren Sie weiterhin Ihren syntaktischen Kontrakt (s.o.).

Dann aber schreiben Sie keine länglichen Dokumente, um zu erklären, was eine Implementation können soll. Stattdessen schreiben Sie sofort Unit Tests, die alle Aspekte der Kontraktsemantik prüfen. Genau: Sie schreiben Unit Tests, ohne eine Implementation zu haben.  Das sollte kein Problem sein, denn zu einem syntaktischen Kontrakt, den Sie ersonnen haben, sollten Sie auch Erwartungen formulieren können, wie er sich zur Laufzeit verhält, wenn Sie ein seiner Implementationen mit diesen oder jenen Parametern aufrufen. Für den obigen Kontrakt kann das so aussehen:

Semantischer Kontrakt:

[TestFixture]
public class ExerciseITaschenrechnerRechenwerk
{
    ...

    [Test]
    public void Check_add()
    {
        ITaschenrechnerRechenwerk tr;
        ...

        Assert.AreEqual(5, tr.Add(2, 3));
    }
    ...

Ein ganz normaler Unit Test für eine Implementation von ITaschenrechnerRechenwerk. Der syntaktische Kontrakt ist durch das Interface vorgegeben, der semantische durch das Assert(): Wenn eine Funktion Add() vorhanden ist (Syntax), dann erwarten Sie, dass sie für die Parameter 2 und 3 das Ergebnis 5 zurückliefert. Das ist unzweideutig. Darüber muss kein Dienstleister mehr mit Ihnen diskutieren. Seine Implementation muss nur diese semantische Anforderung erfüllen. Punkt. Wenn er nicht versteht, was "Add" bedeutet, dann soll er halt bei Ihnen nachfragen. Ob sein Verständnis am Ende zu korrektem Code im Sinne Ihres Kontraktes geführt hat, beweist ein erfolgreicher Test.

Semantische Kontrakte ohne Implementation definieren

Klingt plausibel, oder? Wie können Sie nun aber vor jeder Implementation den semantischen Kontrakt formulieren? Mit Mock-Objekten. Ob obigen semantischen Kontrakt steht hinter tr keine "richtige" Implementation, sondern nur ein Mock-Objekt, dass die im Assert() formulierte Erwartung erfüllt. Nicht mehr, nicht weniger. Das kann mit Rhino Mock zum Beispiel so aussehen:

MockRepository mocks = new MockRepository();
tr = mocks.StrictMock<ITaschenrechnerRechenwerk>();
Expect.Call(tr.Add(2,3)).Return(5);
mocks.ReplayAll();

Ohne Frage funktioniert das bei Ihnen, wenn Sie den semantischen Kontrakt formulieren. Den Code können Sie auch dem Dienstleister geben - aber in Bezug auf dessen Implementation des Kontrakts ist er nutzlos. Er ist genauso passiv wie ein PDF-Dokument. Der Dienstleister kann ihn nur lesen, aber nicht auf seine Implementation anwenden.

Das Problem ist, dass Sie tr fest ein Mock-Objekt zuweisen. Wie soll das der Dienstleister durch seine Implementation des syntaktischen Kontrakts ersetzen? Denn nur dann kann schon er vor Auslieferung an Sie seine Implementation auch gegen den semantischen Kontrakt testen.

Als Lösung bietet sich eine kleine Factory-Methode an:

[TestFixture]
public class SemanticContract_ITaschenrechnerRechenwerk
{
    protected virtual
             ITaschenrechnerRechenwerk
             CreateInstanceToExercise(Func<ITaschenrechnerRechenwerk> factory)
    {
        return factory();
    }

    [Test]
    public void Check_add()
    {
        ITaschenrechnerRechenwerk tr;
        tr = CreateInstanceToExercise(delegate
                {
                    MockRepository mocks = new MockRepository();
                    tr = mocks.StrictMock<ITaschenrechnerRechenwerk>();
                    Expect.Call(tr.Add(2,3)).Return(5);
                    mocks.ReplayAll();
                    return tr;
                });

        Assert.AreEqual(5, tr.Add(2, 3));
    }
    ...

Die Factory-Methode liefert eine Instanz des zu prüfenden Kontrakts zurück. In Abwesenheit einer realen Implementation bekommt sie die als Parameter in Form einer weiteren Factory-Methode geliefert. Der anonyme Delegat erzeugt das Mock-Objekt, das bei Ihnen den semantischen Kontrakt garantiert erfüllt.

Wenn Sie eine Testklasse in dieser Weise formulieren, läuft sie wunderbar in Ihrem Testrunner (z.B. ReSharper). Ganz ohne eine echte Kontraktimplementation. Und sie können sie mit dem syntaktischen Kontrakt als separate Assembly an den Dienstleister schicken. Ob Sie dann noch zusätzlich Kommentare in den Kontrakt-Quellen oder ein PDF brauchen, müssen Sie beurteilen. Jedenfalls müssen Sie sich nicht mehr auf guten Glauben verlassen, ob der Dienstleister solche Dokumentation verstanden hat. Er muss nur darlegen, dass seine Implementation erfolgreich mit dem semantischen Kontrakt geprüft wurde.

Semantische Kontrakte gegen Implementation prüfen

Und wie prüft der Dienstleister seine Implementation gegen den semantischen Kontrakt? Oder wie prüfen Sie eine Implementation dagegen? Das ist ganz einfach: Sie müssen dem semantischen Kontrakt zur Laufzeit nur eine echte Implementation unterschieben statt der default Mock-Objekte. Dazu genügt aber die Ableitung einer neuen Testklasse von der des semantischen Kontrakts:

[TestFixture]
public class CheckTaschenrechnerRechenwerk
                             : SemanticContract_ITaschenrechnerRechenwerk
{
    protected override
             ITaschenrechnerRechenwerk
             CreateInstanceToExercise(Func<ITaschenrechnerRechenwerk> factory)
    {
        return new Dienstleister.TaschenrechnerRechenwerk();
    }
}

Diese Klasse kann der Dienstleister mit seinem Testrunner genauso ausführen wie Sie Ihre Testklasse des semantischen Kontrakts. Nur wird jetzt nicht gegen die Mock-Objekte geprüft, die die factory-Funktion erzeugen würde, sondern gegen die wahre Implementation. Bei diesem Akzeptanztest wird die factory-Funktion aus den Testmethoden einfach nicht berücksichtigt.

Zusammenfassung

Mehr ist nicht nötig für vollständige Kontraktdefinitionen für Komponenten:

1. Definieren Sie einen syntaktischen Kontrakt in Form von Interfaces und/oder (abstrakten) Klassen in einer eigenen Assembly.
2. Definieren Sie zum syntaktischen Kontrakt einen semantischen Kontrakt in Form von Tests in einer eigenen Assembly.
3. Geben Sie dem Dienstleister für die Realisierung der Komponente sowohl den syntaktischen wie auch den semantischen Kontrakt und verlangen Sie, dass er nur an Sie ausliefert, wenn auch der semantische Kontrakt bei ihm fehlerfrei ausgeführt wird.

Da Sie zum Zeitpunkt der Definition des semantischen Kontrakts keine Implementation vorliegen haben, benutzen Sie Mock-Objekte, um Ihre Erwartungen zu erfüllen. Der Dienstleister muss diese Mock-Objekte zur Überprüfung seiner Implementation dann nur leicht ersetzen können. Mit einer abstrakten Factory-Methode wie oben gezeigt, ist das aber leicht.

So entwickeln Sie zwar noch nicht wirklich Test-driven, aber zumindest Test-first innerhalb von Contract-first: vor jede Implementation setzen Sie einen syntaktischen und (!) einen semantischen Kontrakt.

Aspektorientiert diskutieren - Weg und Ziel entkoppeln vermeidet Konflikte [OOP 2009]

Warum fällt Veränderung oft schwer? Liegt es wirklich vor allem daran, dass alte Gewohnheiten schwer zu "entlernen" sind? Teaching an old dog new tricks: ist das wirklich so mühsam? Gestern meine ich einen Zipfel von der Erkenntnis erhascht zu haben, dass das nicht wirklich der Grund ist. Wir machen uns Veränderung vielmehr selbst schwer.

Gestern saß ich in meinem Lieblingscafé in Hamburg, dem elbgold am Mühlenkamp, und wollte eigentlich nur meinen Lieblingskuchen genießen, Schokosahne - leider nur am Wochenende -, da bekam ich leider keinen Platz. Zunächst. Dann bot mir aber ein mir vom Sehen her bekannter anderer "elbgold-Bewohner" einen Hocker bei sich an und wir kamen ins Gespräch. Kaum sah er, dass ich ein C#-Buch unterm Arm hatte, outete er sich als Java-Jünger. So kamen wir denn unvermeidlich auch auf Clean Code Developer (CCD) als plattformunabhängige Qualitätsoffensive.  Und wir kamen auf die Defizite im Vorgehen in seiner Firma.

Issue Tracking als Veränderungsproblem

Da ist zum Beispiel das Thema Issue Tracking. Damit hat man dort noch nicht soviel am Hut. Man beginne gerade sich zu bemühen, Aufgaben im Nachhinein zu erfassen, also das, was man schon getan hat. Aber mit einer proaktiven Liste von Fehlern oder gar Anforderungen... nein, darüber diskutiere man noch. Es sei alles nicht so einfach: der Chef müsse noch überzeugt werden, ein Tool sei zu entscheiden, das Team hätte unterschiedliche Vorstellungen usw.

Ich habe meinem Gesprächspartner dann natürlich aus aktuellem Anlass gleich den soziokratischen Konsent als Hilfsmittel für die Entscheidungsfindung nahegelegt. Statt die Verantwortung auf den Chef abzuwälzen (Autokratie) oder langwierig unter allen einen Konsens für eine Abstimmung zu erzielen (Demokratie) sei auch ein anderes Vorgehen möglich - und wahrscheinlich sogar zielführender.

Mit diesem Rat bin ich immer noch zufrieden. Konsent ist ein allgemein hilfreiches Instrument zur Entscheidungsfindung. Dennoch oder gerade deshalb geht Konsent nicht die Wurzel des Übels an.

Was macht die Situation in der Firma meines Gesprächspartners so unerquicklich. Was macht die Veränderung zu konsequentem Issue Tracking so schwer? Die neue Gewohnheit, eine qualitätssteigernde Praktik des orangen Grades des CCD, hat es schwer Fuß zu fassen im immer eiligen Tagesgeschäft, bei dem alles wichtig+dringend ist - außer eben solcher Veränderung.

Ist Issue Tracking an sich schwierig? Braucht man dafür schwer zu erlernde Fertigkeiten? Ist es Professoren vorbehalten, Issue Tracking zu verstehen? Oder kostet Issue Tracking schlicht soviel Zeit, dass man dafür eigentlich tagelang den Betrieb schließen müsste?

Alles quatsch! Issue Tracking ist kinderleicht und schnell gemacht.

Also nochmal: Wo liegt das Problem?

Weg und Ziel entkoppeln

Ich glaube, die Veränderung hin zu Issue Tracking ist so schwierig, weil das Team ein undifferenziertes Bild davon hat. Issue Tracking erscheint als großer Klumpen, den es ganz oder gar nicht zu schlucken gilt. Man versucht eine die Entscheidung zu treffen und umzusetzen "Wir machen Issue Tracking so und so. Punkt."

Hört sich doch auch ganz normal an. Man entscheidet sich für oder gegen Issue Tracking in einer bestimmten Weise. Was sonst?

Und genau da liegt der Hase im Pfeffer. Das ist nicht-agiles Denken. Das ist Denken aus einer Welt, die erstens überschaubarer war und zweitens viel langsamer und weniger vollgepackt.

So ist es ja aber eben nicht in der Firma meines Gesprächspartners. Dort steht man ständig unter Kundendruck. Neue Features eben noch einflicken, Releases schnell noch zusammenbasteln, Fehler korrigieren, dann wieder neue Features und die Aufwandsabschätzung für das Angebot des Chefs nicht vergessen... Wie so oft findet die Arbeit im ständigen "emergency mode" statt. Da ist die Welt einfach nicht überschaubar, weil man sie durch einen Tunnel sieht. Es gibt kaum Spielräume.

Das kann und soll man beklagen. Am Ende lässt sich diese grundlegende Situation selbst aber nicht schnell ändern. Sie definiert die Rahmenbedingungen für die Einführung von Issue Tracking und sonstigen Veränderungen.

Was also tun? Wie kann es sich das Team einfacher machen, Issue Tracking einzuführen?

Meine Erkenntnis derzeit ist, ein großer "Veränderungsklumpen" sollte zunächst grundsätzlich aufgeteilt werden in die Aspekte Ziel und Weg. Der Weg ist also mal nicht das Ziel. Weg und Ziel sind vielmehr deutlich zu unterscheiden. Die Zugspitze ist nicht die Zugspitzbahn. Mir reicht auch nicht die Fahrt mit der Zugspitzbahn ohne längeren Aufenthalt auf dem Gipfel. Und für den Aufenthalt auf dem Gipfel muss ich nicht unbedingt mit der Zugspitzbahn dorthinkommen.

Was ist mit dieser Unterscheidung gewonnen? Das Team kann jetzt zwei Fragen diskutieren:

1. Wollen wir Issue Tracking einführen?
2. Wie wollen wir Issue Tracking einführen?

Der Vorteil liegt erstens in einem viel besseren Verständnis davon, was alle Beteiligten unter Issue Tracking überhaupt verstehen. Da mögen die Meinungen nämlich schon auseinandergehen. Solche Meinungsdifferenzen, wenn sie nicht aufgedeckt werden, behindern ansonsten den Veränderungsprozess im Sinne eines "Veränderungsklumpens".

Aus der Diskussion darüber, was Issue Tracking ist, welche Formen es gibt, wo die Vor-/Nachteile liegen usw. ergibt sich dann ein Ziel. Dazu kann das Team einen ersten Beschluss fassen - im besten Fall mittels Konsent. Der Beschluss kann z.B. lauten: "Wir führen Issue Tracking für Anforderungen und Fehler für alle Projekte ein."

Der Trick dabei: Dieser Beschluss ist viel einfacher zu fassen als der über den bisherigen "Veränderungsklumpen". Die Vorteile von Issue Tracking ja liegen auf der Hand. Dass jemand es nicht haben möchte - ganz unabhängig davon wie man das schaffen kann -, ist schwer vorzustellen. Nichtsdestotrotz ist es wichtig, genau solche Einmütigkeit explizit zu machen. "In Notzeiten", wenn die Veränderung mal wieder schwer fällt, kann man sich dann nämlich gegenseitig daran erinnern. "Wir haben doch alle dasselbe Ziel. Wir sind alle für Issue Tracking. Lasst uns das Ziel jetzt nicht aus den Augen verlieren."

Wenn nun das Ziel klar ist, dann kann sich das Team an die zweite Frage machen. Wie wollen wir das Ziel erreichen? Welche Schritte wollen wir in seine Richtung machen?

Das ist eine ganz andere Frage als die erste, grundsätzliche, was das Ziel eigentlich sei. Während man den Weg diskutiert, kann man jetzt auch gewiss sein, einer Meinung zu sein, dass das Ziel überhaupt erreicht werden soll. Die Diskutanten richten kohärent ihre Energie darauf, einen Weg zu finden, um gemeinschaftlich ans Ziel zu kommen.

Oft ist es nun gerade diese Diskussion, die von Differenzen und Missverständnissen geplagt ist. Aber das ist jetzt nicht mehr so schlimm. Denn da sich alle einig über das Ziel sind, haben alle ein Interesse, den "Sand im Getriebe" aufzuspüren und unschädlich zu machen.

Baby Steps

Mit dem Fokus auf dem Weg ist es nun auch einfacher, eine sehr praktible Technik anzuwenden, um ihn zu gehen: die Technik der kleinen Schritte. Der gleichermaßen komische wie tiefgründige Film "Was ist mit Bob?" ("What about Bob?") mit Bill Murray und Richard Dreyfuss sagt dazu "Baby Steps".

Veränderungen lassen sich am besten mit kleinen Babyschritten erreichen. Sich nicht zuviel vorzunehmen, sich Unsicherheiten und Fehlschläge zu gestatten, das ist eines der Geheimnisse erfolgreicher Veränderung. Wer nur kleine Schritte macht, kann seinen Weg auch immer wieder korrigieren. Denn Korrektur ist sicher nötig: unvorhergesehenes passiert, auf das man reagieren muss; Feedback unterschiedlicher Art signalisiert, dass man vom Weg abgekommen ist.

Der ursprüngliche undifferenzierte Entschluss für Issue Tracking mag so ausgesehen haben: "Wir führen Issue Tracking ab dem 1.10.2008 für alle Projekte ein und benutzen Bugzilla für alles: Anforderungen und Fehler und Design Issues." Dass führt notwendig zu Problemen. Jedes Problem mit dem Wie (z.B. Bugzilla) stellt dann auch das grundsätzliche Was (Issue Tracking) in Frage.

Wenn Was (Ziel) und Wie (Weg) aber getrennt sind und der Weg auch noch in Baby Steps aufgeteilt ist... dann ist es viel einfacher. Was und Wie geraten nicht mehr in Konflikt. Teammitglieder geraten nicht mehr in Konflikt. Naja, zumindest nicht mehr so leicht.

Mit der konsentbasierten Grundsatzentscheidung - "Wir führen Issue Tracking für Anforderungen und Fehler für alle Projekte ein." - ist das Team viel freier, kleine, auch im Tagesgeschäft gangbare Schritte festzulegen. Die könnten z.B. sein:

1. Issue Tracking nur für Fehler mit Excel für das Projekt A über 4 Wochen.
2. Issue Tracking für Fehler und Anforderungen mit Excel für das Projekt A über 4 Wochen.
3. Issue Tracking für Fehler und Anforderungen mit Bugzilla für das Projekt A über 4 Wochen.
4. Issue Tracking für Fehler und Anforderungen mit Bugzilla für Projekt A und B über 4 Wochen.
5. Issue Tracking für Fehler und Anforderungen mit Bugzilla für alle Projekte

Sieht aus wie ein Spring Backlog? Ist ein Backlog. Ein Backlog ist nichts anderes als eine Folge von geplanten Schritten. So sind wir denn also beim Wie zu einem Thema auf dem vertrauten Terrain agilen Vorgehens. Das sollte es einfach machen, die Unterscheidung zwischen Ziel und Weg zu treffen.

Jeder dieser Babyschritte kann separat beschlossen werden - im Konsent. Es müssen zunächst auch gar nicht soviele sein. Mit dem gemeinsamen Ziel könnten in einer ersten Beschlussrunde auch nur Schritte 1 bis 3 ins Backlog kommen plus einer expliziten Entscheidung über den weiteren Weg:

1. Issue Tracking nur für Fehler mit Excel für das Projekt A über 4 Wochen
2. Issue Tracking für Fehler und Anforderungen mit Excel für das Projekt A über 4 Wochen
3. Issue Tracking für Fehler und Anforderungen mit Bugzilla für das Projekt A über 4 Wochen
4. Entscheidung über Bugzilla und den weiteren Weg

Das Schöne an der Entzerrung von Ziel und Weg ist, dass damit der Weg quasi befreit ist von irgendwelcher festgefügter Konkretheit. Er muss nicht in ganz bestimmter Weise zwangsläufig verlaufen. Er kann geplant und später korrigiert werden. Jeder Schritt muss im Moment des Beschluss nur in den Augen aller einen Beitrag zur Erreichung des Zieles leisten. Stetiger Fortschritt ist wichtiger als gerade Linie.

Dass die beschlossenen Schritte auch abgegangen werden, ist dann eine Sache recht einfacher Kontrolle. Dabei kann Scrum helfen. Welche Schritte beschlossen werden sollen, wie die Prioritäten aussehen, das liegt jedoch außerhalb des Vorgehensmodells.

Bei Veränderungsprozessen gibt es keinen externen Kunden. Die Organisation selbst ist vielmehr der "Kunde" oder genauer: die Organisationsführung. Da kommt die Soziokratie wieder ins Spiel. Es sollte eine Kreishierarchie sein, die das Ziel von Veränderung und den Weg dorthin festlegt. Sie definiert die Schritte und delegiert die Ausführung dann an einen Kontrollprozess.

Veränderung = Aspektorientierung + Soziokratie + Scrum

Veränderungen aspektorientiert in Ziel und Weg zu zerlegen und dann mit Soziokratie und Scrum anzugehen, hat mehrere Vorteile:

• Durch die differenzierte aspektorientierte Sicht werden Missverständnisse/Konflikte vermieden und gleichzeitig die Energie in Richtung Ziel gebündelt. Kohärenz entsteht durch das gemeinsame Ziel.
• Durch explizite Beschlüsse für den Weg entsteht eine Schrittfolge, die korrigierbar und erweiterbar ist. YAGNI und KISS lassen sich nicht nur auf Code anwenden, sondern auch auf solche Schrittfolgen. Probleme auf dem Weg färben nicht auf das Ziel ab. Kohärenz wird erhalten und gleichzeitig Agilität gewonnen.
• Eine soziokratische Organisation all derjenigen, die von Veränderungen betroffen sind, vermeidet Konflikte, weil alle eingebunden sind und ihre Bedürfnisse einbringen können; und sie erhöht das Wissen über mögliche Hindernisse auf dem Weg.
• Eine Kreishierarchie der "Betroffenen" vereinfacht den Rahmen für Veränderung. Es gibt nicht mehr hier die Führung, dort die Betroffenen und dann einen Prozess. Im Sinne von Scrum sind da vielmehr nur noch "Kunde" (Kreishierarchie der "Betroffenen") und "Team" (operative Organisation der "Betroffenen"). Die Koordination der Beteiligten im Sinne der beschlossenen Schrittfolge ist damit sehr klar.

Veränderungen unter Druck haben durch klare Trennung der Aspekte Ziel und Weg, aber auch Führung und operatives Geschäft eine größere Chance auf Erfolg.

• Die, die sich verändern sollen, formieren sich als Führer ihres eigenen Veränderungsprozesses in einer soziokratischen Kreishierarchie.
• Die Veränderung selbst findet in kleinen Schritten in einem iterativen Vorgehensmodell im Tagesgeschäft statt. (Scrum schreint mir da sehr naheliegend.)
• Ergebnisse werden wiederum an die Kreishierarchie gemeldet, die als "Kunde" den Weg jederzeit verändern kann.

Nach Reflektion des gestrigen Gesprächs scheint mir weniger nicht mehr wirklich zielführend in der heutigen Zeit.

Agil entscheiden - Soziokratie statt Autokratie und Demokratie [OOP 2009]

Wo positioniert sich Soziokratie im Unternehmen? Welche Struktur hat soziokratische Führung? Diese beiden Fragen habe ich in den bisherigen Postings beantwortet. Das mag für Sie schon teilweise gewöhnungsbedürftig gewesen sein. Aber das ist noch gar nichts ;-) Denn jetzt zur Frage, wie Soziokratie sozusagen innen funktioniert. Wie geht Soziokratie mit dem Feedback um, das in seine Kreishierarchie hineinfließt? Wie entscheidet Soziokratie, wie fassen die Kreismitglieder Beschlüsse? Die Antworten darauf scheiden viele Geister. Nichtsdestotrotz finde ich sie hochspannend, sehr zeitgemäß und kompatibel gerade zur Softwarebranche.

Kritik des Üblichen

Um den Wert der Soziokratischen Methode (SKM) wirklich fühlen und genießen zu können, ist es vielleicht nützlich, sich zunächst die üblichen Methoden zur Führung mit ihren Vor- und insbesondere ihren Nachteilen zu vergegenwärtigen.

Da wäre die altehrwürdige Autokratie. Sie entsteht quasi spontan als default, wenn keine andere Führungsform bewusst gewählt wird. In der Autokratie sagt einer an und die anderen gehorchen. Wer ansagt, hängt von der Organisation ab. Es mag der im Hinblick auf den Zweck der Organisation beste sein, der, der am kenntnisreichsten ist, am schnellsten, am stärksten, am erfahrensten. Oder es ist der, der einfach Macht über andere hat, weil er begehrte Ressourcen verwaltet oder Schaden zufügen kann. Einerlei, denn der Effekt ist derselbe: Anweisungen fließen von oben nach unten durch eine Hierarchie. Informationen von unten nach oben hingegen haben es schwer.

Die Vorteile der Autokratie: Effizienz und Komplexitätsreduktion. Die Nachteile: Wahrnehmungsschwäche, Starrheit, Arroganz. (Vom vielleicht idealen Fall eines wirklich in der Sache kompetenten Autokraten, der auch noch gütig und offen ist, will ich einmal absehen. Den gibt es eigentlich nur noch in der überschaubaren Welt der Märchen.)

Autokratie ist an sich keine schlechte Führungsform. Sie ist nur ein Mittel, ein Werkzeug, das selbstverständlich in geeigneten Situationen gute Dienste leisten kann. Wenn es schnell gehen soll und ein Autokrat tatsächlich den Überblick hat, dann mag Autokratie sogar die beste Form sein, um im allgemeinen Sinne zu führen.

Angesichts der Komplexität unserer Welt möchte ich jedoch den Begriff "Führung" hier grundsätzlich streichen. Wie im letzten Abschnitt meines vorherigen Postings ausgeführt, wird im operativen Geschäft nicht geführt, sondern koordiniert. Autokratie hat deshalb eigentlich an keinem anderen Einsatzort mehr Zweck als im operativen Geschäft, weil ihre Nachteile der Geschäftsführung in heutigen Märkten im Wege stehen. Also kann Autokratie nur noch geeignet sein für Koordinationsaufgaben. Das sieht die Soziokratie auch so und sperrt sich daher nicht gegen autokratische Strukturen im Tagesgeschäft. Ein Meister darf seine Gesellen autokratisch im operativen Geschäfts koordinieren. Ein Vertriebsleiter darf sein Team im Sinne der Aufgaben des Tagesgeschäftes autokratisch koordinieren. Der Werkschutzleiter darf seinen Sicherheitsleuten auch autokratisch Aufgaben zuteilen - allemal, wenn Gefahr im Verzug ist. Autokratie hat also auch in der heutigen Zeit ihren Wert, weil sie sehr effizient sein kann.

Gerade zur Führung großer und vielfältiger sozialer Systeme ohne äußeres Ziel ist Autokratie aber seit langer Zeit schon aus der Mode gekommen. Ihre Nachteile waren zu gewichtig, als dass sie von der Basis der Hierarchien noch ertragen wurden. Die Menschen wollten nicht immer unter einer Macht über sie leiden. Sie wollten selbst Anteil an der Macht haben, sie wollten sich mehr selbst bestimmen. Deshalb setzen wir heute in der Politik und auch in anderen Organisationen auf die Demokratie. Mit der Demokratie bestimmt nicht mehr einer über viele, sondern viele über sicht selbst. Sie führen sich selbst, sie legen zusammen ihre Grundsätze fest, sie treffen gemeinsam Entscheidungen. Ob die Vielen dabei alle direkt zu Wort kommen oder nur vermittels Repräsentanten, ist nicht so wichtig. Den Kern der Demokratie macht die Bestimmung durch eine Mehrheit aus.

Das ist sicherlich ein Fortschritt gegenüber der Autokratie, die letztlich nur die Bedürfnisse des einen Mächtigen berücksichtigt. Aber Demokratie hat auch ihren Preis! Ganz offensichtlich ist sie nicht effizient. Wenn es schnell gehen muss, dann kann man nicht erst zu Diskussion und Abstimmung zusammenkommen. Bei Polizeieinsätzen wird immer noch nicht demokratisch, sondern autokratisch koordiniert. Deshalb ist die Demokratie eigentlich auf die Führung von Organisationen beschränkt. Grundsatzentscheidungen trifft man demokratisch, ausgeführt/koordiniert wird autokratisch.

Weniger offensichtlich ist Demokratie jedoch nicht nur ineffizient, sondern ebenfalls "arrogant". Das bemäntelt sie allerdings nach Kräften. Sie erhebt es sogar zu einer Tugend, sich dieser "Arroganz" zu unterwerfen. Das mag merkwürdig klingen, doch schon ein simples Rechenbeispiel legt den Finger in die Wunde: Wenn ein Verein mit 100 Mitgliedern einen Beschluss mit der üblichen einfachen Mehrheit fassen will - zum Beispiel könnte es um die Farbe des neuen Anstrichs für das Vereinsgebäude gehen -, dann werden die Bedürfnisse von 49 Mitgliedern nicht berücksichtig, wenn sich 51 für Pink entscheiden. Je größer die demokratische Gruppe, desto näher an 50% liegt der Anteil derer, über die eine Abstimmung sich mit einfacher Mehrheit hinwegsetzt! Bei allen Segnungen, die wir durch Demokratie erfahren haben, sollten wir das nicht vergessen. Selbst vielfach vorteilhafte Demokratie darf nicht zum Dogma verkommen. Auch für sie gilt: das Bessere ist der Feind des Guten. Demokratie ist auch nur ein Werkzeug mit bestimmten Eigenschaften und geeigneten Einsatzszenarien und kein Selbstzweck.

"Arrogant" habe ich Demokratie hier etwas polemisch genannt, weil sie sich im Grunde nicht für die Minderheitsmeinung interessiert. Ihre Regel lautet: die Mehrheit bekommt Recht. Für die Mindertheit hat sie nur ein lakonisches "Pech!" übrig. So ist es zumindest am Ende nach einer Abstimmung mit einer Mehrheit. Der Weg dahin kann allerdings steinig sein. Was, wenn es zunächst keine Mehrheit im Sinne des Abstimmungsverfahrens gibt? Vielleicht gibt es zunächst im Verein drei Meinungen zur Farbe des Vereinsgebäudes und hinter keiner stehen die notwendigen 51 Stimmen für einen demokratischen Beschluss. Dann muss zunächst ein Konsens erarbeitet werden zwischen genügend vielen Mitgliedern, um mindestens 51 Stimmen auf eine Farbe zu vereinen.

Das mag noch trivial sein. Letztlich unterscheidet es sich aber nicht von der Situation, wenn Regierung und Bundesrat von unterschiedlichen Parteien bzw. Koalitionen dominiert werden. Entscheidungen kommen dann erst durch Konsensverhandlungen zustande. Und die können sich sehr, sehr lang hinziehen. (Empfehlenswerte Lektüre dazu: "Konsens ist Nonsens") Das mag zwar vor allem ein Problem des deutschen Föderalismus sein - doch letztlich steckt das Risiko "Konsensfalle" schon in der ihm zugrundeliegenden Demokratie.

Was bedeutet das nun alles für die Unternehmensführung? Die ist zunächst zurecht autokratisch. Nur Autokratie verspricht genügend Effizienz, um den Unternehmenszweck "Gewinnerwirtschaftung für den Eigner" zu erreichen. Der Preis dafür ist allerdings hoch: geringer Wahrnehmungshorizont der Organisation und geringe Motivation der Mitarbeiter.

Alle Mann ins Boot!

Mit dem Gedanken echt orthogonaler Führung im Hinterkopf könnten Sie ja nun aber fragen: Warum nicht die Führung demokratisieren und das operative Geschäft autokratisch lassen? Wären da nicht die Vorteile der Demokratie - viel Feedback durch breite Beteiligung sowie hohe Motivation durch Selbstbestimmung - und Effizienz der Autokratie vorteilhaft verbunden?

Nein! So einfach ist es leider nicht, auch wenn der Gedanke natürlich löblich ist ;-) Das operative Geschäft würde zwar nicht ausgebremst... aber womöglich die Geschäftsführung. Die "Konsensfalle" lauert überall.

Noch schlimmer jedoch: Demokratie löst das Motivationsproblem nicht wirklich. Wie oben schon gesagt sind 49,9...% Prozent der Abstimmenden immer unzufrieden. Darüber langfristig mit dem Hinweis hinwegzugehen, so sei es halt und ein guter Demokrat füge sich der Mehrheit, ist kontraproduktiv. Nicht berücksichtigte Bedürfnisse lassen sich nicht so einfach rational zurückstellen. Jenachdem, worum es bei einer demokratischen Entscheidung geht, wird also nicht nur ein Entschluss gefasst, sondern auch Widerstand in den Untergrund gedrängt.

Der Ansatz der Psychologie ist daher schon lange, Widerstände eben nicht zu verdrängen, sondern entweder aufzulösen oder zumindest zu integrieren. Ein solches Bemühen geht der Demokratie ab. Sie sucht nur die Mehrheit zu finden. Sie reduziert Lösungen auf eine Mindestzahl an Zustimmungen, damit eine Mehrheit entsteht. Warum einer seine Stimme abgibt oder eben nicht wie die Mehrheit stimmt, das ist egal. Am Ende zählen nur Zahlen.

Ob Autokratie oder Demokratie: letztlich führen also beide quasi notwendig zu Unzufriedenheit, die mühsam wieder kompensiert werden muss. Denn unzufrieden ist jeder, der im Entscheidungsprozess nicht gehört wurde. Für kleine Probleme ist das vielleicht unerheblich und wird durch Gehaltszahlung oder Incentives kompensiert. Auf die Dauer jedoch sucht sich Unzufriedenheit andere Kanäle. Dienst nach Vorschrift, ein hoher Krankenstand, geringe Produktqualität können Symptome dafür sein.

Die größte Herausforderung an die Organisation der Führung und ihre Entscheidungsprozesse ist mithin, sowohl einen weiten Horizont zu haben, was die Wahrnehmung von Feedback aus operativem Geschäft und des Markt angeht. Und andererseits möglichst alle Meinungen mit den dahinter stehenden Bedürfnissen zu berücksichtigen. Führung heute bedeutet, wirklich alle ins Boot der Unternehmenspolitik zu bekommen.

Ist das aber nicht unrealistisch? Ist dieser Aufwand wirklich nötig?

Ja, so sieht es wohl aus. Das "Alignment" möglichst vieler ist kein Selbstzweck. Es geht auch nicht um Gutmenschtum. Unternehmensführung mit maximalem Feedback, d.h. Beteiligung möglichst vieler, und Entscheidungsfindung mit maximaler Bedürfnisberücksichtigung ist heute essenziell für nachhaltige Entwicklung des Unternehmens.

Die heutigen Märkte sind sehr veränderlich. Also brauchen Unternehmen feine Sinnesorgane nach außen und innen. Jeder Mitarbeiter ist ein solches Sinnesorgang und hat Interesse am Erhalt seines Arbeitsplatzes. Deshalb hat er ein Interesse, seine Wahrnehmungen weiterzugeben - wenn das denn etwas bringt, wenn er Gehör findet. Das Potenzial für viel Feedback ist also in jedem Unternehmen vorhanden. Jetzt muss eine geeignete Führungsorganisation es nur ausnutzen.

Die heutigen Märkte erfordern hohe Effizienz, Evolution und Innovationen. Die bringen aber nicht bessere Prozesse oder Werkzeuge, sondern am Ende die Menschen. Wo Menschen sich bewusst oder unbewusst weigern, sich einzubringen, da herrscht Ineffizienz, Stillstand, Konvention. Unternehmen tun also gut daran, solchen Sand aus dem Getriebe zu entfernen. Nicht, indem sie auf Menschen verzichten, sondern indem sie die Menschen einbinden. Auch hier geht es darum, das vorhandene Potenzial auszuschöpfen.

Damit ist eng verbunden Aufbau und Erhalt von Erfahrungen. Was können Unternehmen tun, damit gute Leute bei ihnen arbeiten wollen? Was können sie tun, um gute Leute zu halten? Die Antwort ist wieder: sie als ganze Menschen einbeziehen. Nicht nur Arbeitskraft im operativen Geschäft abschöpfen und (gut) bezahlen, sondern auch ihre Meinung erfragen. Wer sich wirklich als Person gesehen und erst genommen fühlt, wechselt nicht so leicht in eine neue (Arbeits)Beziehung.

Feedback, Effizienz, Innovation, Retention: Das sind die Gründe, warum Unternehmen eine Führung etablieren sollten, die sich um die Berücksichtigung möglichst vieler bemüht.

Konsent: Widerstand statt Zustimmung

Autokratie wollen wir nicht, Demokratie bringt es nicht. Wie soll denn dann aber eine Unternehmensführung Entscheidungen treffen? Wenn möglichst viele mit ihren Bedürfnissen und Meinungen berücksichtigt werden sollen, läuft das denn nicht wieder auf zähe Konsensfindung hinaus? Nein!

Konsens ist nicht nötig, um viele Positionen zu integrieren. Die Soziokratie stellt sozusagen die Demokratie auf den Kopf, um dieses Kunststück zu vollbringen. Das Zauberwort heißt dabei Konsent. Dem Deutschen ist es fremd, das Englische kennt es jedoch: consent bedeutet dort soviel wie Einverständnis, Einwilligung, Übereinstimmung, Genehmigung - oder früher sogar Harmonie.

Man mag die lautlich geringe Distanz zwischen Konsent und Konsens beklagen, denn nichts könnte Konsent ferner liegen als Konsens. Aber so haben sich die (deutschen) Soziokraten nun einmal entschieden. In den soziokratischen Kreisen geht es um Konsent. Und das bedeutet: nicht Einwilligung ist gesucht, sondern Berücksichtigung von Kritik.

Konsent konzentriert sich auf Widerstände, statt Zustimmung.

Wenn eine Entscheidung über ein Thema ansteht, dann wird nicht (!) gefragt, wer dafür sei. Und es werden auch keine Gegenstimmen gezählt.

Stattdessen fragt der Leiter eine Soziokratischen Kreises, ob es substanzielle Kritik am zu fassenden Beschluss gibt. Auf den Verein bezogen könnte das so aussehen: "Wir wollen heute eine Entscheidung über den Anstrich des Vereinshauses treffen. Gibt es schwerwiegende Gründe, die gegen einen neuen Anstrich sprechen?" Auf solche Frage kann nun jedes Kreismitglied seine begründeten Bedenken vortragen. Gibt es keine, gilt der Beschluss als gefasst.

Was sind nun aber begründete Widerstände? "Ich finde einen neuen Anstrich unnötig" könnte z.B. die Äußerung eines Kreisteilnehmers des Vereins sein. Ist das schon ein begründeter Widerstand? Nein. Ihm fehlt der Bezug zu Rahmenbedingungen der Organisation. Widerstände müssen aus den Grundsätzen oder der Politik oder der aktuellen Situation abgeleitet werden. "Ein Anstrich in diesem Jahr kann nicht ohne Erhöhung des Vereinsbeitrags bezahlt werden. Die Kasse ist leer." Das wäre eine begründete Kritik, weil sie auf die Budgetsituation verweist. Auch "Für den Anstrich haben wir keine Zeit bis zum Herbst und dann wird das Wetter nicht mehr mitspielen" wäre eine begründete Kritik. Ihr liegen Annahmen zugrunde, die sich verifizieren oder anderweitig berücksichtigen lassen.

Die Soziokratie begrüßt Emotionen als Grundlage von Äußerungen ausdrücklich. Negative Emotionen sind wertvolle Hinweise auf Widerstände, die früher oder später einen negativen Effekt auf die Umsetzung von Beschlüssen hätten. Aber die Soziokratie bleibt nicht bei den Emotionen stehen. Sie nimmt sie auf, geht ernsthaft auf sie ein und versucht, hinter sie zu schauen. Emotionen sind wichtige Informationen, aber keine Entscheidungsgrundlagen an und für sich.

"Ich finde einen neuen Anstrich unnötig" ist zunächst einmal nur eine legitime emotionale Äußerung. Ihr mag Angst vor einer Beitragserhöhung zugrunde liegen oder Unsicherheit in Bezug auf den für den Anstrich nötigen eigenen Arbeitsanteil oder oder oder. Wenn also ein Kreismitglied sich zu solch einer Äußerung entschließt, hakt der Kreis nacht. "Was bedeutet für dich 'unnötig'? Meinst du wirklich, der heutige Anstrich ist noch gut genug? Oder meinst du vielleicht, ein neuer Anstrich sei zu teuer?" Dann muss der "Kritikus" seine Äußerung begründen.

Hört sich das anstrengend an? Ja, vielleicht ist es das zunächst. Sich seiner wahren Beweggründe bewusst zu werden, ist immer anstrengender als einfach nur anonym eine Stimme auf einem Wahlzettel abzugeben oder auch nur die Hand für eine Wahlmöglichkeit zu heben.

Doch diese Anstrengung jedes Einzelnen lohnt sich für das große Ganze:

• Wenn der Konsent-Prozess nach Widerständen fragt, dann fragt er nach Wahrnehmungen. Nimmt die Kreisversammlung durch ein Mitglied etwas wahr, das einem Beschluss entgegensteht? Daraufhin kann sich natürlich auch ein Repräsentant eines untergeordneten Kreises mit Bedenken melden. Wahrnehmungen auch aus den entlegendsten Organisationsteilen können so zu Bewusstsein der Führung gebracht werden.
• Wenn im Konsent-Prozess alle Kreismitglieder gleichberechtigt sind und jede Äußerung willkommen ist, dann muss sich niemand mehr ausgeschlossen fühlen. Jedem wird Gehör geschenkt - sogar so ernsthaft, dass es womöglich erstmal ungemütlich ist.

Das wirkt in Summe einer Kultur des Abnickens entgegen. Niemand muss mehr überzeugt sein. Es reicht, wenn es keinen substanziellen Widerspruch mehr gibt. Und das ist nicht dasselbe wie Zustimmung. Soziokratie ist integrativ, wo Demokratie nur Stimmen zählt. Das Argument zählt und muss keine Angst vor einem unbegründeten Veto haben. Es gibt kein Vetorecht im soziokratischen Kreis.

Agil entscheiden

Indem die Soziokratie darauf verzichtet, zunächst erst mühsam eine Mehrheit zu bilden, um anschließend die schwelenden Widerstände der Überstimmten im operativen Geschäft zu überwinden, ist sie schon effizienter als Demokratie.

Wenn Sie genau hinschauen, sehen Sie aber noch mehr: Soziokratie hat auch keinen Perfektionsanspruch. Es geht nicht darum, die beste Lösung für alle zu finden. Die muss Demokratie nämlich quasi zwangsläufig insofern anpeilen, weil nur sie mehrheitsfähig ist. Soziokratie hingegen begnügt sich mit "gut genug". Auch das macht sie schnell. Denn "gut genug" ist, was keinen begründeten Widerstand mehr hervorbringt.

SKM institutionalisiert somit die Heuristik des Satisficing: Eine Entscheidung wird getroffen, wenn alle Anforderungen grundsätzlich "irgendwie" erfüllt sind. Ein Kreis wartet nicht auf ein Optimum. Es reicht, wenn es nicht mehr zu schlecht ist und ein Fortschritt erzielt wird.

Insofern geht es auch nicht mehr um ganz bestimmte Entscheidungen. Durch die vorgebrachten Widerstände in der Vereinskreissitzung kann z.B. das Ziel verändert werden. Der SKM-Kreis lässt dann vielleicht das ursprüngliche Thema "Neuanstrich des Vereinsgebäudes" los zugunsten eines anderen wie "Neuanstrich nur des Geräteschuppens in diesem Jahr", weil das keinen Widerstand aufgrund knapper Vereinsfinanzen mehr hervorruft.

SKM gleicht darin Scrum. Scrum will auch kein bestimmtes Feature umsetzen, sondern nur dafür sorgen, dass Anforderungen nach Priorität und Machbarkeit in Iterationen abgearbeitet werden. Genauso liegt SKM auch nichts an inhaltlich ganz bestimmten Beschlüssen, sondern nur daran, Fortschritt ohne begründeten Widerstand sicherzustellen.

Dass es dazu eines guten Kreisleiters bedarf und einer gewissen Disziplin wie Offenheit bei allen Kreismitgliedern, ist selbstverständlich. Deren (Aus)Bildung ist denn auch viel Zeit vor und während der Einführung von Soziokratie als Führungsmethode gewidmet.

Interessanterweise wirkt nun dieser Satisficing-Anspruch zurück auf den Konsent-Prozess. Denn wo Entscheidungen nicht mehr optimal oder in ganz bestimmter Weise getroffen werden müssen, da äußert sich erstens Widerstand leichter - andererseits wird er aber weniger schnell zum Selbstzweck. Denn wer heute nur ein schlechtes Gefühl hat und seine Kritik noch nicht begründen kann, der findet jederzeit Gehör, wenn er dafür bereit ist.

Das sorgt dann ganz natürlich dafür, dass SKM-Kreise zu weniger irreversiblen Entscheidungen tendieren. Ganz ausschließen kann man sie nicht, doch die Mitglieder werden sensibler ihnen gegenüber. Denn jeder irreversible Beschluss schränkt ja die durch SKM geschenkte Freiheit für berechtigte Kritik ein. Soziokratische Arbeit ist sozusagen ein natürliches Gegenmittel gegen BDUF (big design upfront) in der Geschäftsführung.

Die von der Soziokratie abgeleitete Holacracy formuliert das in einem Interview mit ihrem Begründer Brian Robertson so:

"Finally, and by far most importantly, [consent] changes the nature of decision-making and process control - the 'steering' of an organization or team - from a predict-and-control model to an experiment-and-adapt model. And that changes everything."

Soziokratisch wählen

Soziokratische Kreise treffen alle Entscheidunge im Konsent. Das gilt also auch für Personalentscheidungen. Wo der Autokrat bestimmt, der Demokrat (geheim) wählt, da sucht der Soziokrat offenen Konsent. Besetzungen folgen deshalb einem Protokoll:

1. Alle Kreismitglieder tragen ihren Besetzungswunsch auf einem Zettel mit ihrem Namen ein. Der Leiter sammelt die Zettel.
2. Dann begründen alle Kreismitglieder reihum ihren Wunsch.
3. Dann haben die Kreismitglieder die Möglichkeit, aufgrund der Begründungen der anderen ihren Besetzungswunsch nocheinmal zu verändern.
4. Aus den nun vorliegenden Besetzungswünschen ermittelt der Kreisleiter einen Favoriten.
5. In Bezug auf den Favoriten wird Konsent gesucht.

Solch offene "Wahl" mag merkwürdig anmuten. Aber letztlich ist das Vorgehen konsequent. Bei ansonsten offenem Konsent wäre es inkonsequent, gerade Besetzungsentscheidungen geheim zu treffen. Und da am Ende ohnehin die "Wahl" im Konsent stattfindet, kann in einer Vorrunde auch offen über Vorschläge gesprochen werden.

Zusammenfassung

Bei den Borgs aus dem Enterprise-Kosmos mag Widerstand zwecklos sein. Bei Soziokratie hingegen ist er gewünscht. Begründeter Widerstand ist der Hebelpunkt für soziokratische Entscheidungen. Geäußerter Widerstand kann keine Kraft mehr im Untergrund entfalten. Geäußerte Bedenken sind wertvoller Input vor jeder Entscheidung. Willkommene Kritik ist ernsthafte praktische Wertschätzung jedes Einzelnen.

Soziokratie realisiert mit dem Konsent-Prinzip das Versprechen der Demokratie und macht Führung gleichzeitig sensibel und effizient. Mit Soziokratie hält die Essenz der Agilitätsbewegung Einzug in die Unternehmensführung.

Deshalb empfinde ich die Softwarebranche als prädestiniert für die Einführung von Soziokratie. Sie ist mit den Grundgedanken schon vertraut. Und sie kann angesichts ihrer hohen Geschwindigkeit jedes Bisschen Effizienzgewinn in der Unternehmensführung gebrauchen. Und nicht zuletzt geht Soziokratie das Problem der Mitarbeiterbindung in Zeiten des IT-Fachkräftemangels an. Denn wer kann es sich leisten, Mitarbeiter zuverlieren, wenn es so schwer ist, gute neue zu finden?

Soziokratie mag gewöhnungsbedürftig sein. Nicht nur für die, die ihre "Macht über" aufgeben sollen. Aber ich glaube, dass in ihr echtes Potenzial zu nachhaltigerer Unternehmensführung steckt. Zufriedenheit, Qualität und Produktivität sind gleichermaßen Anliegen der SKM.

Alles Führen ist in Kreisen - Die soziokratische Kreisorganisation [OOP 2009]

Soziokratische Geschäftsführung führt iterativ. Die Grundlage ist eine Lernschleife aus Messen, Reflektieren/Beschließen, Handeln - ganz ähnlich wie bei Scrum. Der soziokratische Führungsprozess ist also ein Kreisprozess.

 

Jetzt die Frage: Wie ist denn die Geschäftsführung in der Soziokratie organisiert? Zur Organisation des operativen Geschäftes sagt die Soziokratie nichts Spezielles. Sie ist vielmehr Ergebnis soziokratischer Geschäftsführung. Wenn die beschließt, das operative Geschäft hierarchisch zu belassen, dann ist das ok. Die soziokratische Theorie mischt sich also nicht in die Praxis des operativen Geschäftes ein. Sie gibt nur einen Rahmen vor, wie eine angemessene Organisation dafür gefunden werden soll. Welche das dann ist, ist der Soziokratie (oder Soziokratischen Methode, SKM) einerlei.

Insofern ist die Soziokratie als Methode auch leer. Sie ist auf kein spezifisches Geschäftsfeld zugeschnitten. Auch hier wieder Ähnlichkeit zu Scrum. Scrum ist ebenfalls leer. Ob Sie Software mit Scrum entwickeln oder eine Party planen, das ist Scrum einerlei. Scrum ist eine Methode zur Produktion von Lösungen bei wechselnden oder unklaren Anforderungen eines Kunden. SKM ist eine Methode zur Entwicklung von nachhaltigen Organisationen in einer volatilen Umwelt. Scrum ist nicht auf Softwareentwicklung festgelegt. SKM ist nicht auf Unternehmen festgelegt und schon gar nicht auf bestimmte Branchen. Mit SKM können Sie auch einen Verein führen.

Der Kreis als Grundbaustein soziokratischer Führungsorganisation

Also, wie sieht die Struktur soziokratischer Führung aus? Auch hier steht der Kreis im Mittelpunkt. Allerdings nicht als Prozess, sondern als Ort. Alles Auswerten von Feedback und Diskutieren und Beschließen von Veränderungen geschieht in Kreisen. (Mir fallen dazu gerade die früheren Versammlungen der Germanen ein, Thing genannt. Auch dort kam man im Kreis an der Thingstätte zusammen. Doch die Ähnlichkeit mit den SKM-Kreisen ist natürlich nur sehr weitläufig. Vor allem, weil SKM in der Durchführung von Kreissitzungen keine Regel für´s Betrinken zur Lockerung der Zuge kennt ;-)

Der Kreis fasst gleichberechtigte Teilnehmer zusammen und hat einen Leiter. Wie in dem Kreis gearbeitet wird, beschreibe ich in einem nächsten Posting. Heute geht es mir nur um die Struktur der SKM-Geschäftsführung.

Der Leiter des Kreises ist natürlich kein autokratischer Chef, sondern eher ein Moderator. Er leitet den Kreis im Sinne eines soziokratischen Prozesses durch Kreissitzungen.

Was bedeutet das für das Beispielunternehmen SoftWunder aus meinem früheren Posting? Das Unternehmen könnte auf die Führung durch einen soziokratischen Kreis umstellen:

Die bisherige hierarchisch autokratische Geschäftsführung wäre jetzt allerdings nur in einen Kreis umgewandelt. Das ist möglich und legitim, schöpft das Potenzial von SKM allerdings nicht aus. Wenn schon Änderung der Geschäftsführungsphilosophie in Richtung "lernende Organisation", warum dann nicht richtig? Bei einem so kleinen Unternehmen wie SKM wäre es möglich oder gar naheliegend und angezeigt, das gesamte Personal in einem geschäftsführenden Kreis zu organisieren:

 

Da haben wir nun den Salat. SKM ist eine partizipative Methode. SKM fördert die Einbindung sovieler Menschen wie möglich in unternehmerische Entscheidungsprozesse. Der Grund dafür ist ganz einfach: mehr Menschen in der Führungsorganisation liefern mehr Feedback. Feedback von innen aus dem operativen Geschäft und Feedback von außen, vom Markt. Im Sinne des Agilitätsmanifestes könnte man vielleicht sagen: "people over reports". Statt Feedback durch vorgegebene Kanäle zu schicken, besser direkt in einem Kreis geben.

Viele Menschen in SKM-Kreise einzubeziehen, ist aber nicht nur ein Vorteil für die Lernfähigkeit des Unternehmens! Durch solche Partizipation wird auch noch das allgegenwärtige Motivationsproblem angegangen. Wo die Literatur sich mit Ideen zur Motivation von Mitarbeitern überschlägt, setzt Soziokratie ein ganz simples Mittel dagegen: Teilnahme. Lass die Menschen teilnehmen, gib ihnen ernsthaft die Möglichkeit, sich einzubringen, dann fühlen sie sich wertgeschätzt und sind motiviert. Soziokratie ist insofern eine sinnstiftende Methode. Und Sinnempfinden ist der Motivator schlechthin. (Das hat übrigens die Motivationsliteratur auch schon gemerkt ;-)

Soziokratie ist also schon eine kleine Revolution. Zumindest werden es viele eingefleischte Führungspersonen in traditionellen Hierarchien so empfinden. "Wo kommen wir denn hin, wenn jeder bei der Geschäftsführung mitreden kann?" Nun, SKM sagt: Wir kommen weiter.

Soetwas lässt sich natürlich nicht gegen den Willen von Menschen einführen. Vor allem nicht gegen den Willen der bisherigen Geschäftsführung. Aber wenn die überzeugt ist, dann steht dem Versuch wenig im Wege, SKM einfach auszuprobieren. Ob die allgemeinen Bedenkenträger Recht behalten oder erstaunt feststellen, dass SKM doch funktioniert, wird sich zeigen. Soziokratie garantiert insofern auch kein Gelingen. Wie bei Scrum oder andere Praktiken muss die Veränderung zu ihr hin auch in einem Lernprozess stattfinden. Und so wie es Scrum Master gibt, so bildet die Soziokratie auch für ihre Einführung und Durchführung Begleiter aus. Im Vergleich zu Scrum steckt das allerdings noch in den Kinderschuhen.

Nochmal: Ein SKM-Kreis versammelt Menschen zu einer soziokratischen Unternehmensführungsgemeinschaft. Die ist innerhalb der Kreises nicht hierarchisch. Deshalb wird innerhalb eines Kreises nach gewissen Protokollen vorgegangen, um gemeinschaftlich zu Entscheidungen zu kommen. Dazu ein andermal mehr. Kreise handeln gegenüber dem operativen Geschäft, sie delegieren dorthin Leitung und Ausführung und messen den Effekt ihrer Handlungen. Messungen werden auch an Kreisteilnehmer als Aufgabe delegiert; ansonsten ist aber auch jedes spontane Feedback von Kreisteilnehmern erwünscht. Alle sind im Kreis gleichberechtigt. Wenn Lehrling und Meister in einem Kreis zusammenkommen, dann gibt es keinen Vorrang durch Ausbildungsstand. Jeder trägt nach Kräften bei.

Außerhalb der Kreise kann das Verhältnis hingegen ganz anders sein! Wie oben schon gesagt, macht SKM keine Aussage über eine "richtige" Organisation des Tagesgeschäftes. Die entwickeln die Teilnehmer der SKM-Kreise nach den Bedürfnissen ihres Unternehmens. Im operativen Geschäft kann es also weiterhin Hierarchien geben. Die sind jetzt aber fokussiert eben auf das Tagesgeschäft. Bei SoftWunder darf der Vertriebsleiter Heinz also weiterhin seine Außendienstler einteilen und ihnen Anweisungen geben. Ganz autokratisch. Seine "Befehlsgewalt" ist jedoch beschränkt auf das operative Geschäft! Sie bezieht sich auf die Sache, hier: den Verkauf.

Sobald Heinz dann mit Rolf und Volker im SKM-Führungskreis zusammensitzt, ist er ihnen gleichgestellt. Dann können die beiden an ihm vorbei Feedback in den Kreis geben, dem auch der Unternehmenseigener angehört. Das kann sich natürlich auf die Befehlsausübung durch Heinz beziehen. So üben sie Macht miteinander aus, statt übereinander.

Soziokratie und Autokratie vertragen sich also. Das ist ganz passend zum sonstigen Leben: Manchmal muss man handeln und nicht diskutieren. Dann sind klare Prozesse und auch Befehlsketten sinnvoll. Aber immer öfter muss man halt im Geschäftsleben nicht nur handeln, handeln, handeln, sondern auch mal nachdenken; und zwar über möglichst breite Wahrnehmungen. Organisationen  müssen nachdenken. Dafür schafft Soziokratie eine "Bewusstseinsinstanz" mit maximaler Reichweite ihrer Fühler ins Unternehmen hinein.

Skalieren mit Kreisen

SoftWunder ist klein. Das operative Geschäft könnte wohl durch einen Kreis geführt werden. Vielleicht stellt sich dabei aber auch heraus, dass das zu schwerfällig ist. Vielleicht sollten viele Mitarbeiter nur gelegentlich in einem Kreis zusammenkommen, wenige jedoch häufiger. Die Geschäftsführung kann dann auf mehrere Kreise in einer Hierarchie verteilt werden. Das gilt auch für Organisationen, die mehr Menschen umfassen, als sich praktikablerweise in einem Kreis zusammenfassen lassen. Für effektive und effiziente Diskussionen in einem Kreis sollte die Obergrenze wahrscheinlich bei 50 Teilnehmern liegen. Letztlich macht die Soziokratie darüber jedoch keine Aussage, sondern bietet ganz allgemein, Kreise in einer Hierarchie anzuordnen. Und das geht so:

 

Jetzt besteht die Geschäftsführung von SoftWunder aus einer Kreishierarchie mit zwei Ebenen. Auf der oberen Ebene 1 hat der Kreis 4 Mitglieder, auf der unteren Ebene 2 sind es 9. Das sind zusammen 13 Teilnehmer an Kreisen bei 11 Mitarbeitern. Wie kann das sein? Des Rätsels Lösung liegt in der soziokratischen Doppelbindung von Kreisen:  Übereinanderliegende Kreise sind durch je mindestens 2 Personen miteinander verzahnt. Diese Personen sind Mitglied sowohl im unteren wie im oberen Kreis. Sie bilden die Schnittmenge der beiden Kreise. Die Soziokratie drückt das in ihren kanonischen Bildern durch überlappende Dreiecke aus:

Warum diese Doppelbindung? Sie sorgt dafür, dass der Informationsfluss erstens immer persönlich ist und zweitens in beide Richtungen läuft. Wären die Hierarchieebenen nicht gekoppelt, dann würde eine obere die untere nicht persönlich über ihre Beschlüsse informieren, sondern mittels Dokumenten. Auch wäre die obere Ebene an den Diskussionen der unteren nicht persönlich beteiligt. Das würde bürokratischen Prozessen statt effizienten, lernenden Vorschub leisten. Die Umsetzung von Beschlüssen von oben nach unten durch die Kreishierarchie wäre behindert. "Die da oben" wären wieder nur "anonyme Herrscher". Indem jedoch ein gleichberechtigtes Mitglied des oberen Kreises ebenfalls gleichberechtigtes Mitglied des unteren ist, garantiert Soziokratie verlustfreie Übersetzung im Sinne ineinandergreifender Zahnräder. Und da Hierarchien den Zweck haben, Entscheidungen von oben nach unten zu verbreiten, ist das Mitglied, das der obere an den unteren Kreis delegiert, sogar der Leiter des unteren Kreises! In dieser Rolle "herrscht" dieses Mitglied zwar nicht über den unteren Kreis, aber es leitet ihn zumindest mit Blick auf die Interessen des oberen Kreises.

Kreise in einer Hierarchie sind deshalb nur halbautonom. So frei und gleichberechtigt ihre Mitglieder sind, es werden ihnen schon Weisungen "von oben" zuteil. Aber erstens wird die Erarbeitung solcher Weisungen durch soziokratische Protokolle in Bahnen gelenkt, die maximal kompatibel mit den Bedürfnissen aller Ebenen sind. Zweitens kann ein Kreis immer noch selbst über die Interpretation der Weisungen entscheiden - wobei der von oben delegierte Leiter bei der Auslegung hilft. Und drittens, fließt Information eben nicht nur von oben nach unten.

Gekoppelt sind die Kreise nämlich nicht nur von oben nach unten durch den Leiter, sondern auch von unten nach oben durch einen Repräsentanten. Der untere Kreis entsendet auch einen "Interessenvertreter" in den oberen Kreis, in dem er gleichberechtigt zu allen anderen Kreismitgliedern ist. So fließt Feedback ungehindert von der Basis zur Spitze. Das ist einer der wichtigstes Aspekte der Soziokratie.

In der Autokratie fließen Weisungen nur von oben nach unten. Aber auf welcher Grundlage werden sie beschlossen? Eine persönliche Präsenz von Informationen der Basis "in höheren Gefilden" gibt es nicht. Führungskräfte leben dort im ständigen Spagat. Sie sind hin und her gerissen zwischen den Interessen der oberen und unteren Ebene, an deren Schnittstelle sie sitzen. "Nach oben ducken, nach unten treten" ist ein typisches Symptom dafür. Kommt unliebsames Feedback von unten, ist es für sie leicht, seinen Fluss nach oben zu sperren.

In der soziokratischen Kreishierarchie kann das nicht passieren. Niemand muss dort ambivalent sein. Der von oben delegierte Leiter kann in angemessener Manier die Interessen des oberen Kreises im unteren vertreten. Und der Repräsentant des unteren Kreises im oberen die seines Heimatkreises. Und wenn es die Situation verlangt, kann der untere Kreis auch mehr als eine Person in den oberen Kreis delegieren oder den einen Repräsentanten durch einen anderen ersetzen.

Die Doppelbindung der Kreise fügt also eine feste Kette die maximal Durchlässig ist für Informationen in beide Richtungen. Die Pfeile über die Schnittmenge hinweg im vorstehenden Bild der SoftWunder-Kreishierarchie sollen das versinnbildlichen.

Im Kreissaal der Kreise

Aus wievielen Kreisen sollte eine soziokratische Kreishierarchie bestehen? Aus einer angemessenen Anzahl. Die Soziokratie macht da keine Vorschriften. Es gilt jedoch: Je mehr Menschen einer Organisation in den Kreisen vertreten sind, desto besser kann die Geschäftsführung die Bedürfnisse aller berücksichtigen. Das erhöht die Motivation der Mitarbeiter - und sensibilisiert gleichzeitig die Wahrnehmung von Feedback.

Mit wievielen Kreisen Soziokratie in einer Organisation aufgesetzt wird, ist daher unternehmensindividuell verschieden. Ebenso der Ort, d.h. wo in der bisherigen autokratischen Hierarchie. Sie kann an der Spitze beginnen oder an der Basis oder auch in der Mitte. Denn wo ein Kreis ist, da kann jederzeit ein zweiter daraus entstehen. Kreise können sozusagen weitere Kreise gebähren. Ein großer kann sich aufspalten, ein kleiner kann andere zu einem Kreis zusammenschließen - eine organisationsentwickelnde Maßnahme! - und anbinden.

Veränderungen an der Kreishierarchie sind immer möglich. Es können sogar "Task Force"-Kreise mit begrenzter Laufzeit gebildet werden ganz im Sinne der Spike Solutions von eXtreme Programming. Wesentlich ist nur immer wieder die Doppelbindung zwischen den Kreisen.

Wie die Kreishierarchien für SoftWunder schon angedeutet haben, ist die Hierarchie der Kreise auch unabhängig von den weiterhin durchaus bestehenden Hierarchien des operativen Geschäftes. Es gibt keinen Zwang, für jede operative Abteilung einen eigenen Kreis aufzumachen. Entwicklung, Vertrieb, Sekretariat müssen sich in der orthogonalen soziokratischen Geschäftsführung nicht in eigenen Kreisen widerspiegeln. SoftWunder könnte durch verschiedene Kreishierarchien geführt werden:

Auch wenn die bisherige Hierarchie in einem Unternehmen eine spiegelbildliche soziokratische Hierarchie nahelegt, so sind Sie nicht daran gebunden. Sie können nach Gesichtspunkten der Akzeptanz, des Wahrnehmungshorizonts für Feedback (Messung), der Umsetzung (Implementation der Geschäftsführungspolitik), der Sinnstiftung usw. immer wieder neu entscheiden, wie die Kreishierarchie aussehen soll.

Soziokratische Führung produziert deshalb auch nicht nur operative Strukturen, sondern ebenfalls ihre eigenen. Soziokratie ist essenziell reflexiv.

Aus diesem Grund ist Soziokratie auch besonders für wachsende Unternehmen geeignet. Sie in einem großen, hierarchisch festgefügten Unternehmen einzuführen, mag schwerer sein als in einem noch kleinen. Hier wie so oft gilt: je früher desto besser. Wer im Kleinen schon Soziokratie geübt hat, dem fällt es später im Großen leichter. Denn Soziokratie skaliert! Sie lässt sich in kleinen Unternehmen wie SoftWunder praktizieren. Oder sogar in noch kleineren, denn eigentlich geht es schon mit 2 Personen los. Die können einen von ihrem operationalen Geschäft getrennten Kreis für dessen Führung bilden. Auch wenn sie sonst den ganzen Tag am selben Schreibtisch sitzen, verhalten sie sich anders, wenn sie ihre "Soziokratiehüte aufsetzen". Dann verhalten sie sich den soziokratischen Regeln konform und kommen auf anderem als üblichem Weg zu Beschlüssen.

Nach oben gibt es keine Grenze für Soziokratie: 2, 20, 200, 2.000 oder auch 20.000 Menschen lassen sich soziokratisch führen. Ein Beispiel gibt davon einen Eindruck:

Diese Kreishierarchie umfasst alle 281 Mitarbeiter eines Mittelständischen Unternehmens. Die Zahl der Teilnehmer eines Kreises ist die darin notierte Summe. Der zweite und dritte Summand bezeichnen jedoch Mitglieder, die von einem oberen oder unteren Kreis delegiert sind. "4+1+2" bedeutet: 7 Kreismitglieder, davon 1 Leiter von oben delegiert und 2 Repräsentaten von unten delegiert. Die Mitarbeiterzahl ergibt sich also aus der Addition nur der ersten Summanden.

Nochmal, weil es so wichtig ist: Mit einer flachen Hierarchie (3 der Basis übergeordnete Ebenen) und insgesamt 15 Entscheidungsinstanzen führen 281 Mitarbeiter sich selbst. Alle Mitarbeiter sind an der Unternehmenspolitik, an ihren Grundsatzentscheidungen beteiligt! Und alle finden durch die doppelte Bindung bei Bedarf Gehör bis in den obersten Kreis. Das Unternehmen ist partizipativ selbstorganisiert.

Wer das gern etwas weniger abstrakt möchte, der findet in  "Die kreativen Kräfte der Selbstorganisation" dazu eine kleine Geschichte.

Ausflug Zum Begriff Führung

In diesen Blog-Postings benutze ich immer wieder den Begriff "Führung" für das, was die soziokratische Kreishierarchie tut. Die Kreise führen das operative Geschäft. Sie sind die Geschäftsführung.

Was ist das aber, was ein Geselle auf der Baustelle mit einem Lehrling macht, wenn der ihm eine Aufgabe zuweist? Ist das nicht auch Führung?

Hm... im weiteren Sinn ist das natürlich auch Führung. Der Geselle führt den Lehrling physisch zu seinem Einsatzort und inhaltlich zu seiner Aufgabe.

Wenn von "Unternehmensführern" gesprochen wird oder in einem Buchtitel wie "Führen, Leisten, Leben" von Fredmund Malik der Begriff  "Führung" auftaucht, dann steckt dahinter allerdings mehr als Aufgabenzuweisung im Tagesgeschäft und Ergebniskontrolle. "Führung" im engeren Sinn ist - zumindest für mich und deshalb gebrauche ich den Begriff hier - mehr als Lenkung oder Koordination von Menschen in Prozessen des Tagesgeschäfts.

Führung steht über dem Tagesgeschäft oder außerhalb seiner. Führung definiert die Rahmenbedinungen innerhalb derer das Tagesgeschäft koordiniert wird. Führung reflektiert über den Verlauf der Geschäftsprozesse, die Effizienz der operativen Organisation und entwickelt beide. Insofern führt Führung nicht Menschen, sondern eine Organisation: die operative Suborganisation eines Unternehmens. Führung findet selbst dann natürlich auch in einer Suborganisation statt - die sie wie oben gezeigt auch reflexiv führt.

Dazu kommt aber dann doch auch noch der Mensch. Gute Führung heute hat den Menschen im Blick. Sie ist an ihm interessiert, will ihn entwickeln und stiftet Sinn.

Und es ist auch wegen dieser Bedeutung, die der Begriff "Führung" für mich hat, dass ich das, was Soziokratie will, als Führen bezeichne. Kurz und knapp. Andere würden vielleicht modern "governance" dazu sagen: soziokratische Governance. Das wäre für mich auch ok. Aber warum nicht den schlichten Begriff "Führung" verwenden?

Dass dann im Tagesgeschäft auch Führung "passiert", weil sich Kopf und Herz nicht ausschalten lassen und auch nicht ausgeschaltet werden sollen, sobald man vom soziokratischen Kreis wieder an den operativen Schreibtisch wechselt, das ist klar. Dem großen Zweck der Führung durch Soziokratie tut das aber ja keinen Abbruch.

Soziokratie führt also umfassend und im Großen eine Organisation. Sie definiert Grundsätze, bestimmt die Organisationspolitik, stiftet Sinn durch Einbeziehung möglichst vieler.

Was dann in der Umsetzung, im Tagesgeschäft, im Kleinen getan wird... nun, das nenne ich mal vor allem Koordination. Im Sinne von Prozessen und Aufgaben werden Menschen und Ressourcen in und durch mehr oder weniger tiefe Hierarchien koordiniert. Das schöne an diesem Begriff ist, dass er so wenig vorbelastet ist. In ihm schwingt nicht die Macht mit, die in "Management" oder auch noch "Leitung" steckt. Wo koordiniert wird, geht es also gar nicht mehr um Macht, sondern um Aufgabenbewältigung.

Macht übt nur die soziokratische Hierarchie über das operative Geschäft aus. Aber das ist nur noch eine Macht über eine Suborganisation und nicht mehr über Menschen. Denn die Menschen, die von dieser Macht betroffen sind, stecken ja im "Machtorgan". Sie sind es selbst. Sie sind beteiligt in den soziokratischen Kreisen. Deshalb spricht die Soziokratie immer wieder auch von "Macht mit" statt "Macht über".

So wie Soziokratie und operatives Geschäft bildlich durch Orthogonalität und Kreisprozess deutlich getrennt sind, so trennen die Begriffe Führung und Koordination die unteschiedlichen Aspekte im Wort.

Führung in Schleifen - Rückkopplung als Fundament der Soziokratie [OOP 2009]

Um agile Unternehmensführung mit Soziokratie zu verstehen, ist es nützlich, Unternehmensführung deutlich getrennt von den sonstigen Tätigkeiten eines Unternehmens zu sehen. Wie dadurch die Darstellung eines Unternehmens klarer wird, habe ich in meinem vorherigen Posting zum Thema beschrieben. Geschäftsführung versteht man am besten orthogonal zum operativen Geschäft. Geschäftsführung hat einen anderen Zweck und wird zu einem großen Teil von anderen Menschen betrieben, als die Erledigung des Tagesgeschäftes.

 

Das Tagesgeschäft bezieht sich auf die Produkte des Unternehmens, seine Leistungen für Kunden. Es erfüllt Anforderungen des Marktes. Geschäftsführung (oder verkürzt: Führung) hingegen ist von außen eher nicht zu sehen. Wenn ein Geschäftsführer in Erscheinung tritt, dann weniger in seiner Geschäftsführerrolle, laut der er die Organisation entwickeln soll. Öffentlich werden Geschäftsführer vielmehr in Rollen des Verkaufs oder des Marketings. Dann stehen sie direkt für ein Produkt ein oder für das den Produkten unterliegende Unternehmensimage.

Einschub bevor ich es vergesse: Streng genommen mag Soziokratie zwar nicht agil sein, zumindest nicht im Sinne der softwaretechnischen Agilitätsbewegung. Dennoch bezeichne ich Soziokratie hier so, weil sie für mich den Kern der Agiltitätsbewegung genauso wie Scrum verkörpert: kühn voranschreiten und sich unterwegs anpassen. Lieber in Kontakt sein, zuhören, lernen und dann ein kleines Bisschen besser werden, als autistisch und (über)lange von einem Wissensmonopol aus planen.

rekursiv gekoppelte Unternehmensführung

Führung ist also orthogonal zum operativen Geschäft. Womit sich das operative Geschäft befasst, wie seine Organisation strukturiert ist, welchen Grundsätzen das Unternehmen folgt und ganz allgemein wie die Unternehmenspolitik aussieht: das ist Gegenstand der Geschäftsführung. Aber wie steht sie mit dem operativen Geschäft in Kontakt? Die Antwort darauf ist leider recht betrüblich: Der Kontakt zwischen Führung und Tagesgeschäft ist meist recht einseitig. Geführt wird heute immer noch oft durch eine Einbahnstraße hindurch, d.h. autokratisch. Der Chef sagt an, die anderen spuren. Von oben nach unten durch die übliche Organisationshierarchie.

Das wird durch die konzeptionelle Freistellung der Geschäftsführung auch nicht besser. Nur klarer.

Die Instanz, die durch die Einbahnstraße führt, kann sich nicht mehr im Organigramm verstecken. Management ist Management.

Für die weitere Darstellung vereinfache ich das Bild allerdings nochmal. Dann kann ich den Unterschied, den Soziokratie bedeutet, einfacher darstellen.

Es bleibt dabei: Heutige Geschäftsführung als Ganzes ist autokratisch gegenüber der Operation - und in sich natürlich auch von oben nach unten. Da folgt sie ganz Conways Gesetz, würde ich sagen. Hierarchische Führung kann nicht wirklich etwas anderes "denken" als ein hierarchisches operatives Geschäft und eigentlich auch keine anderen Beziehungen in der Umwelt.

Was bedeutet nun solche "Einbahnstraßenführung"? Ihr Ideal ist es, alles schon zu wissen und im Tagesgeschäft nur noch Befehle erteilen zu müssen. Autokratische Führung geht also von der Möglichkeit aus, dass wenige alles nötige über das Unternehmen und seine Umwelt wissen und daraus auch noch die notwendigen Schlüsse für nachhaltige Unternehmungen ziehen können.

So das etwas vereinfachte Modell heutiger Geschäftsführung. Soviel zur Hybris vieler heutiger Geschäftsführungen.

Das meine ich gar nicht mal so bös, wie es klingen mag. Dieses Führungsmodell ist legitim und war in den vergangenen Jahrhunderten oft erfolgreich. Wir sind es einfach gewohnt. Womöglich zu gewohnt, um es grundlegend in Frage zu stellen.

Warum spreche ich trotzdem von Überheblichkeit und Selbstüberschätzung? Weil das Fundament dieses Führungsmodells nicht mehr trägt, man sich aber dennoch daran festklammert. Nicht mehr tragfähig ist die Annahme, dass wenige genug wissen können, um Unternehmen sicher nachhaltig erfolgreich zu führen. Das ist nicht nur bei großen Konzernen so, die eins ums andere Mal ins Trudeln geraten. Das ist schon so bei der kleinen Softwareschmiede. Solch hierarchische Führung kann selbst in einem Beispielunternehmen wie SoftWunder (s. vorheriges Posting) nicht mehr genug wissen. Markt und Technologien ändern sich zu schnell.

Früher, da mag das anders gewesen sein in Manufakturen und Handwerksbetrieben. Und auch noch Anfang des letzten Jahrhunderts als einzelne Unternehmen zu volkswirtschaftlich relevanten Organisationen wurden. In Märkten des Mangels war es einfach, die Bedürfnisse zu erkennen und effiziente Organisationen zu entwerfen. Die vorherrschenden Wünsche mit immer besser werdender Massenware zu befriedigen, war recht mechanisch zu erledigen.

Inzwischen hat sich das Bild allerdings durch eben diese Produktionsweise geändert. Heute sind die Märkte gesättigt. Kreativität ist gefragt. Flexibilität ist gefragt. Noch höhere Effizienz ist gefragt. Noch mehr Signale sind zu verarbeiten, da der Markt letztlich für quasi alle global ist. Und das alles ist mit der bisherigen hierarchischen Geschäftsführung in Einbahnstraße nicht mehr möglich. Wo die Umwelt komplex geworden ist, muss auch die Organisation komplex werden. Das ist ein Naturgesetz: eine bestimmte Komplexität lässt sich nicht mit weniger Komplexität bewältigen. Hierarchien sind aber per se einfach und nicht komplex. Deshalb reiben sie sich zunehmend auf an der steigenden Komplexität der Umwelt.

Das ist natürlich keine binäre Situation. Geschäftsführung funktioniert nicht entweder gut oder gar nicht. Wenn Hierarchien nicht mehr passen, dann geht also nicht das Licht aus. Stattdessen nehmen Konflikte zu, der Druck wird stärker, die Stimmung sinkt, Spielräume werden gestrichen, die Bürokratie nimmt zu, aus der einstigen Vision wird ein Tunnelblick.

Natürlich soll nun Geschäftsführung nicht in beliebiger oder gar komplizierter Weise komplexer werden. Im Gegenteil! Ein wesentlicher Schritt zu angemessener Komplexität ist sogar ganz einfach. Er ist so einfach wie der Wechsel von einem einfachen Heizungsventil zu einem Heizungsthermostaten.

Geschäftsführung muss in ernsthafte und gleichberechtigte Rückkopplung mit dem operativen Geschäft treten. Geschäftsführung muss in einer Feedbackschleife stattfinden. Das ist nichts anderes als die Agilitätsbewegung für die Softwareentwicklung will. Kein BDUF (Big Design UpFront), sondern Iterationen. Keine autokratische Einbahnstraßenführung, sondern Führung nach Feedback und in Iterationen. Geschäftsführung muss also ganz fundamental vom bzw. durch das operative Geschäft lernen.

Natürlich gibt es auch heute schon gewisse Wege für Feedback an die Unternehmensführung. Berichte werden turnusmäßig produziert und Management Informationssysteme werden aufgesetzt. Im Vergleich zur nach unten zeigenden Führungsmacht ist die Macht des aufwärtsgerichteten Feedbacks jedoch gering und allemal nicht unbedingt zeitnah. Und es ist sehr formalisiert. Was nicht in den dünnen Feedback-Kanal passt, das hat kaum Chance auf Wahrnehmung in der Führung. Macht von oben und Feedback-Macht von unten sind heute also sehr asymmetrisch. Um das zu betonen, habe ich den Feedback-Kanal bis zum vorstehenden Bild gar nicht erst eingezeichnet.

Soziokratie stellt dem das gleichberechtigte und breite und nicht notwendig formale Feedback gegenüber. Soziokratische Führung ist insofern echt rekursiv gekoppelt mit dem operativen Geschäft. Beide durchlaufen eine Co-Evolution: soziokratische Führung wirkt auf die Operation ein, die Operation reagiert und wirkt zurück auf die soziokratische Führung, die wiederum reagiert und wirkt auf das operative Geschäft und so weiter und so fort immer im Kreis. Sie verformen sich gegenseitig. (Deshalb habe ich beiden in den folgenden Bildern auch keine konkrete Struktur gegeben. Die ist im Augenblick unerhelblich. Wesentlich ist nur, dass sie sich verändert, um sich immer wieder neuen Verhältnissen anzupassen.)

Das Bild zieht den Kreis in der Zeit auseinander. Denn durch die Entwicklung beider Seiten stehen sie quasi nicht auf der Stelle. Der Kreis ist eher eine Spirale. Und beide Unternehmensaspekte bewegen sich in einem dynamischen Gleichgewicht um einen Punkt der Optimalität in Bezug auf den Markt und das Ziel Nachhaltigkeit (d.h. Effizienz über lange Zeit).

Rekursive Organisation

Solche rekursive Kopplung mag neu innerhalb eines Unternehmens sein. Ansonsten gehört sie aber zur Natur von Unternehmen. Denn so stehen sie in Beziehung zur Umwelt, zum Markt. Sie wirken auf den Markt mit ihren Produkten ein, der Markt verändert sich dadurch, dann wirkt der Markt zurück aufs Unternehmen. Das Unternehmen als autopoietische System - d.h. eine sich selbst erhaltende Organisationsform - kann nicht anders.

Mit der Soziokratie findet diese Kopplung nun Eingang in das System. Eine Form des Austausches auf grober Granularitätsebene setzt sich fort innerhalb der Organisation auf feinerer Granularitätsebene. Innerhalb eines rekursiv gekoppelten Systems sind Systeme, die ebenfalls rekursiv gekoppelt sind. Rekursive Kopplung findet somit selbst wieder rekursiv statt. Soziokratische Unternehmen sind Unternehmen mit rekursiver Struktur.

Das wird noch deutlicher, wenn Sie innerhalb der blauen operativen Organisation einen Scrum-Prozess denken. In ihm sind auch Systeme rekursiv gekoppelt: Product Owner und Team.

Die rekursive Kopplung mit der Umwelt ist natürlich und alt. Früher war der Markt jedoch viel überschaubarer, stabiler. Innerhalb eines Unternehmens mussten deshalb nicht auch noch fundamentale Regelkreise aufgebaut werden. Es reichte aus, dass die Geschäftsführung ihre Wahrnehmungen unidirektional in Grundsätze und Organisationsstruktuen goss.

Das ist heute fundamental anders! Unternehmen sind heute mit einer sehr volatilen Umwelt gekoppelt, die auch noch viel mehr Signale sendet. Erfolg ist nicht mehr eine Sache von Planung am Reißbrett. Zwischen Erfolg heute und Erfolg morgen liegt keine recht klar absehbare Strecke. Der Weg führt vielmehr durch Nebel und ist voller Stolperfallen. Die Soziokratie schlägt deshalb vor, das Lernen innerhalb von Unternehmen zu institutionalisieren in Form der gezeigten fundamentalen Schleife. Dabei liefert das operative Geschäft ständig und auf vielen Kanälen Informationen an die Führung.

Die Frage ist dann nur, wie die soziokratische Geschäftsführung aussieht, damit sie dieses Feedback auch verarbeiten kann. Bisher habe ich ihr ja noch keine konkrete Struktur in den Bildern gegeben. Doch davon mehr im nächsten Posting.