Teil 2: Mannschaftsspiel im Profifußball als passende Metapher für agile Softwareentwicklung

Architektur versus Agile: Mannschaftsspiel als Modell für Softwareentwicklung
Keine Kommentare

Ist die Architektur-Metapher für ein Verständnis von Softwareentwicklung noch hilfreich? In Teil 2 des Artikels erarbeiten wir ein Modell, das besser auf die Anforderungen agiler Softwareentwicklung angepasst ist als die Metapher der Architektur: Mannschaftsspiel im Profifußball

Nachdem wir im ersten Teil des Artikels die Bau- bzw. Architekturmetapher unter die Lupe genommen und die Limitierungen identifiziert haben, die diese Metapher im Bereich der agilen Softwareentwicklung darstellt, entwickeln wir in der Folge ein Modell, das besser auf unsere Anforderungen passt: Mannschaftsspiel im Profifußball.

Mannschaftsspiel als Modell für Softwareentwicklung

Wie wir in Teil 1 hergeleitet haben, braucht es ein Modell, das beschreibt, wie ein unscharf definiertes Ziel unter laufend und scheinbar weitgehend zufällig wechselnden Bedingungen erreicht werden kann. In solchen Umgebungen haben sich Gruppen von relativ autonom aber gleichzeitig koordiniert agierenden Akteuren als überlegen effektiv erwiesen (Kasten: „Autonom und koordiniert gegen Komplexität“). Mannschaftsspiele sind eine ritualisiert vereinfachte Form dieses Vorgehens und daher prinzipiell als Modell geeignet. Als gut bekanntes Beispiel soll im Folgenden Fußball dienen, und, da es um professionelle Softwareentwicklung geht, speziell der Profifußball.

Autonom und koordiniert gegen Komplexität
Gruppen von autonom aber koordiniert agierenden Akteuren haben sich als überlegene Strategie erwiesen, wenn es darum geht, in komplexen und volatilen Situationen zu bestehen und eigene Ziele zu erreichen. Das zeigte sich zum Beispiel 1806, als die in starren Reihen aufmarschierenden preußischen Truppen von den selbstständiger handelnden und das Gelände zur Deckung ausnutzenden napoleonischen Soldaten vernichtend geschlagen wurden. Auch das so genannte Shop-in-Shop-Konzept, das dabei ist, den traditionellen Kaufhäusern den Rang abzulaufen, oder Franchising sind Anwendungen dieser Strategie.

Die Aufgabe, in einem Spiel oder einer Serie erfolgreich zu sein, ist genau betrachtet auch nicht präziser beschrieben als die Vorgabe, einen bestimmten Kundennutzen oder eine verbesserte Stellung im Markt zu realisieren. Die Aktionen des Gegners sind die wechselnden Rahmenbedingungen und Störungen des eigenen Vorgehens. Wer hat nicht schon mal bei einer Anwendung den Eindruck gehabt, dass es sich nicht um ein seelenloses Programm, sondern einen bösartigen Gegner handelt, der einem bewusst das Leben schwer machen will? So modelliert gehören auch Änderungen der Wünsche des Kunden zu den gegnerischen Aktionen, weil sie Anpassungen erfordern und somit einem schnellen Erfolg hinderlich sind. Um keine Missverständnisse aufkommen zu lassen: Der Begriff „Gegner“ bezieht sich hier lediglich auf die Modellierung und steht in keinerlei Beziehung zur Sicht auf den Kunden oder Auftraggeber des Projekts.

Die Akteure, also die Spieler, stehen für einzelne Entwickler, Entwicklergruppen, Abteilungen oder ganze Unternehmen – je nach Betrachtungsebene. Um erfolgreich zu sein, müssen die Spieler genau mit dem fertigwerden, was im vorigen Abschnitt als kennzeichnend für die Softwareentwicklung zusammengestellt wurde. Das heißt, sie müssen mehr oder weniger autonom im Sinne des gemeinsamen Ziels agieren, ohne ständig alle Informationen über den aktuellen Gesamtzustand zu kennen und ohne die Konsequenzen ihres Handelns immer zuverlässig bewerten zu können.

Neben den Spielern gibt es selbstverständlich auch noch Trainer mit ihren Assistenten, Manager und Sponsoren. Die Projektion der letzten beiden Rollen auf das diskutierte Modell ist trivial und wird deshalb nicht tiefer betrachtet. Mit dem Trainer beschäftigt sich ein eigener Abschnitt.

