Softwareprojekte, mit System betrachtet

Ein Softwareprojekt erscheint aus Sicht der klassischen Vorgehensmodelle oft als ein Prozess. Ein Prozess ist ein Denkmodell. Sein Metamodell enthält z.B. die Klassen Rolle, Aktivität, Ergebnis, Zeitpunkt, Ereignis. Im Mittelpunkt steht die immer gleiche Frage “Wer erstellt bis wann welches Artefakt?”. Das Metamodell “Prozess” suggeriert, dass “wer” immer mit einer Rolle, “erstellt” immer mit einer Aktivität, “wann” immer mit einem Zeitpunkt oder Ereignis, und “Artefakt” immer als Ergebnis beschrieben, d.h. im Denken modelliert werden kann.

Aus der Praxis wissen wir, dass diese Sicht nur aus einem bestimmten Abstand stimmt …

Ein Fußballfan auf der Tribüne schreit gelegentlich “Schiedsrichter ans Telefon!”, weil er aus seiner Sicht anders entschieden hätte, wäre er nur selbst unten auf dem Rasen gewesen. Denkt er zumindest. Nur, hätte er das wirklich? Nein, möglicherweise eben nicht! Es ist ein Unterschied, ob man drinnen oder draußen ist.

Zurück zum Softwareprojekt. Ein Softwareprojekt ist aus der Sicht der Teilnehmer mitnichten ein Prozess in obigem Sinne. Wenn man “drinnen” ist, werden plötzlich ganz andere Dinge wichtiger als Rollen, Aktivitäten und Ergebnisse. Ein Softwareprojekt beschreibt man aus der Innensicht viel besser mit einem anderen Denkmodell: Ein Softwareprojekt ist von innen betrachtet ein *System* aus Menschen, ihren Fähigkeiten und Interaktionen.

Was ist ein System?

Der Biologe Karl Ludwig von Bertalanffy (1901-1972) war der Begründer der Allgemeinen Systemtheorie. Er verstand ein System als eine neue Einheit, die zwar bestimmte Elemente als Voraussetzung hat, aber nicht als bloße Summe dieser Elemente zu verstehen ist: Durch die Beziehungen der Elemente untereinander und die daraus entstehenden Wechselwirkungen ergibt sich etwas Neues, das nicht ausschließlich auf die Eigenschaften der Elemente zurückführbar ist (das Ganze ist mehr als die Summe seiner Teile!). Dem Astrophysiker Steven Klein wird der einfache Satz zugeschrieben: “Ein System ist ein synergetisches Produkt aus einer Vielzahl von Komponenten.”

Ein paar einfache Beispiele hierfür: Ein Wirtschaftssystem besteht unter anderem aus Unternehmen und Kunden. Je nachdem, ob man in einer Marktwirtschaft oder einer Planwirtschaft befindet, haben Unternehmen ein sehr unterschiedliches Verhalten. Dieses Verhalten erklärt sich dann nicht mehr aus den Eigenschaften der Unternehmen selbst, sondern aus der Wechselwirkung der Unternehmen untereinander und mit ihren Kunden.

Anderes Beispiel: Eine Brutkolonie von Vögeln hat eine beschränkte Anzahl von Nistplätzen. Jeder Vogel braucht zu seinen Nachbarn einen Mindestabstand, um zu brüten. Je mehr Vögel zuziehen, desto geringer wird die Zahl von freien Nistplätzen, es stellt sich aufgrund dieser negativen Rückkopplung ein Gleichgewicht bei einer gewissen Maximalgröße der Kolonie ein, ohne dass dies auf einen “Beschluss” einzelner Vögel zurückgeführt werden kann.

Ein Beispiel mit gleich zwei Systemen, die zu einander in Beziehung stehen: Man kann beobachten, dass die Population von Füchsen in regelmäßigen Abständen wächst und entsprechend wieder sinkt; sucht man die Begründung dafür in den Füchsen selbst, so wird sich keine befriedigende Lösung ergeben – erst in der Wechselwirkung mit der Hasenpopulation am gleichen Ort wird sich zeigen, daß diese ihren zahlenmäßigen Höchstpunkt hat, wenn die andere ihren Niedrigstpunkt erreicht und umgekehrt. Das Räuber-Beute-System stellt also eine neue Einheit dar, die nicht allein auf eines der beteiligten Systeme zurückführbar ist.

