Ist Agilität tot?

Kürzlich habe ich den Artikel „Scrum sucks“ von Matteo Bianchi [1] gelesen. „Stimmt doch gar nicht!“, waren meine ersten, reflexartigen Gedanken. Seit über 20 Jahren folge ich in meiner Arbeit agilen Prinzipien. Und zwar erfolgreich! Nachdem die erste Emotion meinen Blick nicht mehr beeinträchtigte, musste ich zugeben, dass Bianchi in seinen Ausführungen leider viel zu oft recht hat.Werfen wir einen tieferen Blick auf die unübersehbaren Probleme mit Agilität und die häufigsten Schwierigkeiten. Warum nervt Scrum? Das kann doch gar nicht sein. Das Konzept ist klar und übersichtlich auf unter 20 Seiten im Scrum Guide [2] dargestellt. Das zugrunde liegende Agile Manifest [3] mit den vier Wertepaaren und den zwölf Prinzipien wird auf zwei Webseiten präsentiert. Beides ist kostenlos und offen zugänglich. Jeder kann es lesen, und jedem sollte es klar sein. Die systemtheoretische Grundlage agilen Vorgehens ist ebenfalls hinreichend abgesichert. Da kann doch nichts mehr schiefgehen. Oder doch?

Warum ist Scrum so schwierig umzusetzen?

Das erste Missverständnis gegenüber agilen Vorgehensweisen ist ein Übertragungsfehler: Nur weil sich etwas einfach erklären lässt, ist es noch lange nicht einfach umzusetzen. Die Prinzipien und Regeln agiler Vorgehensweisen wie Scrum sind zwar schnell erklärt und gut nachzuvollziehen. Die Umsetzung agiler Vorgehensweisen dagegen ist leider komplex und alles andere als einfach. Doch warum ist das so?Mit Agilität verhält es sich ähnlich wie mit dem Blues in der Musik: Easy to learn, but difficult to master! Agilität in einer Organisation zu leben ist ein fortwährender Prozess. Wir führen nicht einfach ein neues Projektmanagement-Framework ein, sondern ändern die Art der Zusammenarbeit und Entscheidungsfindung und damit die Kultur einer Organisation. Von dieser Veränderung ist jede einzelne Person direkt oder indirekt betroffen.Doch auch unterhalb der großen Dimension Organisationskultur treffen wir auf praktische Hindernisse bei der Umsetzung agiler Frameworks. Jede einzelne Mitarbeiterin und ­jeder Mitarbeiter sind direkt gefordert, sich immer wieder ­aktiv einzubringen. Daily Stand-ups und Planungsmeetings oder Retrospektiven bilden dabei nur die Eckpfeiler der Teamzusammenarbeit und des gemeinsamen Lernens. Doch macht das auch wirklich jedes Teammitglied? Oder möchte jemand einfach nur seine Arbeit hinter sich bringen? Sage mir, was ich tun soll, und ich mache es …

Agil arbeiten oder agil sein?

Oft ziehen wir die Rituale des Scrum-Frameworks bedingungslos durch, ohne ihre Wirkung zu hinterfragen. Scrum nimmt dann die Form eines Cargo-Kults an: Andernorts erfolgreiche Handlungsweisen werden nachgeahmt in der Hoffnung, unsere Projekte liefen ebenso erfolgreich ab. Oberflächlich arbeiten wir agil, ohne es aber tatsächlich zu sein. Die wirklich wichtige Information fließt nicht in die Dailies, und die wahren Pro­bleme kommen in den Retrospek­tiven nicht zur Sprache. Manchmal wird diese Zeitverschwendung erkannt, und als Konsequenz werden die Meetings abgeschafft oder zeitlich sehr gestreckt. Spätestens dann wird offensichtlich, dass unsere Arbeitsweise in keiner Weise agil ist.Natürlich sind hier in erster Linie die Scrum Master gefragt, um gegenzusteuern. Doch was können sie bewirken, wenn das Team nicht mitzieht? Hier können gruppendynamische Modelle wie die Teamuhr aus Bild 1 helfen. Eine Gruppe durchläuft dabei im Lauf der Jahre immer wieder vier Phasen (vergleiche [4]):

