Agile Führung - Mit Soziokratie über agile Softwareentwicklung hinausgehen [OOP 2009]

Agile Softwareentwicklung ist die Antwort auf eine unvorhersehbare Umwelt. Wer ein Produkt herstellen will, dessen Anforderungen nur unvollständig bekannt sind und sich auch noch häufig ändern, der muss einfach anders vorgehen als jemand, der etwas klar Umrissenes und Stabiles produzieren soll.

Agile Vorgehensmodelle als optimale Lösungen

Im Kern der agilen Vorgehensmodelle steht deshalb "das lernende Team":

• Agile Teams bemühen sich um Nähe zum Kunden. Sie suchen sein unmittelbares und häufiges Feedback zu ihrem Produkt, der Software.
• Agile Teams setzen Feedback möglichst zügig und auf den Punkt um. Änderungen und Neuerungen werden unter ständiger Qualitätskontrolle implementiert.
• Agile Teams liefern in kurzen Abständen und verlässlich immer wieder an den Kunden. Sie setzen ihr Produkt seiner Prüfung aus.

Das "lernende Team" dreht sich also in einer nimmer endenden Schleife von Feedback - Implementation - Release. Oder allgemeiner ausgedrückt: Das "lernende Team" beobachtet seine Umwelt, es misst sie. Dann reflektiert es über diese Wahrnehmungen und passt sich bzw. sein "Modell der Umwelt" intern an. Schließlich handelt es wieder  in der Umwelt und überprüft damit die Stimmigkeit seines "Modells".

Lernen findet dabei insbesondere statt, wenn die Wahrnehmung nicht der Erwartung entspricht. Fehler sind die wahren Informationsquellen für "lernende Teams". Sie sind die "Unterschiede, die einen Unterschied machen" (Gregory Bateson).

Scrum ist hier für mich das minimalistische Vorgehensmodell in diesem Sinn. Die Lernschleife ist darin institutionalisiert. Alles dreht sich in Scrum im wahrsten Sinne des Wortes darum, das Richtige zu tun (die am höchsten priorisierten Backlog-Items implementieren), bald das Arbeitsergebnis in die Welt zu entlassen (am Ende eines kurzen Sprints) und dann Feedback über die Qualität der Arbeit einzuholen (über neue Backlog-Items).

Die zunehmende Verbreitung von Scrum gibt diesem Vorgehensmodell Recht. Es definiert mit seinen Rollen und Prinzipien eine Organisation und einen Prozess zur Bewältigung des Problems "Produktentwicklung in unvorhersehbarer Umwelt". Agile Vorgehensmodelle scheinen nach 60 Jahren Softwareentwicklung die optimale Lösung für diese konkrete Situation.

Optimale Lösungen gibt es nicht!

Für das konkrete Problem "Softwareentwicklung" ist Agilität im Allgemeinen oder Scrum im Speziellen die optimale Lösung. Zumindest im Augenblick.

Wie lange können wir aber sicher sein, dass das so ist? Wie können wir Lücken oder Unvollkommenheiten in der Anwendung eines Vorgehensmodell entdecken und korrigieren? Kann es überhaupt optimale Lösungen geben, also solche, die eben immer optimal sind? Kaum. Alle Vorschläge für ein Vorgehen bei der Softwareentwicklung sind eben nur Vorschläge. Sie definieren Ausgangspunkte für die eigene Suche nach der für die eigene Situation besten Lösung.

Und auch diese eigene Lösung ist nicht dauerhaft optimal. Optimal in einem statischen Sinn, ist nichts. Alle Vorgehensmodelle bzw. ihre Implementationen im eigenen Team sind nur vorläufig. Denn nicht nur Kundenanforderungen ändern sich ständig, sondern auch die allgemeine Situation, in der entwickelt wird. Veränderungen in der Teamgröße, neue Technologien oder Firmenfusionen können nahelegen, am aktuellen Vorgehen etwas zu ändern.

So ist es nicht nur in der Softwareentwicklung. Die Organisation eines Unternehmens insgesamt und seiner Prozesse sind ganz allgemein gesprochen nie optimal. Sie hinken immer irgendwie der Realität hinterher. Finanzkrise, Veränderungen der Wettbewerbssituation oder des Käuferverhaltens, neue Materialien und Technologien... all das und viel mehr kann ständig eine Veränderung der Unternehmensorganisation nahelegen. Es könnte nötig sein, mehr Menschen zu beschäftigen oder weniger. Es könnte nötig sein, mehr Marketing oder weniger zu betreiben. Oder vielleicht sollten Abteilungen zusammengelegt oder getrennt werden? Wie ist es mit der Entwicklung neuer Produkte? Oder lieber das Produktportfolio verkleinern? Expandieren? Fusionieren?

Ständig lautet die allgemeine Frage in einem Unternehmen: Wie sieht die beste Organisation, wie sehen die optimalen Prozesse aus?

Die Frage von Scrum ist allerdings: Wie sieht die optimale Organisation des Produktes aus und was sollte als nächstes getan werden, um maximalen Kundennutzen zu stiften? Die Organisation des Teams hingegen ist fix. Sie wird ja durch Scrum vorgegeben.

Auf einer allgemeinen Ebene ist genau das aber anders. Bei gegebenem Unternehmenszweck - Gewinnerzielung mit bestimmten Produkten - ist die geeignete Organisation der Mitarbeiter in Bezug auf diesen Zweck nicht fix. Sie gilt es vielmehr immer wieder neu zu finden.

Lernende Organisationen

Mit Scrum lernt ein Team, für den Kunden passende Software zu produzieren.

Wie lernt aber ein Unternehmen, die passende Organisation zur Herstellung seiner Produkte aufzubauen? Liegt die auf der Hand? Es scheint so, denn wer wüsste nicht, dass ein Unternehmen Buchhaltung, Produktion, Lager, Vertrieb, Marketing, Management, Sekretariat usw. braucht?

Das ist natürlich nicht falsch. Je nach Branche braucht ein Unternehmen diese grundsätzlichen Verantwortungsbereiche im Sinne einer Arbeitsteilung. Trotzdem ist damit nicht viel über die Organisation eines Unternehmens gesagt. Der Teufel steckt im Detail! Denn nicht dass (!) es Lager, Vertrieb, Produktion usw. gibt ist problematisch, sondern wie diese Verantwortungsbereiche miteinander kommunizieren und wiederum intern organisiert sind. Arbeiten sie direkt und reibungslos zusammen? Oder ist das Verhältnis eher kühl und bürokratisch? Gibt es lange Dienstwege, die einzuhalten sind? Findet man nur schwer Verantwortliche im Falle von Kundenbeschwerden?

Im Detail ist es eben nicht leicht, für einen Unternehmenszweck die am besten passende Organisation mit optimalen Prozessen zu finden. Und je größer das Unternehmen, je komplizierter die Produkte, je volatiler der Markt, desto schwieriger wird es.

Das ultimative Ziel jedes Unternehmens ist es nun, nachhaltig zu agieren. Es will möglichst lange leben und Gewinne einfahren. Dazu muss es effizient sein, denn nur dann stimmt die Marge. Dazu muss es aber auch flexibel sein, denn nur dann kann es unter wechselnden Anforderungen effizient produzieren.

Solche Nachhaltigkeit setzt gut passende Organisation voraus. Ein nachhaltiges Unternehmen muss daher daran interessiert sein, seine Organisation und seine Prozesse immer nah am Optimum zu haben. Genauso wie ein Scrum Team ein Interesse daran hat, seine Software nahe am Optimum der Kundenzufriedenheit zu haben. Wie kann ein Unternehmen das schaffen?

Das Zauberwort heißt auch hier: Lernen. Das Unternehmen muss ein lernendes Unternehmen werden. Peter Senge hat dazu schon vor Jahren ein wegweisendes Buch geschrieben: "Die fünfte Disziplin: Kunst und Praxis der lernenden Organisation" - leider bleibt es jedoch einige Antworten zur Umsetzung des Lernens schuldig.

