Vorgehensmodelle in der Softwareentwicklungsindustrie

Inhaltsverzeichnis

1 Einführung: Motivation und Fragestellung

2 Grundlagen und Begrifflichkeiten
2.1 Vorgehensmodelle im Software Engineering
2.1.1 Klassisches Software Engineering: Das Wasserfallmodell
2.1.2 Agile Projektvorgehen
2.2 Soziologische Grundlagen und Betrachtungen
2.2.1 Funktionale Systeme und Organisationen - eine sehr kurze Ein­führung
2.2.2 Eine Betrachtung der Vorgehensmodelle

3 Einordnung in aktuelle Forschung

4 Methodik der Arbeit

5 Ergebnisse I: Hintergründe und Gründe agiler Vorgehensmodelle
5.1 Alter Wein in neuen Schläuchen - Neues und Bekanntes im agilen Vorgehen
5.2 Gründe für Agilität in den Projekten
5.3 Die Fiktion einer vollständig durchdachten, alles umfassenden Lösung

6 Ergebnisse II: Betrachtungsweisen und Bewertungen von Agilität
6.1 Wahrnehmung der Stabilität der eigenen Aufgabenbeschreibung
6.2 Agilität folgt keiner feststehenden, einheitlichen Definition
6.3 Individuelles Erleben und Bewerten von Agilität
6.4 Eignung von Projekten für agile Vorgehen
6.5 Schwierigkeiten verschiedener Blickwinkel

7 Ergebnisse III: Betrachtung und Bewertung sozialer Komponenten
7.1 Die Illusion selbstorganisierter Teams
7.2 Motivation und Zufriedenheit
7.3 Anforderungen von Scrum an Mitarbeiter und Kunden

8 Ergebnisse IV: Adaptionen im Projektvorgehen
8.1 Strategien und Elemente aus dem klassischen Software Engineering in agilen Projekten
8.2 Strategien der Adaption
8.3 Schwierigkeiten durch Adaptionen, Mischformen und Derivate

9 Ergebnisse V: Ausblicke und die Zukunft in Projekten und Projekt­vorgehen
9.1 Wider den Dogmatismus
9.2 Kombinierte Vorgehen sind die Zukunft
9.3 Agile Organisationen: Agilität in Projekten ist nicht ausreichend

10 Zusammenfassung und Ausblick

Literaturverzeichnis

Anhang

A Fragen der Qualitativen Interviews
A.1 Einführungsfragen
A.2 Konkrete Fragen zum Projektalltag
A.3 Allgemeine Fragen zum Projektvorgehen
A.4 Konkrete Fragestellungen und ihre Lösungen
A.5 Abschlussfragen

Kapitel 1

Einführung: Motivation und Fragestellung

Um IT-Projekte — und hiermit meinen wir solche zur Erstellung von Software - ab­zuwickeln, wird zunächst ein Vorgehensmodell benötigt, also eine Anleitung, wie man von Ideen, Wünschen und Vorstellungen zu einer (fertigen) Softwarelösung kommt. In der Softwareindustrie waren über einen langen Zeitraum klassische Vorgehens­modelle (Wasserfallmodell oder V-Modell in verschiedenen Derivaten) führend, um große Softwaresysteme zu bauen (Royce (1970)). Klassische Vorgehensmodelle sehen eine schrittweise Erstellung in Phasen wie Anforderungsanalyse, Spezifikation, Kon­struktion, Implementierung und Test vor (die durchaus iterativ erfolgen kann), mit einem definierten Anspruch an die Dokumentation der jeweiligen Phase. In diesen Modellen gibt es demnach eine klar definierte Spezifikation, in der zu jedem Zeitpunkt das Systemverhalten und seine Entwurfsmuster nachgeschlagen werden können, ein Testkonzept, das u. a. klar regelt, wann zu welchem Zeitpunkt auf welchen Umgebun­gen welche Inhalte zu testen sind, und vieles mehr. Dieses ingenieurwissenschaftliche Vorgehen hat zur Folge, dass von der ersten Idee bis zur Auslieferung viel Zeit ver­geht und auf dem Weg dorthin umfangreiche Dokumentationen geschrieben werden müssen. Damit sind zuweilen schon kleinere Anpassungen sehr teuer und zeitaufwän­dig. Dies ist ein Argument dafür1, dass sich in jüngerer Zeit für die Erstellung von Softwaresystemen zunehmend agile Vorgehensmodelle durchgesetzt haben. Obwohl bereits Ende der 90er Jahre vorgeschlagen (Beck (2003)), hat der Einzug der verschie­denen agilen Vorgehensmodelle in die Softwareindustrie einige Zeit benötigt, und sie wurden (und werden) stark in Onlineforen, Blogbeiträgen, Erfahrungsberichten und natürlich auf den Gängen der großen Softwarehäuser diskutiert. Agile Vorgehens­weisen (wie etwa Scrum oder eXtreme Programming) orientieren sich am Team und am zu erstellendem Produkt, welches backlogorientiert und iterativ in kurzen Ent­wicklungszyklen - den Sprints - implementiert wird. Heute hat sich dieses Vorgehen im Wesentlichen bei allen Systemhäusern und Entwicklern von Softwareprodukten durchgesetzt und muss nun von den Mitarbeitern angenommen und gelebt werden¹ (Komus and Kuberg (2017)). Der damit verbundene Paradigmenwechsel ist am ein­fachsten an den vier Leitsätzen des Agilen Manifests - welches als Fundament der agilen Softwareentwicklung gilt - selbst auszumachen. Dieses verlangt gerade, sich von bisherigen Prozessen, Verträgen, Dokumentationen und Plänen zu lösen und setzt andere Prioritäten als dies in klassischen Vorgehen der Fall war (Beck et al. (2001)):

Wir erschließen bessere Wege, Software zu entwickeln, indem wir es selbst tun und anderen dabei helfen. Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt:

Individuen und Interaktionen mehr als Prozesse und Werkzeuge. Funktionierende Software mehr als umfassende Dokumentation. Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung. Reagieren auf Veränderung mehr als das Befolgen eines Plans.

Mit agilen Vorgehensweisen, auf den Punkt gebracht im Agilen Manifest, ändern sich die Arbeitsgrundlagen, die gesamte Zusammenarbeit der Softwareentwickler, Fachexpertinnen und Projektleiterinnen. Artefakte, Zusammenarbeitsmodelle, Qua­litätsdefinitionen die bislang richtig oder wichtig waren, spielen keine wesentliche Rolle mehr. Stattdessen rücken andere Dinge, wie die Teamzusammenarbeit oder ein schnell vorzeigbares Produktinkrement in den Vordergrund. Damit scheint sich die Arbeit (der Prozess der Erstellung von Softwarelösungen) von der früheren grund­legend zu unterscheiden, wenngleich doch Ausgangslage und Endprodukt sich nicht geändert haben. Wir werden in dieser Masterarbeit untersuchen, wie die beteilig­ten Menschen mit diesen Veränderungen ihres beruflichen Alltags umgehen. Hierbei leiten uns zentrale Fragen:

- Wie bewerten Menschen die Arbeit in einem neuen Vorgehensmodell, das eine andere Art der Zusammenarbeit (mit ihren Rollen und definierten Aufgaben), der eigenen Verantwortung, der inhaltlichen Arbeit und der Kommunikation verlangt?
- Wie finden sich Menschen, die sowohl mit dem einen als auch mit dem anderen Vorgehensmodell gearbeitet haben, im agilen Vorgehen wieder?
- Wie definieren sie ihre Rolle, und wie finden sie Lösungen für Probleme, die sie früher nicht kannten?
- Welche Strategien entwickeln diese Menschen? Werden Elemente, Verhalten, Strategien übernommen, was wird an Neuem anerkannt und angewendet?

Auch interessiert uns, wie die Projektmitglieder diese Änderung selbst empfunden haben. Wir untersuchen, wie die betroffenen Menschen den Wandel für sich und andere bewerten und versuchen herauszufinden, wie sie in ihrem neuen Umfeld nach Vertrautem oder gewohnten Verhalten suchen oder vielleicht gerade all das Alte hinter sich lassen und sich in einer neuen Rolle neu finden. Mit anderen Worten, wir beschäftigen uns mit der Fragestellung: Wie (in welcher Form) agieren, reagieren, entwickeln sich Menschen, deren Arbeitsergebnisse sich nicht verändert haben, wohl aber die Art, wie sie zu diesem Ergebnis kommen (in anderen Vorgehensmodellen)? Der Wandel der Vorgehensmodelle in IT-Projekten von klassischen hin zu agilen Vorgehen hat zu vielfältigen Forschungsfragen und mannigfaltigen Veröffentlichun­gen geführt, die Forschungslandschaft mithin ungemein belebt. Offenbar scheinen diese Vorgehen Fragen aufzuwerfen, untersuchungs- und diskussionswürdig zu sein. Die Untersuchungen umfassen zum einen normative Darstellungen, beschäftigen sich also mit der Frage, wie agile Projekte sein sollen, und geben Gründe hierfür an, die sowohl in den Defiziten der klassischen Vorgehen zu finden sind als auch Begründun­gen in Psychologie und Verhaltensforschung (mit Blick auf die Zusammenarbeit im Team) finden. Empirische Studien untersuchen zweitens gewisse Phänomene agiler Projekte wie etwa die Motivation des Teams, die Auswirkungen von Transparenz oder das Leben agiler Werte in agilen Entwicklungsteams. Und drittens tragen sys­tematische oder strukturelle Studien zur Theoriebildung agiler Projektvorgehen bei, die agile Projekte etwa kategorisieren, miteinander vergleichen und in einen Gesamt­zusammenhang bringen. Wir werden auf verschiedene, für diese Arbeit relevante Forschungen in Kapitel 3 eingehen.

Diese Arbeit ist eines nicht: normativ. Es geht uns nicht darum zu sagen, was sein sein soll, wie Softwareprojekte am besten oder „richtig“ (im Hinblick auf verschiedene Metriken) durchgeführt werden sollen. Wir gehen empirisch vor, befassen uns jedoch nicht mit einzelnen, isolierten Phänomenen und versuchen diese zu untersuchen oder nachzuweisen, was der Gegenstand vieler aktueller Forschungen ist. Wir versuchen uns an einem holistischen Ansatz: Wir beschreiben in einer Momentaufnahme (und nur eine solche kann es sein), wie Menschen, die die eine Welt kennen, in der anderen agieren, und welche Schlüsse sie selbst daraus ziehen. Wir beschreiben den gesam­ten Umgang mit diesen neuen Vorgehensmodellen. Hierbei spannen wir den Bogen von den Anfängen von Agilität also den Gründen, der Motivation, der Abgrenzung gegenüber klassischen Vorgehen im ersten Ergebniskapitel (Kapitel 5) bis hin zu ei­nem Blick in eine mögliche, sich vielleicht bereits abzeichnende Zukunft sowohl der Durchführung der Projekte als auch der Auswirkungen agiler Vorgehen auf Orga­nisationen im letzten Ergebniskapitel (Kapitel 9). Dazwischen beschäftigen wir uns mit der Gegenwart - wir betrachten die verschiedenen Blickweisen auf die Projekt­vorgehensweisen und arbeiten die unterschiedlichen Bewertungen einzelner Elemente heraus (Kapitel 6 und 7). Wir zeigen zudem, welche Auswirkungen dies in der Pra­xis hat, und wie eben die Menschen darin agieren. Wir werden Beispiele sehen, wie Agilität in der Praxis aussieht, welche Impulse der agilen Vorgehen in welcher Form aufgenommen werden. Dies mündet in verschiedene Adaptionen der Projektvorge­hen, so, wie sie für Projekt und Mensch passend erscheinen oder sich ergeben haben. Wir werden gemeinsame Kernelemente verschiedener Adaptionen beschreiben und Gründe hierfür aufzeigen (Kapitel 8).

Wir (und die Interviewteilnehmer) erkennen und zeigen in den Ergebnissen dieser Arbeit die Kontingenz des gewählten Vorgehens. Es wird klar, dass Projekte sowohl auf die eine als auch auf die andere und, vielmehr noch, auf eine völlig andere, uns im Augenblick noch gar nicht bekannte Art und Weise durchgeführt werden können. Im Moment der Auswahl kann sich aus einem Methodenkoffer bedient werden, der sich für alle Interviewpartner eben durch neue Vorgehensmodelle erweitert hat - mit dieser Erweiterung ist auch klar geworden, dass es noch viele weitere Möglichkeiten geben kann und gibt, auch wenn diese noch keine Rolle spielen, genau genommen noch nicht einmal bekannt oder denkbar sind. Mit anderen Worten, den Projektbe­teiligten heutiger Projekte, die vergangene Modelle erlebt haben, ist die Kontingenz der jetzigen Art und Weise der Projektdurchführung vollkommen klar, und sie sehen diese auch für zukünftige Projekte - es könnte also alles anders sein, wir wissen aber noch nicht, wie. Dies führt dazu, dass sie sich vehement gegen jeglichen Dogmatismus bei der Auswahl und der Verfolgung von Vorgehen in Projekten aussprechen. Dieses zentrale Resultat, dass die Zunahme hypothetischen Denkens durch den Wandel der Vorgehensmodelle, durch einen Paradigmenwechsel gerade bei nahezu gleichbleiben­der Aufgabe zeigt, wird in allen Ergebniskapiteln sichtbar.