DevOps Docker Camp

Sie lernen die Konzepte von Docker und bauen Schritt für Schritt eine eigene Infrastruktur für und mit Docker auf.

Grenzen des Modells

Wie jedes Modell vereinfacht auch dieses die Realität. Gerade dadurch kann es dabei helfen, Zusammenhänge klarer zu sehen, die sonst unter der Vielzahl von Details verborgen bleiben. Die wichtigste Vereinfachung hier ist das Vernachlässigen zeitlicher Aspekte. Bei einem Spiel ist die Dauer vorgegeben, die Kosten sind unabhängig davon, wie lange es bis zum Erfolg dauert. Außerdem ist die Zeitskala eine andere, sodass Dinge, die üblicherweise zwischen den Spielen erledigt werden, bei der Softwareentwicklung parallel erfolgen müssen. Schließlich ist nicht zu übersehen, dass das Aufwandsverhältnis zwischen Vorbereitung und Spiel ein ganz anderes ist.

Ein anderes bei Anwendungen der Spieltheorie häufig gehörtes Gegenargument ist, dass sich die Verhältnisse gewöhnlich nicht so zielgerichtet zum eigenen Nachteil ändern, wie das durch einen Gegner im Spiel passiert. Dieser Argumentation liegt ein unvollständiges Verständnis der Modellierung zugrunde, denn genau das lässt sich durch Betrachtung unterschiedlich starker Gegner simulieren.

Schwieriger ist der Umgang mit der Tatsache, dass die Regeln und Grenzen des Spiels bei der Abbildung realer Vorgänge nicht sicher bestimmt werden können. Das ist für die folgenden Überlegungen aber nicht relevant, weil es hier nur um Wege geht, komplexen und volatilen Herausforderungen zu begegnen. Schließlich muss man der Versuchung widerstehen, das Modell zu überinterpretieren und jedes Detail abbilden zu wollen. So etwas mag eine interessante Denksportaufgabe sein, lenkt aber von den eigentlichen Zielen und dem Wesen der Modellierung ab.

Unterschiede: Fußballmodell vs Architekturmodell

Der wichtigste Unterschied des Fußballmodells zu dem am Bauen orientierten Entwicklungsmodell ist die größere Eigenständigkeit der Akteure. Es gibt keine vordefinierten Aufgaben, bei deren Umsetzung es nur noch auf das handwerkliche Geschick ankommt. Was wo gemacht wird, bestimmt jeder Akteur weitgehend selbst, unter Berücksichtigung der konkreten Situation und im Zusammenspiel mit seinen Mannschaftskollegen. Damit das funktioniert, müssen einige Vorbedingungen erfüllt sein:

  • Jeder Akteur muss über ausreichende technische Fertigkeiten (für mehr als eine einfache Aufgabe) verfügen.
  • Jeder Akteur muss sich ständig ausreichend über die Gesamtsituation informieren können.
  • Es gibt eine gemeinsame Idee, wie das Ziel erreicht werden soll.
  • Die Akteure müssen sich verständigen und ihre Aktionen koordinieren können.
  • Dazu ist u. a. eine gewisse Kenntnis der jeweiligen Stärken und Schwächen erforderlich.
  • Eine in der Regel unvollständige Vorstellung über mögliche Strategien und Taktiken des Gegners muss vorhanden sein.
  • Es gibt einen Satz von Rahmenbedingungen, deren Veränderungen sehr unwahrscheinlich ist (= Regeln).

Die Überschneidungen dieser Voraussetzungen mit den Regeln für agile Teams sind offensichtlich. Damit wird auch klar, dass es darum geht, die in der agilen Methode bereits angelegten Ideen weiterzuführen. Ganz nebenbei erhält man noch ein schönes Bild, um der abwertenden Gleichsetzung von fehlender Organisation („Jeder macht, was er will.“) und Agilität entgegenzutreten.

Wo ist der Trainer in der Softwareentwicklung?

