Follow my new blog

Sonntag, 8. März 2009

Manifestierte Softwareentwicklung [OOP 2009]

Die Softwareentwicklung hat ein neues Manifest, das Manifesto for Software Craftsmanship:

image

Nach dem Manifesto for Agile Software Development [dt.] meint "man" offensichtlich, noch einen Schritt weitergehen zu müssen. Die "Software-Handwerker" nehmen den Ball der Agilisten auf und schlagen ihn bewusst zurück. Die "linke Seite" ihrer Grundsätze (z.B. "working software") entspricht der "linken Seite" bei den Agilisten. So entsteht nun eine dreistufige Wertehierarchie:

Prä-Agil Agil Handwerklich/Post-Agil
Ausführliche Dokumentation Funktionierende Software Handwerklich gute Software
Befolgen eines festgelegten Plans Mut und Offenheit für Änderungen Stetiger Wertzuwachs
Prozesse und Werkzeuge Individuen und Interaktionen Professionelle Gemeinschaft
Vertragsverhandlungen Stetige Zusammenarbeit mit dem Kunden Produktive Partnerschaft

 

Früher war der Fokus also z.B. auf ausführlicher Dokumentation. Darüber haben die Agilisten funktionierende Software gesetzt: Was nützt die beste Dokumentation, wenn am Ende die Software nicht befriedigt? Und darüber setzen nun die "Software-Handwerker" wiederum handwerklich gute Software. Denn was nützt funktionierende Software, die zwar läuft, aber nur zusammengezimmert ist und bei der ersten Belastungsprobe Probleme macht?

Im Craftsmanship-Manifest heißt es zwar "but also" statt "over" wie im Agile-Manifest, d.h. die handwerklichen Werte stehen nicht unbedingt höher als die agilen. Doch letztlich ist das eine Feinheit, denke ich. Wenn über den Grundsätzen der Software-Handwerker "Raising the bar" steht, setzen sie ihre Werte höher als die der Agilisten an, weil sie den umfassendsten Anspruch formulieren:

image

Das hört sich gut an. In Zeiten, da Softwarequalität schon für tot erklärt wird, ist jede Bemühung um mehr Qualität - denn um nichts anderes geht es den Software-Handwerkern - zu begrüßen.

Und dennoch... Irgendwie mag ich mich nicht vorbehaltlos über diese Form "manifestierter Softwareentwicklung" freuen. Warum? Ich glaube, es liegt an zweierlei:

  • Die Form des Manifestes hat für mich gerade auch durch die direkte Bezugnahme auf das agile Manifest einen Beigeschmack. Da schwingt für mich Me-Too-Denken gemischt mit Neid und Kränkung und Hang zur Theatralik mit. Für mein Empfinden sind die Kopie der Form und die Bezugnahme daher kontraproduktiv trotz allem "but also" stat "over".
  • Der Inhalt des Handwerker-Manifestes verliert aus meiner Sicht bei allem Willen zum Gegenteil den Kontakt zur Hauptperson: dem Kunden. Als Kunde interessiere ich mich nicht dafür, ob ein Softwareentwickler eine Handwerker- oder Ingenieursattitüde hat. Er soll gefälligst gute Software abliefern. Wie er das macht... egal. Er hat es schließlich gelernt. Oder? Folgt man aber den Diskussionen in der amerikanischen Software-Craftsmanship Gruppe, dann geht es eher um das "rechte Leben als Handwerker" als um Wege zu mehr Kundenzufriedenheit. Erste Softwareentwickler sind sogar schon zusammengezogen. Pair Programming scheint nun nicht mehr zu reichen.

So liegt für mich die Qualität des neues Manifests deutlich hinter der seines Vorgängers. Die Agilisten haben in ihren Grundsätze Aussagen darüber gemacht, was ihrer Meinung nach bessere Software bzw. einen besseren Produktionsprozess ausmacht: funktionierende Software statt "Gerede über Software", die Fähigkeit des Teams zum Umgang mit der Realität häufiger Änderungswünsche, flüssige Kommunikation im Team, enger Kontakt zum Kunden. Das ist knackig. Das lässt sich in seiner Effektivität messen.