Wir haben diese Ergebnisse aus semistrukturierten Interviews extrahiert, die wir mit verschiedenen Vertretern aus den Gruppen Projektleiterinnen, Softwareentwick­lerinnen und Fachexperten sowie Querschnitt eines Softwaresystemhauses geführt haben. Bei der Auswahl der Interviewpartner haben wir Wert darauf gelegt, dass die Interviewpartner in beiden Vorgehensmodellen gearbeitet haben und arbeiten, die Modelle also in ihrer täglichen Arbeit erleben und leben. Der konzipierte Fragebo­gen A lässt Raum für Berichte aus dem eigenen Projektalltag. Diese Berichte und Darstellungen von Erlebnissen in den Vorgehensmodellen helfen uns, die konkreten Situationen zu bewerten und das Agieren der Menschen nachzuvollziehen. Diejenigen Interviews mit den tiefsten Einsichten (9 Stück) wurden vollständig transkribiert und die Ergebnisse hieraus abgeleitet. Wir haben also gerade nicht im Vorfeld eine Theo­rie entwickelt, die wir versuchen, mithilfe der Fragen zu beweisen oder zu verwerfen, sondern wir haben anhand der Antworten verschiedene Ergebnisse herausgearbeitet. Bei Unklarheiten haben wir entweder in der Gruppe der gewählten Interviewpart­ner oder in einer weiteren Referenzgruppe nachgefragt. Dies haben wir entsprechend gekennzeichnet.

Diese Arbeit folgt einer klassischen Struktur. Im Kapitel 2 führen wir die theore­tischen Grundlagen ein, also alle Konzepte und Definitionen, die wir in der Arbeit benötigen.² Es folgen eine Darstellung eines Ausschnitts der aktuellen Forschung zum Thema im Kapitel 3, eine Beschreibung der Methodik der Interviews und der Arbeit im Kapitel 4, eine die Darlegung der Ergebnisse in den Kapiteln 5 bis 9 sowie ein Ausblick mit Fazit im Kapitel 10.

Entstanden ist die Arbeit im Übrigen hybrid, also sowohl mit Elementen des klas­sischen Vorgehens - zunächst eine vollständige Erstellung der Interviews und Tran­skriptionen und darauf aufbauend dann die Theorieentwicklung - als auch mit agilen Elementen - Auslegung und Interpretation der Interviews parallel zur Herausarbei­tung der Phänomene und iterative Theoriebildung und -erprobung. Mit anderen Worten, die Methodik dieser Arbeit folgt ihrem Ergebnis, oder umgekehrt: Eine Kombination aus verschiedenen Elementen ist sinnvoll - nur kein Dogmatismus!

Kapitel 2

Grundlagen und Begrifflichkeiten

2.1 Vorgehensmodelle im Software Engineering

Wir geben im Folgenden eine Einführung in Vorgehensmodelle der Software- oder Systementwicklung, wie sie in der Standardliteratur für klassisches Software Engi­neering etwa in Denert and Siedersleben (1998) oder Ludewig and Lichter (2013) beziehungsweise für agile Softwareentwicklung etwa in Cockburn (2006), Schwaber and Beedle (2002) oder Wolf and Bleek (2017) zu finden sind. Wir geben hier nur einen kleinen Ausschnitt wieder, der wesentliche Gedanken und das grundlegende Vorgehen beschreibt. Hierbei setzen wir den Fokus auf genau diejenigen Grundlagen, die notwendig sind, die Interviews und vor allem die Ergebnisse der Arbeit nachzu­vollziehen.

2.1.1 Klassisches Software Engineering: Das Wasserfallmodell

Die Frage, wie Software entstehen wird, also wie vorgegangen werden soll, um von ei­ner Anforderung, einem Wunsch oder einer Idee zu einer Softwarelösung zu kommen, stellte sich mit Beginn der Entwicklung von großen Softwaresystemen. Es ist nahelie­gend, sich zunächst zu überlegen, welche Probleme genau das zu implementierende System eigentlich lösen sollte, welche Prozesse es unterstützen muss, welche Men­schen mit welchen Kenntnissen daran arbeiten sollten usw. Mit anderen Worten, es muss eine Anforderungserhebung durch einen Anforderungsingenieur (gebräuchlicher ist der englischsprachige Begriff Requirement Engineer) in Form eines Lasten- oder Pflichtenheftes erfolgen. Dies erfordert spezielle Fertigkeiten (etwa bei der Prüfung der Kohärenz oder Redundanzfreiheit von Anforderungen) und spezielle Fähigkeiten des Anforderungsingenieurs (beispielsweise den Nutzer dazu zu bringen, in Anforde­rungen und nicht schon in Lösungen zu denken). Im nächsten Schritt erfolgt aus der (zuweilen sehr großen) Liste der Anforderungen ein Systemdesign - hier überlegen sich ein oder mehrere Spezifikateure nach einem bestimmten Vorgehen, wie all diese Anforderungen durch ein Softwaresystem abgedeckt werden können. Die Spezifika­tion beschreibt also, wie dieses System aussehen soll. Das passiert auf Papier (bzw. in Form eines elektronischen Dokuments) und beinhaltet typischerweise eine ganze Menge an verschiedenen Artefakten (z.B. eine Beschreibung von Anwendungsfällen, eine Beschreibung der Schnittstellen zu anderen Systemen oder das Aussehen der Dialoge der Benutzeroberfläche). Diese Beschreibung geschieht in einer für Entwick­ler verständlichen und umsetzbaren Form, damit diese nun tatsächlich das System implementieren können. Hierzu wird ein Architekt Vorgaben machen, beispielsweise zur Technologie, aber auch in Form von Richtlinien zur Implementierung (etwa für einheitliche Programmierung oder zur Umsetzung nichtfunktionaler Anforderungen wie Sicherheit oder Performanz). Im klassischen Projektvorgehen überlegt er sich dies vor Beginn der Implementierung. Ist die Software schließlich fertiggestellt, muss das System noch durch Tester getestet und schließlich ausgeliefert werden. Anschließend können Erweiterungen am System erfolgen, oder es muss lediglich gewartet werden (Datenbankbereinigung, Fehlerbehebung, Anpassungen der Infrastruktur etc.). Für jede der Phasen sind verschiedene (zum Teil über Jahre zu erwerbende) Fertigkeiten vonnöten, seien diese nun technologischer, fachlicher, organisatorischer oder mensch­licher Art. Zusammenfassend besteht also das klassische Softwareengineering aus

- den Phasen: Anforderungserhebung, Systemdesign (Spezifikation), Konstruk­tion, Implementierung, Test und Wartung;
- den Rollen: Anforderungsingenieurin, Spezifikateurin, Entwicklerin, Testerin und Projektleiterin bzw. -managerin;
- den zu jeder Phase korrespondierenden Artefakten (Lastenheft/Pflichtenheft, Spezifikation/Konstruktion, Implementierung, Testspezifikation und getestetes Produkt).

Im Wasserfallvorgehen1 werden diese Phasen nacheinander ausgeführt (siehe Abbil­dung 1), und in der Extremausprägung auch nur ein einziges Mal.^{3 4}

Die Anforderungsingenieure müssen sich mithin sehr genau überlegen, was wichtige oder wesentliche Anforderungen sind, und diese dann systematisch erfassen. Und genau hierin liegt eine Kritik am Wasserfallmodell - kaum jemand kann heute sagen, welche Funktionalitäten einige Monate später in welcher Form tatsächlich benötigt werden. Offenkundig dauert es eine gewisse Zeit, bis die Phasen durchlaufen sind und auf ingenieurwissenschaftliche Art und Weise ein neues System entstanden ist. Wir werden darauf noch in 5.3 eingehen. An diesem Problem setzen agile Projektvorgehen an. Sie sollen zu schneller auslieferbaren Funktionalitäten (dann freilich weniger) und damit zu schneller Rückmeldung durch den Anwender führen.

2.1.2 Agile Projektvorgehen

Der Begriff Agilität oder agiles Projektvorgehen beinhaltet drei verschiedene Aspekte:

(1) Das Agile Manifest als eine Art Geisteshaltung. Hierum rankt sich in (vermutlich allen) Handbüchern zu Agilität die Geschichte eines Treffens der soge­nannten Gründerväter agilen Projektvorgehens in Utah (USA), bei dem zum einen der Begriff Agilität geprägt und zum anderen jenes Agile Manifest verabschiedet und erstmals unterzeichnet wurde. Hierin ist festgehalten, was Grundlage des Denkens und des Handelns in agilen Projekten sein soll. Was im Agilen wichtig(er) ist, for­mulieren die Autoren Beck et al. (2001):

Wir erschließen bessere Wege, Software zu entwickeln, indem wir es selbst tun und anderen dabei helfen. Durch diese Tätigkeit haben wir diese Werte zu schätzen ge­lernt:

Individuen und Interaktionen mehr als Prozesse und Werkzeuge. Funktionierende Software mehr als umfassende Dokumentation. Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung. Reagieren auf Veränderung mehr als das Befolgen eines Plans.

Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden, schätzen wir die Werte auf der linken Seite höher ein.

Diese Formulierungen lassen Raum für unterschiedliche Auslegungen, insbesondere sind die Komparative nicht quantifiziert, es ist also nicht klar, wie viel Dokumen­tation denn noch erlaubt oder richtig im Sinne dieser Vorgaben ist, oder wie die Zusammenarbeit mit dem Kunden die Verträge ersetzen soll oder kann. Mit anderen Worten: Das agile Manifest bildet eine durchaus auslegungsfähige Grundlage (und so ist es auch gedacht) dessen, was man denn nun tun soll. Etwas ausführlicher sind die (2) Agilen Prinzipien. Aus diesen insgesamt zwölf Prinzipien greifen wir hier diejenigen heraus (siehe Beck et al. (2001)), auf die sich unsere Interviewpartner beziehen.

- Heiße Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.
- Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne.
- Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbst­organisierte Teams.
- In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann, und passt sein Verhalten entsprechend an.

Was nun wie getan werden soll, ist in einem (3) Vorgehensmodell definiert. Hier werden zum Beispiel Rollen (mit ihren Aufgaben), Events und Artefakte festgelegt. Es gibt verschiedene agile Vorgehensmodelle (z.B. eXtreme Programming (XP), Cry­stal, KANBAN, Scrum) - eine Zusammenfassung findet sich etwa in Anwer et al. (2017)). Dasjenige, das sich derzeit durchgesetzt hat und auch von allen Interview­partnern referenziert wird, ist Scrum, weswegen wir dieses Modell hier ganz kurz beschreiben möchten.

Das Scrum-Vorgehen sieht zunächst eine zentrale Rolle vor, den Product Owner. Das ist diejenige Person, die genau weiß, was wann und in welcher Form benötigt wird und mithin implementiert werden muss. Hierzu füllt der Product Owner ein Pro­duct Backlog mit User Stories. Dies sind Anforderungen an das zu implementierende System in der Form:

Ich (Name) als (Rolle) möchte (Funktionsbeschreibung), damit (Grund).