Auf professioneller Ebene ist in allen Mannschaftssportarten der Trainer mit seinen Assistenten für den Erfolg fast genauso wichtig, wie die Mannschaft selbst. Das war nicht immer so, und manche Hobbymannschaft bringt es auch ohne Trainer zu einigen Erfolgen. Unbestritten ist jedoch, dass ein hohes Niveau ohne Anleitung nicht erreichbar ist. Die bisherigen Überlegungen führen zu der – zunächst provokant klingenden – These: Die agile Softwareentwicklung ist weitgehend noch auf dem Niveau nicht professionellen Spielens. Im verbleibenden Teil dieses Beitrags werden dafür Belege geliefert.

Eine dem Trainer entsprechende Rolle gibt es in der Softwareentwicklung nicht. Einige Aufgaben werden wie oben gezeigt den Softwarearchitekten zugeordnet. Andere sollen durch Selbstorganisation gelöst werden. Aber Selbstorganisation benötigt Zeit und skaliert nicht gut (Kasten: „Selbstorganisation und Skalierung“). Bisweilen müssen Festlegungen einfach schnell erfolgen. Ein erheblicher Teil der Entscheidungen, die durch den Trainer zu treffen wären, wird daher oft zufällig oder zumindest nicht direkt am Projektziel orientiert getroffen.

Selbstorganisation und Skalierung
Selbstorganisation skaliert nicht. Das ist einer der Gründe, warum beispielsweise Scrum nicht ohne Probleme auf große Projekte übertragbar ist. Auch andere Beispiele wie Wikipedia oder die Piratenpartei zeigen, dass ab einer gewissen Größe die basisdemokratischen Verfahren inadäquat sind. Das ist keine ideologische Verblendung, sondern der einfachen Tatsache geschuldet, dass die Anzahl der möglichen Kommunikationsverbindungen mit der Anzahl der Partner quadratisch zunimmt. Dieser überproportionale Anstieg führt zwangsläufig dazu, dass – ohne geeignete Gegenmaßnahmen – für die eigentliche Aufgabe nicht mehr genügend Ressourcen verfügbar sind: „Große Systeme können sich selbst beschäftigen.“

Die Aufgabe des Trainers ist es zunächst, aus einer Gruppe eine Mannschaft zu machen und danach diese Mannschaft zu immer höheren Leistungen zu führen. Das ist eine anspruchsvolle Tätigkeit, die neben den fachlichen auch soziale und organisatorische Kompetenzen verlangt. Nicht ohne Grund gibt es dafür spezielle Ausbildungen. Alle diese Aufgaben stehen ebenfalls an, wenn eine neue Software durch mehrere Personen oder Teams entwickelt werden soll:

  • Es bedarf einer Grundstrategie (Spielsystem) zur Lösung der Aufgabe.
  • Idealerweise werden der Strategie entsprechende Teams ausgewählt oder zusammengestellt (Aufstellung).
  • Die Strategie muss den Teams vermittelt und taktische Varianten der Umsetzung geübt werden (Training).
  • Für die unmittelbar bevorstehenden Aufgaben sind strategische Vorgaben abzustimmen und festzulegen (Mannschaftsbesprechung).
  • Ständige Überprüfung und erforderlichenfalls Veränderung der Strategie oder des Spielsystems (Auswechslung, taktische Hinweise).

Schon bei dieser kurzen Interpretation wird deutlich, dass das vorbereitende Training in der Softwareentwicklung häufig zu kurz kommt. Die Auswahl des Spielsystems übernimmt meist der Softwarearchitekt, um die Teams kümmert sich das Management, und das Training besteht eventuell aus der ein- oder anderen Schulung und einem Kickoff. Viele Probleme in Projekten gehen auf Defizite zurück, die durch entsprechendes Training zu vermeiden gewesen wären: unzureichendes Verständnis der Gesamtstrategie, fehlende Abstimmung zwischen Teilprojekten, unterschiedliche Entwicklungsmethoden usw.

Effektives Training braucht allerdings Anleitung und Zeit und verursacht entsprechende Kosten. Selbst wenn sich ein Architekt oder Projektleiter dazu aufschwingt und versucht, die Rolle des Trainers zu übernehmen, werden die unverzichtbaren Rechte vom Management selten zugestanden und damit mögliche Erfolge verhindert. Durch den Verzicht, zielgerichtet Mannschaften zu entwickeln, wird erhebliches Potenzial verschenkt.

