Archiv der Kategorie: Buchtipp

Human Systems Dynamics: Ein Modell zur Selbstorganisation

Veröffentlicht am von

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

Neue XING-Gruppe zu Lean Software Development

Veröffentlicht am von

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:

Buchtipp: Sam Kaner et.al. „Facilitator’s Guide to Participatory Decision Making“

Veröffentlicht am von

Meine Moderationsausbildung ist jetzt über 15 Jahre her und ich habe seitdem ein paar hundert Workshops, Meetings und Retrospektiven geplant und moderiert; von Routinemeetings bis hin zu emotional und politisch hochbrisanten Konfliktmeetings. Dass ich mir Sam Kaners Buch bestellt habe, lag eher daran, dass Diana Larsen ihn empfohlen hatte: Da musste ja was dran sein. Und es ist etwas dran, sogar sehr viel! Es ist tatsächlich das beste Buch zur Moderation, das ich bisher in der Hand hatte.

Kaner führt in einem sehr kurzen Theorieteil ein in die Gruppendynamik von gemeinsamen Entscheidungsprozessen, stellt dann alle möglichen Werkzeuge und Techniken für die Moderation vor, die jeweils mit Anwendungsbereich, Durchführung und Konsequenzen beschrieben werden, gibt Hinweise, wie man nachhaltige Übereinstimmung herstellt und stellt schließlich Techniken vor, um verbindliche Abschlüsse zu erreichen. Etwa 70-80% der Techniken waren mir bekannt, die anderen sind interessante Variationen, von denen ich sicher das eine oder andere in mein Portfolio aufnehmen werde. Anders formuliert, inhaltlich leistet das Buch das, was geleistet werden muss.

Begeistert hat mich aber die Präsentation: Jede Seite kann für sich stehen, man kann das Buch ebenso als Nachschlagewerk verwenden, wie zum Durchlesen. Jedes Kapitel gibt eine ein- bis zweiseitige Einführung in die Theorie des Themas, dann kommen Praktiken. So enthält alleine das Kapitel „Alternatives to Open Discussion“ zwölf Varianten für Meetingformate:

  • Small Groups
  • Jigsaw
  • Multi-Tasking
  • Fishbowls
  • Scrambler
  • Roleplays
  • Tradeshows
  • Open Discussion
  • Individual Writing
  • Listing Ideas
  • Presentations and Reports
  • Structured Go-Arounds

Jedes einzelne Format wird mit Empfehlungen über den Einsatzbereich, genauen Anweisungen zur Durchführung und Variationen beschrieben, in der Regel inklusive der Auswirkungen auf die Gruppendynamik. Da gibt es sowohl für Neueinsteiger als auch für alte Hasen einiges zum Lesen und Nachschlagen. Er spart auch „heiße“ Themen wie den Umgang mit „diverse communication behaviour“ nicht aus.

Einziger Wermutstropfen, den ich bisher gefunden habe: Zu den Übungen sind praktisch keine Zeitangaben enthalten. Wenn man ein wenig Erfahrung hat, lässt sich das sicher verschmerzen, aber ich empfinde nach wie vor die Zeitangaben in Esther Derbys und Diana Larsens „Agile Retrospectives“ als sehr hilfreich bei der Vorbereitung. Zur Ehrenrettung muss man allerdings auch erwähnen, dass Kaner natürlich viel breiter ansetzt und auf jede Form des Workshops anwendbar ist. Das macht Zeitangaben schwierig.

Kurz und gut: Eines der besten Bücher, die ich die letzten Jahre in die Finger bekommen habe und das sicherlich noch viele Stunden auf meinem Schreibtisch vor sich haben wird, auf einem Ehrenplatz neben dem Buch von Esther Derby und Diana Larsen.


Sam Kaner with Lenny Lind, Catherine Toldi, Sarah Fisk, and Duane Berger: „Facilitator’s Guide to Participatory Decision Making“, 2nd edition, Jonny-Bass/Wiley, 2007, ISBN 978-0-7879-8266-9, 341 Seiten

Crystal Methodenfamilie in einer Minute

Veröffentlicht am von