Der Product Owner (PO) sortiert all seine User Stories (die er in Zusammenarbeit mit Anwendern erstellt hat) nach Priorität und stellt diejenigen, die im nächsten Sprint (ein Entwicklungszyklus von 1-8 Wochen) vom Entwicklungsteam („Scrum-Team“) implementiert werden sollen, diesem Team im Sprint Planning vor. Dort werden Fragen zum Produkt geklärt und das Team in die Lage versetzt, im nächsten Sprint diese User Stories zu entwickeln. Hierzu werden die User Stories (zu denen sich das Team für diesen Sprint „committed “) in ein Sprint Backlog übernommen und in Tasks (kleinere Arbeitseinheiten) heruntergebrochen. Innerhalb des Sprints trifft sich das Team täglich für etwa 30 Minuten zu Daily-Scrum-Terminen, in denen jeder kurz über das Erreichte und mögliche Probleme berichtet. Für die Moderation dieses Termins, die Einhaltung der Methodik und die Lösung der Probleme ist ein Scrum Master verantwortlich, dessen Aufgabe es ist, die Methodik von Scrum sicherzustellen und im Projekt umzusetzen. Zum Ende des Sprints stellt das Team dem Product Owner das Ergebnis - das Potentially Shippable Increment (PSI) - vor. Dieses PSI soll einen direkten Mehrwert für den Nutzer erbringen und auch zum Einsatz kommen, sofern der Product Owner damit zufrieden ist und das PSI im Sprint Review abnimmt. Anderenfalls werden durch den Product Owner weitere User Stories in das Backlog geschrieben und diese für die nächsten Sprints eingeplant. Im Anschluss führt der Scrum Master eine Retrospektive mit dem Team durch, in der es vor allem um die Zusammenarbeit im Team und mögliche Verbesserungsmöglichkeiten geht. Darauf folgen direkt das nächste Sprint Planning und der nächste Sprint.

Mit anderen Worten - Scrum besteht aus:

- den Events: Sprint Planning, Sprint, Daily Scrum, Sprint Review und Retro­spektive.
- den Rollen: Product Owner, Scrum Master und dem Team.
- den Artefakten: Product Backlog (und zusätzlich noch dem Sprint Backlog - das sind die User Stories, die vom Team in einem Sprint umgesetzt werden sollen), Potentially Shippable Increment

Die Theorie von Scrum besteht aus weiteren Ausführungen zu den jeweiligen Events, Rollen und Artefakte. Mit der obigen kurzen Beschreibung des Scrum Zyklus’ sind jedoch die wesentlichen Verwendungen, so wie wir sie in dieser Arbeit benötigen, beschrieben.

Damit haben wir in aller Kürze diejenigen Begrifflichkeiten eingeführt, die wir für diese Arbeit benötigen, und können jetzt einen Blick auf soziologische Grundbegriffe für unsere Arbeit werfen, um diese dann in einen Zusammenhang mit den Vorge­hensmodellen und ihren Prinzipien zu bringen und zu diskutieren.

2.2 Soziologische Grundlagen und Betrachtungen

Es gibt einige Denkweisen und Impulse, die uns in dieser Arbeit leiten und immer wieder anregen, gewisse Ergebnisse zu reflektieren. Wir haben einige Aspekte oder Phänomene ausgemacht, die sich mit der Theorie Luhmanns erklären, vielleicht so­gar verstehen lassen. In diesem sehr kurz gehaltenen Abschnitt möchten wir auf wesentliche Ideen eingehen und erste Betrachtungen anstellen, auf die wir dann in den Ergebniskapiteln (die auf empirischer Basis erarbeitet wurden) zurückkommen werden.

2.2.1 Funktionale Systeme und Organisationen - eine sehr kurze Einführung

Wir geben hier einige wenige Kerneinsichten der Theorie struktureller Differenzie­rung und ihren Zusammenhang mit Organisationen wieder. Wir folgen in der Dar­stellung, Begrifflichkeiten und den Ansichten in Nassehi (2005), Nassehi (2011) und Luhmann (1980) und setzen uns nicht mit vielen weiteren möglichen Fragestellun­gen auseinander (wie etwa der nach alternativen Beschreibungsmöglichkeiten). Auch haben wir nicht den Anspruch einer vollständigen Beschreibung - das ist für diese Arbeit nicht erforderlich, wäre ein zu umfangreiches Unterfangen, und zudem kön­nen dies andere viel besser. Hier können wir etwa auf die obigen Quellen oder eine hilfreiche Auswahl verschiedener Veröffentlichungen unter Luhmann (2001) verwei­sen. Stattdessen beschreiben wir grundlegende Ideen und einige zentrale Begriffe, um dann einige Erkenntnisse herausgreifen zu können, die für unser Thema impulsge­bend sind oder Ansätze zur Übertragung auf die Fragestellung dieser Arbeit geben können. Das reicht für unsere Zwecke, geht es uns doch um Impulse, Erklärmöglich­keiten sowie verschiedene Blickwinkel sowohl für die Vorgehen in Projekten als auch deren Wandel.

Wir beginnen mit der Einführung wesentlicher Begrifflichkeiten, die wir im weiteren nutzen werden. Ein (soziales) System verstehen wir als Ergebnis der Interaktionen und der Kommunikation seiner einzelnen Teile und seiner Abgrenzung zur Umwelt, oder anders gewendet: Wir definieren rekursiv das System als Differenz zwischen System und Umwelt. Diese Kommunikation erhält das System und findet (daher) kontinuierlich statt. Die Kommunikation hat also eine zentrale Bedeutung, mehr noch, sie ist die Grundlage für das Bestehen und sich Reproduzieren eines Systems: Wenn sie abreißt, stirbt das System, durch Kommunikation hält sich das System am Leben, verändert sich, wird gestaltet. Diese Kommunikation geschieht gleichzeitig, parallel an verschiedenen Stellen, die sich gegenseitig beeinflussen, bedingen, auf­einander aufbauen, folgen. Es gibt damit zum einen keinen stabilen Systemzustand, der festgehalten werden kann oder von Dauer ist. Zum anderen ist Kommunikation damit nichtdeterministisch - das Resultat ist also nicht eindeutig vorhersagbar. Ein Impuls, ein Anstoß zu Kommunikation verläuft sprunghaft und nicht steuerbar. Und es gibt keine hierarchisch übergeordnete Instanz, die führend eingreift und Ergeb­nisse deterministisch und gewollt beeinflussen, ja vollständig kontrollieren kann. Das heißt, es kann nicht eindeutig gesagt werden, was bei bestimmten Interaktionen im Gesamtsystem zu erwarten ist. Umgekehrt heißt es auch, dass für einen Systemzu­stand nicht mehr genau und vollständig rekonstruierbar (und auch reproduzierbar) ist, wie es zu diesem kam, und welche Interaktionen genau hierzu geführt haben.

Die Abgrenzung des Systems jeweils zu dessen Umfeld führt zu einer Gliederung eines Gesamtsystems in verschiedene Teilsysteme (also jeweils Systeme und deren Umwelt), die sich jeweils gegen ihre Umwelt abgrenzen, abgeschlossen gegenüber ih­rer Umwelt sind. Damit meinen wir nicht, dass es keine Interaktion zwischen System und Umwelt gibt, sondern, dass diese Umwelt für das System selbst abstrakt, verein­fachend angenommen werden kann, mit gegebenenfalls definierten Schnittstellen zum System. Das gibt dem System die Möglichkeit, von der Komplexität und der Kommu­nikation des Gesamtsystems zu abstrahieren und seine eigene Kommunikation, seine eigene Logik auszuprägen. Was bedeutet (Nassehi bezieht sich hier auf Luhmann (1995)), dass (soziale) Systeme sowohl ihre eigenen Probleme hervorbringen als auch die zugehörigen funktionalen Lösungen, hierzu ihre eigenen Ressourcen nutzend (wes­wegen wir auch von funktionalen Systemen sprechen können) - also aus sich selbst heraus, aus (und mit) der dem System eigenen Kommunikation. Diese Abgrenzung ermöglicht eine Spezialisierung, eine Vereinfachung innerhalb des Systems, indem die Kommunikation eben von der Umwelt abstrahiert und nicht diese immer und voll­ständig mit einbeziehen muss. Dieser Entlastungswunsch, diese Vereinfachung führt zu unterschiedlichen Systemen mit jeweils eigenen Logiken und Aufgaben. Mit ande­ren Worten, in Reaktion auf die Komplexität eines Gesamtsystems zergliedert sich dieses in verschiedene, spezialisierte Teilsysteme.

Eine Gesellschaft ist ein (das) Beispiel eines sozialen (Gesamt-) Systems. Innerhalb der einzelnen Teile des Gesamtsystems bestehen jeweils unterschiedliche Logiken und Denkweisen: Wenn wir von einer Gesellschaft mit Teilsystemen wie Wissenschaft, Wirtschaft und Kunst reden (um nur wenige zu nennen), sind dies also entsprechend die Logik des Nachdenkens über Wahrheitsfragen, ökonomisches Denken und die Beschäftigung mit Fragen der Schönheit und Inspiration. Mit anderen Worten: Die Systeme unterscheiden sich funktional (hinsichtlich ihrer Funktionen, Fragestellun­gen, Denkweisen). Genau darin (in der funktionalen Differenzierung) liegt ihre Stärke und die Möglichkeit der Optionssteigerung - die Grundlage und Möglichkeit, inner­halb des eigenen Systems, der eigenen Logik, ohne Fragestellungen anderer Logiken zu optimieren bis hin zur vollständigen Ausdifferenzierung, also einem Zustand, in dem die zu beantwortenden Fragen nur noch aus sich selbst heraus entstehen und beantwortet werden.⁵ Das Gesamtsystem optimiert sich durch Verteilte Intelligenz, also die Verteilung von Wissen, Praktiken, Denkweisen und der Optimierung inner­halb der einzelnen funktionalen Systeme, die das Gesamtsystem darstellen. Um zu optimieren, sind die (Teil-) Systeme in ihren Logiken getrennt, interagieren jedoch miteinander - diese Schnittstellen müssen die Übersetzungsleistungen von der Logik des einen in die Logik des anderen Teilsystems erbringen und benötigen mithin eine eigene Intelligenz. In der Gesamtbetrachtung haben wir damit innerhalb eines Sys­tems Teilsysteme, mit ihrer eigenen Kommunikation, und sich durch diese erhaltend und von der Umwelt abgrenzend. An den Schnittstellen zur Umwelt entsteht eine Abstraktion, eine Vereinfachung der Umwelt, die nicht in der gesamten Komplexität in die Kommunikation innerhalb des Systems einbezogen werden muss. Organisatio­nen können an den Schnittstellen der Systeme agieren, können Logiken verbinden und für sich in Einklang bringen. (Vollständige) Ausdifferenzierung eines Systems geht (beobachteterweise) mit der Entstehung von Organisationen einher. Jedenfalls existieren Organisationen, und wir betrachten diese sowohl als normal, als auch als notwendig.

Organisationen können als eine Instanz (im technischen Sinne) dieser Systembe­schreibung aufgefasst werden - Luhmann (Luhmann (1978)) formuliert, dass Or­ganisationen Teilsysteme (funktionaler) Systeme sind. Diese haben aber spezielle Ausprägungen. So ist es Organisationen möglich, im Wesentlichen über die Bedin­gungen der Mitgliedschaft (oder Teilhabe) zu entscheiden, ebenso wie über die ei­genen Praktiken und Handlungsweisen. Organisationen bilden sich innerhalb von Funktionssystemen mit ihren Eigenarten heraus (etwa unterscheidet sich die Kirche als Organisation des funktionalen Systems „Religion“ von einem Unternehmen als Organisation im „ökonomischen System“). Mehr noch: Ohne Organisationen können wir uns das funktionalen System schwer vorstellen (Was wäre das funktionale System „Kunst“ ohne Museen, Galerien, ...?). Sie können jedoch offenbar funktionale Syste­me koppeln, ohne diese aufzulösen oder zu verschmelzen. So muss auch in Galerien Geld verdient, vielleicht Politik betrieben oder ein Erziehungsauftrag wahrgenom­men werden. Es treffen hier also verschiedene Logiken aufeinander. Nassehi (2005) führt ein weiteres (für die Betrachtung agiler Organisationen interessantes) Merkmal aus:

Organizations are able to emerge as a special form of languid stability by institutionalizing transparent roles and positions, redundant procedures, and repeatable practices. (Nassehi (2005), Seite 8)

Mit anderen Worten: Rollen, damit verbundene Aufgaben und Verantwortungen so­wie Vorgehensbeschreibungen sind wesentlich für Unternehmen, kennzeichnen diese, tragen (jedoch) auch zu einer gewissen Stabilität im Unternehmen bei. Auf der einen Seite ist das effizient, weil eingeübt, klar verständlich und eben nicht diskussionsbe­dürftig. Auf der anderen Seite führt die Trägheit dieser Stabilität dazu, dass große Aufwendungen notwendig sind, um diese aufzubrechen. Nichtdestotrotz werden ak­tuell auch Organisationsmodelle beschrieben, die zwar nicht auf Rollen, wohl aber auf klassische Hierarchien verzichten sollen. Treibende Kraft sind hier agile Projekt­vorgehen, die den Anspruch erarbeiten, sich auf Organisationen auszuweiten oder andere Organisationsformen zu benötigen.