Mit einer guten Vorbereitung allein ist es jedoch nicht getan. Das Training muss die ganze Saison über (d. h. während der gesamten Projektlaufzeit) weitergeführt werden. Die Ziele sind dabei u. a. die Einstellung der Mannschaft auf unerwartetes Vorgehen des Gegners, das Einüben von Spielzügen, das Beheben einzelner Schwächen, die Vorbereitung taktischer Varianten, die Einbeziehung neuer Spieler oder die Verbesserung des Zusammenspiels.

Als Kaizen hat das Prinzip der ständigen Verbesserung in das Software-Engineering bereits Einzug gehalten. Es wird aber vorrangig als etwas gesehen, das von unten bzw. von innen ausgeht – eine spezielle Form der Selbstorganisation. Das ist ohne Zweifel wichtig und richtig, kann jedoch nicht eine von außen kommende Analyse und Anleitung ersetzen. Beides muss sich ergänzen.

Erfahrungen sind in dynamischen Situationen nur begrenzt nützlich, weil sich die Tricks und Taktiken des Gegners laufend verändern. Um zu bestehen, muss die Wirksamkeit der Taktik ständig überprüft werden. Aus der Sicht des einzelnen Spielers ist das wegen des fehlenden Überblicks nur unvollständig möglich. Außerdem gibt es Entscheidungen, die nur aus globaler Sicht getroffen werden können. Das gilt für Spiele wie für Projekte. Probleme, die sich beispielsweise aus unpassender Verteilung von Aufgaben oder falscher Priorisierung ergeben, sind oft nur von übergeordneter Warte aus erkennbar. Es kann vorkommen, dass sich eine Teilstrategie oder ein einzubindendes Produkt als ungeeignet oder nicht leistungsfähig genug erweist. Dann ist es an der Zeit, auszuwechseln. Ebenso wichtig ist es, Erfolge auszuwerten. Letztlich geht es darum, Erkenntnisse, die einzelne Akteure (ganz gleich ob Gruppen oder Individuen) nicht unmittelbar sehen können, zu gewinnen und zum Wohl des Projekts zu nutzen.

Es ist beispielsweise für die längerfristige Teamentwicklung ein Nachteil der Scrum-Methodik, dass keine fachliche Supervision vorgesehen ist. Die Rolle des Scrum-Masters besteht im Überwachen der Methodik, nicht der Fachlichkeit. Bekanntermaßen kommen aus heterogenen Gruppen oft interessantere oder bessere Lösungen, bei der gleichzeitigen Tendenz, die „Störer“ auszuschließen. Treffen nun zu stark divergierende Ansichten aufeinander, besteht bei reiner Selbstorganisation die Gefahr des „Stuhlkreissyndroms“ – d. h. der Verdrängung von Konflikten durch endlose Diskussionen statt deren Austragung, oder des Zurückziehens weniger dominanter Mitglieder. In beiden Fällen wird die mögliche Leistung beeinträchtigt. Solche Situationen bedürfen einer gewissen Führung.

Softwarearchitekt = Fußballtrainer

Die wichtigste Schlussfolgerung aus diesen Überlegungen ist die, dass die Softwareentwicklung auf den verschiedenen Ebenen Trainerrollen braucht. Leider sind die passenden Begriffe mit -coach und -trainer schon anderweitig belegt. Vielleicht sollte man die Rolle „Projektstratege“ nennen?

Von der Funktion her steht der Softwarearchitekt dieser Aufgabe am nächsten und es ist gut möglich, dass der Begriff entsprechend umgedeutet wird. Viel wichtiger als der Name ist jedoch das Gewicht dieser Position. Man wird wohl lange suchen müssen, um einen Softwarearchitekten zu finden, der in seinem Einfluss nur annähernd an den eines Fußballtrainers heranreicht. Genau das ist das Problem. Die Trainer haben ja nicht (nur) deshalb so viel Macht, weil sie sich auf Strategie und Taktik in Auseinandersetzungen verstehen. Ausschlaggebend ist der Erfolg, den diese spezielle Zusammenführung von fachlicher und administrativer Führung gebracht hat. Versuche, diese Macht einzuschränken, hat es vielfach gegeben. Bisher hat das nie so gut funktioniert, dass es Nacheiferer gegeben hätte.