Die Software-Handwerker hingegen formulieren schwammig. Sie werfen Fragen auf, wo angesichts lauter Klagen über die Softwarequalität konkrete Antworten nötig wären:

  • "Handwerklich gute Software" klingt gut - aber wie lässt sich die handwerkliche Qualität messen? "Funktionierende Software" ist demgegenüber leicht erkennbar.
  • "Stetiger Wertzuwachs" bei der Software ist eine gute Sache - aber wie geht das über eine agile Praktik wie das Scrum Backlog hinaus, bei dem der Kunde jederzeit selbst bestimmt, was für ihn wertvoll und daher als nächstes zu realisieren ist? Die agile Offenheit für Änderungen steht im Gegensatz zu Planbefolgungswahn. Der Nutzen, den Agilität behauptet, ist klar zu erkennen. Aber "Wertzuwachs" ist demgegenüber schwach.
  • Was bringt eine "Professionelle Gemeinschaft" dem Kunden? Oder ersteinmal: Wer ist überhaupt Mitglied in der Gemeinschaft? Die Softwareentwickler unter sich? Oder das Team zusammen mit dem Kunden? Wo die Agilisten den Menschen ins Bild holen, addiert aus meiner Sicht die "community of professionals" nichts hinzu. Jedenfalls nichts, was erstens messbaren Vorteil böte oder zumindest für den Kunden verständlich wäre.
  • Und schließlich die Frage, was an einer "produktiven Partnerschaft" neu ist? Das agile Manifest formuliert wieder klar einen Gegenentwurf: früher verschanzen hinter einmal abgeschlossenen Verträgen, heute stetige Kommunikation. Partnerschaft ist dazu kein Gegensatz und auch kein großer Schritt voran. Allemal, weil Partnerschaft niemandem aufgezwungen werden kann. Will der Kunde ein Partner sein? Die Agilisten lassen die Frage unbeantwortet und begnügen sich mit Realistischerem: kommunikativ engere Kopplung.

Allesinallem empfinde ich also das neueste Manifest der Softwareentwicklung als gut gewollt - aber zu kurz gesprungen. Eine Not zur Herausforderung der Agilitätsbewegung bestand nicht. Aber wenn schon Herausforderung, dann bitte auch "Butter bei die Fische" und nicht Herumgeeiere.

Bemühungen um mehr Softwarequalität und mehr Professionalität in der Softwareentwicklungen sind wichtig. Es ist höchste Zeit dafür. Clean Code Developer soll da nicht allein stehen. Die Software-Craftsmanship-Bewegung ist ja auch schon älter und will im Grunde dasselbe. Eigentlich. Nicht umsonst ist Robert C. Martin Teil beider Schnittmenge. Aber es ist schade, wenn eine Bemühung sich in romantischen Vorstellungen einer Handwerkerzunft ergeht und dann als weit sichtbare öffentliche Geste nur ein Remake eines Erfolgsschlagers zustande bringt.

Getting Things Done - ganz anders und ganz einfach [OOP 2009]

image Ja, auch ich habe den Zeitmanagement-Klassiker "Getting Things Done" ("Wie ich die Dinge geregelt kriege") von David Allen gelesen. Und ich habe daraus auch etwas gelernt:

  1. Habe einen (!) Platz, an dem du alle Aufgaben bzw. Hinweise darauf, sammelst.
  2. Nutze diesen Platz konsequent und regelmäßig, um die nächste Aufgabe "abzuholen" bzw. zukünftige Aufgaben zu hinterlegen.
  3. Erledige Kleinstaufgaben sofort, plane größere Aufgaben ein.

Ziel dieser Praktik sind mentale Entlastung und Kontrolle. Aufgaben, die man nicht gerade erledigt, sollen die Konzentration im Hier und Jetzt nicht behindern. Äußere Umstände beherrschen nicht, sondern werden durch aktive Planung beherrscht.

That´s it.

Mehr hat mir David Allen nicht gebracht - außer einem schlechten Gewissen, sein ausgefeiltes System nicht genauso ausgefeilt zu benutzen.

Naja, in einem Punkt habe ich es noch angepasst: Wo er empfiehlt, "Abteilungen" für Aufgaben anzulegen, die mit bestimmten Orten oder Gelegenheiten zu tun haben (z.B. "Wenn ich das nächste Mal beim Faxgerät bin"), da nutze ich diese Orte selbst. Habe ich eine Aufgaben, die mit dem Faxgerät oder dem Lebensmitteleinkauf zu tun haben, dann lege ich mir Aufgabenzettel genau dorthin, also zum Faxgerät und zur Wohnungstür (durch die ich zum Einkauf gehe). So "stolpere" ich über meine Aufgaben. Ich muss sie also nicht im Hinterkopf halten.