Diese Arbeit betrachtet eine Momentaufnahme des Übergangs einer Organisations­form von Projekten mit ihren Rollenmodellen, Verantwortlichkeiten, Aufgabenver­teilungen und Artefakten in eine andere und liefert einen Ausblick auf den noch zu vollziehenden Übergang der Organisationen auf institutioneller Ebene. Wir haben in diesem Unterabschnitt einige Bausteine oder Konzepte der Systemtheorie ange­rissen - die (funktionale) Differenzierung von Systemen in Teilsysteme mit eigenen Logiken und dort möglichen Optionssteigerungen, die fehlende Durchgriffsmöglich­keit mit einem klaren Durchsetzen im gesamten System sowie die Intelligenz und die Kommunikation an den Schnittstellen etwa mithilfe von Organisationen. Im Hinblick auf unsere Fragestellung werden wir im nächsten Unterabschnitt diese Konzepte ver­tiefen und schlaglichtartig einzelne Aspekte herausgreifen und beleuchten. Das heißt, wir werden Erkenntnisse dieser Theorie (mit den Grundlagen aus diesem Unterab­schnitt) auf den Wandel der Vorgehensmodelle in IT-Organisationen anwenden und hierüber reflektieren.

2.2.2 Eine Betrachtung der Vorgehensmodelle

James (1977) verwendet in seinem Buch (und in seiner Vorlesung) für die Verbin­dung von - grob gesagt - Theorie und Praxis, die Metapher eines Glases mit Wasser, in welches man schaut: Das Wasser stellt die sinnliche Welt der Tatsachen dar, die darüber befindliche Luft die Welt der abstrakten Ideen. Nun könne der Mensch nur - wie ein Fisch im Wasser - in der sinnlichen Tatsachenwelt leben und Sinneseindrücke sammeln. Freilich ist ihm dies nur möglich durch Aufnahme von Sauerstoff aus der Luft. Gelegentlich schwimmt der Mensch an die Oberfläche und kehrt mit neuer Kraft und Inspiration (und Direktive) zurück. Ähnlich „pragmatisch“ gehen wir in dieser Arbeit vor. Wir arbeiten stark mit den Sinneseindrücken, mit dem tatsächli­chen Erleben der Befragten, die wir in Interviews erfragen, und arbeiten Phänomene und Beobachtungen heraus, lassen uns aber immer wieder von Theoriekomplexen in den Schlüssen inspirieren (und auch beeindrucken). Mit anderen Worten, wir lassen Theorien und Gedanken auf unsere Beobachtungen wirken oder wenden diese dar­auf an. In diesem Abschnitt möchten wir dies mit einigen der Ideen der Theorien sozialer Systeme tun. Wir nehmen hierzu Gedanken auf und wenden sie als Impulse auf unsere Fragestellung an. Hier bauen wir auf den Grundlagen des vorangegange­nen Abschnitts auf, führen aber an einigen Stellen auch ein paar weitere Ideen (im Wesentlichen aus denselben Quellen) ein.

Effizienz in Kommunikation und Projekten; Entscheidungen: Wir haben oben gesehen, wie wesentlich Kommunikation zum Erhalt sozialer Systeme ist. Kom­munikation erhält sich selbst aufrecht, gerade weil diese nicht auf eine vollkommene Kongruenz des Erlebens aufsetzen kann, weil jede Kommunikation im Gegenüber eine andere Wahrnehmung erzeugt (siehe auch Luhmann (1981a) und Luhmann (1975)). Weil das von Person x Gesagte von Person y in den eigenen Erfahrungshorizont ein­geordnet und ausgelegt wird, wird die Information in keinem Fall lediglich dupliziert (auch nicht bei etwaigen Nachfragen), sondern nimmt eine andere Gestalt an, manch­mal in Nuancen, zuweilen vielleicht sogar im absoluten Gegenteil des Gesagten. In Organisationen gibt es, wie oben gesehen, einen Lösungsversuch: feststehende Rollen mit ihren Aufgaben und Verantwortlichkeiten. Ist über einen langen Zeitraum klar, was eine fachliche Chefdesignerin tut, wie sie in verschiedenen Situationen reagiert und entscheidet, entsteht in Projekten etwas mehr an Deckungsgleichheit in den jeweiligen Erfahrungen. Es wird begründbar (und das oftmals schon im Vorfeld), wie eine Chefdesignerin reagiert, indem sie ihre Rolle lebt und erwartbar ausführt. Feste Rollen in Projekten sorgen für eine gewisse Sicherheit im Erleben: Ein Test­manager wird bei Überschreitung einer gewissen Fehlerzahl die Auslieferung eines Softwarereleases ablehnen, eine Projektleiterin kann jedoch anders entscheiden und (aus verschiedenen Gründen) dennoch die Auslieferung anordnen. Dieses gemeinsa­me Verständnis, dieses gemeinsame Erleben ist Grundlage von effizientem Handeln innerhalb von Projekten. Ein neues Vorgehen in einem Projekt muss also (wenn wir einen Blick auf Effizienz legen - und dies ist ein Argument agiler Vorgehen!) nicht nur aus sich selbst heraus effizienter sein, es muss auch eine Antwort auf die effiziente Überwindung der vorhandenen Strukturen liefern - wenn es ein effizienteres Vorge­hen gibt, muss man eben auch dorthin kommen, sind die Aufwände der Änderung zu hoch, dann lohnt diese eben doch nicht. Dies ist ein Grund, warum in dieser Ar­beit gerade dieser Übergang von dem einen Vorgehen in ein anderes interessant ist, wobei es uns nicht im Allgemeinen um die Frage geht, wie ein solcher Übergang ge­lingen kann (auch wenn dies interessant ist), sondern was tatsächlich (auf der Ebene des Erlebten) passiert, vor allem, wenn man sich aus theoretischer Perspektive über diesen Übergang kaum Gedanken gemacht hat. Dieses unterschiedliche Erleben ist auch ein Grund, warum diese Arbeit im weiteren Verlauf (nach diesem einführenden Kapitel) empirisch angelegt ist. Sie soll auch zeigen, welche Kommunikationsschwie­rigkeiten es geben kann, wie unterschiedlich verschiedene Dinge erlebt oder eben auch bewertet werden, wenn es um einen Übergang, ja einen Umbruch geht.⁶ Es gibt noch weitere Gründe für ein Interesse am Übergang der Vorgehensmodelle: Luh- mann (siehe Luhmann (1981b)) weist, wieder in Bezug auf Kommunikation, auf zwei weitere Phänomene hin - zum einen die neben der (aufgrund der oben erwähnten Hinderungsgründe) ohnehin nicht möglichen Kongruenz von Erlebenshorizonten und damit Wahrnehmung und Auslegung der Kommunikationsinhalte auf die Tatsache, dass Konsens gerade Kommunikation beendet (Luhmann (1981b), S. 19):

Konsens ist das télos der Kommunikation - auch in dem Sinne, dass Konsens die Kommunikation beendet, da sich nach dem Konsens Kom­munikation nicht mehr lohnt.

Mit anderen Worten, zum Erhalt der Kommunikation trägt bei, dass es die kleineren und größeren Verwerfungen in der Auslegung und Bewertung der Vorgehensmodelle gibt. Auch, dass es eben kleinere und größere Veränderungen in den Modellen gibt: die graduellen Anpassungen an klassischen wie agilen Modellen, wie eben auch den größeren Wandel von klassischen hin zu agilen Modellen. Dies kann Projekte aufrecht­erhalten (durch eben die Neugestaltung), dies kann bestimmte Gefühle (Motivation, Identifikation, Veränderungsfreude, Gestaltungswillen) aufrechterhalten. Auch dies werden wir in dieser Arbeit betrachten. Im gleichen Aufsatz stellt Luhmann fest, dass die Entscheidung für etwas bedeutet, zu kontinuieren oder aber große Auf­wände zum Abbruch hinzunehmen. Dies spielt in unsere obige Betrachtungen der Effizienz. Die Entscheidung zu agilen Vorgehensweisen war mühsam und ein länge­rer Prozess, wie wir oben gesehen haben. Ab einem gewissen Zeitpunkt scheint er jedoch nur noch mit viel Aufwand in den jeweiligen Projekten umkehrbar, die „Agili- sierung“ der Projekte demnach kaum aufzuhalten und auch argumentativ schwer zu begründen zu sein. Wir werden in der Tat feststellen, dass die Entscheidung für agile Projektvorgehen sowohl in den IT-Systemhäusern als auch bei deren Kunden kaum umkehrbar erscheint. Diese Nichtumkehrbarkeit wird in dieser Arbeit eine Rolle spie­len - in der Annahme dieser durch die beteiligten Projektmitglieder, wie auch in dem Umgang hiermit (siehe etwa Abschnitt 8). Jedoch ist diese Entscheidung keine ei­gene, persönliche Entscheidung der Projektmitglieder. Wie wir oben gesehen haben, sind Hierarchien und Rollen in Organisationen wesentlich. In Organisationen werden Entscheidungen, die alle Projekte und alles zukünftige Handeln betreffen (also „stra­tegisch“ sind), nicht von den Projektmitgliedern getroffen. Formal liegen diese meist noch streng hierarchisch bei einer Geschäftsleitung. Nassehi (Nassehi (2011), S. 223) weist jedoch auch darauf hin, dass Entscheidungen nicht entschieden werden, sondern geschehen. Das gilt auch für die Agilität in Unternehmen. Eine offizielle Entscheidung (im Sinne einer Erklärung und einem Bekenntnis hierzu) für agiles Vorgehen gab es zu einem Zeitpunkt, da kaum ein Aufhalten möglich schien. Entwicklungen lassen sich also nicht aufhalten, sie passieren durch den Einfluss ganz verschiedener Phänomene. Das Narrativ des agilen Projektvorgehens sieht als Begründung für die Einführung agiler Projektvorgehen den Kundenwunsch nach schnellem Feedback und schnellen neuen Features bzw. Korrekturen vor, den Wunsch von Menschen nach Selbstorga­nisation (mit der Geschichte der Effizienzsteigerung durch mehr Motivation durch Selbstorganisation im Team) und schließlich die gesellschaftlichen Entwicklungen im Allgemeinen vor. In jedem Fall (sei es, weil eine Geschäftsleitung entschieden hat, oder sei es eher ein „geschehen Lassen“) haben wir keine Situation, in der betrof­fene Menschen über einen gewissen Zeitraum hinweg nachgedacht und dann - alle Informationen bewertend - gemeinsam entschieden hätten, dass dieses oder jenes Vorgehen für die nahe Zukunft die richtige Wahl ist. Es ist also nicht die Situation, in der eine Entscheidung ein Nachdenken über die Situation selbst und ihre Folgen beendet, wie Nida-Rümelin bemerkt (siehe Nida-Rümelin (2016), S. 148):

Eine Entscheidung bringt eine, wie auch immer rudimentäre, Deliberation zum Abschluss. Sie legt etwas fest. Und wenn das de facto nicht festliegt, dann war es keine Entscheidung.

Das hat mehrere Gründe: es können gar nicht alle relevanten Informationen vor­liegen, diese werden zudem unterschiedlich bewertet (wie wir auch in dieser Arbeit sehen werden, gibt es viele Phänomene, die der eine als positiv betrachtet, die ande­re als Grund, sich genau gegen etwas zu entscheiden) und beides ist zudem zeitlich abhängig (heute werden Dinge anders gesehen als gestern oder morgen). Dennoch erkennen wir einen Weg, der eingeschlagen wurde und also doch mindestens hier­für eine Entscheidung vorgelegen hat. Das bedeutet, dass, wie Luhmann bemerkt, ein Abbruch (also etwa eine Rückkehr zu klassischen Vorgehensweisen) aufwändig (in vielerlei Hinsicht), wenn nicht gar unmöglich wäre, jedoch eben nicht, dass das Nachdenken über die Richtigkeit dieser Entscheidung und auch mögliche andere We­ge abgeschlossen ist. Wir werden in dieser Arbeit sehen, dass Menschen sehr viel über richtige Vorgehensmodelle, geeignete theoretische Ansätze für Projektdurchführun­gen und ihre eigenen Aufgaben in neuen Projektvorgehen nachdenken - im Projekt selbst, oder auch außerhalb der Projekte.