Man muss kein Prophet sein, um vorherzusagen, dass es nicht leicht sein wird, eine derartig starke Funktion innerhalb der Softwareentwicklung zu etablieren. Tendenzen in diese Richtung sind dennoch in der Wirtschaft schon heute erkennbar. Ein Beispiel dafür war Steve Jobs bei Apple, der für gewöhnlich als Magier oder Visionär bezeichnet wird. Eigentlich war er vor allem der Trainer, der aus einer Mannschaft, die sich trotz guter Spieler im Abstiegskampf befand, einen Champion gemacht hat. Allerdings ist diese Kombination von fachlichen Fähigkeiten und Macht eine seltene Ausnahme. Trotzdem wird man mit der Verschärfung des Wettbewerbs solche Entwicklungen öfter sehen, wobei derzeit eher die Folgen des Fehlens guter Trainer zu beobachten sind. Aber alles braucht seine Zeit, und auch die Fußballtrainer haben einst klein und als bessere Ratgeber am Spielfeldrand angefangen.

Aus dem Vergleich sieht man jedoch auch, dass Trainer eine sehr anspruchsvolle und schwierige Aufgabe ist. Es gibt außerhalb des Sports kaum geeignete Ausbildungsgänge und wenig Erfahrung mit der fachlichen Anleitung von Teams. Die Größe der Herausforderung wird schon an der Vielfalt und der Dynamik der zu beherrschenden Fachlichkeit deutlich. Der Trainer muss nicht nur das richtige Verhältnis zwischen Anleitung und jeweiliger Eigeninitiative (zwischen Führung und Selbstorganisation) finden, er muss vor allem qualitativ bewerten. Metriken und Codeanalysen können dabei unterstützen, die subjektive Bewertung können sie aber nicht ersetzen. Solche Qualitätsmaßstäbe zu entwickeln, der Mannschaft zu vermitteln und in der jeweiligen Situation angepasst anzuwenden, ist eine weitere schwierige Aufgabe. Keinesfalls darf der Verlockung nachgegeben werden, Qualität automatisiert bewerten zu wollen. Es sind zwar alle Mittel zur Analyse erlaubt, aber wie im echten Fußball sollte niemand auf die Idee kommen, einzig aus messbaren Größen wie der Anzahl der Ballkontakte oder dem Laufweg die Leistung eines Spielers für das Gesamtergebnis bewerten zu wollen.

Wenn hier von der Rolle des Trainers die Rede ist, heißt das natürlich nicht, dass diese Rolle nur von einer Person wahrgenommen werden kann oder sollte. Selbst im Fußball, der verglichen mit ernsthaften Softwareprojekten eine einfache Angelegenheit ist, steht hinter dem Trainer ein ganzes Team von Spezialisten. Allerdings sollte die Entscheidungsgewalt in einer Hand konzentriert sein, um die unter dem Begriff „Design by Committee“ apostrophierten Fehler zu vermeiden.

Nicht zuletzt braucht der Trainer oder Projektstratege einen starken Rückhalt, denn in einer Hinsicht wird es nicht den geringsten Unterschied zum Fußballplatz geben: Jeder Zuschauer weiß, wie man es hätte besser machen können.

Schlussfolgerungen

Viele Projekte entsprechen einem Spiel ohne Trainer. Eine Mannschaft wird kurzfristig zusammengekauft, es wird kurz abgestimmt, wer wo steht, und los geht es. Ob nun 4-3-3 oder 4-2-4 gespielt wird, ist nicht unbedingt klar. Wenn der Gegner schwach genug ist, kann das durchaus erfolgreich und daher wirtschaftlich optimal sein. Schwierig wird es, wenn der Gegner stärker ist oder im Laufe des Spiels stärker wird. Man kann dann versuchen, die eigene Mannschaft zu verstärken. Früher oder später stößt das aber an Grenzen, weil entweder das Budget oder der Markt ausgeschöpft sind. Beispiele dafür, dass auch sehr potente Mannschaften an starken Gegnern (zunächst) scheitern können, gibt es genug – auch im Fußball. Der Fakt, dass es im zweiten Anlauf bzw. mit starker Verzögerung oft noch klappt, „weil man gelernt hat“, heißt nichts anderes, als dass man das erste Spiel einfach nachträglich zum Training umdeklariert.

Ähnlich läuft es oft beim Versuch, „auf der grünen Wiese“ etwas gänzlich Neues zu schaffen. Dieses Bild meint ja, einen neuen Weg zu beschreiten – also mit einer neuen oder stark veränderten Mannschaft gegen einen zumindest teilweise unbekannten Gegner anzutreten. Der Aufbau einer neuen Mannschaft braucht jedoch Zeit. Die Versuchung ist groß, sich diese Zeit durch höhere Investitionen in Spieler zu erkaufen. Das ist nichts anderes als eine riskante (Sport-)Wette. Es kann gut gehen, doch selbst wenn man meint, den Gegner gut zu kennen, sind Überraschungen nie ausgeschlossen.

