Human Systems Dynamics: Ein Modell zur Selbstorganisation

„Welche Theorien nutzen Sie eigentlich, um Ihre Firma zu organisieren?“ werde ich gelegentlich von jenen gefragt, die verstanden haben, dass wir immer weniger nach klassischen Unternehmensstrukturen arbeiten und dennoch kein wildes Chaos zelebrieren. Ich persönlich beschäftige mich seit vielen Jahren mit systemischen Ansätzen, spätestens seit ich vor 12 oder 13 Jahren Peter Senges „Fifth Discipline“ und Jerry Weinbergs „Quality Software Management Series“ gelesen habe. Aber das wirklich operationalisierbar zu machen, ist mir erst gelungen, nachdem ich letztes Jahr von Diana Larsen Human Systems Dynamics (HSD) kennengelernt hatte und mich anschließend intensiver damit beschäftigt habe. Der Ansatz findet auch innerhalb von it-agile mehr und mehr Anwender, so dass ich wohl nicht zu sehr daneben greife, wenn ich ihn zumindest als eine von mehreren Theorien sehe, auf denen wir aufbauen.

Worum geht es? Etwas flapsig formuliert ist HSD ein Mashup verschiedener Modelle aus dem Umkreis der System- und Komplexitätstheorie, angepasst für den Einsatz in Organisationen. Der Grundkurs dauert 14 Tage, Sie werden also vermutlich gar nicht wollen, dass ich das hier ausführlich darstelle… Grundlage ist die Sicht einer Organisation als komplexes, adaptives System von Individuen. Diese Sicht funktioniert für jede Organisation, von der straff durchorganisierten Behörde bis zum chaotischen Grundlagenforschungs-Team. Jede Organisaton lässt sich mit Hilfe des sogenannten CDE-Modells modellieren, das hilft, die Organisation oder Teilaspekte von ihr als komplexes System zu verstehen. In diesem Modell wird das System nach drei verschiedenen Aspekten modelliert: Container, Differences und Exchanges

  • Container sind die Grundelemente, aus denen die Organisationen aufgebaut sind. Das können individuelle Mitarbeiter sein, Abteilungen oder Arbeitsgruppen, also alles, was in einem Organigramm sichtbar ist. Aber es gibt auch ganz andere Formen von Containern, zum Beispiel Meetings und Boards für Kommunikation, Büros, Standorte, Regelwerke und so weiter. Im wesentlichen kann alles ein Container sein, was nach außen halbwegs klar abgrenzbar ist und in sich ein Eigenleben führt – und sei es auch noch so traurig. Wobei Regelwerke genau genommen Container definieren. Die Container entsprechen also den Aktoren in der klassischen Systemtheorie. Anders als Aktoren in der klassischen Systemtheorie können Container in HSD allerdings geschachtelt sein, also jeder Container besteht für sich wieder aus einem kompletten System
  • Differences sind Unterschiede zwischen verschiedenen Containern, aber auch innerhalb eines Containers. Wenn ich eine Entwicklungsabteilung und eine Testabteilung als zwei verschiedene Container habe, ist deren unterschiedliche Aufgabe ein „Difference“, aber auch die unterschiedliche Ausbildung, unterschiedliche Berufserfahrungen, unterschiedliche Aufgabenstellung, unterschiedliche Vorlieben beim Essen, in der Kleidung, in der Partnerwahl usw. sind Differenzen. Einige dieser Unterschiede sind relevant für das System, wie z.B. Ausbildung oder Aufgabenstellung, andere sind nicht relevant, wie z.B. die Unterschiede in der Partnerwahl oder die Vorlieben beim Essen. Welches die „Unterschiede sind, die einen Unterschied machen“ hängt dabei vom Kontext ab. So können die Vorlieben bei der eigenen Partnerwahl, die in unserer Branche keine Rolle spielen (sollten) durchaus eine Rolle spielen, wenn man in einer Konfliktberatung für Homosexuelle arbeitet, oberster Schwulen-Hasser der Tea-Party-Bewegung oder weißrussischer Diktator ist. Welche Unterschiede wirklich relevant sind, ist nicht immer offensichtlich und kann durchaus auch zu Überraschungen führen. Unterschiede sind nichts schlechtes, sondern sie stellen nach HSD die potenzielle Energie dar, die das System antreibt. Ein klassischer Antrieb sind zum Beispiel die Unterschiede in der Hierarchie einer Organisation, die über Arbeitsanweisungen und ähnliche Mittel Energie in das operative Geschäft einspeisen, über Statusunterschiede und Karrierewünsche aber auch die Energie für persönliche Veränderungen erzeugen. Wichtig für eine zielgerichtete Organisation ist, dass die potenzielle Energie dieser Unterschiede im wesentlichen auf das Ziel hinführen und nicht in internen Streitereien oder Grabenkämpfen aufgebraucht wird. Unterschiede sind also neutrale Fakten, weder gut, noch schlecht – die potenzielle (chemische) Energie eines Stücks Dynamit kann ja auch ebenso zum Freisprengen eines Tunnels genutzt werden, wie für die Expansionsgelüste weißrussischer Diktatoren.
  • Exchanges sind schließlich die Interaktionen zwischen oder innerhalb von Containern. Exchanges können breit, ungerichtet und informell sein, wie das Gespräch in der Kaffeeküche oder – ein wenig formalisierter – ein Open Space. Sie können aber auch sehr schmal und zielgerichtet sein, wie das Einreichen eines Formulars. Sie können synchron und breitbandig sein, wie ein persönliches Gespräch oder ein Meeting, oder asynchron und schmalbandig, wie ein E-Mail-Kanal, ein Microbloggingsystem oder ein Bugticket. Auch hier gilt wieder: Es gibt kein richtig und kein falsch, kein besser und schlechter, sondern nur unterschiedliche Effekte, je nach Gestaltung des Exchanges. Es gibt auch Container, die ihrerseits Exchanges sind. So kann man ein Kanbanboard als Container auffassen, der dem Team einen asynchronen Exchange mit hoher Breite und geringer Tiefe bietet. Hängt das Kanbanboard an der Wand, benötigt das Team weniger Energie für den Exchange und nutzt ihn damit häufiger, liegt es elektronisch vor, benötigt es mehr Energie und der Exchange büßt damit Bandbreite und und Austauschfrequenz ein. Ob das ein Unterschied ist, der einen Unterschied ausmacht, muss man ausprobieren. Das Daily Standup ist ebenfalls ein Container für einen weniger formalisierten Exchange, das Formular für Reisespesen ist ein Beispiel für einen hochformalisierten Exchange.