Relationen

Jedes System besteht aus Elementen, die zueinander in Beziehung (Relation) stehen. Meist bedeuten diese Relationen ein wechselseitiges Beeinflussen – aus der Beziehung wird ein Zusammenhang. Nehmen wir die Entwickler und die Manager. Entwickler produzieren lauffähigen Code und machen dabei Fehler.

Manager gehen mit Fehlern unterschiedlich um. Manche betrachten Fehler nach dem Schuldprinzip: Wer ist dafür verantwortlich, dass dieser Fehler passiert ist? Mit wem muss ich also ein ernstes Gespräch führen, damit das nur ja nicht wieder passiert? Nimmt ein Manager mit den Entwicklern eine solche Wechselwirkung auf, wird das dazu führen, dass Entwickler die Fehler nicht mehr offen ansprechen und dazu tendieren, sie zu verheimlichen. Es passiert genau das Gegenteil von dem, was gewünscht ist: Die Fehler bleiben so lange geheim, bis sie der Kunde findet. (Wie in der Bibel bei Hiob: “Was ich befürchtete, kam über mich.”)

Andere Manager betrachten Fehler als etwas Alltägliches, eine Lernerfahrung. Werden die Entwickler so geführt, werden sie offen über Fehler sprechen, mit dem Erfolg, dass Fehler schon projekt-intern gefunden und behoben werden können, bevor sie der Kunde findet, also genau das vom Manager gewünschte Verhalten.

Unterschiedliche Relationen sind nicht per se richtig oder falsch, sondern höchstens dem Projektziel mehr oder weniger angemessen. Beide Partner, die an den Enden der Relation sitzen, sollten sich das klarmachen und wenn nötig die Relation anpassen.

Ein System im obigen Sinne lässt sich durch die Definition zweckmäßiger Systemgrenzen von seiner Umwelt (den übrigen Systemen) weitgehend abgrenzen, um es modellhaft isoliert beobachten und das Geschehen reflektieren zu können. Diese (vorübergehende) Einschränkung ist zweckmäßig, weil das menschliche Bewusstsein in seiner Auffassungsgabe systemischer Abläufe begrenzt ist.

Mitglieder eines Entwicklungsteams werden die Grenzen ihres Teams als Systemgrenzen wahrnehmen. Wer nicht dieselben Erfahrungen wie die Teammitglieder gemacht hat, wer an einem anderen Ort arbeitet, wer von einem anderen Leitwolf (Manager) geführt wird, wird als außerhalb des Systems, fast als “Alien” wahrgenommen. Alien bedeutet meistens und in erster Linie: Ich nehme keine Beziehung zu ihm auf und bleibe als Element lieber allein oder in Beziehung zu den anderen Elementen des wohlbekannten Systems “Team”.

Das wird besonders dann spürbar, wenn Aliens mit dem Team zusammenarbeiten sollen. Beispiel: Die berühmte Infrastrukturabteilung des Unternehmens. Diese bekommt die Aufgabe, die Anwendung in Betrieb zu bringen, die vom Entwicklungsteam produziert wurde. Die Infrastrukturabteilung wird über Service Level Agreements (SLAs) gesteuert und hat eine bestimmte (in den SLAs definierte) Verfügbarkeit, Performance, Sicherheit usw. ihrer Anlagen und der darauf laufenden Anwendungen zu gewährleisten. Die Infrastrukturabteilung möchte deshalb möglichst rigide Prozesse fahren: Eine neue Version der Anwendung darf nur nach Durchlaufen sehr strenger Prüfungen auf den Servern installiert werden, selbst wenn die alte Version, die dort bereits läuft, Dutzende bekannter Fehler enthält.

Das System Infrastrukturabteilung zeigt ein Verhalten, das von den Entwicklern nicht im Mindesten verstanden wird. Diese sind der Ansicht, dass die neue Version ja um Längen besser sei als die alte und deshalb unbedingt installiert werden müsse. Mit Entwicklungsteam und Infrastrukturabteilung treten hier zwei Systeme in Beziehung, die völlig unterschiedliche Wechselwirkungen (Regelsätze) zwischen ihren Elementen aufweisen.