Verteilte Intelligenz in Projekten: Nassehi (Nassehi (2017)) konstruiert für das Verständnis von Interaktionen in Systemen und für verteilte Intelligenz die Metapher von verteilten IT-Systemen, die hier, also in einem IT- Kontext, in doppelter Bedeu­tung passend ist. Wir nutzen hier (etwas zweckentfremdet übertragen) ein ähnliches Bild im Wirken und Übertragen von Abschnitt 2.2.1 auf kleinere Einheiten (vielleicht Suborganisationen), also in der Betrachtung von Vorgehensmodellen der Software­systementwicklung. Das Wasserfallmodell stellt ein schönes Bild verteilter Intelligenz dar. Jede einzelne Gruppe denkt hier in ihren spezifischen Fragestellungen, in eige­nen Methoden und Lösungen. Es gibt einen klaren Aufgabenbereich und eine klar definierte Schnittstelle zwischen den einzelnen Domänen:

- Anforderungingenieure denken in Fragen von Kundenwunsch und von effizien­ten und effektiven Prozessen. Zuweilen können sie sich vollständig frei machen von Fragestellungen der Implementierung oder der Testbarkeit. Ihre Methoden sind darauf ausgerichtet, die Kundenwünsche zu verstehen, die Anforderungen redundanzfrei und kohärent aufzuschreiben, perfektioniert bis dahin, dass sie eigentlich viel besser ohne anschließende Implementierung auskommen und zu­weilen auch vergessen, dass ihr Artefakt - das Lasten- oder Pflichtenheft (und damit die Schnittstelle zum Spezifikateur) kein Selbstzweck ist.
- Spezifikateure denken in Fragen korrekter Spezifikation, im richtigen Ausfül­len von Datenelementekatalog, Schnittstellenbeschreibung, Datenmodell, Be­nutzerschnittstellenbeschreibung usw. (also daran, dass jeder Inhalt an genau der richtigen Stelle in der richtigen sprachliche Form dargestellt wurde). Ihre Logik ist die einer eleganten, ausgefeilten und korrekten Beschreibung. Diese Spezifikation ist jedoch eigentlich die Schnittstelle zur Implementierung.
- Entwickler denken in Fragen von guter Architektur, geeigneter Technologie­auswahl. Ihre Logik ist die Schönheit und Eleganz der Implementierung. Ihre Schnittstelle zu den anderen Domänen ist die fertige Implementierung.

Die Rollen sind trennscharf abgezirkelt und geben die Möglichkeit, die eigene Profes­sion bis zur Perfektion zu verbessern. Für diese Vorgehensweise ist eine Welt ideal, in der Menschen genau eine Aufgabe vollkommen erfüllen möchten, sich selbst fast grenzenlos spezialisieren können und wollen, und die Interaktion und die Kommuni­kationsformen mit anderen sehr genau geregelt sind. Im Extremfall (oder Idealfall) muss gar nicht anders als über die Artefakte kommuniziert werden. Denn da „steht ja schon alles drin“. Es gibt nur ein Problem: Es muss gemeinsam ein IT-System gebaut werden. Es sollte also auf ein Ziel (so unterschiedlich dessen Wahrnehmung auch sein mag) hin gearbeitet werden (so wie in der Metapher der verteilten Syste­me bei Nassehi (2017) auch das Gesamtsystem am Ende funktionieren muss - und das deterministisch). So gern die Fachdesignerin es auch anders sähe, und so sehr sie sich auch in der eigenen Methodik ihr Bild zurechtlegen kann, am Ende ist all ihr Wirken sinnfrei, wenn nicht eine Entwicklerin all ihre beschriebenen Dokumente in ein lauffähiges System umsetzt. Und so gern diese Entwicklerin auch unbehelligt von fachlichen Fragen und Notwendigkeiten die beste Architektur nach dem aktuells­ten und spannendsten Stand der Technik umsetzen würde, so wertfrei bliebe diese Arbeit ohne eben die fachliche Analyse. Dennoch, die Rollen und Aufgaben sind klar und können sich innerhalb ihrer eigenen Domäne noch weiter ausdifferenzieren, also spezialisieren (Schnittstellenverantwortliche, die sich nur um die Spezifikation der Schnittstellen kümmert, eine Testdatenverantwortliche und in der Domäne „Ent­wicklung“ dann reine Backend-, Frontend oder Datenbankexperten). Damit erreicht man höchste Effizienz - überwacht von einem Projektleiter, der weisungsbefugt ist, selbst zur Arbeitsweise und zu den Zeitpunkten der Erstellung der Artefakte (zu­mindest in der Theorie), der also durchgreifen kann (im doppelten Sinne). Agile Vorgehensweisen ändern diese Sichtweise. Es gibt darin zunächst keine Hierarchie mit verschiedenen Ebenen, auf denen die eine Mitarbeiterin der anderen unterge­ordnet ist, sondern ausschließlich Rollen und damit verbundene Aufgaben. Das Ziel der Effizienzsteigerung liegt in agilen Projekten beim Team selbst (und dem Mes­sen an sich selbst) und nicht bei einem Projektleiter oder Manager. Das Team soll in der Theorie agiler Projektvorgehen (gegeben der User Stories durch den Product Owner) selbstbestimmt arbeiten, also innerhalb eines Sprints selbst entscheiden, wel­ches Teammitglied zu welchem Zeitpunkt welche einzelnen User Stories bzw. deren Tasks bearbeitet, und wie dies in der technologischen Umsetzung ausgeführt wird (dies betrifft beispielsweise Entscheidungen zur Architektur, aber auch der Nutzung verschiedener Technologien). Ein agiles Team in einer Organisation soll eben ge­rade nicht sein, worauf Nassehi (2005) (auf Coleman referenzierend) hinweist: eine asymmetrische Gesellschaft, in der Individuen ihr Potenzial zur Selbstbestimmung verlieren. Mit anderen Worten: Durch die Änderungen in den Vorgehensmodellen ändert sich etwas an der bisherigen Logik und den Selbstbeschreibungen zunächst der Projektorganisationen und (mit einem leichten zeitlichen Versatz) auch etwas an den institutionellen Organisationen selbst. Wissen, Logiken und Praktiken wer­den nun neu verteilt, die Schnittstellen neu und völlig anders definiert. Was diese Transformationen in den beteiligten Personen bewirken, werden wir in dieser Arbeit untersuchen.

Theorietypen und die Welt der Möglichkeiten: Luhmann (siehe etwa Luh- mann (1981b)) unterscheidet zwischen zwei Theorietypen, dem einen, der eine Ord­nung, etwas Gegebenes voraussetzt und die Abweichungen davon problematisiert (also das Beispiel des Augenarztes, der den Augeninnendruck aller Patienten misst und alle Patienten, deren Augeninnendruck außerhalb des 5. bzw. 95. Perzentils liegt, als krank und damit behandlungsbedürftig klassifiziert). Und dem anderen, der die Normalität als unwahrscheinlich auffasst. Es ist in der Denkweise dieses Theorie­typs unwahrscheinlich, dass eine Ordnung aus apriorischen Gründen entsteht oder zustande kommt - weil sie aber da ist, wird sie als normal empfunden. In der Denk­weise der Systemtheorie passt dies: Systeme entwickeln sich durch das Einstellen auf ihre Umwelt, und nicht auf die eigene Perfektion hin. Es passt jedoch auch zur Agilität in Projekten: Diese ist die Reaktion auf verschiedene Einflüsse - der Wan­del im Privaten, der eher kurze Aufmerksamkeitsspannen fördert, der Wunsch nach Partizipation auf Kundenseite, die Forderung nach Identifikation usw. Gesellschaft­licher Wandel wirkt sich auf Organisationen aus. Agilität in Unternehmen ist nicht denkbar ohne eine Gesellschaft, die schnelllebig scheint. Damit meinen wir, dass zur agilen Erzählweise gehört, dass sich Berufliches auf die Ansprüche im Privaten ein­stellen muss, und dass Menschen im Privaten derzeit eine ganz andere Welt als die des langen Nachdenkens und Designs erleben.⁷ ) Mit anderen Worten - hätte vor 20 oder 30 Jahren jemand ein Projektvorgehen, so wie es heute als normal empfunden wird, prognostiziert (und das ist durchaus getan worden), so wäre der Glaube an das Durchsetzen eben jenes Vorgehens sehr gering gewesen. Umgekehrt ist in der Retrospektive heute klar, dass es eine derartige Entwicklung eigentlich hat geben müssen - jedenfalls können hierfür einige Begründungen gefunden werden. Der erste Theorietyp setzt ein teleologisches Weltbild voraus. Wenn von etwas Perfektem oder Richtigem ausgegangen wird und die Defizite an der Messung daran erkannt werden (und nach entsprechenden Verbesserungen gefragt wird), dann muss vor allem eines bekannt sein: das Perfekte und Richtige. Luhmann weist uns hier auf die Existenz von Halbordnungen hin. Das bedeutet, es gibt in einer Relation (zum Beispiel „bes­ser als“) vergleichbare Elemente (ich kann zum Beispiel sagen, dass ein Team von 5 Personen effizienter kommunizieren kann als ein Team von 50 Personen), aber es gibt eben auch unvergleichbare Elemente. Er selbst nutzt (siehe Luhmann (1981b)) die höchste Metapher: Ein allmächtiger Gott schafft eine perfekte Welt (die per­fekt ist, weil sie göttlich ist). Weil er aber allmächtig ist, könnte diese Welt auch anders aussehen (und dennoch perfekt, weil göttlich sein). Mit anderen Worten, es gibt immer Dinge, die könnten eben so sein, aber auch anders (und wären damit nicht schlechter). Das mag auf der einen Seite beunruhigend sein, denn, wie Luh- mann feststellt, ist die Auswahl stets doppelt kontingent - zunächst ist der Raum der Möglichkeiten zu wählen und dann aus diesem die Möglichkeit selbst. Es ist in unserer Fragestellung also zunächst der Raum der möglichen Vorgehen aufzuzeigen. Wir werden sehen, dass schon dies nicht möglich ist, da wir zukünftige Entwicklun­gen kaum voraussagen können und unser Denken letztlich genau auf die bekannten Modelle (und Kombinationen hiervon) beschränkt ist. Auf der anderen Seite führt diese Einsicht jedoch auch zu einer gewissen Ruhe (wie wir auch in den Ergebnis­kapiteln sehen werden), heißt es doch, dass in manchen Fällen die eine Wahl so gut ist wie die andere. Halbordnungen haben den Vorteil, dass die Entscheidung für ein Vorgehensmodell die Situation nur anders gestaltet, aber eben in der gewählten Me­trik nicht besser oder schlechter. Der Aufwand der Umentscheidung ist jedoch sehr hoch. Mit anderen Worten, eine vom Hergebrachten abweichende Wahl bedeutet für die nahe Zukunft eine Einschränkung. Wenn es ein zentrales Ergebnis dieser Arbeit gibt, so ist es diese Einsicht der Menschen: Projekte, die ehemals auf die eine Art abgewickelt wurden, werden nun eben auf eine andere Art abgewickelt. Das ist mög­lich, und das lässt sich zunächst auch nicht (oder nur mit einem großen Aufwand) ändern. Das neue Vorgehen ist aber nicht das einzig richtige und schon gar nicht das einzig mögliche (gegeben der spezifischen Umstände des Projekts - wir meinen damit noch nicht einmal ein universell für alle Projekte gültiges Vorgehen). Es könnte also auch anders sein und, es wird vermutlich auch anders sein. Gegeben unserem heu­tigen Wissen werden sich neue Kombinationen ergeben, die sich auf die wandelnde Umwelt einstellen. Das ist dann keine Optimierung oder kontinuierlicher Verbesse­rungsprozess, sondern eine Auflösung des einen und eine Entwicklung des anderen (siehe Luhmann (1981a) S. 26):

Wenn man die Natur als überwundene Unwahrscheinlichkeit begreift, ge­winnt man ein anderes Maß für die Beurteilung des Erreichten und des zu Verbessernden; dann wird zumindest klar, dass jede Auflösung einer Ordnung in die Unwahrscheinlichkeit einer Rekombination zurückführt.

Dies werden wir empirisch in den Abschnitten 5.2 und 9.2 erkennen. Wir halten verschiedene Optionen für möglich. Warum sich gerade agile Vorgehen entwickelt haben, kann begründet werden, sieht sich auf der anderen Seite aber auch mit einem hohen Maß an Unwahrscheinlichkeit konfrontiert, gegeben der vielfältigen anderen Möglichkeiten, gegeben aber auch der bislang bekannten klassischen Modelle und des Gegentrends der technokratischen Sichtweisen und Prozessoptimierungen, etwa im Sinne eines Reifegradmodells wie CMMi. Agile Projekte haben sich jedoch durch­gesetzt - sie sind zum jetzigen Zeitpunkt (in welcher Form auch immer) gelebte Realität, befinden sich jedoch bereits wieder in der Auflösung, in den Einflüssen neuer Denkweisen. Dies werden wir in dieser Arbeit beschreiben, und wir werden sehen, dass hierzu der erste Theorietyp ungeeignet ist. Dieser setzt eben voraus, dass man den eigenen Begriffsbaukasten bereits kennt, man weiß, was gesagt und gezeigt werden soll.⁸ Wir kennen den Zielentwurf nicht, wir werden zu keinem Zeitpunkt genau wissen, was das Richtige für ein Projekt oder für einen Mitarbeiter ist, nicht retrospektiv und schon gar nicht prospektiv.