HSD beitet nun eine Reihe von Werkzeugen und Ansätzen, um durch geeignete Gestaltung von Containern, Differences und Exchanges zu erreichen, dass sich in dem System hilfreiche Verhaltensmuster ausbilden. Die Organisation wird also nicht durch Organigramme, Rollen und Artefakte gesteuert, sondern auf der Meta-Ebene, indem Container mit sinnvollem Schnitt von Differenzen und adäquaten Exchanges etabliert werden. Dadurch entwickelt das System ein bestimmte Verhaltensmuster, es tritt also Emergenz auf. Ich komme gleich noch mal auf die Gestaltung eines solchen Systems.

Ein System kann nun in verschiedenen Modi operieren: Vom effizienten, kontrollierten aber unflexiblem über selbst-organisiert-adaptives Verhalten bis hin zum chaotisch-innovativem Verhalten. Dieses Kontinuum ist auch vom Stacey-Diagramm bekannt. Welches Verhalten zielführend ist, hängt von der Aufgabenstellung ab. So möchte man das Finanzamt gerne im kontrolliert-vorhersehbares Bereich verortet wissen, während die Experimentalphysiker besser im innovativ-choatischen Bereich nach Higgs-Bosonen suchen. Produktentwicklung wiederum findet sinnvollerweise im selbstorganisiert-adaptiven Bereich statt, weil dort sowohl Zielerreichung als auch innovative Ideen eine Rolle spielen (genau genommen muss auch Grundlagenforschung einen großen Teil der Zeit in diesem Bereich spielen, wenn es darum geht, Ideen wissenschaftlich sauber aufzuarbeiten). Als Faustregel gilt: Je größer die Container und Differenzen sind und je breiter und ungerichteter die Exchanges sind, umso mehr arbeitet die Organisation Richtung innovativ-chaotisch, je kleiner die Container und Unterschiede und je enger die Exchanges sind, umso mehr arbeitet das System im kontrollierten Bereich. Daher basieren Exchanges in Behörden stark auf Formularen und Dienstwegen und führen damit zu kontrolliertem Verhalten. Grundlegende Forschungserkenntnisse, die durch das Ausfüllen von Formularen gewonnen wurden, sind mir nicht bekannt (wobei Umfragen nur Exchanges sind, um Rohmaterial zu besorgen, die Forschung findet in der Auswertung statt).

