Ethical Debt: Wenn wir unsere Moral für die Velocity verkaufen

Warum "Move fast and break things" ausgedient hat – und wie wir mit einer "Definition of Ethics" unser Gewissen (und unser Business) retten.

Jeder, der schon einmal in einem Softwareprojekt gearbeitet hat, kennt den nagenden Schmerz technischer Schulden. Es ist jener Moment am Ende des Sprints, in dem wir uns bewusst entscheiden, den Code “quick and dirty” zu schreiben, nur um das Release-Datum zu halten. Wir trösten uns mit dem Versprechen, es später aufzuräumen – wohl wissend, dass “später” in der IT oft ein Synonym für “nie” ist. Die Konsequenz ist bekannt: Die Software wird wartungsintensiv, träge und instabil.

Doch während wir in Retrospektiven stundenlang über Spaghetti-Code und fehlende Unit-Tests diskutieren, häufen viele Teams fast unbemerkt eine weitaus gefährlichere Art von Verbindlichkeiten an: Ethische Schulden. Das Prinzip ist erschreckend ähnlich, die Währung jedoch eine andere. Statt schlechten Codes implementieren wir moralische Abkürzungen, um kurzfristig Business Value zu generieren.

Ethical Debt im agilen Projektmanagement vermeiden

Das zeigt sich in Dark Patterns im UX-Design, die Nutzer fast unkündbar in Abos festhalten, oder in Algorithmen, die zwar effizient sind, aber aufgrund unsauberer Datenbasis bestimmte Bevölkerungsgruppen diskriminieren. Wir opfern langfristiges Vertrauen für kurzfristige Conversion Rates. Getreu dem veralteten Silicon-Valley-Mantra “Move fast and break things” nehmen wir Kollateralschäden in Kauf. Das Problem dabei: Wenn wir technischen Code “brechen”, stürzt im schlimmsten Fall der Server ab. Wenn wir ethische Grenzen “brechen”, riskieren wir Reputationsschäden, Klagen und den Verlust unserer Integrität.

Agilität darf keine Ausrede für Gewissenlosigkeit sein. Ein Minimum Viable Product (MVP) sollte nicht bedeuten, dass wir Minimum Viable Ethics anwenden. In diesem Artikel untersuchen wir, warum gerade der Zeitdruck agiler Sprints zur ethischen Falle werden kann – und wie wir mit einer einfachen Erweiterung der Definition of Done sicherstellen, dass wir nachts nicht nur wegen Server-Alarmen, sondern auch wegen unseres Gewissens ruhig schlafen können.

Wie sehen Ethische Schulden aus? (Die Diagnose)

Um das Phänomen zu begreifen, müssen wir es vom Abstrakten ins Konkrete holen. Technische Schulden erkennen wir an “Spaghetti-Code” oder fehlenden Unit-Tests. Ethische Schulden hingegen erkennen wir daran, dass sich das Produkt gegen den Nutzer wendet, um Unternehmensziele zu erreichen. Sie sind oft das Resultat von Design-Entscheidungen, die Business-Metriken (wie Conversion oder Engagement) radikal über das Nutzerwohl stellen.

Der wohl prominenteste Vertreter sind Dark Patterns. Das sind jene manipulativen Design-Tricks, die Nutzer zu Handlungen drängen, die sie eigentlich nicht wollen. Ein klassisches Beispiel ist das “Roach Motel”-Prinzip: Der Abschluss eines Abonnements gelingt in drei Sekunden per Fingerabdruck, die Kündigung hingegen erfordert die Navigation durch fünf verschachtelte Untermenüs, das Ausfüllen eines Formulars und im schlimmsten Fall einen Anruf in einer Hotline. Kurzfristig senkt dies die Churn Rate und der Product Owner wird gefeiert. Langfristig ist es ein Kredit auf die Geduld und das Vertrauen der Kunden. Wir “borgen” uns Umsatz von einer Zukunft, in der uns der Kunde hassen wird.

Ein subtilerer, aber oft gefährlicherer Posten in unserer Schuldenbilanz ist der Bias in Algorithmen. Wenn ein agiles Team unter Zeitdruck steht, greift es oft auf die erstbesten verfügbaren Trainingsdaten zurück (”Quick and Dirty”). Trainieren wir eine Recruiting-KI mit den Daten der letzten zehn Jahre, in denen zufällig primär Männer eingestellt wurden, lernt der Algorithmus: “Männer sind besser”. Das ist meist keine böse Absicht, sondern Schlampigkeit – eben eine Schuld, die wir aufnehmen, weil wir uns die Zeit für eine saubere Datenkuration («Refactoring») gespart haben.

