Ich beobachte dieses Schauspiel in nahezu jeder agilen Transformation. Mitten im Refinement erhebt sich jemand, winkt ab und verkündet: «Das müssen wir nicht mehr aufschreiben, wir sind jetzt agil.» Kopfnicken ringsum. Der Satz fühlt sich an wie ein Befreiungsschlag, wie die endgültige Abkehr vom administrativen Wasserkopf, wie der pure Geist des Manifests. Und dennoch ist er grundfalsch. Er zählt zu den kostspieligsten Irrtümern, die sich in Teams einnisten können.
Seit Jahren arbeite ich als Team Coach mit agilen Teams. Die Varianten dieses Satzes begegnen mir ständig: «Scrum kennt keine Dokumentation.» «Der Code dokumentiert sich selbst.» «Wenn du fragen musst, frag einfach im Daily.» Immer dasselbe Schema: Ein Team hat den ersten Halbsatz eines Wertepaars aus dem Agilen Manifest gelesen. Den zweiten hat es ignoriert.
Ich werde diesen Mythos hier in seine Bestandteile zerlegen. Du erfährst, was die Verfasser des Manifests tatsächlich im Sinn hatten, welche nachweisbaren Kosten fehlende Dokumentation verursacht, welche Anforderungen Scrum tatsächlich stellt und wie du in agilen Teams das angemessene Mass an Dokumentation findest, ohne in alte Wasserfall-Rituale zurückzufallen.
Woher der Mythos kommt: Ein Wort macht den Unterschied
Die Quelle des Missverständnisses ist exakt zu benennen. Siebzehn Softwareentwickler trafen sich 2001 im Skiresort Snowbird in Utah und verfassten das Agile Manifest. Das zweite der vier Wertepaare lautet:
«Working software over comprehensive documentation.»
Funktionierende Software über umfassende Dokumentation. Nicht: funktionierende Software statt Dokumentation. Und das Manifest endet mit einem Satz, den die meisten nie gelesen haben: Die Autoren betonen ausdrücklich, dass auch die rechts stehenden Werte ihre Berechtigung besitzen; sie gewichten lediglich die linke Seite höher.
Das kleine Wort «over» schultert die gesamte Beweislast. Ersetzt du es durch «instead of», verkehrst du die Aussage in ihr Gegenteil. Genau diese Verkehrung ist millionenfach geschehen. Nuclino bringt es auf den Punkt: Aus «lenke mehr Aufmerksamkeit auf die Software als auf überdetaillierte Vorab-Dokumentation» wurde in unzähligen Köpfen «lass die Dokumentation komplett weg und vertraue darauf, dass sich schon alle an alles erinnern werden».
James Grenning, einer der siebzehn Mitautoren des Manifests, hat sich Jahre später in einem Interview präzise zu diesem Punkt geäussert. Sein zentraler Gedanke: Die Werte des Manifests drücken eine Gewichtung aus, eine Sache über einer anderen. Gelesen werden sie jedoch häufig als «das eine und nicht das andere». Bei der Dokumentation tritt dieses Missverständnis besonders oft zutage.
Der historische Kontext: Wogegen sich das Manifest richtete
Um die Aussage korrekt einzuordnen, musst du begreifen, wogegen die Autoren rebellierten. In den Achtziger- und Neunzigerjahren beherrschten dokumentengetriebene, phasenbasierte Vorgehensmodelle das Feld. Bevor die erste Zeile Code geschrieben wurde, mussten Teams Anforderungsspezifikationen, Designdokumente und Architekturbeschreibungen verfassen, reviewen, aktualisieren und vom Kunden absegnen lassen.
Das Ergebnis: Umfassende Dokumentation wurde geliefert, funktionierende Software dagegen oft gar nicht oder in miserablem Zustand, weil der Löwenanteil der Energie in Anforderungs- und Designpapiere sickerte. Kunden bestellten einmal jährlich und packten daher alles in die Spezifikation, was ihnen in den Sinn kam. Bis die Software fertig war, hatten sich die Anforderungen längst gewandelt. Die dicken Ordner beschrieben ein Produkt, das keiner mehr haben wollte.
Gegen diese Übertreibung wandte sich das Manifest. Seine Botschaft: Wenn du entscheiden musst, wohin deine Kraft fliesst, dann wähle die Software, die dem Kunden Nutzen stiftet. Niemals sagte es: Dokumentation ist wertlos. Larry Apke, langjähriger Agile Coach, trifft den Kern: Präziser wäre es gewesen, von «umfassender Anforderungs- und Designdokumentation» zu sprechen. Diese begriffliche Schärfe hätte Teams die Ausrede genommen, gar nichts mehr zu dokumentieren.
Was der Mythos kostet: Zahlen statt Bauchgefühl
Wer den Mythos lebt, bezahlt dafür. Nicht sofort und nicht als sichtbaren Posten im Budget, sondern schleichend, verteilt auf Einarbeitung, Wartung, Fluktuation und Nacharbeit. Die Zahlen dazu sind ernüchternd.
Produktivitätsverlust in Milliardenhöhe
Branchenschätzungen taxieren den weltweiten Produktivitätsverlust durch schlechte Dokumentation auf rund 85 Milliarden Dollar pro Jahr. Eine McKinsey-Untersuchung kommt zu dem Schluss, dass Unternehmen mit schlechter Dokumentation 18 Prozent länger brauchen, um Projekte auszuliefern. In einem Markt, in dem Geschwindigkeit über Marktanteile entscheidet, ist das kein Rundungsfehler.
Für ein einzelnes Entwicklungsteam mittlerer Grösse rechnet die Agentur DECODE vor, dass sich die versteckten Kosten schlechter Dokumentation auf 500’000 bis 2 Millionen Dollar jährlich summieren können, wenn man Produktivitätsverlust, verzögerte Projekte, Kontextwechsel und Rework zusammenzählt. Der entscheidende Punkt dabei: Diese Kosten tauchen auf keiner Rechnung auf. Sie verstecken sich in Symptomen, über die sich Teams ohnehin ärgern: langsames Onboarding, ständige Rückfragen, Wissensmonopole.
Entwickler verbringen den Grossteil ihrer Zeit mit Verstehen statt Bauen
Noch eindrücklicher sind die Zahlen auf Ebene der einzelnen Entwicklerin. Untersuchungen zeigen, dass Programmierer rund 42 Prozent ihrer Zeit mit der Wartung von Code verbringen, den sie nicht vollständig verstehen. Weitere 21 Prozent der Zeit fliessen in das Wiederentdecken von Wissen, das im Team einmal vorhanden war, aber nie festgehalten wurde. Zusammengerechnet gehen fast zwei Drittel der Arbeitszeit für Verstehen und Rekonstruieren drauf statt für Bauen.
Lies diesen Absatz zweimal. Ein Team, das «keine Zeit für Dokumentation» hat, verbrennt ein Vielfaches dieser Zeit damit, undokumentiertes Wissen immer wieder neu zu erarbeiten. Der Verzicht auf Dokumentation spart keine Zeit. Er verschiebt den Aufwand in die Zukunft und multipliziert ihn dabei.
Onboarding wird zum Blindflug
Beim Onboarding schlägt der Mythos am härtesten zu. Organisationen mit schlechtem Onboarding verlieren 25 Prozent ihrer technischen Neueinstellungen im ersten Jahr, und innerhalb der ersten sechs Monate entscheiden die meisten neuen Mitarbeitenden, ob sie langfristig bleiben. Fehlende Dokumentation ist dabei ein Haupttreiber: Wer nicht herausfindet, wie die lokale Umgebung aufgesetzt wird, wo die Schnittstellenbeschreibungen liegen und wie das Team mit Fehlern umgeht, fühlt sich verloren.
Die Gegenprobe existiert ebenfalls: Eine Forrester-Untersuchung zeigt, dass strukturiertes Onboarding mit sauberer Dokumentation die Einarbeitungszeit um 30 Prozent verkürzt. Dokumentation ist damit kein Verwaltungsaufwand, sondern ein Hebel für Time-to-Productivity.
Der Busfaktor: Wenn Wissen kündigt
Das grösste Risiko trägt einen unfreundlichen Namen: Busfaktor. Er beschreibt, wie viele Personen ein Team verlieren darf, bevor kritisches Wissen unwiederbringlich weg ist. In undokumentierten Systemen liegt dieser Faktor oft bei eins.
Du kennst die Situation: Ein Entwickler ist seit acht Jahren im Team, hat einen Grossteil des Systems gebaut und nichts davon aufgeschrieben. Jetzt kündigt er, und in seiner letzten Arbeitswoche soll er «Übergabedokumente» schreiben, die acht Jahre Systemwissen abdecken. Motivation: null. Zeit: fünf Tage. Der schlechteste Zeitpunkt, um mit Dokumentation zu beginnen, ist der Moment, in dem das Wissen das Haus verlässt.
Wissensmonopole entstehen dabei nicht aus bösem Willen. Sie entstehen, weil kritisches Systemverhalten nur im Gedächtnis einzelner Personen lebt statt in zugänglicher Form. Diese Personen werden zum Flaschenhals: Jede Frage läuft über sie, jede Abwesenheit bremst das Team. Ausgerechnet der agile Anspruch, dass Teams selbstorganisiert und unabhängig arbeiten, scheitert an fehlender Dokumentation.
Was Scrum wirklich verlangt: Transparenz ist Pflicht, nicht Kür
Die Behauptung, Scrum lehne Dokumentation ab, ist der zweite Teil des Irrglaubens. Sie zerfällt bei näherem Hinsehen. Der Scrum Guide verlangt zwar keine klassischen Lastenhefte, Pflichtenhefte oder wöchentlichen Statusreports. Daraus aber zu folgern, Scrum funktioniere ohne jegliche schriftlich fixierte Information, ist schlicht abwegig.
Scrum ruht auf drei empirischen Grundpfeilern: Transparenz, Inspektion und Adaption. Der Scrum Guide lässt daran keinen Zweifel: Der entstehende Prozess und die Arbeit müssen für alle sichtbar sein, die sie ausführen oder entgegennehmen. Entscheidungen von Tragweite stützen sich auf den wahrgenommenen Zustand der drei formalen Artefakte. Sind diese Artefakte intransparent, führt das zu Entscheidungen, die den Wert schmälern und das Risiko hochtreiben. Und weiter heisst es: Transparenz schafft die Voraussetzung für Inspektion. Inspektion ohne Transparenz ist irreführend und reine Verschwendung.
Übertragen auf die tägliche Arbeit im Team bedeutet das: Ein Product Backlog, das ausschliesslich im Kopf der Product Ownerin herumschwirrt, ist ein Scrum-Verstoss. Eine Definition of Done, die nie schriftlich festgehalten wurde und bei jeder Diskussion anders ausgelegt wird, verletzt Scrum. Ein Increment, dessen tatsächlicher Zustand sich niemandem erschliesst, verletzt Scrum ebenfalls.
Die drei Artefakte sind im Kern nichts anderes als Dokumentation in ihrer zweckmässigsten Ausprägung:
Das Product Backlog ist eine emergente, geordnete Liste all dessen, was das Produkt verbessern soll, und die alleinige Arbeitsquelle des Scrum Teams. Es hält das Was und das Warum fest.
Das Sprint Backlog dokumentiert den für alle sichtbaren Plan des Teams für den laufenden Sprint.
Das Increment wird durch die Definition of Done beschreibbar und überprüfbar. Die Definition of Done ist ein dokumentiertes Qualitätsversprechen.
Jedes Artefakt trägt zudem ein Commitment: Product Goal, Sprint Goal, Definition of Done. Diese Commitments existieren laut Scrum Guide aus einem präzisen Grund: Sie stärken Transparenz und Fokus und machen Fortschritt messbar. Wer steif und fest behauptet, Scrum verlange keinerlei Dokumentation, hat den Scrum Guide entweder nie gelesen oder seinen Kern nicht erfasst. Scrum verlangt keine überflüssige Dokumentation. Es fordert maximale Transparenz der entscheidungsrelevanten Information. Das ist ein Unterschied wie Tag und Nacht.
Und was ist mit regulierten Umgebungen?
In etlichen Branchen entscheidet nicht das Team allein über den Umfang der Dokumentation. Schienenverkehr, Medizintechnik, Finanzwesen, Pharmaindustrie: Überall dort fordern Gesetzgeber und Auditoren lückenlose Nachweise über Prozesse, Entscheidungen und Kontrollmechanismen. In regulierten Umgebungen ist Dokumentation keine Kür, sondern der Beleg dafür, dass definierte Abläufe tatsächlich eingehalten wurden.
Scott Ambler, der Begründer des Agile Modeling, schildert aus eigener Anschauung mit FDA-auditierten, lebenskritischen Systemen sowie nach SOX und Basel II regulierten Organisationen, dass dort zwangsläufig mehr Dokumentation anfällt als in anderen Kontexten. Sein zentraler Punkt bleibt aber auch unter solchen Vorzeichen gültig: Selbst mit Auditpflicht schreibst du exakt so viel Dokumentation, wie zur Erfüllung der Aufgabe nötig ist. Nicht weniger, aber eben auch kein Blatt mehr.
Agilität und Compliance sind keine Gegensätze. Sie begegnen sich in der entscheidenden Frage: Welche Information braucht wer, zu welchem Zeitpunkt, in welcher Güte? Wer diese Frage präzise beantwortet, dokumentiert zielgerichtet statt mit der grossen Kelle.
Wie gute Dokumentation in agilen Teams aussieht
Der Mythos hält sich auch deshalb so hartnäckig, weil die Alternative im Ungefähren bleibt. Zwischen «gar nichts aufschreiben» und «300-Seiten-Pflichtenheft» erstreckt sich ein breites Spektrum. Die agile Community hat dieses Terrain längst kartografiert. Die tragenden Prinzipien stammen aus Scott Amblers Agile Modeling und haben sich über zwei Jahrzehnte hinweg praktisch bewährt.
Just Barely Good Enough: Das Optimum liegt beim Zweck
Das Kernprinzip trägt den Namen Just Barely Good Enough (JBGE): Ein Dokument soll für die gegebene Situation genügen, und zwar haargenau genügen. Die Bezeichnung stiftet oft Verwirrung. JBGE meint nicht, das Dokument sei mangelhaft. Ganz im Gegenteil: Erreicht ein Artefakt den Punkt, an dem es just barely good enough ist, befindet es sich per Definition an der wirksamsten Stelle, die es überhaupt erreichen kann. Jede Zeile darüber hinaus ist Aufwand ohne Ertrag; jede fehlende Zeile lässt Fragen offen, die später teuer werden.
Ob ein Dokument diesen Punkt trifft, entscheidet nicht die Verfasserin, sondern die Leserschaft. Ambler unterstreicht: Ohne aktive Zusammenarbeit mit den direkten Adressaten eines Dokuments kannst du nicht wissen, was «gut genug» konkret heisst. Bei einer Systemübersicht sind das die Menschen, die das System später warten. Bei einem Benutzerhandbuch die Endanwender. Frag sie, was sie benötigen. Alles andere ist Spekulation.
Ein Dokument pro Zweck, eine Quelle pro Information
Zwei weitere Prinzipien räumen mit klassischen Dokumentationssünden auf:
Single Source Information: Bewahre jede Information an genau einem Ort auf. Akzeptanztests können als vollwertige Anforderungsdokumentation dienen, Unit Tests als detaillierte Designbeschreibung. Tests sind ausführbare Spezifikationen; sie veralten nicht, weil sie bei jeder Änderung zwingend durchlaufen müssen. Schriftliche Dokumentation bleibt dem vorbehalten, was sich auf keinem anderen Weg fixieren lässt.
TAGRI: They Ain’t Gonna Read It: Überflüssige Dokumentation wird schlicht nicht gelesen. Und falls doch, stiehlt sie den Lesenden Zeit. Jedes Dokument braucht einen Zweck und ein Publikum, sonst braucht es das Dokument nicht.
Kontinuierlich und spät dokumentieren
Klingt nach Widerspruch, ist aber keiner. Agile Modeling empfiehlt zwei einander ergänzende Praktiken:
Document Continuously: Verfasse auslieferbare Dokumentation fortlaufend, parallel zur Entwicklung, nicht als Sonderprojekt am Ende. Dokumentation gehört in die Definition of Done, nicht in eine separate Phase nach dem Release.
Document Late: Halte Inhalte so spät wie vertretbar fest und dokumentiere stabile Information statt spekulativer Ideen, die sich noch mehrfach drehen. Dokumentiere die getroffene Entscheidung, nicht jeden verworfenen Entwurf.
Im Zusammenspiel erzeugen die beiden Praktiken einen tragfähigen Rhythmus: Du dokumentierst in kleinen Portionen, immer genau dann, wenn eine Information belastbar geworden ist. So bleibt der Aufwand pro Sprint überschaubar und die Dokumentation aktuell.
Konkrete Formate, die sich bewährt haben
Aus diesen Prinzipien lassen sich handfeste Formate ableiten, die in agilen Teams funktionieren:
Architecture Decision Records (ADRs): Eine Seite pro Architekturentscheidung: Kontext, Entscheidung, Konsequenzen. ADRs beantworten die Frage, an der jedes neue Teammitglied verzweifelt: «Warum zur Hölle ist das so gebaut?»
Definition of Done mit Dokumentationskriterium: Eine Story ist erst dann wirklich fertig, wenn die betroffene Dokumentation nachgeführt ist. DECODE identifiziert genau das als strukturellen Hebel: Dokumentation in die Definition of Done aufnehmen, Entscheidungen festhalten, solange sie frisch sind, und die Pflege einer verantwortlichen Person zuweisen.
Team-Wiki mit kleinen, fokussierten Seiten: Ambler beschreibt den Ansatz, grössere Dokumente aus kleinen Einheiten zusammenzusetzen: eine Seite pro Thema, verlinkt aus mehreren Inhaltsverzeichnissen. Kleine Seiten lassen sich pflegen; monolithische Werke veralten unweigerlich.
Onboarding-Pfad: Eine gepflegte Startseite mit Setup-Anleitung, Systemüberblick und Ansprechpersonen. Der Return on Investment zeigt sich bei jeder einzelnen Neueinstellung.
Ausführbare Spezifikationen: Automatisierte Tests als lebende Anforderungs- und Designdokumentation, wie oben beschrieben.
Was auf dieser Liste fehlt, ist genauso aufschlussreich: Statusberichte, die niemand liest. Detailspezifikationen für Features, die noch gar nicht refined sind. Protokolle von Meetings, deren Ergebnisse längst im Backlog stehen. All das ist Verschwendung im Lean-Sinn, und gegen genau diese Verschwendung richtete sich das Manifest von Anfang an.
Der Praxistest: Drei Fragen für dein Team
Wenn du wissen willst, wo dein Team steht, brauchst du kein aufwendiges Audit. Drei Fragen genügen:
Erstens: Was passiert, wenn eure erfahrenste Entwicklerin morgen für drei Monate ausfällt? Lautet die ehrliche Antwort «dann stehen wir still», hat dein Team ein Dokumentationsproblem, kein Personalproblem.
Zweitens: Wie lange braucht ein neues Teammitglied bis zum ersten produktiven Beitrag? Dauert es länger als zwei bis vier Wochen, bis jemand substanziellen Code liefert, sind Dokumentationslücken der wahrscheinlichste Blocker. Befrage neue Mitarbeitende nach 30, 60 und 90 Tagen, welche Information sie gebraucht, aber nirgends gefunden haben.
Drittens: Wie oft beantwortet ihr dieselbe Frage zum zweiten Mal? Jede wiederholte Antwort im Chat ist ein Kandidat für eine Wiki-Seite. Einmal aufschreiben schlägt zehnmal erklären. Immer.
Was diese Fragen offenlegen: Dokumentation ist kein Selbstzweck. Sie bildet das Fundament, auf dem ein Team tatsächlich einlösen kann, was Agilität im Kern verspricht – rasch reagieren, autonom handeln, Wissen teilen, statt es zu bunkern.
Abschliessende Gedanken
Ich formuliere es mit der nötigen Schärfe: «Wir sind agil, wir dokumentieren nicht mehr» ist kein Ausweis von Agilität. Es ist Bequemlichkeit, die sich ein agiles Mäntelchen umgehängt hat.
Das Agile Manifest entstand als Reaktion auf eine pathologische Dokumentationskultur, in der Papier mehr zählte als das Produkt. Diese Pathologie haben die allermeisten Organisationen hinter sich gelassen. Viele Teams laborieren heute am gegenteiligen Problem: einer Wissenskultur, die ausschliesslich auf mündlicher Übergabe beruht – und beim ersten Abgang kollabiert. Wer 2026 noch das Manifest heranzieht, um Untätigkeit zu legitimieren, bekämpft einen Feind, der seit zwanzig Jahren tot ist, und päppelt nebenbei einen neuen hoch.
Was mich daran am meisten aufbringt: Der Mythos trifft die Falschen. Die routinierte Entwicklerin, die den gesamten Kontext im Kopf trägt, kommt mühelos durch den Tag. Bezahlen tun die anderen: die neue Kollegin, die sich drei Wochen lang nicht zu fragen traut. Der Kollege, der um 23 Uhr im Incident hängt und keine Ahnung hat, wie das Failover funktioniert. Das Nachbarteam, das eure Schnittstelle integrieren soll und aufs Raten angewiesen ist. Dokumentationsverzicht ist keine Teamentscheidung. Es ist eine Umverteilung von Aufwand – von den Wissenden zu den Unwissenden. Das ist für mich das Gegenteil von Teamarbeit.
Und ja, ich kenne den Einwand: «Dokumentation veraltet ohnehin.» Richtig – wenn du sie als Grossprojekt aufziehst. Sie veraltet nicht, wenn du sie behandelst wie Code: kleingeschnitten, versioniert, eingebettet in die Definition of Done, betreut von denen, die sie benötigen. Teams, die täglich Tests schreiben und Refactorings durchführen, können mir nicht ernsthaft erzählen, zwei Absätze in einem ADR seien nicht machbar.
Meine Erwartung an agile Teams ist deshalb unbequem: Hört auf, über das Ob zu streiten. Streitet über das Was und das Wieviel. Just barely good enough – für ein echtes Publikum, mit einem echten Zweck. Alles darüber ist Verschwendung. Alles darunter ist Fahrlässigkeit. Wer das Manifest als Ausrede für Fahrlässigkeit missbraucht, hat es nicht gelesen. Und wer es gelesen hat und dennoch so argumentiert, dem geht es nicht um Agilität. Dem geht es darum, eine lästige Aufgabe abzustossen.
Agil sein heisst nicht, weniger zu wissen. Agil sein heisst, Wissen so festzuhalten, dass es sich bewegen kann.