Ein schönes Beispiel für die Gestaltung eines solchen Systems ist Scrum: Es definiert Container für die Struktur (Team, Product Owner, Scrum Master, Stakeholder) und Exchanges (Planning, Daily Scrum, Taskboard, Product Review und Retrospektive). Einige sind breit und relativ ungerichtet (Planning, Retrospektive), andere eher eng und formalisiert (Daily Scrum, Storycard). Der Containerschnitt trennt manche Unterschiede, wie z.B. PO und Team (Was? und Wie?), um die Exchanges zu kanalisieren. Andere Schnitte definieren, welche Unterschiede innerhalb der Container liegen sollten, um dort sehr breite Exchanges zu ermöglichen (Entwickler und Tester im cross-funktionalen Team). Es gibt Änderungen an Scrum, die diese Struktur nicht beeinträchtigen und damit verträglich sind mit Scrum, zum Beispiel die Frage, ob das Team mit oder ohne Taskplanung arbeitet. Andere Änderungen beeinträchtigen die Strukturen und führen daher in der Regel zum ScrumBut, zum Beispiel wenn der Product Owner oder ein anderer Manager die Containergrenzen missachtet und dem Team in technische Entscheidungen hineinpfuscht.

Wie kann man HSD nun zur Gestaltung von Organisationen nutzen? Letztlich geht es wie gesagt darum, die „richtigen“ Container, Differenzen und Exchanges zu etablieren. Das ist aber leichter gesagt, als getan, weil sich die Auswirkungen von Änderungen in komplexen adaptiven Systemen nicht vorhersehen lassen. Bei dem einen Team setzt ein kurzer Scrum-Lehrgang ungeahnte Energien frei und verändert das gesamte Miteinander. In einem anderen Team müht sich der gleiche Coach zwei Jahre ab und das Team fällt binnen weniger Monate in die alten Arbeitsweisen zurück, sobald es wieder auf sich gestellt ist. Beide Verhaltensweisen lassen sich sich mit HSD erklären: Das System (=Team) bildet ja nicht nur aufgrund der formalen Container, Differenzen und Exchanges Verhaltensmuster aus, sondern auch aufgrund der informellen, die sich oft über zehn oder mehr Jahre entwickelt haben. Ein wesentliches Merkmal komplexer Systeme ist ihre „Resilienz„, die Fähigkeit, äußere Veränderungen abzupuffern, ohne die Muster nachhaltig zu verändern. In der Regel sind versteckte Regeln dann mächtiger, als die offiziellen. Welche Änderungen notwendig sind, um echte Veränderung zu bewirken, lässt sich also nicht vorhersagen, weil man nicht weiß, wie die einzelnen Individuen und Container tatsächlich auf die Veränderung reagieren.

Man muss also experimentieren: Eine Änderung vornehmen und schauen, ob sie zu der gewünschten Veränderung führt. Dann die nächste Änderung vornehmen und so weiter. Um Resilienz zu durchbrechen, muss man manchmal auch „eine Bombe zünden“, also grundlegende Strukturen verändern, wie Scrum das meist tut. Aber es gibt nun mal Bunker, die sich auch mit viel Dynamit nicht sprengen lassen.

Das Experiment umfasst übrigens immer die Option des Scheiterns. Deshalb lassen sich agile Einführungen auch nicht vorweg planen und per „Blueprint“ ausrollen. Und deshalb haben wir beim „Agile Enterprise Adoption Workshop“ der Agile Alliance auch das „Ständige Lernen durch Experimente“ als eines der fünf kennzeichnenden Merkmale agiler Organisationen identifiziert.

Selbstorganisation bei it-agile

„The best architectures, requirements, and designs emerge from self-organizing teams“ heißt es in den viel zu wenig beachteten 12 Prinzipien des agilen Manifests. Nach mittlerweile mehr als einer Dekade Erfahrung mit agiler Entwicklung wird wohl jeder Praktiker dieses Prinzip bestätigten.

Auf Teamebene ist Selbstorganisation mittlerweile Stand der Kunst. Aber wenn es um eine ganze Organisation geht, betritt man noch immer Experimentiergebiet. Wir versuchen bei it-agile, Selbstorganisation so weit zu leben, wie das möglich ist (siehe dazu auch Stefan Roocks Blog-Eintrag) – eine erhebliche Herausforderung, weil die meisten traditionellen Organisationsformen früher oder später auf hierarchische Strukturen zurückgreifen. Nun ist es das eine, von hierarchiefreien, selbstorganisierten Unternehmen zu träumen, etwas anderes, das wirklich umzusetzen. Zumindest, wenn man die Phase des kleinen Startups verlassen hat, das im wesentlichen auf Zuruf funktioniert.