• Orientierungs- beziehungsweise Umorientierungsphase: Hierbei formt sich die Gruppe noch eher unverbindlich, und Möglichkeiten werden eruiert.
• Konfliktphase: Konflikte, die sich aus den verschiedenen ­individuellen Zielen der Gruppenmitglieder ergeben, werden aufgelöst.
• Organi­sierungphase: Die Arbeitsabläufe und Prozesse innerhalb der Gruppe werden entwickelt und eingeübt.
• Hochleistungsphase: Aus der Gruppe ist ein Team geworden, das flexibel und ideenreich seine Aufgaben umsetzt und Probleme löst.

Auf die in Bild 1 dargestellte Weise kann Agilität sauber eingeführt und im Team weiterentwickelt werden. Wenn sich die Gruppe durch neue oder die Gruppe verlassende Personen verändert oder einzelne Mitglieder neue, verantwortungsvollere Aufgaben übernehmen wollen, wird über die erneute Umorientierung mit anschließender Konfliktphase das Team entsprechend angepasst, und alles ist wieder im Lot.Klingt logisch, doch der Teufel steckt wie so oft im Detail. Probleme, die in der Konfliktphase nicht konstruktiv gelöst werden, werfen die Gruppe immer wieder aus der Organi­sierungsphase zurück, sodass die Hochleistungsphase nicht ­erreicht wird. Auch kann es zu Timingproblemen kommen. Arbeiten mehrere Teams parallel in einem großen Projekt, werden diese Zyklen nicht gleichzeitig durchlaufen. Einzelne Phasen dauern unterschiedlich lang, sodass die Teams in ihrer Entwicklung auseinanderlaufen und die Zusammenarbeit so erschwert wird. In größeren Teams können sich auch Untergruppen bilden, deren Dynamik sich ebenfalls unterschiedlich schnell entwickelt. All das wirft uns immer wieder zurück, und die Scrum Master haben alle Hände voll zu tun, um die Teams wenigstens zeitweise in die Hochleistungsphase zu bringen.

Individuelle Ziele

Werfen wir noch einmal einen Blick auf Bild 1. Dort wird zwischen den dominanten Zielen unterschieden. In den beiden oberen Phasen stehen die individuellen Ziele im Vordergrund, in den beiden unteren Phasen dagegen die Gruppenziele. Agilität spielt sich also in der Organi­sierungs- und vor ­allen Dingen in der Hochleistungsphase ab. Stehen die individuellen Ziele einzelner Teammitglieder zu stark im Vordergrund, oder werden die Konflikte in der Konfliktphase nicht konstruktiv aufgelöst, ist die Hochleistungsphase nur kurz oder wird nie erreicht. Wenn das dann auch noch phasenverschoben zwischen den Teams oder innerhalb von Untergruppen erfolgt, war es das mit der Agilität.Kritisch sind noch zwei andere Varianten der individuellen Ziele. Dominiert der eigene Karriereplan das Denken und Handeln einzelner Personen, so wird das aktuelle Team oder Projekt hauptsächlich als Sprungbrett betrachtet. Oder einzelne Teammitglieder haben kein Interesse am Team, sondern möchten für sich ihre Arbeit erledigen. Meist bezieht sich das primär auf die Programmierung, sodass die anderen notwendigen Aufgaben eines Entwicklungsteams wie Softwarearchitektur oder der funktionale Feinschliff, zum Beispiel im Sinne der Nutzbarkeit, darunter leiden. Beides geht zulasten der gemeinsamen Ziele und der Zusammenarbeit. So wird es kaum möglich sein, Agilität im Projektteam erfolgreich zu implementieren und dauerhaft zu leben.

Skalierung

