Vom Pixelperfektionisten zum Konzeptstrategen: UX-Arbeit im skalierten Scrum neu denken
Warum das Einbetten von UX-Designern in einzelne Scrum-Teams in skalierten Frameworks wie LeSS strukturell scheitert – und wie eine andere Rollenverteilung teure Design-Schulden verhindert.
Transparenzhinweis: Dieser Artikel wurde auf Basis meiner eigenen Erfahrungen aus mehreren Jahren in skalierten agilen Projekten mit Unterstützung von Claude (Anthropic) verfasst. Die Inhalte, Bewertungen und Einschätzungen stammen von mir – die Formulierung hat die KI übernommen.
Ein Scrum-Team soll ein Konzept für die Änderungshistorie ihres Features entwickeln. Die Aufgabe klingt überschaubar – bis klar wird: Ein sinnvolles Historienkonzept muss produktweit funktionieren, sonst entstehen sieben verschiedene Lösungen für dasselbe Nutzerproblem. Aber der Rahmen lässt es nicht zu: Jedes Team liefert innerhalb seines Scopes, in 14 Tagen. Für übergreifende Konzeptarbeit ist keine Kapazität vorgesehen.
Sechs Monate später braucht jedes Feature im Produkt genau diese Funktion. Jedes Team löst es für sich. Was ein gemeinsames Konzept früher hätte erledigen können, kostet jetzt ein Vielfaches – und hinterlässt inkonsistente Ergebnisse, die irgendwann mühsam vereinheitlicht werden müssen.
Das ist kein Zufall. Das ist Struktur.
In diesem Artikel beschreibe ich, warum ich das so sehe – aus meiner Erfahrung in verschiedenen Unternehmen mit skalierten agilen Frameworks. Ich bin sicher, dass es Organisationen gibt, die das besser lösen. Aber das Muster begegnet mir immer wieder, und ich glaube: Es hat eine strukturelle Ursache, die sich nicht durch mehr Abstimmung oder bessere Tools lösen lässt.
Scrum ist nicht das Problem – aber nicht jede Rolle passt gleich gut
Für Entwicklungsteams, die einen definierten Scope abarbeiten, ist Scrum oft hervorragend geeignet. Ich sage das ausdrücklich, weil ich nicht das Framework kritisieren möchte. Die Frage ist, ob alle Rollen gleich gut in diesen Rahmen passen. Meine Erfahrung sagt: nein – und UX ist eine davon.
Der Standard-Ansatz: Jedes Scrum-Team hat einen eingebetteten UX-Designer, zuständig für den vollständigen UX-Prozess seines Teams. Auf dem Papier sauber. In der Praxis arbeitet jeder Designer unter Zeitdruck an einem kleinen Ausschnitt des Produkts – ohne strukturellen Raum für das große Ganze. Dabei wollen strategische Produktverantwortliche und Product Owner in aller Regel genau das: Konzepte, die langfristig stabil bleiben und weit genug gedacht wurden. Der Widerspruch liegt nicht im Wollen – er liegt in der strukturellen Schwierigkeit, das innerhalb von 14-tägigen Sprints mit feature-bezogenem Scope zu leisten.
Vier Symptome, die ich immer wieder erlebe
Kein Blick auf das große Ganze. Wer ein skalierbares Navigationskonzept oder eine zukunftsfähige Informationsarchitektur entwickeln soll, braucht Zugang zur Roadmap – wissen, welche Funktionen in einem Jahr dazugehören werden. Dieser Zugang ist im eingebetteten Modell strukturell nicht vorgesehen.
Fragmentierte Parallelarbeit. Mehrere Designer arbeiten am selben Produkt, aber nicht miteinander. Das Ergebnis: Für dasselbe Nutzerproblem entstehen unterschiedliche Konzepte. Informelle Absprachen helfen, reichen aber nicht. Übergreifende Abstimmung konkurriert im Sprint-Alltag mit laufenden Commitments und hat keine gesicherte Kapazität – nicht weil niemand sie will, sondern weil das Framework dafür keinen Platz schafft.
Das Design System löst nicht alles. Es liefert wertvolle produktübergreifende Standards – konsistente Komponenten, eine gemeinsame visuelle Sprache. Aber an vielen Stellen ist es zu generisch für die spezifischen Anforderungen eines Produkts. Und was es grundsätzlich nicht leisten kann: die Nutzerforschung. Needs und Pains zu verstehen ist immer produktspezifische Arbeit – sie lässt sich nicht outsourcen. Unter Sprintdruck kommt genau diese Grundlagenarbeit systematisch zu kurz.
Iterativ wachsen ohne Gesamtvision. Was in Sprint drei noch passt, wird in Sprint neun zur Sackgasse. Features entstehen in Fragmenten – und fühlen sich am Ende auch so an.
Die Neuausrichtung: UX als vorbereitendes strategisches Team
Das Gegenmodell beginnt mit einer anderen Grundannahme: UX-Designer sind nicht primär Ausführende in Scrum-Teams. Sie sind ein strategisch vorbereitendes Team – ähnlich wie Requirement Engineers. Das UX-Team kennt die Roadmap, entwickelt ganzheitliche Nutzungskonzepte für Features bevor diese in Pakete geschnitten werden, und arbeitet gemeinsam mit den Product Ownern den Releaseplan aus. Ein Designer folgt nicht mehr einem Team, sondern einem Feature über seinen gesamten Lebenszyklus – und bleibt auch während der Umsetzung Ansprechpartner für das Entwicklungsteam.
Das bedeutet auch: weniger pixelgenaue Screens für jeden Zustand, mehr konzeptionelle Tiefe. Informationsarchitektur durchdenken, Interaktionsmuster klären, Nutzungskonzepte entwickeln, die über den initialen MVP-Scope hinausdenken. Detailgetreue Ausarbeitung dort, wo das Produkt vom Standard abweicht – nicht überall.
Dazu kommt ein weiterer Vorteil: UX-Arbeit ist enorm breit. Research, Informationsarchitektur, Prototyping, Usability-Tests, UI-Gestaltung – kein einzelner Designer ist in allem gleich stark. Im eingebetteten Modell muss trotzdem jeder alles alleine leisten. In einem übergreifenden UX-Team können Stärken gezielt eingebracht werden: Wer stark in der Forschung ist, führt die Interviews. Wer schnell im Prototyping ist, baut den Klickprototyp. So wie Architekt, Frontend und Backend arbeitsteilig an einem Feature arbeiten – warum sollte UX das anders handhaben? Gemeinsames Arbeiten schließt außerdem Kompetenzlücken: Junioren lernen von Senioren nicht durch Feedback auf fertige Arbeit, sondern durch gemeinsames Denken.
Was das voraussetzt – und warum es sich lohnt
Dieser Ansatz braucht strukturelle Voraussetzungen: Zugang zur Roadmap, Kapazität für Discovery außerhalb des Sprint-Rhythmus, und die Bereitschaft, UX-Arbeit organisatorisch neu einzubetten. Die Herausforderung ist nicht das Wollen – alle Beteiligten wollen ganzheitliche, stabile Konzepte. Die Herausforderung ist, die Rahmenbedingungen zu schaffen, die das erst ermöglichen.
Präventive, ganzheitliche UX-Konzeption ist langfristig wirtschaftlicher als reaktive Korrekturen. Das Historien-Beispiel vom Anfang macht es sichtbar: Ein gemeinsames Konzept früher hätte Wochen gespart. Das ist kein designerisches Argument. Das ist ein strategisches.
Die Frage ist nicht, ob wir uns diese Umstellung leisten können. Die Frage ist, ob wir es uns leisten können, sie nicht vorzunehmen.
Was das auf der praktischen Ebene bedeutet – wie ein verteiltes UX-Team trotz Scrum-Einbettung enger zusammenarbeiten und gemeinsam bessere Konzepte entwickeln kann – beschreibe ich im Artikel „Fünf Designer, ein Produkt – warum guter Wille allein kein gemeinsames Konzept ergibt".
Du siehst das anders – oder erkennst dich darin wieder? Ich freue mich über den Austausch. Schreib mir einfach an, und lass uns darüber reden.
Dieser Artikel wurde mit Unterstützung von Claude (Anthropic) verfasst. Grundlage waren meine eigenen Erfahrungen aus der Arbeit in skalierten agilen Projekten sowie eine strategische Analyse, die ich im Oktober 2025 zu diesem Thema ausgearbeitet habe.