it-agile gehört zu über 70% den derzeit 33 Mitarbeitern, wodurch die Mitarbeiter rein formal jederzeit einen Gesellschafterentscheid herbeiführen können. Bei den meisten Firmen mischen sich Gesellschafter nur sehr wenig in die operativen Abläufe im Unternehmen ein, weil sie ihre Beteiligung eher als Finanzanlage sehen. Unsere Gesellschafter haben aber deutlich mehr im Spiel: Ihre Entscheidungen beeinflussen nicht nur die Rendite, sondern auch ihre tägliche Arbeit. Sie machen daher munter von ihren Möglichkeiten Gebrauch und fällen Entscheidungen über alle Belange, die ihnen wichtig sind. Das Paradies?

Leider hat auch diese weitreichende Selbstorganisation ihre Schattenseiten. Schließlich müssen sich über 30 erwachsene Menschen auf Lösungen einigen. Das führt dazu, dass Entscheidungen intensiv diskutiert werden, was sie nicht immer beschleunigt.

Damit Selbstorganisation funktioniert, benötigt man unstrukturierte Kommunikationskanäle. In vielen Unternehmen tut eine gemütlich eingerichtete Kaffeeküche da schon gute Dienste, wir arbeiten oft über ganz Deutschland verteilt. Als Kaffeeküchenersatz nutzen wir ein internes Microbloggingsystem, das von der Mehrheit der Mitarbeiter fleißig genutzt wird.

Das reicht in der Regel, um einen großen Teil der Probleme zu artikulieren. Sie zu einer Lösung zu führen, ist deutlich schwieriger. In den letzten Jahren haben wir gelernt, durch den Einsatz von regelmäßigen Open Spaces, World Cafés, Fishbowl Sessions und Retrospektiven auch mit über 30 Mitarbeitern noch zu Entscheidungen zu kommen, aber manchmal braucht das schon eine ganze Menge Moderationstechnik. Vor allem aber haben wir gelernt, nicht mehr nach der großen Lösung zu suchen. Stattdessen bemühen wir uns um kleine Schritte. Statt des großen Veränderungsprojekts setzen wir auf kleine Experimente. Die Chance, für einen Vorschlag eine Mehrheit zu bekommen, ist umso größer, je kleiner die Veränderung ist.

Wenn die Entscheidungen Kunden betreffen, lassen wir uns von den Ideen des Lean Startups leiten und experimentieren mit Kundenumfragen, mit Veränderungen auf der Web-Seite, oder indem wir bei unseren Bestandskunden nachfragen, ob sie Interesse haben, sich an einem Experiment zu beteiligen. Bei internen Fragen ist die Kernfrage immer, „Was ist die kleinste, mögliche Veränderung, um das auszuprobieren?“ Oft genug stellen wir dann fest, dass selbst diese „kleine“ Veränderung deutlich mehr Dynamik entfaltet, als wir dachten.

Ein schönes Beispiel dafür ist die Einführung der Peergroups: Zunächst war bei uns der Kreis der Seniorberater (zu dem auch die Geschäftsführer gehören) dafür zuständig, Personalgespräche zu führen und über die Einstufung der einzelnen Mitarbeiter zu entscheiden. Mit zunehmender Größe funktionierte das nicht mehr, weil wir immer weniger Einblick in die tägliche Arbeit der Kollegen hatten. Anstatt den üblichen Weg zu gehen und eine Hierarchieebene einzuziehen, wählten wir einen viel kleineren Schritt – zumindest dachten wir das: Jeder Mitarbeiter kann sich drei Kollegen suchen, mit denen er seine Personalgespräche durchführt, von denen einer ein Seniorberater sein musste. Diese Gruppe würde den Mitarbeiter in seiner persönlichen Entwicklung beraten und der Seniorberaterrunde eine Gehaltsempfehlung machen. Im Prinzip vergrößerten wir also das Gremium des Personalgesprächs „nur“.