Agilität und das Lösen von Problemen: Wir haben auch gesehen, dass Kom­munikation gleichzeitig erfolgt und Informationen lücken- bzw. bruchstückhaft über­trägt. An verschiedenen Stellen finden Interaktionen statt, die zuweilen sich gegensei­tig verstärken, in manchen Fällen auseinanderdriften. Eine Aufmerksamkeit an einer Stelle, ein Lösen eines Problems (siehe auch Luhmann (1981a)) führt zum Verlust an Aufmerksamkeit und Verständnis an anderer Stelle, macht die Lösung eines anderen Problems unwahrscheinlicher. Vor diesem Hintergrund können wir auch unseren Pa- radigmenwechsel der Vorgehensmodelle betrachten. Agilität möchte einige Probleme lösen - lange Auslieferungszyklen, den Umgang mit Unsicherheit bezüglich des zu erstellenden Produkts usw. - und das Hilfsmittel ist direkte (verbale) Kommunikati­on. Stattdessen werten agile Modelle andere Formen der Kommunikation (vor allem schriftliche) als weniger wichtig - etwa Verträge oder Dokumentationen. Mit anderen Worten, die Lösung von bestimmten Problemen bedeuten an anderen Stellen Ver­zicht und damit Lücken, neue Probleme oder aber wieder erscheinende Probleme, die bereits in einem anderen Vorgehen gelöst waren. Aber schon mit der vermeintlichen Lösung eines Problems kann ein Teilaspekt behoben sein, in der Gesamtheit aber wiederum mit der Lösung weitere Probleme, selbst in Richtung der Lösung genau jenes Problems aufgeworfen werden: Es wird scherzhaft die Frage gestellt, ob Agi­lität nicht eigentlich neomarxistisch ist, weil das Kollektiv im Vordergrund steht. Das Individuum wird im Agilen hervorgehoben - Events wie Retrospektiven und Dailys sollen den Fokus auf den einzelnen Menschen und seinen Beitrag bzw. sein Empfinden legen. Jedoch wird er gleichermaßen wieder entpersönlicht - das Team und dessen Aufgaben treten in den Vordergrund, jegliche individuelle Neigungen und Präferenzen (bezüglich eingesetzter Technologie, der präferierten Zusammenar­beit im Team etc.) werden negiert. Alles geschieht nur im Sinne des Produkts. Es lassen sich für beide Thesen Argumente und Gründe finden: Agilität als ein vom Mitarbeiter gewolltes, weil seinen Neigungen und der privaten Kommunikationswelt entsprechendes Vorgehen, das motivations- und zufriedenheitssteigernd wirkt. Aber umgekehrt auch als entmenschlichtes Dauerkommunikationsvehikel, das Mitarbeiter zwingt, sich in Rollen wiederzufinden und in fest vorgegebenen Events eng (jedoch ohne Schnittstellendefinitionen in einem Team) mit anderen zusammenarbeitet. Wir werden sehen, wie Menschen damit umgehen, für sich und in ihrem Projektalltag zu Lösungen finden und diese jedoch auch kritisch bewerten. Wir haben oben gesehen, dass Konzepte und Ideen aus der Gesellschaftstheorie, wie Nassehi in Nassehi (2011) darlegt, nicht einfach in Organisationssoziologie aufgehen. Das liegt schon daran, dass „Organisationsmitgliedschaft letztlich die Freiheit und Gleichheit der Menschen suspendiert“(Nassehi (2011), Seite 198). Es wäre zu diskutieren, wie viel Wahlfrei­heit denn tatsächlich dem Team bleibt (schon allein in der Wahl des Vorgehens, aber hier meinen wir eher in den täglichen Entscheidungen), zumal dieses Team in eine Organisation sowohl im eigenen Unternehmen als auch beim Kunden eingebunden ist. Auch dies werden wir in dieser Arbeit betrachten.

Organisationen werden Attribute wie sachbezogen, formal, berechenbar, effizienz­steigernd in ihrer hierarchischen Arbeitsteilung zugeschlagen. Dies manifestiert sich in IT-Systemhäusern in klassischen Projektvorgehen, die ebenso attributiert werden können. Der Wandel zu agilen Projektvorgehen wird mit anderen Attributen verse­hen (von denen wir schon hier gesehen haben, dass ein kritischer Blick lohnt). Das kann bedeuten, dass sich auch die institutionellen Organisationen ändern werden - es wird bereits heute von agilen Organisationen gesprochen und über sie geforscht, also solche Organisationen, die das Narrativ agiler Projekte auf die gesamte Zusammen­arbeit und Struktur im Unternehmen auszuweiten versuchen. Wir werden dies hier lediglich am Ende der Ergebniskapitel als eine Art Ausblick betrachten (auch deswe­gen, weil hierzu immer wieder Rückmeldungen der Befragten zu verzeichnen waren). Im Mittelpunkt dieser Arbeit steht jedoch der noch längst nicht abgeschlossene Wan­del der Projekte (und vielleicht auch der Menschen). Im nächsten Kapitel werden wir hierzu aktuelle Forschung, die im Bezug auf diese Arbeit und ihre Einordnung relevant ist, vorstellen.

Kapitel 3

Einordnung in aktuelle Forschung

Agile Prinzipien, deren Umsetzung in verschiedenen Branchen und Projekten so­wie ihre Vor- und Nachteile in verschiedenen Dimensionen sind vielfach untersucht worden, mit unterschiedlichen Ergebnissen. Wie auch immer diese Agilen Prinzipien zu bewerten sind, und welches Vorgehen sich in der Praxis bewähren wird, haben Ideen agiler Projektdurchführung und die Einführung von Agilität in Projekten zu vielfältiger Forschung und der Bereicherung der Forschungslandschaft um ein sehr ergiebiges Thema geführt. Es gibt vielfältige Forschung zu ganz unterschiedlichen Fragestellungen: der Einführung von Agilität im Unternehmen, der Wirkung agiler Elemente und Methoden in bestimmten Projekten oder Unternehmen, zu Erweite­rungen und Anpassungen bestehender Vorgehensmodelle usw. Wir zeigen hier einen kleinen Ausschnitt aus dieser Forschung, der für unsere Ergebnisse relevant ist, wes­wegen wir neben den Resultaten auch den Bezug zu unserer Arbeit darstellen. Da auch wir in dieser Arbeit an empirischen Ergebnissen interessiert sind, fokussieren wir uns in diesem Überblick über aktuelle Forschung auf empirische Resultate und führen an geeigneter Stelle in den Ergebniskapiteln theoretische Ergebnisse an.