Gute Trainer verwenden sehr viel Zeit für die Analyse gegnerischer Mannschaften. Auf Projekte übertragen ist das die Risikoanalyse, deren Stellenwert deutlich erhöht werden muss (Kasten: „Risikoanalyse“). Manager setzen sich nicht gern mit den Ursachen möglichen Scheiterns auseinander: „Ich will nicht hören, warum es nicht geht!“ In einer Welt, in der unerwartete Ereignisse häufiger eintreten als erwartete, ist solche Ignoranz auf die Dauer kostspielig und dumm. Intelligenter ist es, die Risikoanalyse als integralen Bestandteil des Requirement Engineerings zu sehen und mit der gleichen Aufmerksamkeit zu behandeln. Wenn man auf mögliche Probleme gefasst ist, sollte es leichter fallen, sie zu bewältigen, falls sie akut werden.

Risikoanalyse
Man kann nicht erwarten, große Projekte ohne sorgfältige Risikoanalyse bewältigen zu können. In dieser Beziehung können ambitionierte Großprojekte auch mit Forschungsreisen verglichen werden. Natürlich hat mancher Entdecker einfach eine gute Nase und viel Glück gehabt. Doch den meisten Katastrophen lag einfach eine schlechte Vorbereitung – sprich Risikoanalyse – zugrunde. Verantwortungsvolle Forscher haben bisweilen (viel) mehr Aufwand betrieben, alle Risiken zu erkennen und abzuwenden, als auf die Reise selbst. Ein überaus eindrucksvolles Beispiel dieser akribischen Sorgfalt findet sich beispielsweise im ersten Teil von F. Nansens Beschreibung seines Drifts mit der Fram durch das Nordpolarmeer.

Das leitet zu einer weiteren Erkenntnis über: Bisweilen ist überflüssige Arbeit sinnvoll. Um das zu illustrieren, soll noch ein Blick auf das Spielfeld dienen. Fast alle Spieler agieren dort ohne Ball. Sie laufen, bringen sich in Stellung – eigentlich überflüssige Aktionen, außer wenn sie dann doch angespielt werden. In ähnlicher Weise kann eine gute Risikoanalyse dazu benutzt werden, Entwicklungszweige zu verfolgen, die antizipierte Probleme vorwegnehmen. Tritt das Problem dann nicht ein, wird der Zweig eben verworfen. Das verursacht zwar auch Kosten, aber die Vorteile im gegenteiligen Fall sind groß. So gibt es mit Sicherheit weniger Zeitverzug. Noch wesentlicher ist aber, dass die Änderungen nicht nachträglich eingearbeitet werden müssen. In dieser Hinsicht unterscheiden sich Änderungen nämlich nicht von Fehlern. Sie sind umso kostspieliger, je später sie akut werden und je frühere Phasen der Entwicklung betroffen sind. In einem sehr veränderlichen Umfeld ist es wahrscheinlich, dass wenigstens einige der spekulativen Arbeiten erfolgreich sind und durch ihren Nutzen den Verlust der nicht erfolgreichen aufwiegen.

Eine andere Schlussfolgerung ist simpel: Man kann auch mal verlieren. Unter nicht vorhersagbaren Bedingungen ist es nie auszuschließen, dass die eigene Strategie versagt. Das ist ein grundlegender Unterschied zum Bauen, wo Scheitern zwar eigentlich nicht vorgesehen ist, manchmal aber doch auch vorkommt. Mit einer Niederlage rechnen und damit umgehen zu können ist allerdings kein Freibrief für schlampige oder keine Vorbereitung. Vielmehr geht es darum, eine falsche Aufstellung rechtzeitig zu erkennen und schnell entsprechende Konsequenzen für den nächsten Versuch zu ziehen.