Nachdem aber fast jeder Mitarbeiter sich plötzlich in einer Peergroup fand und damit ein Stück Verantwortung für die Kollegen übernehmen musste, wurden Fragen der persönlichen Entwicklung plötzlich von einer hierarchischen Angelegenheit zu einer Teamaufgabe. Viele Kollegen wurden damit zunächst auch aus ihrer Komfortzone herausgerissen, insbesondere bei der Diskussion der Gehaltseinstufung. Interessanterweise entsprachen aber bei der nächsten Gehaltsrunde alle Empfehlung der Peergroups auch den Einschätzungen der Seniorberaterrunde. Man war offensichtlich zu gleichen Ergebnissen gekommen. Bei einer Retrospektive nach einem halben Jahr war die Quintessenz eindeutig: Das Feedback war deutlich wertvoller geworden, die meisten empfanden das neue Vorgehen als wesentlich fairer. Einige Kollegen hatten allerdings auch das Gefühl, dass es schwieriger geworden sei, im Gehaltsgefüge aufzusteigen. Niemand, der schon eine Peergroup hatte, zog allerdings die formal noch immer mögliche Option, wieder zum alten Modell zurück zu kehren.

Mittlerweile sind die Peergroups ein fester Bestandteil der Firmenkultur. Was als Experiment gestartet war, wurde durch Selbstorganisation und emergentes Verhalten zu einem zentralen Element unseres Miteinander. Und einzelne Kollegen experimentieren bereits mit den nächsten Schritten: Zum Beispiel laden sie Kunden mit in ihre Peergroups ein, oder experimentieren mit unterschiedlichen Frequenzen. Damit das nicht in einen unkoordinierten Zoo ausartet, treffen wir uns ein- bis zweimal im Jahr zu einem „Peergrouptag“, zu dem neben einer ganzen Serie von Peergroup-Gesprächen auch die gemeinsame Reflexion und Verbesserung des Konzepts gehört, aber ohne einen Zwang zur Einheitlichkeit. Und anschließend gibt es die „Beergroup“.

Für traditionell gesinnte Manager hört sich das an, wie eine Entmachtung der Geschäftsführung und in der Tat treffen die Mitarbeiter/Gesellschafter bei uns viele Entscheidungen, die üblicherweise im Aufgabenfeld der Geschäftsführung liegen, wie zum Beispiel Personalprozesse. Allerdings empfinden wir das nicht als „Machtverlust“, sondern als wesentliche Qualitätsverbesserung. Je größer die Firma wird, umso mehr geht unsere Aufgabe weg vom operativen Management. Stattdessen kümmern wir uns mehr und mehr darum, die Selbstorganisation sicher zu stellen, die Kommunikationskanäle weit genug offen zu halten, arbeits- und selbstorganisationsfähige Einheiten zu ermöglichen und dafür zu sorgen, dass ausreichend unterschiedliche Positionen die Dynamik erhalten. Eine deutlich spannender Aufgabe, als Urlaubsanträge zu genehmigen (was wir übrigens abgeschafft haben). Natürlich fällt nicht jede Entscheidung so aus, wie ich oder mein Kollege Henning Wolf uns das wünschen, aber oft genug ist die gefundene Lösung zumindest ebenbürtig, wenn nicht sogar besser. Und auch, wenn eine Entscheidung mal nicht so gelungen ist, steht die Mannschaft zumindest dahinter und korrigiert sie, statt sie einfach zu unterlaufen.

Ist ein solcher Grad an Selbstorganisation und Emergenz für alle Unternehmen empfehlenswert? Ich denke, nein. Unser Modell basiert meiner persönlichen Ansicht nach auf einigen Voraussetzungen, die so nicht überall gegeben sind:

  • Ein tolles Team, das Freude daran hat, eine etwas andere Firma zu gestalten
  • Tolle Kunden, die bereit sind, auch mal ungewöhnliche Wege mit uns zu gehen
  • Die Doppelrolle als Mitarbeiter und Gesellschafter, die dazu führt, dass die Gewinne nicht in einem Machtpoker zwischen Mitarbeitern und Eignern verteilt werden, sondern jede(r) auch ökonomische Verantwortung hat
  • Die Tatsache, dass ein großer Teil unserer Kollegen in Moderation, Reflexion und Selbstorganisation geschult ist und sie diese Techniken auch in der täglichen Arbeit immer wieder einsetzen
  • Ein hoher Level gegenseitigen Respekts
  • Eine Marktstrategie, die auf Innovationskraft basiert und die notwendigen Spielräume bietet
  • Der Mut und die Freude zum Experimentieren
  • Eine Firmenkultur, die üblichen Status- und Machtsymbolen wenig bis gar keinen Wert bemisst