Schliesslich gibt es das Addictive Design. Wenn wir Features wie Infinite Scroll oder aggressive, rote Notification-Badges implementieren, nur um die “Time on Site” künstlich hochzupeitschen, nutzen wir psychologische Schwachstellen des menschlichen Gehirns aus. Wir optimieren das Produkt, damit es wie ein Spielautomat funktioniert. Das mag die KPIs im Sprint Review grün färben, hinterlässt aber Nutzer, die sich nach der Nutzung der App leer und ausgebrannt fühlen statt bereichert.

Der entscheidende Unterschied zu technischen Schulden liegt in der Währung der Zinsen. Schlechten Code können wir später umschreiben; das kostet “nur” Geld. Ethische Schulden zahlen wir in härterer Währung zurück: durch massive Reputationsschäden, Shitstorms in sozialen Medien, rechtliche Keulen wie die DSGVO oder – und das wird oft unterschätzt – durch die innere Kündigung talentierter Entwickler, die schlicht keine Lust haben, ihre Lebenszeit in den Bau digitaler Fallen zu investieren.

Die MVP-Falle: Warum Agilität das Problem verschärft

Es ist eine unbequeme Wahrheit: Agilität, falsch verstanden, wirkt wie ein Brandbeschleuniger für ethische Schulden. Das Agile Manifest proklamiert “Working software over comprehensive documentation”. In vielen Teams wird dieser Grundsatz jedoch fatal uminterpretiert als: “Hauptsache, es läuft irgendwie, über die Konsequenzen denken wir später nach.” Diese Mentalität des Shipping at all costs schafft ein Klima, in dem Bedenken als Bremser gelten.

Besonders tückisch ist das Konzept des Minimum Viable Product (MVP). Die Definition von “Viable” (lebensfähig) wird dabei fast ausschliesslich ökonomisch ausgelegt: Ist das Feature gut genug, um Nutzer anzulocken oder Umsatz zu generieren? Sicherheitsnetze, Inklusions-Checks oder Mechanismen gegen Missbrauch fallen oft der Schere zum Opfer, weil sie nicht unmittelbar Business Value liefern. Sie landen als “Nice-to-have” oder “Non-functional Requirement” ganz unten im Backlog. Und wir alle wissen: Der Boden des Backlogs ist der Ort, an dem Tickets sterben.

Ein weiteres systemisches Problem ist unsere Obsession mit Metriken. Scrum-Teams werden oft an ihrer Velocity gemessen. Wie viele Story Points schaffen wir pro Sprint? Die Velocity ist jedoch eine blinde Metrik. Sie misst Geschwindigkeit, aber keine Richtung. Ein Team kann hocheffizient und mit perfekter Burn-down-Chart ein Feature bauen, das Nutzerdaten gefährdet oder manipulative Muster nutzt. In Jira sieht das aus wie ein “High Performing Team”, in der Realität ist es eine ethische Zeitbombe.

Wenn der Product Owner ausschliesslich darauf incentiviert wird, Konversionsraten und Klickzahlen zu steigern, wird Ethik zum Hindernis im Sprint. Fragen wie “Ist das gut für die psychische Gesundheit unserer Nutzer?” lassen sich schwer in Story Points schätzen und noch schwerer in Euro messen. Im Zweifel gewinnt im Sprint Planning also das Feature, das den schnellen Umsatz verspricht, gegen dasjenige, das “nur” das Richtige tut. Wir optimieren unsere Prozesse gnadenlos auf Output und verlieren dabei den Outcome – die tatsächliche Wirkung auf Mensch und Gesellschaft – aus den Augen.

Der Ausweg – Die “Ethics Review” in der Definition of Done

Moralische Appelle in Sonntagsreden ändern selten das Verhalten am Dienstagmorgen. Wenn wir Ethische Schulden wirklich vermeiden wollen, müssen wir Ethik operationalisieren. Sie darf kein Bauchgefühl bleiben, sondern muss ein harter Prozessschritt werden, genauso verbindlich wie ein Unit-Test oder ein Code-Review. Die Lösung liegt in einem Werkzeug, das jedes Scrum-Team bereits nutzt: der Definition of Done (DoD).