Übersichten über empirische Studien zu agilen Vorgehen finden sich beispielsweise bei Dybâ and Dings0yr (2008) (mit einem gewissen Fokus auf eXtreme Programming, Vallon et al. (2018) (mit Fokus auf globale Softwareentwicklung) und Hossain et al. (2009) (mit Fokus auf Scrum und globale Softwareentwicklung). Dybâ and Dings0yr (2008) beispielsweise untersuchen 1.996 Aufsätze und finden darin 36 relevante, ihren Ansprüchen an empirische Studien zur Agilität genügende Arbeiten. Diese unterteilen sie nach solchen, die die Einführung und Adoption von agilen Methoden behandeln, solchen, die menschliche und soziale Faktoren berücksichtigen, und wieder anderen, die Anpassungen an agilen Methoden behandeln. Schließlich finden sie mit „Verglei­chenden Studien“eine wichtige letzte Kategorie. Dybâ and Dings0yr (2008) kommen in der Zusammenfassung der Studien zu dem Ergebnis, dass es in gewissen Projekten bestimmte Vorteile und Grenzen agiler Projektabwicklung gibt (sie beziehen sich auf Produktivität, Zufriedenheit der Mitarbeiter, Erfahrung der Teammitglieder sowie die Einführung in komplexen Unternehmen und Projekten), die gefundenen Evi­denzen jedoch nicht sehr stark sind, weswegen sie schließen, dass es kein allgemein richtiges, überall passendes Vorgehen gibt.

Die vorliegende Arbeit beschäftigt sich explizit nicht mit der Einführung von Agilität im Unternehmen. Hierzu findet sich umfangreiche Literatur (meist in Form von Er­fahrungsberichten), die anhand von Beispielen aufzeigt, welche Schwierigkeiten sich bei der Einführung in bestimmten (meist klassischen) Unternehmen ergeben können (siehe etwa Dikert et al. (2016) als Überblick, mit Fokus auf „large scale Scrum“ (also Scrum in großen Projekten), Pikkarainen et al. (2005) oder Svensson and Host (2005)). Svensson and Host (2005) betrachten einen agilen Prozess, der in einem klas­sischen Unternehmen eingeführt wurde, das sich auf Wartungsarbeiten spezialisiert hat. Sie weisen darauf hin, dass in komplexen Softwareentwicklungsprojekten (damit sind insbesondere evolutionär gewachsene Projekte mit entsprechenden Strukturen gemeint) innerhalb großer Unternehmen die Einführung agiler Methoden deutlich schwieriger ist als in einfacheren Umgebungen. Das scheint nicht überraschend, und so zeigen sie in ihrer Studie:

The complexity of the organization made it necessary to redesign many of the practices in order for them to fit the needs of the software development team.

Gerade mit solchen Anpassungen in klassischen Unternehmen beschäftigen wir uns in der vorliegenden Arbeit und betrachten damit die Fragestellungen „Anpassungen an agile Methoden“ und „menschliche und soziale Faktoren“ nach Dybâ and Dings0yr (2008). Jedoch geht es uns vor allem um den Einfluss, den der Erfahrungshintergrund aus klassischen Projektvorgehen hinterlässt, und die daraus resultierenden Strategi­en der Menschen in agilen Projekten. Die meisten hier genannten Studien und Ver­gleichsarbeiten kommen (wie auch Svensson and Host (2005)) auf einen Unterschied zwischen Start-up-förmigen Umgebungen und klassischen Entwicklungsprojekten in etablierten (konservativen) Branchen zu sprechen. Wir bewegen uns mit dieser Arbeit in einem klassischen, gewachsenen Unternehmen, in dem ebenso wie in dem Aufsatz von Svensson and Host (2005) keine rein agilen Methoden eingeführt wurden.

Tatsächlich zeigen sowohl Forschung als auch praktische Erfahrung, dass sich ver­schiedene agile Verfahren (insbesondere Scrum) zwar durchgesetzt haben, dabei je­doch in wesentlichen Elementen kaum nach Lehrbuch eingesetzt werden. Es gibt eine ganze Vielfalt von unternehmensspezifischen Adaptionen und Derivaten. Ei­nige Autoren stellen fest (siehe Eloranta et al. (2016)), dass einige Derivate (auf­grund des fehlenden Verständnisses agiler Methoden) kontraproduktiv sind. In ihrer empirischen Studie identifizieren Eloranta et al. (2016) in verschiedenen Unterneh­men und Scrum Teams sogenannte Anti-Patterns agiler Softwareentwicklung.⁹ Diese beinhalten naheliegende Dinge wie nicht fest definierte Sprintlängen, traditionelle Dokumentation (aufgrund von Erfahrungen im Wasserfall) zu Beginn der Sprints, fehlende Rückmeldungsschleifen (keine Durchführung von Retrospektiven), fehlende Burn Down Charts usw. Sie identifizieren Probleme, die mit diesen Lösungen und Derivaten einhergehen könnten. Babb et al. (2017) beobachten in ihrem Aufsatz (der sich dem Übergang von Agilität zu DevOps widmet), dass viele Ideen, wie kurze Ent­wicklungszyklen und adaptive Planung, in vielen Projekten willkommen sind, andere grundlegende agile Prinzipien aber ersetzt werden. Hierzu zählen, dass der Product Owner als „customer on site“ ersetzt wurde durch einen Proxy Product Owner im eigenen Team (interessanterweise ist der Kunde als Product Owner bei Eloranta et al. (2016) ein Anti-Pattern), und lose gekoppelte Individuen, geführt durch einen Projektmanager, treten an die Stelle des eigentlich vorgesehenen selbstorganisierten Teams. Wir sind hier an solchen Adaptionen und der Bewertung dieser durch die Teilnehmer an dieser Studie interessiert.

Studien zur Bewertung von Agilität in Teams und zur Einschätzung verschiedener agiler Elemente und Versprechen (Selbstbestimmung, Qualitäts- und Performanzstei­gerungen usw.) kommen zu vielfältigen auch divergierenden Ergebnissen. Lindsjörn et al. (2016) betrachten in einer klassischen Umfrage die Teamwork-Qualität von agi­len und klassischen Teams. Hier können sie keinen Unterschied feststellen, bemerken jedoch eher einen positiven Effekt, wenn das Team selbst oder die (erstaunlicherwei­se) im Team vorhandenen Führungskräften diese Teamwork-Qualität beurteilen, als wenn dies der Product Owner täte. Hodgson and Briand (2013) betrachten Autono­mie und Selbstbestimmung in agilen Projekten in kreativen Branchen (Entwicklung von Computerspielen), wo natürlicherweise klassische Kontrolle keine Rolle spielt und deshalb eine Offenheit für agile bzw. neue/andere Instanzen erwartet wird. Die Teammitglieder hatten ähnliche Freiheiten in der Selbstbestimmung wie sie in den Projekten unserer Interviewpartner vorkommen: Auswahl der Tasks, Qualitätsstan­dards, Arbeitsmethodik usw. Tiefergehende Entscheidungen, etwa die Auswahl von Teammitgliedern oder Entscheidungen zu Zielen, wurden außerhalb des Teams ge­troffen. Mit anderen Worten, Selbstbestimmung findet in diesen agilen Teams nur innerhalb eines klar umrissenen Rahmens statt. Fagerholm et al. (2015) sind an den Erfahrungen von Entwicklerteams mit der permanenten Adaption an ein volatiles Umfeld interessiert und fragen nach den Einflüssen auf die Team-Performanz. Sie stellen zunächst fest, dass sich der Begriff „Performanz“ (wie auch schon oben der zur Qualität der Teamzusammenarbeit) schwer fassen lässt, kann man sie doch mit verschiedenen Metriken messen. Sie retten mit einer offenen Fassung des Begriffs als ein Teams mit überragender Leistung (S.133):

One definition of high-performing teams is that they outperform all rea­sonable expectations as well as all other similarly situated teams. und zitieren hier Katzenbach and Smith (2015). Damit erkennen sie Faktoren, die Performanz beeinflussen und unterteilen diese in zwei Kategorien - solche, die die Organisation beeinflussen kann (Entscheidungsmacht des Teams bzw. Kontrolle über die eigene Arbeit), und weiche Umweltfaktoren (wie die Atmosphäre in Organisation oder Team). Hier finden sie 33 beeinflussende Faktoren (hierzu zählen das Verständ­nis von Agilität oder das Lernen aus Fehlern) und untersuchen zudem, in welchen Unternehmen (verschiedener Größen) diese zu finden sind. Auch zur Adaption des Vorgehen, um gleiche Performanz auch bei äußeren Veränderungen sicherzustellen (etwa, wenn sich Vorgaben, Vorgehensmodelle etc. ändern) befragen sie ihre Inter­viewpartner. In Summe erkennen sie, wie vielfältig und vielschichtig Auswirkungen auf die Performanz und Adaptionsfähigkeit eines Teams sind, wie schwer schon allein die Begriffe eindeutig zu fassen sind, und wie unmöglich sich dies auf eine einfache Vorgabe „was eben zu tun ist“ bringen lässt.

Unsere Interviewpartner haben darauf hingewiesen, dass Agilität eher ein entwick­lungszentriertes Vorgehen ist. Tatsächlich beschäftigt sich die Literatur (siehe oben) im Zusammenhang mit agilen Projektvorgehen fast ausschließlich mit Entwicklungs­teams und Entwicklern als Objekten der qualitativen Forschung. Das Paradigma der Agilität hält inzwischen aber auch Einzug in Organisationen, und es ist in den letz­ten Jahren hierzu ein eigenes Forschungsgebiet entstanden. Untersucht und erprobt werden hierin verschiedene Konzepte:

- Führung der Zukunft. Hierzu zählt ein Verzicht auf Kontrolle, das Nachdenken über Motivationsfaktoren und die Einführung von Coaching und Mentoring statt klassischer Führung.
- Organisation „anders denken“. Hierzu zählen der Verzicht oder die schwache Auslegung von hierarchischen Strukturen (oder im ersten Schritt andere Or­ganisationsstrukturen wie „das Organigramm auf den Kopf stellen“) sowie Ge­danken zu selbstorganisierenden Teams.
- Zusammenarbeit und New Work. Hierunter fallen Fragestellungen der Zusam­menarbeit in den Teams, mit solchen Elementen wie kollegialem Feedback, Lobboxen usw.

Die Diskussionen hierzu werden befeuert durch die Agilität in den Projekten, aber auch durch aktuelle populärwissenschaftliche Veröffentlichungen (Laloux (2014) oder Creusen et al. (2017)) und durch Selbstberichte von Start-up-ähnlichen Firmen zur eigenen Firmenkultur (siehe etwa Mois and Baldauf (2018)). Wir betrachten in dieser Arbeit einige von den Interviewpartnern genannte Aspekte in Abschnitt 9.3, insbe­sondere die Forderung nach Agilität nicht nur in den Projekten, sondern auch im Unternehmen. In Kapitel 7 greifen wir verschiedene damit zusammenhängende so­ziale Aspekte der Agilität auf. Die Forschung geht bei der Transformation der agilen Grundgedanken auf andere Bereiche jedoch noch weiter. Lang (2017) hat ein Se­mester einer Vorlesung in Informatik nach agilen Prinzipien und mit entsprechenden Elementen (sprintbasiertes und backlogorientiertes Vorgehen) durchgeführt. Die Er­gebnisse sind: Planung und Durchführung von Projekten nach agilen Vorgehen sind sehr zeitaufwändig, die Studenten und Studentinnen begrüßen das Vorgehen jedoch. Auch wir werden beide Aussagen in dieser Arbeit für die Projektarbeit im Unter­nehmen bestätigt sehen.

Die zitierten Aufsätze sind in den meisten Fällen an einer Wertung interessiert (was für die Praxis sehr hilfreich ist). Es wird dargestellt, wann und wie Autonomie er­reicht werden kann (oder eben nicht), wo Performanz und Teamzusammenhalt zu finden sind, und welche Auswirkungen verschiedene Faktoren auf Softwarequalität, Mitarbeiterzufriedenheit oder andere Kriterien haben. Es gibt Anti-Pattern (also Fehlverhalten und Fehlentwicklungen) oder Darstellungen und Berichte, wie agile Vorgehen unter verschiedenen Umständen (große Teams, verteiltes Arbeiten, tradi­tionelle Unternehmen) eingesetzt werden können. Diesen Anspruch haben wir hier explizit nicht. Wir betrachten die Menschen in den Projekten, mit ihren verschiede­nen Aufgaben und Rollen, und untersuchen ihr Handeln, ihre Strategien bei einem substantiellen Wechsel der Art der Arbeit. Wir nutzen hier die Gelegenheit, dass Menschen in verschiedenen Vorgehensmodellen gearbeitet haben und dort ähnliche Aufgaben innehatten. Uns interessiert, wie sie ihre Situation beurteilen, und wie sie damit umgehen. Wir möchten damit zum Verständnis beitragen, wie sich Menschen verhalten, wenn sich im Arbeitsleben zwar weder Ziel noch Ergebnis, wohl aber die Art und Weise verändert, wie es dazu kommen soll. Es geht uns hier ganz explizit nicht um Change Management und dessen Fragestellungen. Change Management heißt, sich zu fragen, wie Menschen in einem Veränderungsprozess mitgenommen werden können: Wie bringe ich Menschen dazu, ihre neue Umgebung bzw. ihr neues Umfeld, ihre neue Art der Zusammenarbeit usw. anzunehmen und dort kooperativ und wertbringend mitzuarbeiten? Ein Change Manager ist erfolgreich, wenn Men­schen zufrieden mit dem Neuen sind und darin erfolgreich arbeiten. Wir dagegen beschäftigen uns mit der Fragestellung, wie Menschen sich im Neuen verhalten. Wir wollen wissen, was sie aus der alten Umgebung, dem alten Vorgehen mitgenommen haben, aus welchen Gründen, und mit welchen Adaptionen. Damit kann diese Arbeit Change Managern helfen zu verstehen, was bei einem Wechsel von Vorgehensmodel­len im Arbeitsalltag passiert, und damit die Grundlage bilden für ihre Strategien der Interaktion mit den Menschen. Wir werden im Verlauf dieser Arbeit aber auch sehen, was sich aus einem einfachen, offen formulierten Vorgehensmodell ergeben kann, und wie dieses von Menschen betrachtet wird, die verschiedene andere Vorgehensmodelle kennengelernt haben.

Kapitel 4

Methodik der Arbeit

Wir sind in dieser Arbeit daran interessiert, bestimmte Phänomene des Handelns von Personen im Zusammenhang mit dem Wechsel ihres Arbeitsvorgehens heraus­zuarbeiten. Zur Bearbeitung dieser Aufgabenstellung wären verschiedene Methoden denkbar (für unsere Zwecke grob vereinfacht - für eine ausführliche Darstellung siehe etwa Schnell et al. (1999) oder Kardorff et al. (1995)):

- A-priori-Methoden, also die Herleitung verschiedener Ergebnisse aus bisherigen Forschungsergebnissen und eigener Denkleistung. Im gegebenen Umfeld wä­re denkbar, Arbeiten etwa zum Change Management, also zur grundlegenden Veränderung in Unternehmen, auf Änderungen der konkreten Vorgehenswei­sen in IT-Systemhäusern zu übertragen. Diese Herangehensweise würde uns allerdings wenig Konkretes über die Menschen in ihrem tatsächlichen Agieren zeigen, weswegen wir diesen Ansatz nicht weiter verfolgen.
- Empirische Methoden, also die Herleitung von Ergebnissen aus der Beobach­tung von tatsächlichem Verhalten. Dies kann in verschiedener Form stattfinden:
— Statistische Analysen und Auswertungen. Hier werden, etwa durch (Online­) Fragebögen, möglichst viele (sorgfältig nach bestimmten Gruppen ausge­wählte) Personen befragt. Die Daten sollten möglichst standardisiert und maschinell auswertbar sein und dann vermöge verschiedener statistischer Verfahren (siehe etwa Rattinger and Maier (2000)) ausgewertet werden. Die Ergebnisse dieser Erhebungstechniken sind mathematisch begründ­bar, zeigen jedoch nicht die Vielfalt der möglichen Denk- und Handlungs­weisen. Insbesondere lassen sie wenig Raum für eigene Antworten und damit die Möglichkeit, hinter eigentliche Beweggründe, hinter das spezifi­sche Denken und Agieren der Interviewpartner zu kommen. Da uns genau daran gelegen ist, haben wir uns gegen dieses Vorgehen entschieden.
— Qualitative Interviews. Hier wird eine kleine (und gut getroffene) Auswahl der Zielgruppe in semistrukturierten, offenen Interviews befragt. Diese liefern tiefe Einsichten in tatsächliches Handeln und dessen Beweggründe. Hopf (1995) schreibt hierzu:

Durch die Möglichkeit, Situationsdeutungen und Handlungsmo­tive in offener Form zu erfragen, Alltagstheorien und Selbstin­terpretationen differenziert und offen zu erheben, und durch die Möglichkeit der diskursiven Verständigung über Interpretatio­nen sind mit offenen und teilstandardisierten Interviews wich­tige Chancen einer empirischen Umsetzung handlungstheoreti­scher Konzeptionen in Soziologie und Psychologie gegeben. Im Zusammenhang mit der Begründung qualitativer Verfahren in der Sozialforschung wurde dies als besondere Leistung qualitati­ver Interviews - im Vergleich zu den begrenzteren Möglichkeiten standardisierter Verfahren - auch immer wieder hervorgehoben [...]

Mit anderen Worten, um tatsächliche Motive und Strategien des Handelns der Interviewpartner zu verstehen, sind qualitative Interviews im Hinblick auf unsere Zielsetzung die richtige Methodik.

Methodisch gehen wir damit vor wie in ähnlichen Aufsätzen auch (siehe etwa Hodgson and Briand (2013)), und wie in der Literatur (etwa Silverman (2006)) vorgeschla­gen. Zur Durchführung der Interviews wurde ein Fragebogen erstellt (Anhang A), der als Leitfaden in den Interviews herangezogen wurde. Wir haben in einer Krea­tivsession mit anderen Kolleginnen Fragen für den Fragebogen entworfen, die unsere Grundfragestellung auf einer sehr abstrakten und allgemeinen Ebene adressieren, aber nicht auf spezielle vorgedachte und bereits formulierte Hypothesen abzielen, et­wa solche Fragen wie: „Wie bewertest Du die mögliche Autonomie in agilen Teams?“. Wir suchten nach Fragen, die genügend Raum für weitere Fragen und Antworten gelassen haben, um hinter die tatsächlichen Gedanken und Strategien der Interview­partnerinnen zu kommen. Es geht uns nicht darum, eine bereits formulierte These nachzuweisen oder zu verwerfen und aus diesen Thesen Leitfragen zu entwickeln, etwa durch Fragen wie: „Was sind die Vorteile von Autonomie im Team?“ oder „Können Grundwerte der Agilität auch in verteilten, großen Scrum-Teams gelebt werden?“. Wir wollen vielmehr den Interviewpartnern Raum lassen, ihre Erfahrungen mit bei­den Vorgehensmodellen zu beschreiben. Aus diesen Berichten haben wir Schlüsse abgeleitet, also anhand der gesammelten Daten Hypothesen und Erkenntnisse for­muliert und begründet.

Wir haben als Interviewpartner jeweils drei verschiedene Vertreter aus den Gruppen Projektleiter, Softwareentwickler und Fachexperten sowie Querschnitt eines Softwa­resystemhauses ausgewählt, die jeweils in beiden Vorgehensmodellen gearbeitet ha­ben und arbeiten, die Modelle also in ihrer täglichen Arbeit erleben und leben. Sie hatten jeweils mindestens 5 Jahre Berufserfahrung aus der Arbeit in unterschied­lichen Teams (verschiedene Teamgrößen, Teams mit und ohne Offshore-Anteil, ver­teilte Teams, verschiedene Teamstrukturen und verschiedene Vorgehensmodelle). Die Softwaresysteme werden im Auftrag von Kunden individuell entwickelt. Die Inter­viewpartner arbeiten in unterschiedlichen Bereichen und Projekten mit über 700 Mitarbeitern des Systemhauses und haben verschiedene (und nicht immer akademi­sche) Ausbildungswege. Wir haben in Summe zwölf Interviews von etwa einer bis 1,5 Stunden Länge geführt, von denen neun Interviews (diejenigen mit den interessan­testen Einsichten) vollständig transkribiert wurden. Zur Wahrung der Anonymität wurden Namen, Projekte und Kunden in den Transkripten durch [xxx] mit einer jeweiligen Kurzbeschreibung des Kontextes ersetzt. Die Interviews wurden von nicht an der Studie beteiligten Personen gegengelesen, aufkommende Unklarheiten und Fragen mit den Interviewpartnern geklärt. Ergänzt wurde die Erhebung durch wei­tere Gespräche in der Phase der Auswertung der Interviews, um die Ergebnisse gegen die Erfahrungen anderer zu validieren und Auswirkungen aus der Stichprobenverzer­rung möglichst gering zu halten. Uns ist bewusst, dass es Verzerrungen aufgrund der Stichprobe gibt: Nur Kollegen, die sich auch zum Interview bereit erklärt hatten, wurden befragt, an der Studie haben nur Mitarbeiter eines Stoftwareunternehmes teilgenommen. Wir sind jedoch der Meinung, dass die Ergebnisse plausibel zeigen, was denkbar ist, und wagen an einigen Stellen Verallgemeinerungen. Mit anderen Worten: Wir verfolgen in dieser Arbeit nicht ausschließlich ein beschreibendes In­teresse. Mit unseren Thesen wagen wir einen Erklärungs- und Deutungsversuch der Aussagen und versuchen, Gründe für diese anzugeben und darzustellen. Zusätzlich wurde eine Literaturrecherche durchgeführt, um die entsprechenden Thesen gegen weitere Ergebnisse zu überprüfen. Dennoch verfolgen wir nicht den Anspruch, eine geschlossene Theorie für den Übergang von einem Vorgehensmodell in ein anderes zu erarbeiten. Uns geht es vielmehr darum, sehr nah an den Antworten der Inter­viewpartner herauszuarbeiten, was tatsächlich ist, was erlebt wird und passiert. Ein wenig folgen wir damit James (1977), wenn er meint:

Wir müssen dem monistischen Dogmatismus entgegentreten und uns nach dem empirischen Befund richten.

Wir betrachten hier vor allem die Empirie, lassen uns in den Schlussfolgerungen (aber auch in den Beobachtungen) immer wieder durch die Theorie inspirieren, wie wir es bereits in Kapitel 2 getan haben.

Bei der Auswertung der Interviews haben wir anhand der Interviews bestimmte Phänomene aus den Interviews herausgearbeitet, diese zunächst mit Passagen aus den Interviews validiert und nach weiteren Evidenzen in den Interviews gesucht. Im Anschluss haben wir die Phänomene und abgeleitete Thesen mit weiteren Kollegen sowie der Betreuerin der Arbeit besprochen und erweitert bzw. hinterfragt. Wir stel­len die Ergebnisse in den Kapiteln 5 bis Kapitel 9 in den jeweiligen Abschnitten dar. Hierzu zitieren wir ausgewählte Passagen aus den Interviews jeweils mit der Nummer des Interviews und dem Zeitstempel (der jeweiligen Textpassage, in der die Passage zu finden ist) im Transkript. In den Ausführungen der Ergebniskapitel (Kapitel 5 bis Kapitel 9) bringen wir unsere Ergebnisse in eine Struktur, die freilich auch ei­ne andere sein könnte. Die Ergebnisse greifen ineinander, beziehen sich aufeinander und zeigen die Zusammenhänge zwischen den einzelnen Kapiteln auch durch erneu­tes Zitieren bereits geäußerter Texte und die vielen Querverweise auf jeweils andere Abschnitte.

Kapitel 5

Ergebnisse I: Hintergründe und Gründe agiler Vorgehensmodelle

In den folgenden Kapiteln diskutieren wir die Ergebnisse der Arbeit, die auf den Aus­wertungen der Interviews, wie im Kapitel 4 dargestellt, beruhen. Hierbei spannen wir den Bogen von einer in gewisser Weise historischen Betrachtung von Vorgehensmo­dellen mit Gründen, Bewertungen und Sichtweisen in den ersten drei Kapiteln. Diese gehen fließend über in Gegenwärtiges und den Umgang in derzeitigen Projekten, al­so gelebter Wirklichkeit von Agilität. Schließlich führen wir hin zu Zukünftigem mit einem Ausblick auf agile Organisationen und zukünftige Projektvorgehen. Wir begin­nen im Kapitel 5 mit einer Beschreibung dessen, was zu agilen Vorgehensmodellen geführt oder beigetragen hat. Die folgenden Kapitel 6 und 7 zeigen verschiedene Sichtweisen agiler und auch klassischer Vorgehensmodelle sowie unterschiedliche und auch einheitliche Bewertungen dieser. Hier geht es uns nicht nur darum, die Per­spektivendifferenz an von den Befragten dargestellten Beispielen aufzuzeigen und zu motivieren sondern auch darum, zu zeigen, warum aktuelle Forschung in der Bewer­tung von agilen Vorgehensweisen zu solch unterschiedlichen Ergebnissen führt. Zu welchen Ergebnissen diese verschiedenen Betrachtungsweisen und Bewertungen in den Projekten führen und wie damit umgegangen wird, stellen wir im Kapitel 8 dar. Wir betrachten Adaptionen und Derivate der verschiedenen Vorgehen und sehen, wie Agilität in der Praxis gelebt wird. Im letzten Ergebniskapitel betrachten wir zukünf­tige Entwicklungen in den Projektvorgehen. Hier betrachten wir zum einen die fast schon kanonisch erscheinende Weiterführung von Agilität auch in Organisationen (und nicht nur in Projekten) und zum anderen die Ideen und Vorstellungen für Än­derungen an den Projektvorgehen und eben der zukünftigen Arbeit. Wobei sich hier zeigen wird, dass die Vorstellungen die heute bekannten Vorgehen nicht überschrei­ten. Dennoch wird es mit dem Erfahrungshorizont der Möglichkeit verschiedener Vorgehen (jetzt bekannt: klassische und agile Vorgehen mit den jeweiligen Adaptio­nen) gesehen, dass die Existenz weiterer Vorgehensmodelle vorstellbar ist, auch wenn dies (die Vorstellbarkeit) die Modelle selbst noch nicht sind. Dies führt zur Forderung nach undogmatischen Vorgehen in der Zukunft und schließt den Kreis zum ersten Kapitel.

Strukturell werden wir in jedem Abschnitt einen Aspekt behandeln. Wir stellen eine These begründet durch unsere Interviews auf und erläutern diese kurz einführend. Anschließend geben wir einen kurzen Überblick über ähnliche oder unterschiedliche

[...]

---

¹ Die Gründe (und auch die Bewertung) des Übergangs von klassischen zu agilen Vorgehensweisen sind - wie wir sehen werden - vielfältig und vielschichtig. Angeführt werden etwa neue Erkennt­nisse und Ideen zu Formen der Zusammenarbeit, eine sich ändernde Gesellschaft und damit andere gewohnte Umgangs- und Arbeitsformen (auch die Auswirkungen des Privaten auf das Berufliche) oder die Änderung der Ansprüche an die Ergebnisse (Lieferungszeitpunkt, Qualität).

² Um eine Übertragung klassischen und agilen Denkens kurz aufzuzeigen: Umgekehrt wäre es auch möglich, das theoretische Grundlagenwissen an genau den Stellen einzuführen, an denen diese zum ersten Mal benötigt werden. Das wäre dann eine „agile Struktur“. Das Bündeln des Grund­lagenwissens an einer Stelle hat jedoch Vorteile: Inhalte können leicht gefunden und nachgeschla­gen werden (etwa, wenn die Grundlagen an verschiedenen Stellen vorausgesetzt werden), und eine geschlossene Theoriedarstellung und Gegenüberstellung von Aspekten des Agilen und des klassisches Software Engineerings ist möglich. Umgekehrt weiß eine Leserin noch nicht, wozu die Grundlagen benötigt werden und kann diese schwerlich einordnen. Damit geraten diese Grund­lagen wieder in Vergessenheit und müssen ohnehin dann, wenn sie relevant werden, nochmals nachgeschlagen werden.

³ Jm Text wird zusätzlich vom V-Modell die Rede sein - hier korrespondiert zu den jeweiligen Phasen immer eine entsprechende Testphase.

⁴ Tatsächlich wird auch im klassischen Vorgehen iterativ vorgegangen, also Teilfunktionalitäten in einer ersten Version (Release) entwickelt und auf dieser aufbauend weitere Funktionalitäten bereit gestellt.

⁵ Großen Unternehmen und Behörden wird nachgesagt, dass diese eigentlich keine Kunden oder Interaktion mit der Umwelt benötigen, sondern sich ausschließlich mit sich selbst beschäftigen können.

⁶ Dieses unterschiedliche Erleben und die Auslegung von Interaktion ist auch ein Grund, warum diese Arbeit diese Form hat, so verstanden wurde und so ausgelegt wurde - weil eben auch die Autorin verschiedene Auffassungen und Denkweisen hat und hier (zuweilen zu ihrer eigenen Unzufriedenheit) eingeschränkt ist.

⁷ Ideen bringen immer auch Gegenpositionen hervor. Kurz vor der großen Welle der Agilisierung war ein anderer Trend über einige Jahre zu verzeichnen. Es gab eine Entwicklung hin zu immer technokratischeren Optimierungen von Prozessen. Dies wurde bis zu einem Reifegradmodell hin verfolgt (CMMi), welches auf verschiedenen Stufen zeigt, wie nachvollziehbar, wie fest definiert, wie messbar Prozesse und Ergebnisse sind. Vielleicht konnte man daran schon sehen, dass eine Gegenbewegung zu erwarten sein würde.

⁸ Wenn man bestimmte Phänomene (Agilität führt zu mehr Autonomie) nachweisen möchte, ist ein solcher Theorietyp jedoch das Mittel der Wahl - auch wenn sich allgemeine und universelle Aussagen auf diese Weise kaum erhalten lassen.

⁹ Pattern spielen in der Softwareentwicklung eine wesentliche Rolle. Hier wird in Mustern gezeigt, wie Lösungen (Architektur, gewisse Implementierungen) sein sollten oder sich als gut erwiesen haben. Sie sind also abstrahierte „Best Practices“, wohingegen Anti-Pattern eben zeigen sollen, was nicht getan werden sollte. Dies ist offenkundig diskussionsbedürftig, ein und dieselbe Lösung kann als Pattern oder Anti-Pattern gesehen werden.