Aber vielleicht gibt es einen ähnlich minimalistischen Ansatz für das Unternehmenslernen wie Scrum es für die Softwareentwicklung ist. Denn wo gelernt werden soll, da ist vor allem eines wichtig: die Lernschleife. Wahrnehmen, verarbeiten, handeln, wahrnehmen, verarbeiten, handeln usw. usf. nimmermüde.

Soziokratie als Organisationsevolutionsmethode

Scrum hat für mich viel Appeal in seiner grundsätzlichen Simplizität. Es verkörpert für mich die Essenz lernender Produktion. Allerdings findet das Lernen hier vor allem auf der konkreten Ebene, der Produktebene statt. In Lernschleifen soll das Produkt dem Kundenwunsch angenähert werden.

Für Unternehmen liegt das Problem hingegen im Allgemeinen und auf der Meta-Ebene. Sie sind nicht nur daran interessiert, dass ihre Teile (z.B. ein Team) lernen, sondern sie müssen als Ganzes lernen. Sie müssen lernen, aus welchen Teilen sie z.B. überhaupt bestehen sollten.

Das findet heute meist aber nur relativ dumpf oder vereinzelt statt. Eine Methode, um ein Unternehmen systematisch lernend zu gestalten, wird nicht gelehrt, wie es scheint. Wenn also Scrum in einem Softwareunternehmen zum Einsatz kommt, dann arbeitet zwar ein Team lernend - doch die Organisation drumherum ist deshalb noch lange nicht lernend aufgestellt. (Ja, auch wenn diese Organisation sich irgendwann verändert hat, indem sie Scrum einführte. Nicht systematisch lernende Organisationen leisten auch Gutes. Aber das könnte ja noch mehr werden, oder? Und in anderen Unternehmen könnte die Entwicklung zu mehr Organisationsqualität und damit Nachhaltig überhaupt ersteinmal beginnen.)

Neulich habe ich nun einen sehr interessanten Artikel (ab Ende Jan 09 im Volltext online) in der brand eins gelesen. Dort wurde eine Methode beschrieben, die mir so minimal wie Scrum erscheint, aber eben genau das Lernen in Unternehmen systematisch erzeugt, von dem schon Peter Senge geschrieben hat. Diese Methode schien mir einerseits im Geiste von Scrum, andererseits aber dazu komplementär. Scrum ist eine Methode mit einer definierten Organisation für das operative Geschäft. Doch die in der brand eins beschriebene Methode zielt auf die Entwicklung eben solcher Organisation ab.

Die Soziokratische Kreismethode (SKM oder auch kurz Soziokratie) ist insofern eine Methode zur Unternehmensführung. Und zwar eine Unternehmensführung, die bewusst lernend stattfindet, d.h. in deren Kern eine Lernschleife aus Messen, "Leiten" und Durchführen steht.

Das hat mich sehr beeindruckt. Vor allem, weil es nicht nur eine Theorie ist, sondern in der Praxis angewandt wird. In Holland können sich Unternehmen unter soziokratischer Führung sogar von der Pflicht zum Betriebsrat befreien lassen. Soziokratie ist dort also schon länger wohlwollend sogar auf dem Radar des Gesetzgebers.

Ansonsten gibt es mehrere soziokratische Zentren, die über die Methode informieren. Das deutsche ist unter www.soziokratie.org zu erreichen. Dort gibt es auch einiges zum Thema zu lesen. Aber ich werde versuchen, das Wesentliche der SKM in einigen Blog-Artikeln hier herauszudestillieren. Ich denke, das lohnt sich, denn wie die aktuelle Finanzkrise zeigt, findet nicht nur Softwareentwicklung in einer unvorhersehbaren Umwelt statt. Die Umwelt für jedes Unternehmen ist heute so unvorhersehbar, dass es angezeigt scheint, nun endlich mit der "lernenden Organisation" Ernst zu machen. Und wenn die SKM hält, was sie verspricht, dann hat sie das Zeug dazu, für Unternehmen als Ganzes das zu werden, was Scrum für die Softwareentwicklung als Teil solchen Ganzen ist. Es geht also um nicht weniger als eine Methode der agilen Führung von Unternehmen.

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.

Spinning – Vorschlag für den Kern jedes Vorgehensmodells

Über eine Iterationslänge von 1 Tag habe ich ja schon öfter geschrieben. Dazu stehe ich weiterhin. Allerdings ist mir aufgefallen, dass sie nicht an erster Stelle stehen sollte. Deshalb versuche ich mal eine andere Formulierung:

Im Kern von Scrum steht der Sprint von mehreren Wochen, d.h. ein fixes Auslieferungsdatum mit fixem Scope. Scrum ist damit fundamental zeitorientiert. Pro Sprint werden mehrere "Arbeitspakete" angegangen, die alle zum selben Zeitpunkt abgeliefert werden müssen.

Im Kern von Kanban steht die Warteschlange. Kanban ist damit fundamental flussorientiert. Wie lange die Ablieferung eines "Arbeitspaketes" dauert, ist egal, solange dadurch keine Verschwendung entsteht (Halden von auf Vorrat produziertem "Zeug").
Klingt irgendwie alles sinnig, oder?

Wenn wir uns das aber mal auf der Zunge zergehen lassen, dann sollte uns "im Abgang" ein bitterer Geschmack auffallen. Es fehlt nämlich etwas. Und was fehlt, ist oft schwer zu erkennen.

Es fehlt der Kundennutzen, es fehlt die Qualität. Beides steht weder bei Scrum noch bei Kanban an erster Stelle. Und nur das meine ich natürlich: Er steht nicht an erster Stelle. Er ist nicht offensichtlich.

Ich will also nicht sagen, dass Scrum und Kanban nicht an Kundennutzen oder Qualität interessiert seien. Nein, im Gegenteil. Teams, die Scrum oder Kanban oder Scrumban machen, wollen selbstverständlich Qualität herstellen. Niemandem soll der Wille zu Qualität abgesprochen werden.

Allerdings glaube ich, dass ein Qualitätsziel schwieriger als nötig (oder wünschenswert) erreicht wird, wenn es nicht an erster Stelle steht. Außerdem haben wir es sowieso schwer, ein Qualitätsziel zu erreichen; wie messen wir Qualität? Und je größer der Brocken, der in Qualität hergestellt werden soll, desto schwieriger.

Viel leichter ist es, einem Prozess zu folgen. "Haben wir X getan, so wie es der Prozess vorschreibt?" Diese Frage ist ungleich einfacher zu beantworten.

Je weiter oben auf der Prioritätenliste eines Vorgehens dann eine Handlung steht, desto eher wird sie auch ausgeführt. "Haben wir den Sprint eingehalten?", "Ist die Warteschlange übergelaufen?" - das sind die beiden ersten Fragen, die sich Scrum- bzw. Kanban-Teams stellen. In beiden kommt Qualität nicht vor.

Wie kann nun ein Vorgehen aussehen, dass Qualität an die erste Stelle setzt? Die Handlung mit höchster Priorität muss mit Qualität zu tun haben. Weitere Handlungen/Aspekte können sich dann auf Zeit oder Fluss oder sonst etwas beziehen. So wie sich weitere Handlungen/Aspekte bei Scrum und Kanban auf Qualität beziehen.

Mein Vorschlag:

1. Füge der Software den kleinsten vertretbaren Nutzen auf dem vereinbarten Qualitätsniveau hinzu.

Das sollte die zentrale, die erste Aufforderung eines Vorgehensmodells für Software sein.

Nutzen: Irgendetwas, das für den Kunden einen Wert darstellt, das ihm etwas bringt, das er beurteilen kann, um festzustellen, ob die Entwicklung auf dem richtigen Weg ist. Nutzen kann in Funktionalität bestehen oder der Erfüllung einer äußeren nicht-funktionalen Anforderungen.
Hinzufügen: Die Software soll etwas mehr Nutzen irgendeiner Art erhalten. Der Nutzenzuwachs kann in etwas mehr Funktionalität bestehen oder in etwas höherer Geschwindigkeit oder in etwas besserer Usability usw.

Kleinstmöglich: Es geht nicht darum, eine ganze User Story oder auch nur ein ganzes Feature hinzuzufügen. Nein, es geht um viel kleinere Inkremente, aus heutiger Sicht quasi unvorstellbar und schmerzhaft kleine Inkremente. Phantasie ist gefragt, Anforderungen so hauchdünn zu schneiden.