Wir erweitern die DoD um einen expliziten “Ethics Check”. Ein Ticket gilt schlichtweg nicht als “Done”, solange diese Prüfung nicht bestanden ist. Das nimmt dem Einzelnen die Last, als “Bedenkenträger” dazustehen. Es ist nicht mehr der nervige Entwickler, der bremst, sondern der vereinbarte Prozess, der Qualität fordert. Das Team muss sich kurz Zeit nehmen, um das Feature gegen eine mentale Checkliste zu validieren.

Drei Testfragen haben sich in der Praxis als besonders wirkungsvoll erwiesen:

Erstens: Der “Black Mirror” Test. Wir zwingen uns zu einem Perspektivwechsel ins Dystopische. Wenn dieses Feature Teil einer Folge der Sci-Fi-Serie “Black Mirror” wäre – wie würde es missbraucht werden? Könnte ein Stalker die neue “Find my Friends”-Funktion nutzen, um jemanden zu bedrohen? Könnte der Algorithmus zur politischen Manipulation zweckentfremdet werden? Wir setzen den Hut des Bösewichts auf, um Lücken im System zu finden, bevor es echte Bösewichte tun.

Zweitens: Der Grossmutter-Test. Er zielt auf Transparenz und Ehrlichkeit ab. Könnte ich meiner Grossmutter bei Kaffee und Kuchen erklären, wie wir ihre Daten nutzen, ohne rot zu werden oder komplizierte Ausflüchte zu benutzen? Wenn die Antwort lautet: “Na ja, eigentlich verkaufen wir ihre Bewegungsdaten an Dritte, aber das steht ja irgendwo in den AGB auf Seite 40”, dann ist der Test nicht bestanden. Wenn wir es nicht einfach und ehrlich erklären können, ist es meist ein Dark Pattern.

Drittens: Der Inklusions-Check. Wer wird bei diesem Feature vergessen oder benachteiligt? Haben wir bedacht, wie der Algorithmus auf Menschen mit nicht-standardisierten Namen, anderen Hautfarben oder Menschen mit Behinderungen reagiert? Oft optimieren wir für den “Standard-User” und diskriminieren unbewusst Ränder der Gesellschaft. Dieser Check zwingt uns, unsere blinden Flecken auszuleuchten.

Natürlich kostet diese “Ethics Review” Zeit. Vielleicht fünf Minuten pro Ticket, vielleicht eine halbe Stunde Diskussion im Refinement. Aber diese investierte Zeit ist die Versicherungsprämie gegen den späteren Bankrott unseres Vertrauenskapitals.

Abschliessende Gedanken: Ethik als Qualitätsmerkmal

Lange Zeit habe ich mich hinter dem bequemen Satz versteckt: “Ich schreibe nur den Code, ich mache nicht die Politik.” Das war eine Lüge. Wir müssen uns eingestehen, dass in einer durchdigitalisierten Welt Code Politik ist. Wenn wir als Product Owner oder Entwickler entscheiden, wie ein Algorithmus priorisiert oder wie aggressiv ein “Nudge” im Interface platziert ist, greifen wir direkt in das Leben und Verhalten anderer Menschen ein. Wir sind nicht mehr nur die Bauarbeiter; wir sind die Architekten des gesellschaftlichen Miteinanders.

Ethisch saubere Software zu bauen, ist für mich daher kein “Gutmenschentum” und auch keine esoterische Übung für Weltverbesserer. Es ist ein knallharter Wettbewerbsvorteil. In einem Markt, der zunehmend von Misstrauen, Datenlecks und algorithmischer Manipulation geprägt ist, wird Vertrauen zur härtesten Währung. Ein Produkt, das seine Nutzer respektiert, statt sie auszubeuten, bindet Kunden langfristig. Wer ethische Schulden vermeidet, spart sich nicht nur den teuren “Reparatur-Aufwand” eines Shitstorms, sondern baut eine Marke auf, für die auch die besten Talente gerne arbeiten wollen.

Ich möchte euch ermutigen, unbequem zu sein. Seid die Stimme im Planning, die den Finger in die Wunde legt. Fragt euch: Wann haben wir das letzte Mal ein Feature nicht gebaut, schlicht weil es sich falsch angefühlt hat? Wenn euch darauf keine Antwort einfällt, ist es höchste Zeit, eure “Definition of Done” anzupassen. Diskutiert das. Nicht irgendwann in einer fernen Strategie-Runde, sondern direkt im nächsten Sprint.