Für die Controller und das Management eher schwierig zu vermitteln ist der Schluss, dass eine eingespielte Mannschaft einen erheblichen Wert darstellt, der schon durch relativ geringfügige Eingriffe vernichtet werden kann, denn dieser Wert lässt sich schwer beziffern. Trotz aller Flexibilität wird auch eine eingespielte Mannschaft nicht mit jedem Gegner, d. h. jeder Aufgabe, optimal fertigwerden. Es wäre schon ein großer Fortschritt, wenn allgemein akzeptiert würde, dass in der Softwareentwicklung gut funktionierende Teams einen Wert darstellen, den zu erhalten, zu entwickeln und zu nutzen eine wichtige Managementaufgabe ist. Damit wird gleichzeitig die Annahme hinfällig, dass Softwareentwicklung in gewisser Weise zum Convenience-Produkt geworden ist. Für anspruchsvollere Aufgaben wird sie das nie werden, aber nur solche Aufgaben rechtfertigen Eigenentwicklungen.

Schließlich betont dieses Modell den sozialen Aspekt der Softwareentwicklung. Die Tatsache an sich ist nicht neu, wird aber gern übersehen. Mannschaftsspiel ist Interaktion zwischen individuellen Persönlichkeiten. Um sich effizient entfalten zu können, muss die Kooperation trainiert werden. Manchmal hilft aber auch alles Üben nicht; bestimmte Akteure passen einfach nicht zusammen und wie beim Fußball kann das ebenso gut für den Trainer gelten. Entwickler, Trainer, agile Teams, ganze Abteilungen haben ihren Charakter, ihre Individualität. Eine gute Mannschaft ist mehr als eine Ansammlung von Ressourcen. Das zu ignorieren, ist pure Verschwendung.

Einordnung

Die vorgestellten Ideen sind allesamt nicht neu. Neu ist bestenfalls die pointierte Darstellung, aber selbst das ist nicht sicher. Peter Naur hat schon 1985 darauf hingewiesen, dass „… the notion of the programmer as an easily replaceable component in the program production activity has to be abandoned.“ [1]. Dabei betont er die gemeinsam entwickelte Theorie hinter jedem Softwaredesign, die nicht leicht weitervermittelt werden kann – also das, was hier etwas salopp als Spielidee umschrieben wurde. Die Notwendigkeit, die Autonomie der Akteure – insbesondere der Entwickler – zu stärken, propagiert u. a. Tom Gilb. Auf die soziale Komponente der Softwareentwicklung weist auch Kent Beck immer wieder nachdrücklich hin. Und selbst die Verbindung von Architektur und Fußball gibt es bereits. Der Architekt H. Hertzberger vergleicht seine Entwürfe mit den Regeln beim Fußball: „… die Leute auf dem Spielfeld sind frei, aber sie haben Regeln, ohne die das Spiel völlig unmöglich wäre.“ Genau so sollte die Rolle der Softwarearchitektur gesehen werden – sie gibt den Rahmen vor, der kreativ auszufüllen ist.

Natürlich ist das vorgeschlagene Modell kein Allheilmittel mit Alleinvertretungsanspruch. Man sollte es besser als komplementäre Extremposition zum herkömmlichen Bild vom Bauen sehen. Das wirkliche Leben spielt sich zwischen diesen beiden Polen ab. Je nachdem, wie wechselhaft oder statisch die äußeren Gegebenheiten eines Projekts sind, d. h. wo dazwischen es einzuordnen ist, ergeben sich unterschiedliche Gewichte für die ableitbaren Konsequenzen.

Zusammenfassung

Die zentrale Botschaft dieses Beitrags lautet, dass einige Aspekte der Softwareentwicklung durch die Analogie zu einem Mannschaftsspiel besser darstellbar sind, als das mit der üblichen am Bauen orientierten der Fall ist. Die Spielsituation spiegelt das häufig sehr volatile Projektumfeld und den Einfluss sozialer Prozesse besser wider. Entwickler oder Teams agieren in agilen Projekten ähnlich selbstständig wie Spieler auf dem Platz. Dieses Modell erlaubt es, typische Probleme einleuchtend zu erklären. Die Frage nach einer der Rolle des Trainers entsprechenden Funktion in Softwareprojekten zeigt, in welche Richtung sich bestehende Vorgehensmodelle möglicherweise weiterentwickeln könnten.

Links & Literatur

[1] Naur, P (1985): „Programming as theory building“, in: „Microprocessing and Microprogramming“, 15(5), S. 253–261

Unsere Redaktion empfiehlt:

Relevante Beiträge

X
- Gib Deinen Standort ein -
- or -