Eine besondere Herausforderung stellt die Skalierung von Projekten dar. Mit ein oder zwei Teams, die aus motivierten Menschen bestehen, die für das neue Projekt brennen, lässt sich alles noch handhabbar gestalten. Vielleicht war diese kleine Gruppe wirklich agil oder zumindest auf einem guten Weg dahin. Doch mit der Vergrößerung des Projekts auf vier, acht oder noch viel mehr Teams hat die Agilität das Weite gesucht.„Wie konnte uns das nur passieren?“ ist eine dann nicht selten gestellte Frage. „Die einzelnen Teams waren doch ganz gut unterwegs.“ Nun, bei der Transformation von einem Pilotprojekt über ein oder zwei Teams hin zu einem großen Projekt mit vielleicht zehn oder sogar mehr Teams verschieben sich die Anforderungen von den zentralen Kernaufgaben hin zu einem immer größer werdenden Anteil übergreifender Aufgaben, die nicht mehr von einem Team alleine und fokussiert bearbeitet werden können [5].In den verschiedenen agilen Skalierungs-Frameworks wie SAFe, LeSS, FAST, Nexus, APM und dergleichen finden sich passende Lösungen dafür. So werden Feature Manager eingeführt, die Teamstrukturen werden immer wieder angepasst, große Team-of-Teams-Strukturen werden aufgebaut oder Gesamtplanungsmeetings mit 100 oder mehr Personen durchgeführt. Doch auch dann hängt die Agilität der Umsetzung stark von der Architektur der Lösung und einem gelungenen Abhängigkeitsmanagement ab, das bereits auf fachlicher Ebene beginnt. Oder anders ausgedrückt: Wir müssen extrem gut und methodisch arbeiten! Doch Hand aufs Herz: Wem gelingt das wirklich unter dem Druck, der üblicherweise auf Projekten lastet?Große gemeinsame Aufgaben, die besser nacheinander angegangen worden wären, werden in der Konsequenz pa­rallel bearbeitet. Das führt zu einer Überforderung der beteiligten Personen, die dadurch keinen klaren Fokus mehr haben können und damit dem gesamten Projekt mit den einzelnen Teams keine Richtung mehr geben. Leider viel zu oft ist dann die Lösung von heute das Problem von morgen. Ein nur minimales oder gar fehlendes Refactoring ist dann meist nur noch der Tropfen, der das Fass zum Überlaufen bringt.Ein weiteres Problem der Skalierung ergibt sich aus dem Trend zum Mittelwert bei großen Arbeitsgruppen. Wird das erste Pilotprojekt noch mit den besten und motiviertesten Personen aufgebaut, so ist es ab einer Projektgröße von über 20 Personen allein statistisch schon nicht mehr möglich, nur mit den besten zehn Prozent der Entwicklerinnen und Entwickler zu arbeiten. Dazu kommen die Schwierigkeiten, die sich aus einer verteilten Entwicklung ergeben. Wer schafft es beim heutigen Fachkräftemangel, so viele Leute an einen Standort zusammenzubringen?

Aufgeben ist keine Option

Doch genug gejammert … Wie können Lösungen aussehen, um selbst unter den beschriebenen schlechten Rahmenbedingungen noch wirklich agil zu sein? Bianchi weist am Ende seines Artikels bereits auf Ideen dazu hin [1]. Er leitet sie strikt aus dem Agilen Manifest ab [3]. In den Vordergrund stellt er den Wert echter Retrospektiven, um die Abläufe wirklich dauerhaft zu verbessern und nicht nur oberflächlich an weniger wichtigen, aber damit in der Veränderung auch kaum schmerzhaften Details zu arbeiten. Auch geht es ihm um die nachhaltige Sicherstellung von Vertrauen, das Vermeiden von Mikromanagement und das Beschränken von Metriken auf ihren eigentlichen Wert als Indikatoren für die Prozessqualität.Spannend ist seine Idee, die Menschen in den Teams um Ratschläge zu bitten und nicht nur um Feedback. Damit nimmt er sie stärker in die Verantwortung, was einerseits motivierend sein kann und andererseits möglicherweise neue Ansätze hervorbringt. Insbesondere hält er pauschale Aussagen für wenig hilfreich. Hier sind die Scrum Master gefordert, die konkreten Details herauszuarbeiten. So weit ist es bei ­Bianchi nachzulesen.Doch was braucht es noch, wenn es um die Probleme aus der Skalierung geht? In großen Projekten mit mehreren, pa­rallel arbeitenden Teams fällt der Zerlegung der Aufgaben und dem Abhängigkeitsmanagement eine besonders wichtige Rolle zu. Wie eine sinnvolle Zerlegung der Anforderungen in überschaubare Inkremente erfolgen kann, stellt Ralf Westphal in seinen Beiträgen zur Anforderungsanalyse detailliert dar ([6] bis [10]). Solange die Teams weitgehend unabhängig voneinander arbeiten können, kann es uns zumindest in einigen Teams gelingen, agil zu sein.Geht es in Großprojekten um die Umsetzung gemeinsamer Aufgaben, die sich nicht ausschließlich einem Team zuordnen lassen, liegt der Schlüssel zum Erfolg außer in der sauberen Implementierung und methodischen Umsetzung des gewählten Skalierungs-Frameworks darin, klare Prioritäten zu haben. Der Fokus auf genau eine dieser gemeinsamen Aufgaben zur gleichen Zeit beziehungsweise das sequenzielle Abarbeiten mehrerer Aufgaben nacheinander sind elementar, damit alle Personen im Team die notwendige Orientierung haben und nicht von den Rahmenbedingungen überfordert werden.