Damit meine ich natürlich nicht beliebig klein. Wie immer im Leben ist auch hier eine Balance zu finden zwischen Nutzenzuwachs und "administrativem Aufwand". Da aber alle andere Vorgehensmodelle auch nicht ohne Balance und Fingerspitzengefühl auskommen, finde ich es nicht schlimm, wenn es hier auch nötig ist.

Warum so kleine Inkremente? Ich würde ja sogar formulieren, sinnvoll kleinstmögliche Inkremente. Aber dann kommt jemand und sagt, so hauchdünne Scheiben machen ja eben für den Kunden keinen Sinn.

Darum geht es ja aber auch nicht. Selbst die in einem Scrum Sprint realisierten User Stories machen für den Kunden keinen Sinn in dem Sinne, als dass er nach dem ersten Sprint die Software produktiv einsetzen würde. Dazu sind schon ein paar mehr Sprints nötig in den meisten Fällen.

Wirklich sinnvoll ist für den Kunden nur, was ihn im Tagesgeschäft einen guten Schritt voran bringt. Am besten natürlich die Erfüllung der kompletten Anforderungen. Das ist ja aber bei keinem Vorgehensmodell möglich. Scrum liefert das nicht nach einem Sprint und Kanban nicht, wenn am Ende der Produktionskette das erste mal etwas heraustropft.

Der kleinstmögliche Nutzenzuwachs dient also nicht irgendeinem Sprung nach vorn im sofortigen produktiven Einsatz, sondern in einem _beurteilbaren_ Zuwachs. Ein Team kann viel Code in 14 Tagen schreiben - aber ob damit die Software näher an die Wunscherfüllung des Kunden kommt, kann der nicht beurteilen. Agiles Vorgehen stellt mithin den Nutzen in den Vordergrund; es wird in Durchstichen entwickelt. So auch hier.

Nutzen ist alles, dessen Qualität (d.h. Anforderungskonformität) der Kunde beurteilen kann. Nutzen hat also nicht zwingen mit GUI oder Datenbank oder Verteilung zu tun. Deshalb kann Nutzen auch in viel dünneren Scheiben und viel schneller produziert werden, als gemeinhin angenommen.

Und warum nun diesen Schritt als ersten im Vorgehensmodell? Weil er erstens auf äußere und auch innere Qualität fokussiert und zweitens schnelles Feedback ermöglicht und drittens auch noch der Grundbaustein konstanten Flusses ist. “Kleinstmöglicher Nutzen” entspricht der Forderung nach “small batch sizes”.

Qualität und Feedback vor allen anderen Gesichtspunkten. Das ist mir wichtig. Andere kommen erst danach, z.B.

2. Schritt 1 sollte am Ende des Tages abgeschlossen sein.

3. Zurück zu Schritt 1. Es können auch mehrere Nutzeninkremente (nacheinander) gem. Schritt 1 hergestellt werden, solange die Bedingung von 2 erfüllt ist

Ziel ist ein konstanter Fluss von Nutzenzuwächsen. Durch diese Vorhersehbarkeit und Verlässlichkeit entsteht Vertrauen in die sonst so schwer für Außenstehende greifbare Softwareentwicklung.

Das war´s. Das ist für mich der Kern des Vorgehens in der Softwareentwicklung. Und weil sich die dabei so schnell dreht, nenne ich das mal Spinning.

Wer jetzt Zeit oder Fluss weiter ins Spiel bringen möchte, der fühle sich eingeladen:
Kanban passt wunderbar zu Spinning. Nutzenzuwächse sollten nicht auf Halde geplant werden. WIP sollte limitiert werden; am besten arbeitet das Team zur Zeit immer nur an einem Nutzenzuwachs. Wenn die Herstellung des Nutzenzuwachses aus mehreren Schritten besteht, dann sollten die über Warteschlangen entkoppelt werden.

Scrum passt auch zu Spinning. Wenn wirklich, wirklich nötig, können die Nutzenzuwächse mehrerer Tage zusammengefasst dem Kunden zur Beurteilung vorgelegt werden. Der PO kann sie sich am Ende des Sprints anschauen, wenn er mag. Damit würde zwar die Chance der hohen Umdrehungszahl nicht ausgereizt, aber es wäre halt möglich. Ein Team kann Spinning einführen, auch wenn der Kunde noch nicht genauso schnell ist. (Allerdings sollte er dahin gebracht werden.)

Spinning ist also orthogonal zu anderen Vorgehensmodellen. Es kann unabhängig davon eingeführt werden, sogar im Wasserfall. Die Vorteile:

• Voranschreiten der Codeproduktion im Sinne der Agilität durch höchste Priorität für Nutzenherstellung
• Fokus auf Qualität durch höchste Priorität für äußere Qualität (Nutzen gem. Anforderungen) und innere Qualität (täglicher Druck auf Evolvierbarkeit durch Nutzenproduktion)
• Chance für kürzesten Feedbackzyklus (Iterationsdauer max. 1 Tag)
• Motivation/Zufriedenheit durch “abgeschlossenes Tagwerk”

Wann schicken Sie Ihr Projekt ins Sportstudio? :-) Mit dem Spinning können Sie sofort beginnen.

Spendieren Sie mir doch einen Kaffee, wenn Ihnen dieser Artikel gefallen hat...

Gläserne Decke für die Agilität – Abhängigkeiten

Agile Softwareentwicklung weist den richtigen Weg zu besserer Software. Die Softwareentwicklung muss alles tun, um so dicht wie möglich an den diffusen und wechselnden Bedürfnissen der Kunden zu sein. Also mehr Dialog als fixierte Kontrakte. Mehr den Menschen im Blick als starre Tools. Mehr Offenheit für Veränderungen als Plantreue.

Dazu muss natürlich das Vorgehen einer Entwicklergruppe passen. Scrum oder XP machen angesehene Vorschläge dazu.

Trotzdem kommt es mir so vor, dass die versprochenen Vorteile sich nicht so schnell manifestieren, wie erhofft. Liegt das immer wieder daran, dass Scrum oder XP nicht gut genug implementiert werden? Ja, sicher kommt das immer wieder vor. Das scheint mir jedoch keine vollständige Erklärung. Ich glaue, selbst wenn ein Team Scrum perfekt einführte, würde es deshalb allein noch nicht wirklich agil werden.

Der Weg zu besserer Software scheint klar. Man muss nur die Vorgehensmodellleiter hochsteigen. Doch dann stößt man – ob man es merkt oder nicht – an gläserne Decken. Die Verbesserungen geraten vorzeitig ins Stocken – der Grund ist allerdings nicht recht auszumachen. Alle Vorgehensmodell-Rituale werden doch eingehalten… Was läuft denn noch falsch?

Ich glaube, eine solche gläserne Decke besteht in einem fundamentalen Widerspruch zwischen zwei Gedankenmodellen von Software.

Das heutige technische Gedankenmodell

Die Softwareentwicklung hat in weiten Teilen ein technisches Gedankenmodell. Im Kern dieses Modells stehen abhängige Funktionseinheiten. Verständlich ist das durchaus, wenn man die Softwareentwicklung als Enkel des Maschinenbaus und Kind der Elektrotechnik sieht. Denn Maschinen und Geräte jeder Art funktionieren nur, wenn ihre Teile komplett sind. Das heißt, die müssen in geeigneter Weise bottom-up hergestellt und integriert werden.

Ein Computer ist ohne Netzteil, Bildschirm, Hauptplatine, Prozessor, Speicher, Tastatur nichts. Man kann keinen aus einem halben Netzteil, einem Viertel Prozessor, einem Drittel Speicher usw. zusammensetzen. Alles steht in einer Abhängigkeitsbeziehung, die zumindest eine Integrationsreihenfolge diktiert. Und alles, was da integriert wird, das muss vollständig sein.

Ohne Display kein vollständiges Gehäuse, ohne Prozessor keine vollständie Hauptplatine usw. Was weiter oben steht, also höher integriert ist, das ist abhängig von dem, was weiter unten steht.

Hört sich das plausibel an? Dann finde ich plausibel, dass das reflexartig genannte Pattern für die Struktur von Software genauso aussieht:

Wenn man Entwickler nach der einer Soll-Architektur fragt, dann kommt in 9 von 10 Fällen “Schichtenarchitektur” als Antwort. Wenn man in Projekten nach der Architektur fragt, dann kommt auch in 9 von 10 Fällen der Begriff “Schichtenarchitektur” – wenn auch meist mit Einschränkungen wie “Wir haben es nicht geschafft, eine saubere Schichtenarchitektur hinzukriegen. Aber das war unser Ziel.” Gefolgt von einem Augenaufschlag, der eigentlich nur eine Reaktion verträgt: Kopfstreicheln. Denn ist eine Strukturierung nach Schichtenmodell - das gern differenzierter als obigens aussehen darf - nicht das Ziel schlechthin, für eine Softwarearchitektur?

Nein, das sehe ich nicht so. Das pauschale Schichtenmodell hat eher mehr kaputt gemacht als Gutes bewirkt. Sein größter Schaden mag dabei gar nicht mal technischer Natur sein, sondern mentaler. Das Schichtenmodell hat offenes, flexibles Denken in Richtung besserer Architekturen gelähmt. Bei vielen Entwicklern.

Aber das ist hier gar nicht mein Punkt. Heute geht es mir um das fundamentale Denken in Abhängigkeiten und deshalb in Schichten. Die “Abhängigkeitsdenke” ist überall. Hier die Diagrammtypen, die der Beitrag zur UML bei Wikipedia zuerst nennt:

Insgesamt werden 12 Diagrammtypen beschrieben, wovon mindestens 7 (58%) Abhängigkeitsdiagramme sind. (Und eigentlich würde ich sogar noch das Sequenzdiagramm mit in diese Gruppe rechnen. Dann wären es 66%.) [1]

Solch technische Sicht ist für sich genommen natürlich kein Problem. Maschinenbau und Elektrotechnik leben damit ja wunderbar – und können eigentlich auch nicht anders. Auch Softwareentwicklung kann man natürlich ausgerichtet an diesem Gedankenmodell betreiben. Das tun ja auch Millionen von Entwicklern täglich.

So weit, so gut also erstmal.

Das agile Gedankenmodell

Agilität interessiert sich erstmal nicht für Technik. Technik ist nur ein Mittel, um für den Kunden eine Lösung herzustellen. Aus Sich der Agilität zählt also nicht, wie Software intern strukturiert ist. Sie hat deshalb ein ganz anderes Gedankenmodell von ihr.

Für die Agilisten besteht Software nicht aus Schichten von abhängigen Funktionseinheiten. Stattdessen denken sie in Scheiben, in Durchstichen, in Längsschnitten durch Software.

Agile Softwareentwicklung orientiert sich konsequent am Nutzen für den Anwender. Der mag klein sein, eine dünne Scheibe vom großen Ganzen, aber nur er zählt.

Solche Nutzenscheiben (Features) können zwar auch abhängig von einander sein insofern, dass z.B. Monatsberichte bei einer Faktura-Anwendung keinen rechten Sinn machen, wenn nicht zumindest Rechnungen vorhanden sind. Doch das ist keine technische Abhängigkeit, sondern nur eine inhaltliche. Das Monatsberichte-Feature könnte mithin technisch hergestellt werden und sogar zum Einsatz kommen, selbst wenn es noch keine Rechnungserfassung gibt, sondern die Rechnungsdaten aus einem Altsystem importiert werden. Abhängigkeiten zwischen Features sind vergleichsweise lose.

Widerstreit

Das scheint mir nun ein fundamentales, wenn auch subtiles Problem: der Widerstreit der Gedankenmodelle, von denen eines die Software in Schichten gegliedert sieht und das andere sie in Scheiben gegliedert denkt.

Diese um 90° gegeneinander gedrehten Vorstellungen von Software müssen von der Programmierung immer wieder überein gebracht werden. Das Vorgehensmodell “denkt” in Scheiben, die Programmierung “denkt” in Schichten.

Klar, irgendwie geht diese Transformation. Jeden Tag bekommen Entwicklergruppen das hin. Aber ist das einfach? Ist das so einfach, wie es sein sollte oder könnte?

Nein, ich glaube, dieser Widerstreit zehrt an der Kraft der Softwareentwicklung. Er führt zu Konflikten zwischen Entwicklern und zwischen Entwicklern und Kunde. Auf die eine oder andere Weise.

Wenn Denkmodelle ganz anders sind, dann braucht es immer wieder Übersetzungsaufwand. Das zeigen Jahrtausende Menschheitsgeschichte. Und jedes Softwareprojekt weiß das aus eigener Anschauung. Denn das Denkmodell des Kunden in Bezug auf seine Fachdomäne trifft ja dort ständig auf das Denkmodell der Entwickler in ihrer technischen Domäne. Bis Entwickler wirklich verstehen, was Kunden wollen, kann viel Zeit vergehen und können viele Tränen fließen.

Warum sollte das anders sein, wenn zwei so unterschiedliche Gedankenmodell in Bezug auf die Herstellung von Software aufeinander treffen? Ist da Verständnis, Harmonie, Einfachheit zu erwarten? Kaum.

Ziel: Kohärenz

Ich glaube, dass Softwareentwicklung mit Agilität solange an eine gläserne Decke stößt, bis sie aufhört, in Schichten und Abhängigkeiten zu denken. Erst wenn ihr primäres Gedankenmodell, d.h. ihre technische Sicht der entspricht, die ein agiler Prozess hat, in dem sie Code produziert, kann sie das nächste Level erreichen. [2]

Kohärenz zwischen agilem und technischem Gedankenmodell ist unabdingbar für eine flüssige Umsetzung von Anforderungen in Code.

Die Frage ist nun, wie kann ein technisches Gedankenmodell aussehen, das Software nicht mehr aus Schichten und Abhängigkeitsbeziehungen aufgebaut sieht, sondern sie ganz natürlich als bestehend aus Scheiben denkt?

Anmerkungen

[1] In der UML mögen “nur” 58% der Diagramme Abhängigkeitsdiagramme sein. Deren Anteil am Entwicklerleben ist aber sicherlich deutlich höher. Ich schätze, dass 80-90% aller Diagramme, die gezeichnet werden von Entwicklern, Abhängigkeitsdiagramme der einen oder anderen Form sind (egal, ob sie strikt der UML folgen oder nicht).

[2] Anders herum hat es übrigens nicht funktioniert. Jahrzehntelang hatte die Softwareentwicklung versucht, die Kunden mit rein technischer Vorgehensweise zu befriedigen. Das Ergebnis kennen wir alle. Software “von unten nach oben” zu bauen, macht niemanden glücklich. Erst das Framework, erst die Infrastruktur, dann die Logik, dann das GUI… Nein, so geht es nicht.

Agile Softwareentwicklung ist das Resultat dieses Irrweges. Sie hat der technischen Sicht eine Kundensicht entgegengestellt, die um 90° gedreht ist. Dadurch ist ein Spannungsfeld entstanden – dem sich früher oder später die Softwareentwicklung eigentlich nur ergeben kann, um effektiver und effizienter zu werden. Mit einem technischen Denkmodell, das immer nur dagegen hält, wird schlicht zuviel Kraft verschwendet.

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.

Co-location als kontraproduktiv erachtet

Wo ein Entwicklungsteam noch an einem Ort sitzt, sollte es verteilt werden. Entwicklungsteams, die gebildet werden sollen, fangen am besten gar nicht erst an, sich an einem Ort zu versammeln. Verteilte Teams sollten der Default sein.

Die Sonne lacht in Hamburg, ein frischer Wind weht an der Alster. Ein guter Tag, um sich unbeliebt zu machen :-) Deshalb diese Vorschläge. Irgendwann muss ich damit mal raus. Warum nicht heute?

Ja, so denke ich inzwischen immer mehr. Co-location ist ein Problem.

Aber der Reihe nach:

Im Jahr 2001 wurde das Agile Manifest unterzeichnet von 17 umtriebigen Geistern - alle weiß, männlich, vor allem Amerikaner und im Durchschnitt zu dem Zeitpunkt wohl um die 50 Jahre alt. Das sage ich so, weil ich glaube, dass wir Agilität wie sie seitdem von den Unterzeichnern gepredigt und von anderen übernommen wurde, davon nicht unabhängig sehen dürfen. Die Unterzeichner sind auch nur Menschen. Sie sind mithin Kinder ihrer Zeit und ihrer Erfahrung. Sie hatten und haben einen je eigenen Horizont, in dem sie denken und innovieren können. Genauso wie Sie und ich ebenfalls.

Scrum wurde von Schaber/Sutherland Mitte der 1990er entwickelt. Da war Schwaber schon 50 und Sutherland wahrscheinlich auch. Sie haben sich darin eingebracht mit allem besten Willen und all ihrer Erfahrung. Nicht weniger - aber eben auch nicht mehr.

Die Frage ist daher: Was war ihre Erfahrung? Und was für ein Ziel lässt sich daraus ableiten?

Das Ziel beschreibt am Ende das Agile Manifest: Es geht um den Softwareproduktionsprozess. Der soll flüssiger werden, der soll näher am tatsächlichen Bedarf laufen. Die Softwareentwicklung soll sich nicht ablenken lassen durch eingefahrene Regularien, Werkzeuge, Dokumentationsanforderungen, Vertragsverhandlungen oder überdimensionierte, schnell veraltende Pläne.

Gut so! Das Manifest enthält wunderbare vier Maximen.

Und dennoch: Es geht um Produktivität. So sehen denn auch die Mittel aus, die zum Einsatz kommen:

• Statt einmaliger Großplanung lieber iteratives Vorgehen in Lernschleifen.
• Statt technischer Meilensteine lieber inkrementelles Vorgehen für schnelleres Feedback.
• Statt Abteilungsgerangel lieber cross-functional teams.
• Statt langsamer indirekter Kommunikation über Hierarchieebenen hinweg lieber schnelle persönliche Kommunikation auf Augenhöhe durch co-location aller Teammitglieder.

Habe ich noch etwas vergessen? Bestimmt. Aber ich glaube, das sind die zentralen Mittel agiler Softwareentwicklung. Auf die sind 50jährige Männer nach intensiver Beobachtung und Diskussion gekommen.

Das ist wunderbar - außer, wenn es nicht wunderbar ist ;-) Denn es steckt in diesen Mitteln Zeitgeist und technische Möglichkeit. Man wusste es halt nicht besser, man konnte nicht anders. Doch seitdem hat sich die Welt gedreht. Wir sind 20 Jahre nach Scrum, 14 Jahre nach dem Agilen Manifest.

Innerhalb meines bescheidenen Horizonts halte ich das iterative/reflektierende Vorgehen für zeitlos. Auch am inkrementellen Vorgehen habe ich nichts auszusetzen. Außer, dass ich es oft noch für zu grobgranular halte und die Iterationen mir zu lange dauern. Aber grundsätzlich bin ich ganz dafür. Und auch die cross-functional teams sind für mich eine sine qua non. Nur so lassen sich Abhängigkeiten flüssig entschärfen.

Bei der co-location hingegen bin ich nicht mehr dabei. Hier sehe ich die weithin real existierende agile Praxis in den 1990ern verharren. Schwaber, Jeffries, Martin & Co sind eben keine digital natives. Sie hatten Email, aber auch wenn Ward Cunningham mit von der agilen Partie war, waren Wikis kein für die Massen verfügbares Werkzeug. Social Media waren in den Kinderschuhen wenn überhaupt Smartphones gab es noch lange nicht. Verteilte Versionsverwaltung lag noch in der Zukunft. Infrastruktur in der Cloud zum kleinen Preis ließ sich noch nicht denken.

Und so sah man sich außerstande, etwas anderes als co-location für die Zusammenarbeit zu empfehlen. Das war ja auch viel besser, als Leute auf office cubicles zu verteilen, oder?[1]

Irgendwie schon. Aber dann doch wieder nicht. Denn ich sehe durch die co-location drei fundamentale Probleme in der Praxis entstehen:

1. Co-location öffnet Unterbrechungen Tür und Tor. Wer im team room nahe beieinander sitzt, kann die Kollegen schnell mal ansprechen. Das ist auch Sinn und Zweck. Fowler sagt: “[I]t promotes lots of informal and deep communication between people on the team.” Was für den, der einen anderen anspricht eine tolle Vereinfachung ist, ist für den Angesprochenen hingegen oft das Gegenteil, nämlich eine Erschwernis seiner Arbeit. Wer angesprochen wird, wird unterbrochen, d.h. aus seinen Gedanken gerissen, im Arbeitsfluss gestört. Da macht es auch nichts, dass der Ansprechende ganz wohlmeinend oder sehr bedürftig ist. Unterbrechungen stören die konzentrierte Herstellung von Resultaten. Das gilt für Unterbrechungen durch Manager, die plötzlich im Raum stehen, genauso wie für Unterbrechungen durch Teammitglieder - oder auch selbstverschuldete Unterbrechungen durch Social Media Benachrichtungen.
2. Co-location leistet unentdeckten Abhängigkeiten Vorschub. Wer im team room sitzt, muss sich tendenziell weniger Gedanken machen über das, was er braucht, um seine Resultate zu erzielen. Abhängigkeiten von Technologien oder Anforderungsverständnis müssen nicht vorher entdeckt und aus der Welt geschafft werden, sondern können ja im Zweifelsfall jederzeit durch Nachfrage bei einem Kollegen aufgelöst werden. Irgendwer weiß immer Bescheid, dafür ist das Team doch cross-functional. Daraus entstehen nicht nur Unterbrechungen für Kollegen, sondern auch geringere Produktivität. Denn so wie ein Koch produktiver ist, wenn er in Phasen arbeitet, also z.B. Gemüse erst komplett schneidet, so ist Softwareentwicklung auch produktiver, wenn sie in Phasen arbeitet; das sind mindestens Analyse, Entwurf, Implementation.[2]
3. Co-location fördert monolithischen Code. Wenn auch nur irgendetwas an Conways Gesetz ist, dann dürfen wir uns nicht wundern, dass 14 Jahre Agilität den monolithischen Anwendungen nicht den Garaus gemacht haben.[3] “Organizations which design systems […] are constrained to produce designs which are copies of the communication structures of these organizations.” Und was für eine “communication structure” soll ein co-located team im team room haben? Eine sehr, sehr enge. Was bedeutet das für das “design”, d.h. die Struktur ihres Produktes Software? Es wird aus eng verbundenen Teilen bestehen.

Auch ich habe meinen Hintergrund. Vor dem sehe ich auf Agilität. Ich bin weniger am Prozess interessiert als am Code.[4] Der muss wandelbar, evolvierbar sein, sondern ist die Softwareentwicklung nicht zukunftsfähig.

Ja, da sehe ich das große Problem unserer Tage in der Softwareentwicklung: Wandelbarkeit. Sogar nicht nur Code, sondern auch Teams (und Unternehmen) müssen wandelbar sein, sich also anpassen können. Dazu gehört natürlich Reflexion, wie sie in der Agilität drinsteckt. Doch es braucht noch mehr. Ohne passende Strukturen lassen sich Ergebnisse der Reflexion nur schwer oder gar nicht umsetzen.

Die meisten Projekte leiden nicht unter technologischen Schwierigkeiten. Wir haben Hardware und Frameworks und Dienste, die leistungsfähig genug sind, um die Effizienzanforderungen an Software zu erfüllen. Das war bis vor 10 Jahren noch ganz anders. Deshalb war Wandelbarkeit für die Agilität auch kein großes Thema. Clean Code kam erst sieben Jahre nach dem Agilen Manifest und 13 Jahre nach Scrum.

Doch nun haben sich die Zeiten gewandelt. Wandelbarkeit ist das zentrale Thema - wenn man nicht grad dem nächsten noch besseren Framework hinterherjagt. Auch die aktuelle µService-Bewegung ist ein Ausdruck des Leidens am Monolithen, an der Unwandelbarkeit.

Und wodurch sind wandelbare Strukturen gekennzeichnet? Durch lose Kopplung. Ein älteres Prinzip gibt es wohl kaum in der Softwareentwicklung.

Lose Kopplung entsteht durch Kapselung (klare Schnittstellen, Autonomie, geringe Abhängigkeiten) und asynchrone Kommunikation.

Wenn man diese Eigenschaften für ein Softwaresystem will, wie ist das zu vereinbaren mit co-location im team room? Wie können lose Kopplung und auch wandelbare verteilte System einfach entstehen, wenn die, die sie herstellenn sollen, einander auf dem Schoß sitzen?

Hier sehe ich die vorherrschende Implementation von Agilität gegen eine Wand laufen. Man macht es sich schwer bis unmöglich, das zentrale Problem der Softwareentwicklung unserer Zeit zu lösen, wenn man als Default für die Teamorganisation den team room setzt.

Entwickler, die man im selben Raum zur selben Zeit sehen will, können eine Menge herstellen - aber entkoppelte Strukturen bzw. wandelbare Software ist sicherlich nicht das Produkt, was ihnen am leichtesten aus den Fingern fließt.

Das Agile Manifest ist gut, wofür es gedacht ist: Produktivität. Es kommt aber an seine Grenzen, wenn es Mittel verschreibt, die der Erfüllung anderer Anforderungen im Wege stehen, hier der Wandelbarkeit.

Deshalb mein radikaler Vorschlag: Geben wir die co-location auf! Setzen wir die Verteilung von Teams als Default. Befreien wir Teammitglieder von Bindungen an Raum und Zeit.

Wir haben genügend Kommunikationsmittel und Tools, um jederzeit Kontakt aufzunehmen zu Kollegen, egal wo sie sich befinden. Chat, Telefon mit Anrufbeantworter, Diskussionsforen, Wikis, Issue Tracker, Repositories, Videokonferenzen, online Whiteboards und was es noch alles gibt in tausend und einer Ausprägung. Asynchrone Kommunikation in unterschiedlicher Geschwindigkeit ist kein Problem. Jeder ist immer erreichbar. Gut so! Wir können unsere Anliegen immer zustellen - ohne den anderen zu unterbrechen. Das sorgt für konzentrierte Arbeit. Das ist gelebte Autonomie: Ich bestimmte selbst über die Nutzung meiner Zeit.

Wohlgemerkt schließt solcher Default der Verteilung nicht die synchrone Kommunikation aus. Zu einem Telefonat oder eine Videokonferenz kann man sich jederzeit verabreden. Das gilt sogar für persönliche Treffen, also Meetings. Niemandem wird verwehrt, sich eine Art der Zusammenarbeit zu wünschen, die für ihn und seine Resultate zuträglich ist. Nur muss das jeder mit den Kollegen verhandeln, denn die mögen andere Vorstellungen davon haben, wie sie ihre Ergebnisse am liebsten erzielen.

Verteilte Arbeit macht es schwerer, dass lokale Resultatsoptima entstehen. Ein Resultat kann weniger einfach auf Kosten vieler anderer Resultate hergestellt werden. Das Ganze wird betont, optimiert - ja, auch wenn ein Einzelner, ein individuelles Resultat dabei einmal zu kurz kommen sollte.

Dass man für verteiltes Arbeit ein paar andere oder gar mehr Soft Skills benötigt, als für die befohlene Arbeit am selben Ort zur selben Zeit wie andere, das mag sein. Man muss sich besser organisieren können, verantwortungsbewusster sein, expliziter und verlässlich kommunizieren… Aber nur weil das schwierig für manche sein mag (ja, auch und gerade für Manager), sollte das nicht bedeuten, dass verteilte Teams nicht anstrebenswert seien. Denn es steht viel auf dem Spiel. Es geht um nicht weniger als die verlässliche Herstellung von Wandelbarkeit. Ohne die gibt es nämlich keine Zukunftsfähigkeit. Sowohl für Code wie für Teams.

Mit verteilten Teams entstehen nämlich nicht nur (einfacher) wandelbare Softwarestrukturen, sondern auch wandelbare Teams. Wo ein Team verteilt arbeitet, ist die Einbindung von neuen Kollegen an beliebigen Orten einfacher. Das ist doch eine gute Nachricht für das Recruiting, oder? Dadurch kommen leichter neue Impulse zu allerlei fachlichen Aspekten ins Team.

Ganz davon abgesehen, dass verteilte Teams weniger hausinterne Infrastruktur brauchen. Heute gibt es alles, was das Entwicklerherz begehrt, in der Cloud. Wer wollte da auch nur einen Server kaufen? Was Entwickler brauchen, sind gute Laptops und viel Internetbandbreite. Gelegentlich noch ein Raum, um tatsächlich mal zusammenzukommen. Am besten mit Beamer/Smartboard und Flipchart. Und das Internet muss stets verlässlich da sein wie Strom aus der Steckdose. Ohne lästige Spezialfirewalls, die Superproxys brauchen, die den Zugriff auf ein DVCS behindern.

Wohlgemerkt, ich rede hier über Entwickler, nicht über sonstige Mitarbeiter von Unternehmen. Was die brauchen, ist eine andere Sache. Aber nur weil die vielleicht etwas brauchen - zum Beispiel ein total supersicheres Firmennetz -, sollte das nicht bedeuten, dass die Softwareentwicklung sich aus Solidarität auch ein Bein hochbinden muss.

Bottom line: Ich glaube, die Zeit der co-location als Default ist vorbei. Angesichts der Kommunikationsmöglichkeiten, die wir haben, hat sie den Punkt erreicht, wo sie kontraproduktiv wird.

Ja, wir haben das Zusammenhocken lieb gewonnen. Irgendwie ist es auch kuschelig mit den Kollegen. Aber was wollen wir? Kuscheln oder wandelbare Software?

Wer kuscheln will, kann z.B. per Chat im Team anfragen, wer mitmachen möchte. Dann kann ein Meeting vereinbart werden. Das sollte jedoch die Ausnahme sein. Synchrone persönliche Kommunikation vieler Teammitglieder macht vielleicht ein gutes Gefühl - aber es wird andererseits auch ganz schnell ganz viel Geld verbrannt.

Die Väter der Agilität haben es gut gemeint. Doch sie waren eben auch begrenzt in ihrer Erfahrung mit Kommunikationstechnologie. Ken Schwaber konnte z.B. nicht anders, als lange Jahre seines Lebens mit Telefon ohne Anrufbeantworter zu leben und zu arbeiten. Dann mit Anrufbeantworter und gelegentlichem Fax. Dann irgendwann später mit Email usw. Kein Wunder, dass er und die anderen co-location als Wunderwaffe empfanden. Irgendwie liegt sie uns ja auch im Blut. Die Bandbreite der Kommunikation ist da so schön hoch.

Aber kuschelige Bandbreite ist eben nicht alles. Wenn ungehinderte Kommunikation in hoher Bandbreite die Norm ist, ist irgendetwas optimiert – und irgendetwas bleibt auf der Strecke. Das ist die Wandelbarkeit.

Drum sage ich: Vorsicht vor der co-location!

So viel Verteilung und Autonomie und Entkopplung wie möglich, so wenig co-location wie nötig.

---

1. Wir können spekulieren, wie das Agile Manifest ausgesehen hätte, wenn 50% der Unterzeichner Frauen gewesen wären. Oder das Durchschnittsalter 25 Jahre. Oder unterschiedliche Kulturen vertreten gewesen wären. ↩

2. Wer hier herauslesen will, dass ich für Big Design Up-Front (BDUF) wäre, liegt falsch. Diese Phasen können manchmal nur Minuten oder Stunden dauern. Selbst in der agile Praktik TDD stecken sie drin - ohne dass das betont würde. 30 Minuten Entwurf mit 2 Stunden folgender Implementation können 5 Stunden vermeintlich reiner Implementation ersetzen, in denen der Entwickler dauernd in unvermutete Abhängigkeiten läuft. Dass man durch beliebig lange Analyse- und Entwurfsphase alle Abhängigkeiten entdecken könnte, behaupte ich auch nicht. Aber ein gesundes Maß an Analyse und Entwurf ist nötig; mehr als oft aufgewandt wird in agilen, co-located Teams. ↩

3. Ganz davon abgesehen, dass Agilität ja nicht Wandelbarkeit als ausdrückliches Ziel hat. Wie man ganz deutlich an Scrum sehen kann, kümmert sich der agile Prozess gar nicht um die Sache - Code -, sondern nur um den Rahmen für die Produktion der Sache. Nicht umsonst hat Jeff Sutherland nun auch ein Buch geschrieben, das Scrum auf alle möglichen Arbeitsfelder anwendet (“The Art of Doing Twice the Work in Half the Time”). ↩

4. Allerdings verschiebt sich dieser Fokus notgedrungen in den letzten Jahren. Denn ich merke, dass ich die Verbesserungen, die mir für Code vorschweben, in Unternehmen nicht gut verankert bekomme, wenn mir der Prozess oder gar die Unternehmenskultur egal ist. Aber das ist ein Thema für einen anderen Artikel… ;-) ↩

Get real, Kanban!

Schöne Sache das Networked Kanban wie es Jurgen Appelo in seinem Blogbeitrag beschreibt - nur was ist denn daran wirklich neu? Jeder nicht triviale Produktionsprozess ist mehr als eine "Eimerkette". Und jeder Produktionsschritt arbeitet immer aus einer Warteschlange. Die ringelt sich auf dem Schreibtisch in Form einer Inbox, die besteht aus Post-It Notes am Monitor oder die zischelt in Excel oder einem anderen Tool im Intranet.

Die "Erfindung" von Kanban kann also nicht in Warteschlangen bestehen. Und wenn Kanban die Softwareproduktion als "Eimerkette" sieht, dann ist das eine sehr vereinfachende Sichtweise.

Aber zum Glück bietet Kanban mehr. Es geht darum, die ohnehin immer existierenden Warteschlangen zur Steuerung zu nutzen. Der bewusste Umgang mit Warteschlangen ist der Trick bei Kanban. Weg von der lokalen ad-hoc Optimierung hin zu einer globalen Optimierung.

Guter Ansatz - nur fehlt mir immer wieder dabei etwas. Daran rührt Jurgen Appelo, finde ich. Es fehlt die Frage, wie denn überhaupt der Produktionsprozess aussieht?

Die Kanban-Boards, die ich bisher gesehen habe, sind aus meiner Sicht so einfach, dass sie der Realität des Softwareproduktionsprozesses nicht wirklich gerecht werden, finde ich. Man freut sich, dass man ein Board aufhängt und nun Warteschlangen beobachtet. Das Vorhandensein eines Terrariums auf dem Gang wird als Meilenstein betrachtet.

Doch was ist es, das man dort beobachtet? Ist das wirklich genug? Ist das die Realität oder nur eine mühelose Abstraktion?

Jurgen Appelo  kommt der Wirklichkeit näher mit dem Netzwerk. So kann Kanban skalieren. (Ob Kanban dafür dann ein guter Name ist, lasse ich mal dahingestellt. Er ist zumindest eingebürgert.)

In Jurgens Beitrag kann man ahnen, dass Softwareproduktion erstens ein Netzwerk von Produktionsschritten ist und zweitens auch noch eine Holarchie: jeder Produktionsschritt auf einer Abstraktionsebene kann potenziell wieder ein Produktionsprozess bestehend aus mehreren Schritten sein. Ich fühle mich erinnert an Staged Event Driven Architecture, SEDA:

Die Masterfrage jedoch lässt auch Jurgen offen: Wie sieht denn überhaupt der Produktionsprozess im Ganzen aus? Wieviele Ebenen hat er, aus welchen Schritten besteht er?

Board-Beispiele wie dies

finde ich viel zu starr. Das Leben und die Produktion von Software finden nicht im Schwimmbad auf klaren Bahnen statt.

Indem Kanban aber immer wieder nur so beschrieben wird, macht man es Teams schwer, ihre Realität wirklich zu finden - und zu optimieren. Denn es kann ja nicht nur darum gehen, einen simplifizierten Prozess zu optimieren. Auch das führt nur zu Reibungen - über die man sich wundert, weil man doch lokal alles optimal gemacht zu haben meint.

Jurgens Beitrag sollte daher ein Appell sein, sich mehr Gedanken über den Produktionsprozess von Software zu machen. Wenn dabei dann erstmal soetwas herauskommt ist das auch ok:

So ist halt das Leben. Gut, dass man das weiß. Dann kann man an die Sache wirklich bewusst herangehen. (Im Bild ist zum Beispiel zu sehen, dass nicht die Softwareentwicklung das Problem ist. Die mit Kanban zu optimieren, brächte nichts. Das Problem steckt in den Schritten davor (rot).)

Kanban-Kärtchen schieben, ist auch wieder keine Silberkugel für die Softwareentwicklung. Genauso wenig wie jeden morgen 15 Minuten Standup-Meeting und alle 3 Wochen ein Release rausschieben nach Scrum.

Die Realität ist unordentlicher und schmutziger. Sie muss zuerst erkannt werden. Teams müssen sich das IST bewusst machen, bevor sie auf den einen oder anderen Zug aufspringen. Das, würde ich sagen, hat auch Jurgen in gewisser Weise gemerkt. Sein Beitrag hilft damit, realistischer in eine Veränderung des Vorgehens bei der Softwareentwicklung einzusteigen. Analyse und Nachdenken helfen halt doch.

Am Ende zählt nicht, ob man Scrum oder Kanban “nach dem Buch macht”. Es zählt, dass die Softwareproduktion besser ist als vorher.

Agil persönlich definiert

In meiner Kritik an Martin Fowlers Absage an die Wissenschaftlichkeit habe ich anklingen lassen, dass ich selbst eine Definition für Agilität hätte. Darauf bin ich nun ein paar Mal angesprochen worden. Nun muss ich wohl Butter bei die Fische machen und sie einmal beschreiben.

Meine Definition

Also gut… Hier sind meine persönlichen Kriterien für agiles Vorgehen oder eine Haltung der Agilität. Sie sind natürlich nicht rigoros im mathematischen Sinne. Das habe ich auch nicht von Martin Fowler erwartet. Aber ich halte sie für klar genug, um mit ihnen in der Hand an ein Projekt herantreten zu können für eine Prüfung, ob es agil durchgeführt wird.

Inkrementell

Die wesentliche Neuerung, die die Agilität in die Softwareentwicklung aus meiner Sicht gebracht hat, ist das Denken in und die Entwicklung von Durchstichen. Software wird nur in nützlichen Inkrementen ausgeliefert. Agilität liefert “Anforderungsscheiben”, d.h. sie macht vertikale Schnitte durch ein Softwaresystem. Als fertig und somit projektfortschrittsrelevant wird angesehen, was dem Kunden etwas wert ist.

Was war vorher? Vorher war die Entwicklung in Meilensteinen. Zum Begriff Meilenstein gehört aber nicht notwendig der Durchstich. Ein Meilenstein kann auch sein “Datenbankschicht fertig” oder “ESB aufgesetzt”. Solche Infrastrukturbelange mögen irgendwie wichtig sein, ohne Datenbankzugriff oder ESB läuft das Softwaresystem nicht. Allerdings interessieren die den Kunden nicht direkt; sie sind nicht nützlich. Er will seine Aufträge bearbeiten, Planungen durchführen, Ressourcen verwalten usw.

Eine Datenbank oder ein ESB sind einfach keine funktionale und auch keine nicht-funktionale Anforderung. Sie sind Mittel zur Realisierung von Anforderungen. Deshalb sind die für sich genommen nicht wertvoll.

Aus meiner Sicht ist es genau diese Unterscheidung, die Agilität vor allem auszeichnet. Den Blick auf die Erfüllung von Anforderungen zu konzentrieren und sich nicht von Mitteln ablenken zu lassen, das macht Agilität für mich aus.

Lernend

Die zweite Neuerung, die Agilität in die Softwareentwicklung gebracht hat, war aus meiner Sicht die Haltung des ewigen Schülers. Wer agil arbeitet, bewegt sich in einer Lernschleife:

1. Herausfinden, was gewünscht ist
2. Inkrement herstellen
3. Überprüfen, ob das Inkrement für den Kunden akzeptabel ist

In der agilen Softwareentwicklung gibt es also keine Phase, die je abgeschlossen wäre.