Das heißt nicht, dass man nicht auch einen Discounter mit angelernten Kräfte in Selbstorganisation führen kann, nur wird man dafür vermutlich andere Techniken einsetzen müssen.

Reanimation meines Blogs

Fast auf den Tag genau zwei Jahr lang schlief mein Blog einen Dornröschen-Schlaf, jetzt wird es Zeit, ihn wieder wach zu küssen. Danke an alle, die mir dennoch so lange die Treue gehalten haben! Ich werde sicher nicht auf die alte Blog-Frequenz kommen und mich auch stärker auf agile Themen konzentrieren, aber ein bis zwei Einträge pro Monat sollten es schon werden.
Eine zusätzliche Motivation ist der it-agile Blogplanet, in dem (fast) alle Kollegen bloggen, nur ich noch nicht. Das muss ändern! 😉
Viel Spaß beim Lesen.

it-agile und Coldewey Consulting gehen zusammen

Ab sofort werde ich neben Henning Wolf als zweiter Geschäftsführer in die it-agile GmbH einsteigen und die neue Münchner Geschäftstelle von it-agile aufbauen. Ich freue mich darauf, gemeinsam mit einem Team einiger der besten Agilisten Deutschlands ein aufregendes neues Kapitel in der Firmengeschichte von it-agile und in meiner eigenen Laufbahn aufzuschlagen. Und vor allem freue ich mich darauf, mit exzellenten Kollegen und guten Freunden zusammen zu arbeiten.

Wir werden zunächst München als zweiten Beratungsstandort neben Hamburg aufbauen mit Schwerpunkt agiler Beratung für Süddeutschland, Österreich und Schweiz. Später werden wir hier auch agile Entwicklungsleistungen anbieten.

Die Marke Coldewey Consulting stelle ich zu diesem Zeitpunkt ein, dieser Blog und meine Web-Seiten werden aber als private Seiten weiter bestehen bleiben. Unberührt bleibt meine Zusammenarbeit mit dem Cutter Consortium und meine Tätigkeit als Chefredakteur des OBJEKTspektrum.

PS: Natürlich brauchen wir zum Aufbau der Münchner Geschäftsstelle auch erfahrene Agilist(inn)en, die Lust haben, unser Team zu verstärken! Sprechen Sie/Sprich mich an!

Aufspalten einer User Story

Agile Entwicklung funktioniert umso besser, je kleiner die fachlichen Schritte sind, die man nehmen muss. Um Anforderungen klein zu hacken, verwendet man üblicherweise sogenannte „User Stories“, also einen Ablauf aus Anwendersicht, der unterstützt werden soll. Schwierig wird es vor allem für Neu-Agilisten allerdings, wenn es darum geht, diese Stories klein genug zu bekommen. Oft genug stehen am Anfang Stories, die mehrere Wochen brauchen, um fertig umgesetzt zu werden, also inklusive Integration und Test. Ziel ist aber, eine Story innerhalb weniger Tage produktionsreif zu bekommen.

Nachdem es um funktionsfähige Häppchen geht, verbietet sich eine Aufteilung „Mach die Oberfläche für XY“, „Mach die Logik für XY“ von selbst: Diese haben keinen eigenen Geschäftswert und taugen bestenfalls (bzw. schlimmstenfalls) als technische Aufgaben. User Stories sollten aber so gestrickt sein, dass sie unabhängig sind, wertschöpfend, verhandelbar, schätzbar, klein und für sich testbar („INVEST“: Independent, Negotiable, Valuable, Estimable, Small, Testable).

Richard Lawrence fasst nun in seinem Blog-Eintrag „Patterns for Splitting User Stories“ neun Strategien zusammen, die sich für die Aufspaltung von User Stories eignen. Ob es wirklich Patterns sind, darüber lässt sich sicherlich streiten. Dennoch ist der Beitrag auf jeden Fall lesenswert und sein „Crib-Sheet“ am Ende könnte auch für dogmatische Nicht-Internet-Ausdrucker ein Grund sein, mal wieder nach einem Druckertreiber zu suchen.

(Siehe auch mein Eintrag „Schneiden von Stories“ vom 2.12.2008)

Vortrag auf der W-Jax zu langfristiger agiler Planung

Kurzfristig werde ich am kommenden Montag, 9.11.2009 auf dem Agile Day der W-JAX in München von 9:00 Uhr bis 10:00 Uhr einen Vortrag zu langfristiger agiler Planung halten:

Techniken zur agilen Planung führen regelmäßig zu hoher Termin- und Vorhersagetreue. Dies liegt vor allem an einer belastbaren Basis von Erfahrungswerten und statistischen Daten, die sich agile Teams aufbauen. Richtig aufbereitet können diese Informationen weit über den reinen Planungsprozess hinaus eingesetzt werden. Ist die Organisation bereit, ausgetretene Pfade zu verlassen, können aus diesen Informationen belastbare langfristige Prognosen gewonnen werden, die wertvolle Informationen für Vertrieb, Geschäftssteuerung und Kundenmanagement liefern. Dieser Beitrag zeigt Praxisbeispiele für solche Ansätze, deren Nutzen und deren Einschränkungen.

Und natürlich beteilige ich mich am Nachmittag von 14:00 Uhr bis 15:00 an der Pecha Kucha Session von Martin Heider und Bernd Schiffer mit 6 Minuten und 40 Sekunden zu dem Thema „Mein agiler Koffer“ — ein Beitrag, auf den ich mich besonders freue!

Alistair Cockburns Keynote „I come to bury Agile, not to praise it“ als Video

Alistair Cockburns keynote auf der Agile 2009 in Chciago steht als Video kostenlos zur Verfügung: http://www.infoq.com/presentations/cockburn-bury-not-praise-agile. Wer Cockburn noch nicht kennt, kann seinen kritischen und fundamentalen Blick auf Agilität kennenlernen, ebenso wie auch seinen Vortragsstil. Wer ihn kennt, kann sich über seine leicht adaptierte Rede des Marc Antonius aus der Beerdigungsszene von Shakespears „Julius Cäsar“ freuen, aus der er auch den Titel des Vortrags entnommen hat. Diese Rede hält Marc Antonius in dem Schauspiel als Antwort auf Brutus‘ Nachruf am Grabe Cäsars. Für alle, die sich näher dafür interessieren, habe ich unten das Original von Shakespear angehängt, das einiges zum Verständnis von Alistairs Text beiträgt.

Wer Cockburn selbst in relativ kleiner Runde erleben will, hat Ende November dazu in Deutschland Gelegenheit im Rahmen zweier dreitägiger CSM-Kurse. Noch sind Plätze frei.

I come to bury Caesar, not to praise him;
The evil that men do lives after them,
The good is oft interred with their bones,
So let it be with Caesar … The noble Brutus
Hath told you Caesar was ambitious:
If it were so, it was a grievous fault,
And grievously hath Caesar answered it …
Here, under leave of Brutus and the rest,
(For Brutus is an honourable man;
So are they all; all honourable men)
Come I to speak in Caesar’s funeral …
He was my friend, faithful and just to me:
But Brutus says he was ambitious;
And Brutus is an honourable man….
He hath brought many captives home to Rome,
Whose ransoms did the general coffers fill:
Did this in Caesar seem ambitious?
When that the poor have cried, Caesar hath wept:
Ambition should be made of sterner stuff:
Yet Brutus says he was ambitious;
And Brutus is an honourable man.
You all did see that on the Lupercal
I thrice presented him a kingly crown,
Which he did thrice refuse: was this ambition?
Yet Brutus says he was ambitious;
And, sure, he is an honourable man.
I speak not to disprove what Brutus spoke,
But here I am to speak what I do know.
You all did love him once, not without cause:
What cause withholds you then to mourn for him?
O judgement! thou art fled to brutish beasts,
And men have lost their reason…. Bear with me;
My heart is in the coffin there with Caesar,
And I must pause till it come back to me.
William Shakespear

Apple und die Macht einer Vision

Eine beeindruckendes Beispiel für die Kraft einer Vision hat Jared Spool auf der Agile 2009 vorgeführt: Einen Film von Apple unter dem schönen Titel „Knowledge Navigator„. In diesem Film von 1987 zeigt Apple eine Vision von der Anwendung von Computern im Jahr 2010.

