Bei www.clean-code-developer.de beschäftige ich mich gerade mit Grundprinzipien professioneller Softwareentwicklung. Vielleicht ist das der Grund, warum Soziokratie in mir eine Saite zum Schwingen gebracht hat. Sie sieht für mich nämlich ebenfalls wie ein Grundprinzip aus. Nicht für die Entwicklung von Software, sondern für die Entwicklung von Organisationen die Software herstellen.
In meinem vorhergehenden Posting habe ich erklärt, warum ich die Softwarebranche für prädestiniert halte, sich die Soziokratie einmal näher anzusehen. Wir sind schon vertraut mit zwei Kernkonzepten der Soziokratischen Kreismethode (SKM): Lernschleife und Rekursion. Und darüber hinaus sind wir prädestiniert zu verstehen, was die Einführung von Soziokratie mit einem Unternehmen macht. Sie führt zu einer Separation of Concerns. Soziokratie ist Unternehmungsführung aspektorientiert.
In unserer Branche kann ich das so einfach schreiben. Was genau ich damit meine, verstehen Sie wahrscheinlich noch nicht. Aber das macht nichts. Zumindest gewisse Bilder entstehen in Ihrem Kopf, weil diese Begriffe in der Softwarebranche etabliert sind. Und das ist, was es aus meiner Sicht einfacher macht, SKM in der Softwarebranche zu studieren oder gar einzuführen. Wir sind vorbereitet.
Schon im brand eins Artikel, der für mich Anlass zur Beschäftigung mit der SKM war, wird deutlich, dass Soziokratie bei allen Vorteilen und einer grundsätzlichen Einfachheit doch einen Nachteil hat: sie lässt sich irgendwie schwer erklären. So finden zumindest auch viele Soziokratieexperten. Und ich stimme durchaus zu. Eigentlich ist SKM simpel - doch beim Erklären hakt es immer wieder.
Warum ist das so? Da lese ich die Literatur zu SKM, die das Soziokratische Zentrum mit Übersetzungsmühe zur Verfügung gestellt hat; die Liste der Grundprinzipien ist kurz; die Bilder sind einfach; die Beispiele bemüht lebensnah. Und doch... etwas hakt. Das merke ich auch, wenn ich mit Isabell Dierkes, der Vertreterin des deutschen Soziokratischen Zentrums skype. Einerseits verstehe ich sie - und andererseits laufen wir auch immer wieder in Missverständnisse.
Warum ist das so? Ich glaube, zumindest eine Ursache gefunden zu haben. Die Soziokratie setzt ein gewisses Verständnis davon voraus, wie Unternehmen funktionieren. Unglücklicherweise ist dieses Verständnis jedoch viel weniger verbreitet als angenommen. Deshalb stelle ich Soziokratie in anderer Weise dar, als die "kanonischen Dokumente" es tun. Ich fange damit an, was die Soziokratie als selbstverständlich voraussetzt.
Führung ist orthogonal
Lassen Sie mich versuchen, den "Ort für Soziokratie" im Unternehmen mit einer kleinen Beispielfirma zu illustrieren: Ein kleines Softwareunternehmen - die SoftWunder GmbH - hat einen Geschäftsführer, ein Entwicklungsteam, Vertrieb und ein Sekretariat. Das Entwicklungsteam arbeitet schon mit im "softwaretechnischen Kreisprozess" Scrum.
Wenn uns der Geschäftsführer und Inhaber sein Unternehmen vorstellen wollte, würde er sicherlich in einer hübschen Powerpoint-Präsentation auch ein Organigramm wie das Folgende zeigen:
Es beschreibt die groben Verantwortungsbereiche im Unternehmen, sozusagen seine Komponenten. Wenn wir hineinzoomen, sehen wir die Rollen, die es mit Leben füllen.
So ähnlich könnte das Personal von SoftWunder heute organisiert sein. Die Belegschaft ist nicht groß, so dass die Hierarchie flach sein kann. Zum Beispiel braucht das Unternehmen keine Sekretariatsleitung und die Architektur entwirft das Entwicklungsteam gemeinsam.
Auf Details im Organigramm, die Sie vielleicht anders erwartet hätten, kommt es auch nicht an. Wichtig ist nicht, was im Organigramm fehlt, sondern was das Organigramm verbirgt! Es verbirgt oder kaschiert nämlich etwas, das eigentlich deutlich sichtbar sein müsste.
Das Organigramm macht denselben "Fehler", den dieser Code für Sie ganz offensichtlich macht:
KundenListe SucheKundenNachPLZ(string plz)
{
logger.Write("Suche Kunden nach PLZ: {0}", plz);
if (cache.ContainsForKey(plz))
return cache[plz];
KundenListe liste = new KundenListe();
SqlConnection conn = new SqlConnection("...");
...
return liste;
}
Wo liegt das Problem in diesem Code? Er vermischt unterschiedliche Aspekte! Logging, Caching und Datenbeschaffung sind unterschiedliche Aspekte der Lösung. Indem sie eine Methode vermischt, wird der Code schwer lesbar und weniger evolvierbar.
Separation of Concerns, Aspekte oder Belange klar voneinander zu trennen, ist daher ein Grundprinzip guter Softwareentwicklung. Die Aspektorientierte Programmierung (AOP) hat dafür Werkzeuge entwickelt wie zum Beispiel PostSharp. Damit ließe sich der Code klarer formulieren, z.B. so:
[Log("Suche Kunden nach PLZ {0}", "plz")]
[Cache("plz")]
KundenListe SucheKundenNachPLZ(string plz)
{
KundenListe liste = new KundenListe();
SqlConnection conn = new SqlConnection("...");
...
return liste;
}
Jetzt steht in der Methode ihr eigentlicher Zweck im Vordergrund: die Beschaffung von Daten. Die Aspekte Caching und Logging sind an sie über Attribute "angeheftet", die von einem AOP-Framework zur Compilezeit oder Laufzeit so eingewoben werden, dass sie wie im ursprünglichen Code ihren Dienst tun.
Das konzeptionelle Verhältnis zwischen den Aspekten, ihre Orthogonalität, mittels AOP einen passenden Ausdruck gefunden. Sie springt uns jetzt ins Auge. Wir verstehen den Code leichter, wir können ihn einfacher erweitern, weil die logische Entkopplung des Aspekte nun auch ihre Entsprechung in der Form hat.
Jetzt zurück zu SoftWunder: Was bedeutet das nun aber für das Organigramm?
Wie gesagt, das Organigramm vermischt genauso wie der ursprüngliche Codeentwurf. Es vermischt ganz unterschiedliche Aspekte eines Unternehmens. Das typische Ogranigramm vermischt operatives Geschäft und Führung dieses Geschäfts. Es trennt nicht deutlich zwischen dem Tagesgeschäft und Management. Es trennt nicht zwischen der Organisation und den Prozessen, die produzieren und verkaufen und einfach den Laden schmeißen - und der Entwicklung all dessen.
Geschäftsführer Friedrich (oder in größeren Unternehmen der Vorstand und das mittlere Management) hat eine fundamental andere Aufgabe als Entwicklerin Rita oder Außendienstler Rolf. Friedrich denkt über das Unternehmen nach, er trifft Grundsatzentscheidungen, er definiert Geschäftsfelder und Grundsätze der Arbeit, er bestimmt das Organigramm. Rita und Rolf hingegen führen nur aus. Sie sind zwar auch verantwortlich in ihren Rollen, aber diese Verantwortlichkeit bezieht sich auf Prozesse des Tagesgeschäftes. Sie arbeiten im Konkreten, Friedrich arbeitet sozusagen auf der Metaebene.
Diese fundamental unterschiedlichen Rollen - Arbeiten im Konkreten und Arbeiten auf der Metaebene, Arbeiten in der Organisation vs Organisationsentwicklung - mache ich mal mit Farben im Organigramm deutlich. Dann sehen Sie die Aspekte schon etwas besser:
Geschäftsführer Friedrich sowie Entwickler, Außendienstler und Sekretariat haben klar getrennte Verantwortungen. Sie gehören eindeutig unterschiedlichen Aspekten an. Scrum Master und Vertriebsleiter jedoch sitzen quasi zwischen den Stühlen. Einerseits sind sie im Tagesgeschäft involviert, andererseits sind sie auch angehalten, darüber hinaus zu denken. Von ihnen erwartet der Geschäftsführer Weitblick und auch (moderate) Eingriffe in die unter ihnen "hängenden" Organisationsteile.
Hört sich alles selbstverständlich an, oder? So ist das halt mit Unternehmen. Oder allgemein: So ist das halt mit organisierten sozialen Systemen. Früher oder später, gewollt oder nicht nehmen sie eine hierarchische Form an. Das ist nicht nur in Unternehmen so. Auch Vereine oder die Politik sind so organisiert. Bestrebungen um flache Hierarchien ändern daran nichts.
Und all diesen Organisationen ist gemein, dass sie in ihren Selbstdarstellungen die Aspekte Operation und Reflektion nicht klar trennen. Das tun sie nicht, weil sie es selbst nicht anders denken. In ihrem Denken verschwimmen die Aspekte, weil die Aspekte mit den zugehörigen Rollen in Personen immer wieder notwendig zusammenfließen. Operieren und Reflektieren geschieht gerade in kleinen Unternehmen zwangsläufig oft in Personalunion.
An diesem Faktum ist auch nichts auszusetzen. Damit aber das Selbstbild, das Denken kontamieren zu lassen, das ist kontraproduktiv! Professionelle Softwareentwicklung braucht klare Prinzipien. Professionelle Unternehmenungen brauchen klare Prinzipien. Wenn drüben Separation of Concerns eine Tugend ist, warum dann also nicht auch hüben?
Größere Organisationen sind da klarer. Der Begriff Management bezeichnet eigentlich den Aspekt Organisationsentwicklung/Reflektion. Im Organigramm sind dann einige Hierarchieebenen rein blau - wenn denn das Organigramm überhaupt farbkodiert wäre. Ist es aber auch in diesen Organisationen nicht. Vielleicht ist es da nicht verwunderlich, dass "die Management-Kaste" in den letzten Jahren sich ins Kreuzfeuer manövriert hat. Vielleicht hat die Krise der Mangements damit zu tun, dass das Denken in den Organisationen nicht so klar ist, wie es sein sollte? Nun, darüber zu sinnen, überlasse ich Ihnen bei einem Bier... ;-)
Hier möchte ich das Organisationsbild im Sinne der Aspektorientierung verbessern. Ich wende einfach mal die Darstellung der Software auf die SoftWunder GmbH an:
Führung ist orthogonal zum Tagesgeschäft. Führung kümmert sich um die Organisation, nicht um die Erledigung eines Auftrages. Sie ist insofern nicht funktional! Führung ist kein Feature der Dienstleistungen eines Unternehmens.
Wenn Sie bei einem Pizza Bringdienst nicht nur à la cart bestellen, sondern auch eigene Pizzavariationen kreieren können, dann ist das ein Feature des Pizza Bringdienstes. Er erfüllt damit einen funktionalen Wunsch der Kundschaft. Wenn die "custom Pizza" auch noch superschnell kommt, dann ist das eine nicht funktionale Eigenschaft des Bringdienstes. Denn auch wenn sie 2 Stunden warten müssten, wäre Ihr funktionaler Wunsch nach einer "custom Pizza" immer noch erfüllt.
Aber woher kommt die hohe Geschwindigkeit? Sie ist resultat guter Unternehmensführung. Denn sie ist es, die die Organisation des Tagesgeschäftes definiert, die Prozesse bestimmt, die Mitarbeiter motiviert, so dass am Ende alle und alles reibungslos läuft.
Führung ist insofern sogar in doppelter Hinsicht nicht funktional: zum Einen ist sie selbst kein Feature des Unternehmens, zum anderen wirkt sie maßgeblich auf die nicht funktionalen Eigenschaften der Dienstleistungsfeatures des Unternehmens ein.
Ich denke, das ist ein weiterer Grund, warum Führung verdient, viel expliziter dargestellt zu werden. SoftWunder täte sich einen Gefallen, wenn es sein Organigramm wie folgt zeichnen würde:
Dem Betrachter wäre sofort klar, wer in die Entscheidungen über das Unternehmen eingebunden wäre. Der Betrachter wüsste sofort, dass überhaupt Reflektion stattfindet, da dieser Aspekt erkannt und explizit dargestellt wurde.
Soziokratie will explizite Führung
So, nach diesem Ausflug ins Grundsätzliche wieder zurück zur Soziokratie. Wenn ich jetzt sage, dass Soziokratie aspektorientierte Unternehmensführung ist, dann verstehen Sie was ich meine. Soziokratie ist eine Methode der Unternehmensführung. Und Soziokratie führt explizit, d.h. durch Ablösung des Aspekts "Führung" vom operativen Geschäft.
Die soziokratische Führung habe ich in diesem Bild in der kanonischen Form dargestellt. Die SKM spricht von einer "Kreisorganisation" der Führung, zeichnet aber Dreiecke. Wenn Sie das merkwürdig finden, dann sind Sie nicht allein ;-) Auch darin sehe ich ein Problem der Soziokratie, sich verständlich zu machen; sie ist mehr oder weniger subtil inkongruent in ihren Aussagen. Ich werde im Weiteren daher die Dreiecke nicht verwenden, selbst wenn ich mich damit gegen "die Weisen aus dem Holland" stelle ;-) (Die Geburtsstätte der Soziokratie ist in den Niederlanden, wo auch das soziokratische Hauptzentrum seinen Sitz hat.)
Das wesentliche Problem der Soziokratie sehe ich vielmehr - da bin ich mir nun ganz sicher - darin, dass sie nicht die Orthogonalität von Führung klar macht. Interessenten haben deshalb immer wieder das grundsätzliche Verständnisproblem, wo denn Soziokratie im Unternehmen zu verorten sei.
Darstellungen wie diese aus "Die Soziokratische Kreisorganisationsmethode" machen es da auch nicht besser:
Indem sie die soziokratische Kreishierarchie in ein bestehendes Organigramm einblendet, will SKM zwar einen wichtigen Punkt rüberbringen - steigert aber letztlich die Verwirrung. Denn so oktroiert SKM einer bestehenden Führung, die ja schon und noch im Organigramm steckt, eine weitere Führung auf. Das will sie natürlich nicht, sie tut es aber doch. Das ist tragisch.
Die aspektorientierte Darstellung vermeidet diese Verwirrung, indem sie zuerst und ganz allgemein Führung orthogonal zum operativen Geschäft zeigt - und dann (!) die traditionelle Führung durch die soziokratische ersetzt.
Führung in dieser Weise orthogonal zu denken und zu zeigen hat zwei Vorteile für die Soziokratie:
- Es wird ganz klar, was Soziokratie will: führen, nicht operieren. Soziokratie hat den Anspruch, die bisherige Führungsorganisation durch etwas Neues zu ersetzen. Was das ist und wie das funktioniert werde ich in zukünftigen Postings beschreiben.
- Es wird ganz klar, dass eine Organisation Soziokratie einführen kann, ohne zwangsläufig an der operativen (!) Organisation etwas zu verändern. Das senkt die Einstiegshürde. Denn woimmer innerhalb eines Organigramms Operation und Reflektion vermischt sind, können sie im ersten Schritt entkoppelt werden, um dann im zweiten Schritt die "herauspreparierte" Führung durch Soziokratie zu ersetzen.
Soziokratie ist also eine Führungsmethode, die auf Organisationen oder Teilorganisationen quasi beliebiger Größe angewandt werden kann. Bei SoftWunder könnte zum Beispiel nur der Vertrieb zukünftig soziokratisch geführt werden (soweit das unterhalb einer traditionellen Geschäftsführung möglich ist). Ist das erfolgreich, kann Soziokratie horizontal in anderen Abteilungen eingeführt werden oder eben auch vertikal, d.h. als Ersatz der kompletten bisherigen Führung. Soziokratische Führung kann in einem traditionellen Organisationsbaum von unten nach oben oder von oben nach unten "wachsen". Sie ist somit rekursiv. Ihre Bilder selbstähnlich.
Verstehen Sie jetzt, warum ich glaube, dass Soziokratie es in der Softwarebranche einfachener haben kann als in anderen? Aspekte, Orthogonalität, Separation of Concerns, Rekursion: das sind Begriffe, mit denen Sie täglich umgehen. Wir verstehen sie. Und ohne sie halte ich Soziokratie für viel schwieriger als notwendig verständlich.
Es ist also kein Wunder, wenn die Soziokratie-Proponenten bisher Schwierigkeiten mit ihrer Frohbotschaft hatten. Handwerksunternehmen oder einem Handelshaus Soziokratie SKM zu erklären, ohne solche begriffliche und darstellerische Schärfe, kann nur zu Missverständnissen führen.
Aber vielleicht nützen ja diese Gedanken hier, um das Konzept allgemein einfacher erklärbar zu machen und seine Verbreitung zu fördern. Ich glaube, dass SKM ein guter Schritt voran zu nachhaltiger Unternehmensführung ist.
Ausblick
Da nun die Positionierung der SKM klar ist, konzentriere ich mich beim nächsten Soziokratie-Posting auf die Wechselwirkung von SKM-Führung mit dem operativen Geschäft und der Organisation der soziokratischen "Kreis-Dreicke".
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 
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.