Ansonsten aber... da grüble ich eher darüber nach, was mich an David Allens gutgemeinten Ratschlägen stört. Und meine Erkenntnis ist inzwischen:

"Getting Things Done" (GTD) ist keine Lösung, sondern ein Symptom.

image Das Buch ist ein Symptom für eine Kultur oder auch nur Arbeitshaltung, in der man soviel "auf dem Zettel hat", dass man überhaupt ein ausgefeiltes System braucht, um es zu bewältigen. Es scheint geradezu eine Tugend zu sein, sich soviel aufzuladen, dass man sich nur mit modernen Hilfsmitteln organisieren kann. Eine Aufgabenliste, ein Kalender, eine Wiedervorlagemappe oder auch (im fortgeschrittenen Stadium) eine Assistenz reichen nicht mehr. Nein, es muss ein mehrdimensionales Verwaltungs- und Erinnerungssystem sein.

Seit ich das erkannt habe, geht es mir besser. Ich brauche GTD nicht. Ich brauche nur Mut, mein Leben/meine Arbeit so einfach zu halten, dass ich gar nicht erst in eine organisatorische Überlastungssituation komme. Wenn ich an soviel denken muss, dass ein simpler Kalender und eine Aufgabenliste nicht mehr reichen, dann (!) habe ich ein Problem. Denn dann bin ich sehr wahrscheinlich auch so unter Druck, dass mir als Softwareentwickler schlicht Spielräume fehlen und der Raum für Kreativität begrenzt ist.

Dass GTD mir dann ja gerade helfen würde, diese Räume wieder zu eröffnen durch gute Planung... nun, das halte ich für eine Empfehlung wie "Putz die Zähne öfter, damit die ganzen Süßigkeiten ihnen nicht schaden."  Hier ist die Wurzel des Übels ein übermäßiger Zuckerkonsum, dort ist es eine Hypertrophie des Verantwortungsbewusstseins. Denn nur wer sich für viele Dinge verantwortlich fühlt, der hat auch viele Aufgaben, um diese Dinge geregelt zu kriegen.

Die wahre Lösung des Problems, mit dem sich GTD beschäftigt, lautet daher: Reduktion und Delegation. Weniger tun müssen und/oder andere an der Bewältigung beteiligen.

Wenn die zu regelnden Dinge soviel werden, dass man überhaupt merklich Zeit für ihre Regelung aufwenden muss, wenn also auch die Regelung zu regeln ist... dann ist Gefahr im Verzug. Soviel mal zur Abwechslung ins Stammbuch der ewig geschäftigen Manager geschrieben - zumindest derjenigen, die sich über ihre Aufgabenlast bewusst beklagen oder körperliche/psychische Symptome der Überlastung zeigen.

GTD hat nun einen Platz bei mir im Schrank als Mahnung, mich nicht von den Dingen beherrschen zu lassen und in eine Situation zu kommen, wo ich sie mit "normalen Mitteln" nicht mehr im Griff habe.

So freue ich mich auch, dass es Literatur gibt, hinter denen ein anderes Menschenbild steht und die aus der Regelung von Dingen nicht noch eine weitere, umständlich zu erwerbende Kompetenz machen. Wer bisher an GTD geglaubt hat, der versuche es doch mal zur Abwechslung mit einer anderen Einstellung:

image

oder ganz simplen Werkzeugen, die sich viel eher auch von Fall zu Fall einsetzen lassen:

image

image

image Ein bisschen Papier in Form von Notizblock, Notizbuch oder Post-It Zetteln reicht oft in Kombination mit dem Willen zu Überschaubarkeit von Verantwortlichkeiten und Aufgabe von Kontrolle.

Die Dinge geregelt kriegen ist dann ganz einfach. Viel einfacher, als GTD meint.

Donnerstag, 26. Februar 2009

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!

Samstag, 14. Februar 2009

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":

image

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 ;-)

image

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.

image 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.

Samstag, 7. Februar 2009

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);

image 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.

imageWie 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.

Sonntag, 25. Januar 2009

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.

imageGestern 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?

imageMeine 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?

image

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

image 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.

image

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

Sonntag, 18. Januar 2009

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.

image 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 imagein 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.

image 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

image 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

imageBei 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.