Die Menschen in den Teams

Dabei haben wir mit der Auswahl unserer Mitarbeiterinnen und Mitarbeiter auch in Zeiten von Fachkräftemangel ein Ass im Ärmel. Nicht die fachliche Eignung darf im Vordergrund stehen. Technische Kenntnisse veralten schnell und müssen ohnehin regelmäßig neu erlernt beziehungsweise aktualisiert werden. Vielmehr stehen andere Fragen im Vordergrund: Wie passt eine Person ins Team? Wie bringt sie sich ein? Wie kommuniziert sie? Welche zusätzliche Stärke erhält das Team von dem Menschen, um den es geht? Diese Fragen gilt es passend zu beantworten, um die Voraussetzungen für agile Teams zu schaffen.Doch auch mit starken und heterogen zusammengestellten Teammitgliedern wird es nur den wenigsten gelingen, unter überfordernden Rahmenbedingungen die Organisationsentwicklung hin zur Agilität umzusetzen. Um die Projektkomplexität auf das notwendige Minimum zu reduzieren, ist ein agiles Prinzip von besonderer Bedeutung: Einfachheit – die Kunst, die Menge nicht getaner Arbeit zu maximieren – ist essenziell [10]. Wir lassen weg, was nicht wirklich notwendig ist. Oder anders ausgedrückt: Perfektion ist erreicht, wenn wir nichts mehr weglassen, und nicht, wenn wir nichts mehr hinzufügen können.Wie gehen wir aber mit den Personen um, die unser Projekt als Sprungbrett für höhere Aufgaben sehen und damit primär ihre individuellen Ziele verfolgen? Zum einen können wir sie auf ihre individuellen Ziele ansprechen und gemeinsam he­rausarbeiten, wie eine gemeinsame, fruchtbare Arbeit aussehen kann. Dafür können wir einen festen Zeitraum definieren, für den die individuellen Ziele hinter den Gruppenzielen zurückstehen. Das wird vermutlich nur für einen überschaubaren Zeitraum zwischen 6 und 18 Monaten möglich sein. Doch das ist ausreichend Zeit. Bis dahin durchlaufen wir sicherlich bereits wieder die Umorientierungsphase aus Bild 1.Zum anderen können wir selbst in jeder Organisation festlegen, was den Projekterfolg ausmacht. Steht die Erreichung individueller Ziele für Beförderungen oder Prämien im Vordergrund, wird es schwer werden, Gruppenziele zu erreichen und wirklich agil zu sein. Stehen dagegen Gruppenziele oder gemeinsame Organisationsziele im Vordergrund, können wir eine Organisation eher in eine agile Richtung entwickeln. Persönliche Karrieren lassen sich auch in einer agilen Organisation erreichen. Dies gilt es anhand einer Verzahnung gemeinsamer Projektziele und persönlicher Einzelziele auszuarbeiten und mit den Projektmitarbeitern zu besprechen. Als Ergebnis steht dann eine Übersicht bereit, an der alle die gemeinsamen und individuellen Ziele sehen und gegebenenfalls Änderungen sofort erkennen können.

Conways Law in agil