Ich wurde kürzlich von Peter Stevens auf der Deutschen Scrum Liste gefragt, wo man Crystal in zehn Minuten nachlesen könne. Ich denke, meine Antwort ist auch für Nicht-Scrummer interessant, deshalb hier noch mal in „voller Schönheit“ mit ein paar zusätzlichen Links.

Gibt es irgendwo ein „Crystal in 10 Minuten“? – Ein google dafür hat nichts nützliches produziert…

Starte vielleicht mal mit http://alistair.cockburn.us/Crystal+light+methods, das dürfte ca. 10 Minuten dauern.

> Oder was ist besonders an Crystal?

Der Kern in drei Sätzen:

  1. Arbeite in kurzen Iterationen
  2. Mache regelmäßig Retrospektiven
  3. Kommuniziere eng

Das ist sozusagen erstmal die Essenz agilen Arbeitens.

Basis sind Alistair Cockburns Überlegungen zur Software Entwicklung als kooperativem Spiel, sowie seine „Feldforschungen“ seit den frühen Neunziger Jahren.

Um das zu unterstützen bietet Crystal sehr viele Praktiken, die sich je nach Kontext einsetzen lassen. Allerdings nicht wie Scrum oder XP (1.0) mit dem Hinweis „So muss man es machen“, sondern mit einem „in dieser Situation haben Teams gute Erfahrung gemacht, jenes zu machen mit folgenden Konsequenzen“. Meines Wissens lassen sich sowohl alle Scrum Praktiken als auch alle XP Praktiken mit Crystal abdecken.