Bei Systemen unterscheidet man die Makro- und die Mikroebene: Auf der Makroebene befindet sich das System als Ganzes. Auf der Mikroebene befinden sich die Systemelemente. Interaktionen auf der Mikroebene bestimmen, wozu das System auf der Makroebene in der Lage sein wird. Auf der Makroebene lassen sich andererseits Beobachtungen machen, die aus dem Verhalten der Elemente auf der Mikroebene nicht erklärbar sind. Das hängt stets vom Standpunkt des Betrachters ab.

Klassisches Beispiel ist hier ein Setup-Fehler zwischen zwei Systemen, der häufig bei neuen Projekten gemacht wird. Nehmen wir an, Organisationseinheit A arbeitet im Tagesgeschäft und wickelt ein produktives Projekt nach dem anderen ab. Von Zeit zu Zeit klemmt es bei A, da sie mit veralteten Tools arbeiten. Die Kunden von A stellen nebenbei auch neue Anforderungen. Organisationseinheit B bekommt deshalb einen Innovationsauftrag: Sie sollen völlig neue Softwaretools entwickeln und dann an A bereitstellen, so dass A schneller und besser arbeiten kann.

Die Mitarbeiter in A werden in Kürze ein neues Produktivprojekt beginnen. Sie beschließen, dazu eine Betaversion der neuen Tools einzusetzen, die von B hergestellt werden. B hat nicht explizit zugestimmt, fühlt sich jedoch geschmeichelt. A möchte sein Produktivprojekt im selben Zeitrahmen wie immer abwickeln, läuft aber plötzlich auf Fehler in der Betaversion der Tools von B. Die Leute aus A verlangen nun von denen aus B, diese Fehler möglichst schnell zu beheben, so dass A seine Termine halten kann. Die Mitarbeiter von B arbeiten jedoch lieber an ihrem Innovationsziel und liefern nicht so schnell wie in A erwartet. Schließlich hat ja niemand behauptet, dass die Tools aus B jetzt schon einsatzreif seien!

Die Mitglieder von A beobachten die Leute in B und sehen, dass sie auf der Mikroebene genauso heftig entwickeln wie die in A. Als Ganzes auf der Makroebene betrachtet, erscheint B jedoch für A außergewöhnlich langsam. Was beide nicht sehen: sie arbeiten für unterschiedliche Ziele! Die einen für die Produktion, die anderen für die Innovation! Lösung: A sollte sein Produktivprojekt besser mit den altbewährten fehlerhaften Tools abwickeln und in Ruhe darauf warten, bis B die Tauglichkeit der innovativen Tools bewiesen hat. Beiden wäre geholfen und die erzielte Qualität wäre insgesamt höher.

Soziale Systeme aus selbstbestätigender Kommunikation

Niklas Luhmann (1927-1998) war ein deutscher Jurist, Soziologe und Philosoph der zweiten Hälfte des 20. Jahrhunderts. Als einer der Begründer der soziologischen Systemtheorie gilt Luhmann als ein ausgesprochen transdisziplinärer Sozialwissenschaftler. Seine zentrale These lautet, dass soziale Systeme

• ausschließlich aus Kommunikation bestehen (nicht aus Subjekten, Akteuren, Individuen o.ä.),

• sich in einem ständigen, nicht zielgerichteten Prozess quasi aus sich selbst heraus erschaffen, d.h. Kommunikation erschafft neue Kommunikation

Luhmann beobachtete, dass Kommunikation in sozialen Systemen ähnlich abläuft wie die Selbstreproduktion lebender Organismen: Ähnlich wie diese nur Stoffe aus der Umwelt aufnehmen, die für ihre Selbstreproduktion relevant sind, nehmen auch Kommunikationssysteme in ihrer Umwelt nur das wahr, was zu ihrem “Thema passt”, was an den Sinn der bisherigen Kommunikation “anschlussfähig” ist. In der unendlich komplexen Umwelt wird nach bestimmten Kriterien nur ein kleiner Teil herausgefiltert; die Grenze eines sozialen Systems markiert somit eine Komplexitätsdifferenz von außen nach innen. Das Innen erscheint einfacher als das Außen.