Melvin Conway hat bereits 1968 erkannt, dass es einen fundamentalen Zusammenhang zwischen der Organisationsstruktur einer Entwicklungsorganisation und der resultierenden Architektur einer Software gibt. Dabei werden die Kommunikationsstrukturen der entwickelnden Organisation in das Design der Software übertragen [11]. Das klingt logisch, da wir versuchen sollten, Abhängigkeiten innerhalb der Software beziehungsweise zwischen den Teilen, aus denen eine Software besteht, zu minimieren. Und Kommunikationswege führen zu Abhängigkeiten.Doch wir können diesen Zusammenhang auch umgekehrt nutzen. Passen wir doch unsere Teamstrukturen an die Aufgaben an, die es zu bewältigen gibt. Damit meine ich nicht, dass eine notwendige Expertin für zwei Sprints von Team A in Team B wechselt. Hier geht es um die Lösung von Problemen, die sich aus der Skalierung ergeben. Wir kombinieren dabei zwei der Lösungsideen von Stefan Roock [5] und strukturieren unsere Teams in Gruppen von 20 bis 30 Personen beziehungsweise drei Teams. Für einen bestimmten Zeitraum von wenigen Monaten beziehungsweise wenigen Sprints, die es für die Umsetzung einer übergreifenden Aufgabe braucht, passt sich diese Gruppe beziehungsweise passen sich bei Großprojekten mehrere dieser Gruppen mit ihrer inneren Struktur an die Lösungsidee der Aufgabe an. Es kann also innerhalb einer Gruppe beispielsweise zwei oder drei Teams geben oder eine kleine, zentrale Gruppe aus drei bis vier Personen mit zwei bis drei Teams drum herum oder, oder, oder. Die Gruppe ist hierbei frei. Wir bauen aus der Gruppe virtuelle Teams auf, die dann eine feste Aufgabenzuordnung haben und nach Fertigstellung der Aufgabe wieder aufgelöst werden. Die Struktur der festen Gruppe hilft den Scrum Mastern dabei, trotz dieser Dynamik ein Wir-Gefühl aufzubauen, die individuelle Entwicklung der Teammitglieder in Richtung auf die notwendige persönliche Flexibilität zu steuern und Probleme in den Griff zu bekommen. Die Menge der beteiligten Personen bleibt durch die feste Gruppe überschaubar.Diese Idee skizziert, wie das Skalierungsproblem praktisch gelöst werden kann. Ausgangspunkt einer solchen Vorgehensweise ist die fachliche Architektur beziehungsweise die Zerlegung unseres Projekts. Wir führen die Lösung damit auf ein bereits bekanntes methodisches Vorgehen zurück. Natürlich ist die passende fachliche Zerlegung und das daraus resultierende Abhängigkeitsmanagement nicht ausreichend, um alle Schwierigkeiten zu meistern und eine agile Organisation zu schaffen beziehungsweise diese bei der Skalierung zu erhalten. Aber sie ist absolut notwendig.

Erfolgsfaktor Mensch

Unabhängig davon, wie wir es methodisch drehen: Der zentrale Erfolgsfaktor sind die beteiligten Personen. Sie bilden den Ausgangspunkt der Dynamik in den Gruppen und der methodischen Umsetzung. Von ihnen geht jede Veränderung aus. Ihr Handeln setzt die Ideen und Theorien in der Praxis um. Daher ist die Anwendung der agilen Prinzipien von so zentraler Bedeutung.Nicht nur die Scrum Master und Agile Coaches leben dies vor. Gerade die Führungskräfte sind besonders wichtig. An ihnen orientieren sich die Mitarbeiterinnen und Mitarbeiter, denn sie bewerten die Personen letztendlich. Nichts ist schädlicher für die Agilität in einer Organisation, als wenn der Chef die Regelungen und Verantwortlichkeiten immer wieder ignoriert beziehungsweise daran vorbeiarbeitet. Natürlich können Anforderungen geändert oder angepasst werden. Das ­erfolgt über die Backlog-Planung der Product Owner. Dabei wird der aktuelle Sprint bis auf wenige, extreme Ausnahmen unangetastet bleiben, um für die Entwickler und Entwicklerinnen ein ausreichend stabiles Umfeld zu schaffen und begonnene Aufgaben abschließen zu können. Wird diese Planungshoheit der Product Owner über das Backlog ignoriert und „par ordre du mufti“ eine neue Priorität eingebracht, lernt das Team nur, dass die Regeln und agilen Prinzipien nicht wirklich wichtig sind.Die Entwicklung der Mitarbeiterinnen und Mitarbeiter gemeinsam mit ihren Führungskräften im Hinblick auf das Wissen und den Einsatz der Methoden, die Kommunikation und die Zusammenarbeit ist essenziell und muss parallel zum Wachstum der Organisation und der damit verbundenen Erhöhung der Komplexität der Aufgabe mit vorangetrieben werden. Nur so können die Menschen die notwendige Flexibilität an den Tag legen, um der Dynamik der Aufgaben angemessen begegnen zu können. Der wachsenden Komplexität der Aufgaben folgt die flexiblere Struktur der Organisa­tion, die wiederum durch die Weiterentwicklung der Menschen zum Leben gebracht wird (Bild 2). Nur wenn diese drei Aspekte ausreichend in der Balance sind, sind wir in der Lage, die Aufgaben auch zu bewältigen und die dafür notwendige Agilität zu erreichen und zu erhalten.