Crystal ist damit viel näher an einer Patternsammlung, als an einem Prozess. Deshalb redet Alistair auch von einer „Methodenfamilie“, bei denen die Methoden nach Kritikalität und Teamgröße zusammen gesetzt werden mit dem Ziel, die „Gerade noch ausreichende Methode“ zu finden. „Crystal Clear“ ist zum Beispiel für Teams bis zu 10 Personen in Projekten, bei denen es nicht um Menschenleben geht. Er deklariert Crystal auch ganz klar als Hilfe für Fortgeschrittene und nicht als Anfängermethode (siehe dazu auch http://alistair.cockburn.us/Shu+Ha+Ri). Sein Ziel ist also nicht unbedingt Minimalismus in der Beschreibung, wie es von Scrum und XP verfolgt wird, sondern Minimalismus im Einsatz.

Crystal bildet damit die Brücke zwischen den agilen „Meta-Methoden“ wie ASD (Jim Highsmith) und Lean Software Development (Mary und Tom Poppendieck) und den eher prozessartig gestalteten Verfahren wie XP und Scrum. Es ist ein Baukasten aus Praktiken mit Regeln, wie sie zusammen gesetzt werden.

Neben Alistair Cockburns Webseite gibt es zwei Bücher von ihm zu dem Thema:

Das Zertifizierungsverfahren ist noch lange nicht so ausgefeilt, wie bei Scrum, es gibt aber immerhin eine handvoll „Certified Crystal Practitioners“, die zu der Ehre gekommen sind, weil Alistair ihre Arbeit gesehen und für gut befunden hat.

Cutter IT Journal „Exploring the Agile Frontier“ derzeit kostenlos erhältlich

Veröffentlicht am von

Das von mir 2007 herausgegebene Heft des Cutter IT Journal mit dem Titel „Exploring the Agile Frontier“ ist derzeit im Zuge einer Marketinginitiative von Cutter kostenlos erhältlich, statt des üblichen Preises von ca. $40.00. Das Heft sammelt Analysen und Projektberichte aus Bereichen, die üblicherweise als „wenig geeignet“ für agile Verfahren gelten. Es enthält unter anderem:

  • Einen Projektbericht über agiles Arbeiten in weltweit verteilten Teams bei Schlumberger von Lise Hvatum
  • Einen Beitrag über agile Entwicklung bei großen und verteilten Teams von Jutta Eckstein
  • Einen Projektbericht über die agile Entwicklung von Beatmungsgeräten von Klaus Marquardt der nach meinen Informationen nirgendwo anders veröffentlicht ist
  • Einen Projektbericht über agiles Arbeiten bei einer „Wasserfall-Behörde“ von Matt Ganis und Tom Hawkins

Sie finden das Heft, auf der Cutter Homepage unter „Sample Our Research“ oder direkt hier.

Teamdynamik und Psychologie

Veröffentlicht am von

Auf den XPDays in Hamburg stellte die Pychologin Maud Winkler das Tuckman-Modell der Teamentwicklung vor (genau genommen, das erweiterte Tuckman-Modell von Eberhard Stahl, das dieser in seinem Buch „Dynamik in Gruppen“ vorstellt):

  • Forming
  • Storming
  • Norming
  • Performing
  • Reforming

Die vierte Phase ist die produktivste Phase (wobei man hier vorsichtig sein muss, diese Phase nicht als konfliktfrei zu verstehen, nur werden hier Konflikte produktiv genutzt). Das Durchleben der anderen Phasen ist jedoch notwendige Voraussetzung dafür, dass das Team bei Performing gut arbeitet. Nicht erledigte Aufgaben aus den vorigen Phasen bleiben als Störfaktoren liegen und behindern das Team in der Arbeit. Um das Modell halbwegs realistisch zu gestalten, hat Eberhard Stahl das ursprüngliche Modell um eine iterative Komponente erweitert, die von Frau Winkler sehr betont wurde.

Dieses Modell erlaubt einen interessanten Blick auf agil geführte Teams. In diesen Teams werden regelmäßig Retrospektiven abgehalten, in denen sich das Team in eine Reflexionsphase begibt. Im Sinne des erweiterten Tuckman-Modells wird das Team also in regelmäßigen Abständen wieder in die Reformingphase „gestürzt“, die im Rahmen der Retrospektive bis zum Norming geführt wird. So werden sachliche und zwischenmenschliche Probleme auf einen klaren Zeitpunkt konzentriert, statt ständig im Untergrund zu rumoren.

Das bedeutet aber auch besondere Anforderungen an die Kompetenz des Moderators einer Retrospektive: Wer hier die Teamsituation falsch einschätzt oder angezeigte Interventionen unterlässt oder überspitzt, bewirkt bestenfalls, dass die „unproduktiven“ Phasen während der Retrospektive nicht abgeschlossen werden und das Team weiter behindern. Schlimmstenfalls wird das Team gesprengt. Hier hilft ein erfahrener externer Moderator, der auch über den dafür notwendigen psychologischen Werkzeugkasten verfügt.

(Um einer Kritik an dem Modell zuvorzukommen, die Joseph Pelrine auf der Konferenz geäußert hat: Das Modell versucht weder einen Prozess zu beschreiben, noch erhebt es den Anspruch auf einzige Wahrheit. Es dient lediglich dazu, Anhaltspunkte für geeignete Intervention eines Leiters oder Moderators zu geben. Es ist also kein „RUP der Teamdynamik“, sondern eben „nur“ ein psychologisches Modell, das ähnlich wie die einschlägigen Kommunikationsmodelle in bestimmten Situationen helfen kann, die aktuelle Situation zu verstehen. Zudem scheint mir das erweiterte Tuckman Modell wesentlich realistischer, als das recht lineare Original, auf das sich Joseph bezog).

Ist Agile Entwicklung billiger II

Veröffentlicht am von

Felix Rüssel schreibt in seinem „Armer Kater“ Blog zu meinem Artikel „Ist Agile Entwicklung billiger?“:

Jens schreibt jedoch auch, dass Kundenzufriedenheit das Primärziel bei jedem Projekt sein sollte. Dem kann ich nicht zustimmen, da dies eine verkürzte Sicht darstellt, v.a. wenn es sich um Unternehmen handelt, die mit Projekten Geld verdienen müssen.

Primärziel einer Unternehmung ist es weiter zu existieren und dabei möglichst Gewinn zu erwirtschaften.

Die Kundenzufriedenheit ist in den meisten Fällen ein wichtiger Faktor, um diese Ziele in einem umkämpften Markt zu erreichen – nicht jedoch das Primärziel!

Um diesen Widerspruch aufzulösen, könnte es helfen, drei Ebenen zu differenzieren:

  • Das Ziel eines (Wirtschafts-)Unternehmens ist es natürlich, am Markt zu bleiben und möglichst auch noch Gewinn abzuwerfen (in dieser Reihenfolge! Wozu die umgekehrte Priorisierung führt, erleben wir gerade recht schmerzhaft). Es gibt natürlich auch noch Organisationen, die andere Ziele verfolgen, z.B. öffentlicher Dienst, gemeinnützige Organisationen, Parteien, usw.
  • Der Existenzgrund einer Organisation muss aber deutlich spezifischer sein — ein Apsekt, den viele Unternehmensberater und Anleger und leider auch manche Manager gerne übersehen. Der Existenzgrund eines Unternehmens ist das, was in den USA gerne in möglichst blumige „Mission Statements“ gepackt wird. Wenn das nicht nur hohle Phrasen sind („Wir wollen unseren Kunden den besten Service liefern zwischen hier und und dem Neptun…“), drückt sich in ihm die Klammer über die langfrsitigen Strategien aus. Gute Existenzgründe beziehen das Zusammenspiel zwischen Kunden und Unternehmen mit ein. Schöne Beispiele für Existenzgründe sind „Wir wollen unsere Kunden mit Lebensmitteln versorgen, die so billig sind, wie möglich“ oder „Wir wollen eine Lebensmittelversorgung sicher stellen, die unserer Verantwortung gegenüber Kunden, Produzenten und Lieferanten gerecht wird.“ Wie man leicht sieht, sind das zwei völlig unterschiedliche, gegensätzliche Geschäftskonzepte, aus denen sich trotz Gewinnabsicht auf beiden Seiten völlig unterschiedliche Unternehmen und Kundenkreise ergeben.
  • Das Projektziel, über das ich geschrieben habe, bezieht sich auf ein konkretes Vorhaben. Der Kunde kann hier ein Vertragspartner sein, wie bei Softwarehäusern, oder eine andere Abteilung, wie bei interner Entwicklung (auch beides gleichzeitig ist möglich, wenn auch oft nicht so wahnsinnig zielführend). Man kann jetzt den Projekterfolg sehr unterschiedlich sehen: „Umfang, Budget, Termin und Qualität erreicht“ ist die traditionelle Definition, „Kunde mit dem Ergebnis hochzufrieden“ ist die agile Definition. Dass die traditionelle Definition besser zu Werkverträgen passt und daher ungeachtet der Probleme mit ihr populär ist, ist schon häufig diskutiert worden.

Der von Felix angesprochene vermeintliche Widerspruch kommt als daher, dass wir über völlig unterschiedliche Ebenen gesprochen haben. Allerdings sind diese Ebenen natürlich gekoppelt. Wenn ich ausschließlich auf kurzfristige Gewinnmaximierung ziele, werde ich versuchen, aus einem Projekt so viel Geld herauszuschlagen, wie möglich, zum Beispiel indem ich es immer weiter aufblase, bis ich 200 billige „Juniorberater“ möglichst mit Tagessätzen erfahrener Leute beim Kunden im Einsatz habe. Für solche Organisationen ist Kundenzufriedenheit in der Tat sekundär, sie akquirieren dann oft eher über Beziehungen (sog. Alumni-Netzwerke, was nicht bedeutet, dass jede Firma, die ein solches Netzwerk betreibt, in diese Kategorie gehört!). Unternehmen, die langfristige Kundenbeziehungen aufbauen, werden allerdings den Kundenutzen sehr hoch priorisieren. „Mir ist relativ egal, ob wir in diesem Projekt rote oder grüne Zahlen schreiben, wenn wir hier erfolgreich sind, stehen wir im gesamten Marktsegment sehr gut da“ ist eine häufige Aussage von Managern, die so denken. Ich glaube, die zweite Sorte von Organisationen wird eher einen Vorteil aus agilen Verfahren ziehen.

Einer anderen Aussagen von Felix möchte ich aber ganz klar widersprechen:

Für die Erreichung der Primärziele Existenzsicherung/Rentabilität sind die Kosten der entscheidende Faktor

Das ist eine zwar sehr moderne aber dennoch fatale Einengung des unternehmerischen Handlungsspielraums. Eine rigide Kostenkontrolle ist dann sinnvoll und notwendig, wenn ich eine Kostenstrategie fahre. Wer eine Differenzierungsstrategie fährt, oder eine Nischenstrategie, kann oft mit seinen internen Kosten deutlich entspannter umgehen (siehe dazu Buchtipp unten). Gerade wegen der von Felix angesprochenen Probleme, Motivätion und Qualität in die Kostenrechnung zu integrieren, ist es bei solchen Unternehmen oftmals kontraproduktiv, zu sehr auf der Kostenbremse zu stehen. Tom DeMarco diskutiert das ausführlich in seinem „Peopleware“ und leitet die Diskussion ein mit einem Memo, das der Vizepräsident von Xerox einst an seine Mitarbeiter verschickte: „It has come to my attention, that some of you, when traveling on expenses, have been traveling economy class. This is a first-class organisation. When you fly on business from now on, you fly first class.“ (s. 153) Gut das war in den frühen Siebzigern. Andererseits war genau das die Zeit, in der Xerox die besten Beiträge zur Software geleistet hat (Smalltalk, Maus, Fensteroberfläche,…).

Ist das Zufall? Ich denke, es hat etwas mit Attitüde zu tun. Wer sich nur auf die Kosten konzentriert, bringt damit ein klares Wertesystem zum Ausdruck. Wer, wie der Chef bei Xerox, klar macht, dass ihm die Arbeitsbedingungen der Mitarbeiter so wichtig sind, dass er bereit ist, dafür Geld auszugeben, ebenfalls. Zur Kostenführerschaft passt das erste Wertesystem, zu den anderen Strategien eher das zweite. Leider sind viele erstklassige Unternehmen von ihrem Management in die Mittelmäßigkeit gedrängt worden, indem sie diesen Unterschied nicht beherzigt haben.

Auf die Gefahr hin, mit Standardlektüre zu langweilen, noch schnell die zwei Quellenangaben dazu:

Scrum Gathering in München

Veröffentlicht am von

Heute war Scrum Gathering in München, des mitterweile jährliche Treffen der Scrum-Anhänger in Deutschland. Ich bin zwar selbst kein Scrum Enthusiast (auch wenn ich gerne die ein oder eine Scrum-Praktik verwende), dennoch wollte ich die Gelegenheit nicht verpassen. Das Treffen war als Open Space organisiert und ich möchte ein paar für mich interessante Themen und Eindrücke wiedergeben.

Was mir gut gefallen hat: Ein guter Teil der Sessions beschäftigte sich weniger mit Scrumpraktiken, sondern mit allgemeiner Teambildungs- und Coachingtechnik. Besonders Hans-Peter Korn hat sich mächtig ins Zeug gelegt, um lösungsbasierte Coachingansätze zu demonstrieren und vor vereinfachenden Modellen zu warnen: Teams und Projekte sind nicht kompliziert (und damit anlysierbar und steuerbar), sondern komplex (und damit weder analysierbar noch steuerbar). Sein Plädoyer: Ihr könnt komplexe Systeme beobachten, Ihr könnt versuchen, sie zu beeinflussen. Aber wenn man anfängt, Modelle einzusetzen, um sie zu analysieren, dann läuft man Gefahr, dass man nur noch das sieht, was ins Modell passt — und Wichtiges übersieht oder falsch interpretiert. Das erinnerte mich doch stark an meinen alten Artikel von 2002: „Manchmal ist mehr drin, als man glaubt – Agile Entwicklung und Emergenz“ und mein Lieblingsbuch zu dem Thema: „Emergence“ von John Holland, das sich mit komplexen Systemen beschäftigt, als Systemen, die Verhalten zeigen, das sich nicht durch Analyse erklären lässt (was nichts mit komplizierten Systemen zu tun hat: Das gute alte Life-Spiel ist ein aus drei primitiven Regeln aufgebauter zellulärer Automat, dessen komplexes Verhalten sich nicht aus den Regeln ableiten lässt!).

Bernd Schiffer stellte in einem ganz interessanten Vortrag das Tuckman Modell zur Gruppenbildung vor (Forming, Storming, Norming, Performing, Re-Performing) und diskutierte dies im Rahmen agiler Teams. Lesenswert, die Folien finden sich hier (Bernds Buchtipp: Eberhard Stahl, „Dynamik in Gruppen: Handbuch der Gruppenleitung“).

Ein Workshop zum Thema Schätzen hat bei mir den Eindruck hinterlassen, dass doch noch deutlich mehr Unsicherheit bei agiler Planung besteht, als ich dachte. Das bedeutet für mich, agiles Schätzen und Planen als nächstes in meiner „Praktiken-Serie“ anzusprechen.

Leider verpasst habe ich einen gemeinsamen Vortrag von Simon Roberts und Christian Schmidkonz, die über die Scrum-Einführung bei der Allianz bzw. SAP berichtet haben – zwei sehr spannende Vorhaben derzeit in Deutschland, die beide schon erfreulich weit gediehen sind.

Nicht ausräumen konnte ich meinen Eindruck, dass manche führenden Köpfe der Scrum Community eher Abstand zu der restlichen agilen Gemeinschaft suchen. Wir alle müssen daran arbeiten, dass hier kein Konkurrenz- oder gar Verdrängungswettbewerb gestartet wird, der nicht nur eine Menge Potenzial vergibt, sondern letztlich beide Seiten sogar schwächt, sondern dass die sehr guten Beiträge beider Seiten gewürdigt und dem gemeinsamen Ziel unterstellt werden: Softwareentwicklung besser, sicherer, wirtschaftlicher und vor allem menschlicher zu gestalten. Als kleiner Lichtblick: Einige der führenden Scrum-Leute sehen durchaus den Bedarf, gemeinsam zu agieren, so dass ich auf einen konstruktiven Dialog unter den Pragmatikern hoffe – und auf Ideen, die vor allem der gemeinsamen Sache helfen. Ich werde dazu beitragen, was ich beitragen kann.

Weitere Berichte zum Scrum Gathering:

Und dann gibt es noch die offizielle Web-Seite: http://scrumaufdeutsch.pbwiki.com/

Cutter Report „Fostering Innovation on the Agile Frontier“

Veröffentlicht am von

Im letzten Jahr habe ich die Ausgaben Mai und Oktober des Cutter IT Journal als Gasteditor herausgegeben. Die Maiausgabe beschäftigte sich unter dem Titel „Exploring the Agile Frontier“ mit dem Einsatz agiler Verfahren außerhalb der „Standardprojekte“, also mit verteilten Teams, bei lebenserhaltenden Systemen und in nicht-agilen Organisationen.

Die Oktoberausgabe hatte den Titel „Fostering Innovation: What Role Does Agile Software Development Play?„. Sie enthielt fünf Beiträge zum Zusammenhang zwischen Innovation und Agilität. Die Thesen verliefen von „Agilität behindert Innovation“ bis zu „Agilität ist die Geburtshelferin der Innovation“.

Aufgrund der großen Nachfrage hat Cutter nun beide Ausgaben zu dem Report „Fostering Innovation on the Agile Frontier“ zusammengefasst.

Praktiken II: Automatisierte Akzeptanztests

Veröffentlicht am von

Nach längerer Zeit nun der zweite Teil meiner Serie über agile Prakitken. Bisher finden Sie in dieser Kategorie die folgenden Einträge:

Der zweite Teil beschäftigt sich mit automatisierten Akzeptanztests:

Auch agile Entwicklung startet mit den fachlichen Anforderungen. Allerdings werden sie direkt als Akzeptanztests aufgeschrieben, statt in Anforderungsdokumenten. Akzeptanztests sind fachliche Beschreibungen dessen, was das System können soll und zwar so, dass sie automatisch ausgeführt werden können. Automatisch ausführbare Tests steuern die Anwendung und überprüfen deren Ergebnisse ohne menschlichen Eingriff. Der Weg zu diesen Akzeptanztests ist noch eher uneinheitlich, man geht aber in der Regel von den geplanten geschäftlichen Abläufen aus (siehe dazu auch „Use Cases oder User Stories„).

Weiterlesen →