Agilität läugnet insofern nicht, dass Softwareentwicklung in sequenziellen Phasen abläuft. Man muss zuerst herausfinden, was gefordert ist, dann muss man die Realisierung planen, dann kann man den Plan implementieren [1] und erst danach kann man die Implementierung überprüfen und schließlich abnehmen lassen.

Aus Sicht der Agilität ist nichts gegen solche Phasen zu sagen. Sie sind sozusagen unterhalb des Radars der Agilität. Deshalb kann man aus meiner Sicht auch nicht mit der Agilität begründen, dass man nicht dokumentiert oder entwirft. Agilität wendet sich nicht dagegen. Es ist ihr schlicht egal. Sie sagt: Mach, was nötig ist, um Inkremente heute und in Zukunft zügig herstellen zu können. Denn nur so kann ihr Anspruch des Lernens erfüllt werden.

Zunächst hatte ich gedacht, dass ein wichtiger Baustein der Agilität Iterationen seien. Inzwischen sind für mich Iterationen allerdings nur noch ein Mittel. Und der wirkliche Baustein der Agilität ist das Lernen. [2] Ebenso sind z.B. Scrum Retrospektiven auch nur ein Mittel, um den Baustein Lernen in ein Projekt zu setzen.

Das bedeutet im Umkehrschluss: Agilität ist dort unnötig, wo nicht gelernt werden muss. Wenn glasklar ist, was zu tun ist, wenn es nur marginale Unwägbarkeiten gibt… dann muss man nicht agil sein.

Agilität ist also kein Ansatz für die Produktion, sondern für jede Form von Entwicklungstätigkeit, sei das “bei den Kreativen” oder bei Ingenieuren.

Unmittelbar

Die dritte Neuerung der Agilität ist dann die Betonung der unmittelbaren Kommunikation. Die, die ein Ergebnis sehen wollen und die, die es herstellen sollen, sitzen im selben Boot. Also ist es wichig im Sinne der Lernschleife und zügiger Inkremente, dass diese Beteiligten möglichst barrierefrei Kontakt haben.

Wie das konkret geschieht, ist der Agilität wieder egal. Aber typische Maßnahmen im Sinne der Unmittelbarheit sind cross-functional Teams und co-location. Auch das Verhältnis ProductOwner zu Entwicklern in Scrum ist dafür Ausdruck.

Informationen sollen fließen, Entscheidungen sollen zügig getroffen werden. Bürokratie jeder Art (Hierarchien, Verträge, Dokumente, Konventionen, …) gehört für die Agilität deshalb auf den Prüfstand. Was nicht unmittelbar dem Ziel “Nützliches Produkt” dient, soll weggeschnitten werden.

Meine Hypothese

Agilität zu definieren ist kein Selbstzweck. Eine Definition macht nur Sinn, wenn daraus etwas abgeleitet wird. Eine Hypothese kommt erst zustande, wenn der Definition auch eine Ergebniserwartung zugeordnet wird.

Aus meiner Sicht lautet die Vorhersage der Agilität:

Wer agil Software entwickelt, der hat größere Chancen, bei gegebenen Budgets (Geld, Zeit, Ressourcen) hohen Nutzen für den Kunden herzustellen.

Oder etwas konkreter: Mit Agilität werden weniger Projekte abgebrochen und die Überziehungen werden geringer und das Supportaufkommen fällt auch nicht so hoch aus.

Natürlich ist diese Vorhersage im Komparativ formuliert. Agilität ist ja als Gegenentwurf zu etwas Bestehendem entstanden. Demgegenüber will sie bessere Ergebnisse liefern. Aber sie ist zumindest so “bescheiden”, sich nicht als das Ende der Fahnenstange zu sehen. Zumindest sollte sie das sein, denke ich. [3]

Zusammenfassung

Das war´s. Mehr gehört für mich derzeit nicht zur Definition von Agilität. Bestimmt ist es weniger, als viele von Ihnen erwartet hätten. Mir reicht es aber. Denn mit diesen Kriterien an der Hand kann ich jedes Projekt, jedes Unternehmen beurteilen. Und Sie können das auch. Dafür muss ich Sie nicht “weihen” ;-)

Gehen Sie einfach diese Checkliste durch:

1. Geht es um ein Entwicklungsvorhaben? Stichwort: Kreativität
2. Wird das Ergebnis inkrementell hergestellt? Stichwort: Durchstiche
3. Wird bewusst lernend vorgegangen? Stichwort: Reflexion
4. Sind die Vorhabenbeteiligten in unmittelbarem Kontakt? Stichwort: Kommunikationsfluss

Wenn jede Frage mit eine Ja beantwortet werden kann, dann liegt grundsätzlich Agilität vor.

So einfach ist das :-) Dazu müssen Sie - aus meiner Sicht - nicht Martin Fowler anrufen und fragen, ob er Agilität erkennt.

Sie können jetzt selbst beurteilen, ob Agilität etwas bringt. Wenn ein Vorhaben inkrementell, lernend und unmittelbar durchgeführt wird, aber sich kein Erfolgsmesswert verbessert… dann nützt ihm Agilität nichts. Dann kann man auch wieder wie früher arbeiten, falls das irgendwelche Vorteile haben sollte. [4]

Und Sie können überlegen, ob gewisse Methoden agil sind oder inwiefern sie der Agilität dienen. Fragen Sie, wie sie das Lernen oder die Unmittelbarheit oder die Lieferung von Inkrementen unterstützen.

Wenn Sie mögen, übernehmen Sie meine Definition von Agilität. Und wenn nicht, dann lassen Sie uns drüber reden, was fehlt. Ich behaupte nicht mal, dass sie gut sei jenseits dessen, dass ich sie für mich praktisch finde. [5] Ich sage nur, dass es überhaupt eine Definition ist und damit das Minimum, was wir von einem Ansatz zur Softwareentwicklung erwarten können.

Fußnoten

[1] Wie umfangreich ein solcher Plan ist, sei dahingestellt. Er mag für Triviales quasi nicht existent sein, so dass die Codierung gleich starten kann. Für anderes mag dann aber durchaus etwas Nachdenken/Entwurf angezeigt. Die Agilität sagt nicht, wieviel Planung nötig ist. Das ist nicht ihr Thema. Sie beschränkt sich auf die Anerkennung von Phasen in der Herstellung von Inkrementen. Wieviele und welche Phasen das sind… ist eine Sache des Herstellungsprozesses. Der sieht für Software anders aus als für ein Auto.

[2] Zu meiner Liste von Agilitätskriterien gehörte zunächst auch noch “Haldenreduziert”. Damit wollte ich dem Aversion gegen “B*UF” (Big {Design, Documentation, …} Up Front) Ausdruck geben. Inzwischen sehe ich es aber so, dass auch das nur eine Folge der Lernwilligkeit ist. Große Halden an Anforderungen, Entwürfen usw. erzeugen einfach Trägheit, die das Lernen behindern. Sie reduzieren die Lernschleifenfrequenz.

[3] Vielleicht ist das unnötig zu erwähnen. Denn wenn Lernen ein Bestandteil der Agilität ist und sie sich so minimal definieren sollte, wie ich das hier zunächst mal nur für mich persönlich tue, dann gibt es erstens daran keinen Zweifel und zweitens steht nicht zu erwarten, dass Agilität dann abgelöst würde. Sie wäre vielmehr der Kern von Weiterentwicklungen.

[4] Selbstverständlich gibt es noch eine andere Möglichkeit: Es könnte sein, dass das mit dem inkrementellen, lernenden und unmittelbaren Arbeiten noch nicht optimal ist. Man kann ja besser oder schlechter inkrementell vorgehen usw. Kritik an der Implementation von Agilität darf also sein. Da gibt es Interpretationsspielraum. Und damit gibt es Raum für die Entwicklung der Agilität. Es können sich ja über die Zeit Best Practices herauskristalisieren, die dann in die Definition von Agilität einfließen.

[5] Allerdings impliziere ich, dass meine Definition in Linie steht mit dem agilen Manifest und beliebten Methoden der Agilisten. Das ist für mich ein Hinweis auf eine gewisse Grundqualität.