Fazit

Softwareentwicklung ist Arbeit mit Menschen für Menschen. Unsere Produkte sind komplex, genau wie der Weg, der uns in der Entwicklung zum Produkt führt. Agilität ist das Konzept, um komplexe Aufgaben durchzuführen. Je größer eine Entwicklungsorganisation dafür wird, desto schwieriger wird es jedoch, agil zu sein und zu bleiben. Die beteiligten Personen wachsen in agilen Organisationen gemeinsam mit dem Projekt und den notwendigen, anspruchsvollen Methoden. Dieser Dreiklang aus den Menschen, der Struktur und der Methodik entscheidet, wie agil eine Organisation ist beziehungsweise bleibt.Nein, Agilität ist (noch) nicht tot! Aber ein richtig blühendes Leben führt sie auch nicht. Sie schwächelt und geht am Stock. Wir können sie zur vollen Pracht bringen, indem wir zur Umsetzung der Agilen Prinzipien methodisch vorgehen. Um das für den Erfolg notwendige Mindestmaß an Agilität zu erreichen, müssen wir dem Projektdruck standhalten und gerade auch in besonders schwierigen Situationen methodisch arbeiten. Sonst geht uns die Orientierung verloren, und die für den Projekterfolg notwendige Agilität zerfällt Schritt für Schritt. Der kurzfristigen Lösung wird dann das langfristige Ziel geopfert.Damit genau das nicht passiert, gehen wir methodisch vor. Das fängt bei der Anforderungsanalyse an, die direkten Einfluss auf unsere Architektur und damit auch die Organisa­tion der Teams hat. Dennoch entstehen gerade durch die Skalierung agiler Frameworks besonders viele Probleme. Auch hier liegen die Lösungen, wie bereits beschrieben, in den Frameworks selbst. Die Entwicklung der Menschen, gepaart mit sauberer, methodischer Arbeit, bildet somit den Rahmen, in dem Agilität ihre volle Kraft entfaltet und zu erfolgreichen Lösungen führt. Es gibt keine Abkürzungen im Projekt­dschungel!

Fussnoten

1. [1] Matteo Bianchi, Scrum sucks. 18 Oktober 2023, www.dotnetpro.de/SL2408Agilitaet1 (deutsche Übersetzung:, http://www.dotnetpro.de/SL2408Agilitaet2)
2. [2] Ken Schwaber, Jeff Sutherland, Der Scrum Guide – Der gültige Leitfaden für Scrum: Die Spielregeln, November 2020, http://www.dotnetpro.de/SL2408Agilitaet3
3. [3] Kent Beck et al., Manifest für Agile Softwareentwicklung, http://www.dotnetpro.de/SL2408Agilitaet4
4. [4] Uwe Vigenschow, Björn Schneider, Ines Meyrose, Soft Skills für IT-Berater, dpunkt.verlag, 2019, ISBN 978-3-86490-697-8,
5. [5] Stefan Roock, Agile Teams als Silo 2.0?, Agile Review 1/24, Seite 16–22, it-agile GmbH,
6. [6] Ralf Westphal, Strukturiert zerlegen, dotnetpro 4/2024, Seite 42 ff., http://www.dotnetpro.de/A2404Slicing
7. [7] Ralf Westphal, Den Stier bei den Hörnern packen, dotnetpro 5/2024, Seite 26 ff., http://www.dotnetpro.de/A2405Slicing
8. [8] Ralf Westphal, Das Messer richtig ansetzen, dotnetpro 6/2024, Seite 34 ff., http://www.dotnetpro.de/A2406Slicing
9. [9] Ralf Westphal, Die Benutzerschnittstelle treibt das Slicing, dotnetpro 7/2024, Seite 44 ff., http://www.dotnetpro.de/A2407Slicing
10. Ralf Westphal, Grobe Schnitte durch die Anforderungen, dotnetpro 8/2024, Seite 30 ff., http://www.dotnetpro.de/A2408Slicing
11. Kent Beck et al., Prinzipien hinter dem Agilen Manifest, http://www.dotnetpro.de/SL2408Agilitaet5
12. Melvin Conway, How Do Committees Invent?, Datamation magazine, April 1968, http://www.dotnetpro.de/SL2408Agilitaet6