Ich war einmal in einem Softwareprojekt als Mittler zwischen zwei fast schon verfeindeten Teams eingesetzt. Beide Teams litten an übertriebener selbstbestätigender Kommunikation. Die systemische Betrachtungsweise half mir, die Barriere zu überwinden, indem ich jeweils einem Team immer wieder begreiflich machte, was das andere Team tat und umgekehrt. Die Komplexitätsdifferenz und damit die Feindschaft aufzulösen war mein Ziel.

Das Ganze klappte nur bis zu einem gewissen Grad, weil die Zahl gemeinsam gemachter Erfahrungen gering war. Da ich sah, dass beide Teams mit ihren Komponenten zu einem lauffähigen Gesamtsystem beitragen mussten, verordnete ich einen gemeinsam durchgeführten Systemtest mit gemeinsamer User Story, wieder mit dem Ziel, die Zahl der gemeinsam gemachten Erfahrungen zu vergrößern.

Auch das klappte nur begrenzt, da ein Team ausbüchste, indem es seine Komponenten bereits vorher isoliert an die Kundschaft auslieferte und dann erst einmal völlig neue Komponenten entwickelte, die mit dem aktuell anstehenden Systemrelease (und damit dem anstehenden Systemtest) nichts zu tun hatten. Wieder keine gemeinsamen Erfahrungen – die Komplexitätsdifferenz wurde erfolgreich aufrechterhalten. Na, anscheinend gab es ja einen Grund, der das Vorgehen für diese Teams notwendig machte und den ich eben nicht kannte!

Später erfuhr ich, dass bei der Kundschaft bezüglich des Deployments der ausgelieferten Komponenten ohnehin alles noch derart unklar war, so dass die oben genannten Probleme kaum eine Rolle spielten. “Ohne wirklichen Leidensdruck keine Gesundung des Patienten”, das war meine Erkenntnis aus diesem Fall. Hätten beide Teams unter Druck auf dasselbe Ziel hinarbeiten müssen, wäre das Problem sehr schnell zu beheben gewesen.

Regelkreise

In Systemen herrschen Regelkreise, man spricht von verstärkender oder balancierender Rückkopplung. Verstärkende Rückkopplung herrscht, wenn die verändernde Kraft den bereits vorhandenen Zustand weiter zementiert. Balancierende Rückkopplung ist dann gegeben, wenn die verändernde Kraft gegen den bereits vorhandenen Zustand wirkt, das System also ausbalanciert.

Viele solcher Rückkopplungen lassen sich in Softwareprojekten identifizieren. Ein Beispiel hatten wir oben schon: Intoleranz gegenüber Fehlern verursacht mehr Fehler, nicht weniger. Weitere Beispiele:

• Terminstress und Zeitsparen verschlechtert die Qualität der Software und führt dazu, dass man den Termin genau deshalb verpasst. Lösung: Zeitdruck zugunsten von QS-Maßnahmen herausnehmen. Entwicklungsgeschwindigkeit nur leicht erhöhen, sobald die Qualität wieder hoch genug ist.

• Wenn ein Kunde dem Entwicklungsprojekt nicht mehr für Fragen zur Verfügung steht, weil er Kosten sparen möchte, wird er mehr Kosten wegen der Korrektur für unerwartete, nicht abnahmefähige Ergebnisse produzieren. Lösung: Zeit zum Feedbackgeben investieren und dadurch Ergebnisse schon fast beim ersten Mal richtig bekommen.

• Vergrößert man das Projektteam, wird die Entwicklungskraft auch größer, doch nicht linear und nicht sofort. Der Kommunikationsaufwand, der mit dem Quadrat der Personenzahl im selben Team ansteigt, ist hier die balancierende Rückkopplung. Lösung: Zeit einplanen, bis das Team neue Leute “absorbiert”. Falls das Team größer als 7-9 Leute wird, dann Subteams bilden, sonst frisst der Kommunikationsaufwand die Investition in neue Leute wieder auf.

Zusammenfassung

Sie sehen: Ein Softwareprojekt einmal nicht mit der Prozess- sondern mit der Systembrille zu betrachten, kann Ihnen helfen, die im Alltag stattfindenden, oft unerklärlichen Besonderheiten zu verstehen. Es lohnt sich, einmal über den Tellerrand unseres Berufsstandes zu schauen. Die Systemtheorie ist ein Wissensgebiet, aus dem sich für die IT viel übernehmen lässt – seien wir kreativ, übernehmen wir durch Analogieschlüsse, was uns hilft!