Zur Erinnerung: Im Jahr 1987 war der „IBM AT“ Stand der Technik, der immerhin mit einem 80286 und 20-30 MHz ausgestattet war und über MS-DOS bedient wurde. Apple hatte damals schon die Idee der Xerox-Labs aufgegriffen und nach dem Lisa-Flop den ersten Mac auf den Markt gebracht. Und es gab mit dem „Osborne“ auch schon die ersten „tragbaren“ Rechner, die aber eher geeignet waren, die Statik des Schreibtischs zu prüfen, als dass man sie im Zug oder Flugzeug hätte einsetzen können. Das Internet war zu diesem Zeitpunkt ein reines Uni-Netzwerk, das World-Wide-Web noch nicht mal bei Cern erfunden, die E-Mail begann gerade, auch in Deutschland anzukommen und wer „DFÜ“ betreiben wollte, musste sich von Postbeamten versiegelte Modemleitungen in die Wand schrauben lassen, deren Monatsgebühr selbst die Rechnungen vom Finanzamt als erstrebenswerte Mitteilungen erschienen ließen; Übertragungsrate: 56kByte/sec.

In diesem Kontext also entwirft Apple die Vision eines Rechners, der zugleich (Bild-)Telefon ist, wie auch umfassende Wissensquelle zu allen Themen der Welt. Ein Computer, der sich so einfach bedienen lässt, wie ein Buch und ganz normaler Teil des Alltags ist. Und — noch beeindruckender — ein Computer, der frappierende Ähnlichkeiten mit dem iPhone hat! Natürlich haben sich die Apple-Leute in einigen Punkten geirrt: Spracheingabe ist heute nur unwesentlich weiter entwickelt, als vor 23 Jahren und „künstliche Intelligenz“ interessiert heute (fast) nur noch Informatik-Historiker. Dafür übersteigen die Effekte von Web 2.0 und modernen Suchmaschinen offensichtlich auch die gewagtesten Phantasien.

Falls Sie jetzt sagen: „Na ja, Steve Jobbs halt“ ist vielleicht noch das Detail interessant, dass Jobbs zu dieser Zeit nicht bei Apple war, sondern versucht hat, Next aufzubauen. Die Vision entstand unter Leitung von John Sculley

Für mich ist dieses Video der Beleg für die Macht einer kraftvollen Vision: Seit fast einem viertel Jahrhundert arbeitet Apple konsequent daran, diese Vision umzusetzen. Manchmal waren sie ihrer Zeit voraus, wie bei der Lisa oder beim Newton, manchmal haben sie mit der Vision einen scheinbar gesetzten Markt komplett aufgerollt, wie beim iPhone. Eine solche Vision zu finden und konsistent zu verfolgen, sei es für ein Projekt oder auch ein Unternehmen, ist der Kern vieler erstaunlich erfolgreicher Vorhaben. Mittelmäßige Produkte und Projekte mussten in der Regel ohne solche Visionen auskommen und sich statt dessen an kurzfristige Terminpläne und Budgets klammern. Auch Terminpläne und Budgets haben ihre Bedeutung. Wirklich glänzen können sie aber nur, wenn dahinter eine Vision steht — selbst wenn sie nicht so beeidruckend ist, wie die von Apple.

Pair Programming in der New York Times

Auf einen schönen Beitrag in der New York Times zum Thema Pair Programming hat Deborrah Hartmann Preuss aufmerksam gemacht: „For Writing Software, a Buddy System„. Die im Artikel beschriebenen Erfahrungen kann ich nur bestätigen – bis auf die Tatsache, dass es einfach ein paar Kollegen gibt, die für Pair Programming ungeeignet sind (oder sich zumindest dafür halten). Ob man dann auf Pair Programming verzichtet oder für diese Kollegen andere Aufgaben sucht, muss man im Einzelfall entscheiden.

Neue XING-Gruppe zu Lean Software Development

Gemeinsam mit Traian Kaiser, Ralf Wirdemann und Stefan Roock habe wir auf XING ein neues Forum zum Thema „Lean Software Management“ gestartet. Lesen ist frei, wer mitdiskutieren möchte, muss sich bei XING und in der Gruppe anmelden.

Zur Erinngerung: Lean Software Development ist eine „Unterdisziplin“ der agilen Verfahren, die versucht, die Lehren und Erkenntnisse aus Lean Management und Lean Development von der Autoindustrie – und da vor allem von Toyota – auf die Entwicklung von Software zu übertragen. Basis sind vor allem die Arbeiten von Mary und Tom Poppendieck und ihre Bücher Lean Development Software: An Agile Toolkit for Software Development Managers und Implementing Lean Software Development: From Concept to Cash. Das Ergebnis ist erstaunlich ähnlich zu anderen agilen Verfahren wie Scrum etc., konzentriert sich aber deutlich mehr auf Zusammenhänge und weniger auf die genaue Einhaltung von Praktiken.

Eine Kurzfassung findet man in einem zweiteiligen Artikel von Mary Poppendieck und mir: