Wenn in einem Team ständig zwischen Aufgaben hin- und hergesprungen wird, reagieren viele Manager instinktiv gleich: „Unsere Leute können sich nicht konzentrieren."
Das klingt logisch. Und es ist bequem, denn es verlangt nichts von dir. Aber es ist falsch.
Kein Mensch wechselt gern alle zwei Stunden das Thema. Task Switching passiert nicht, weil Entwickler es wollen. Es passiert, weil das System sie dazu zwingt.
Wie ein normaler Arbeitstag heute aussieht
Bevor wir über Teams reden, lohnt ein Blick auf die Ausgangslage. Microsoft hat 2025 Telemetriedaten aus Microsoft 365 ausgewertet und mit einer Befragung von 31'000 Wissensarbeitern kombiniert. Das Ergebnis liest sich wie eine Anklageschrift gegen den modernen Arbeitstag:
In der Kernarbeitszeit wird der Durchschnittsmitarbeitende alle zwei Minuten unterbrochen — durch ein Meeting, eine Mail oder einen Chat-Ping. Auf den Tag summiert sind das 275 Unterbrechungen. 60 Prozent der Meetings sind nicht geplant, sondern entstehen ad hoc. Und knapp die Hälfte der Mitarbeitenden beschreibt die eigene Arbeit als chaotisch und fragmentiert.
Das ist der Boden, auf dem dein Team steht, bevor auch nur eine einzige Story zu gross geschnitten wurde. Wer in diesem Umfeld von „Konzentrationsschwäche" redet, verwechselt das Wetter mit dem Charakter.
Die wahren Ursachen
Innerhalb des Teams kommen dann die strukturellen Gründe dazu, und sie sind fast überall dieselben:
Stories sind zu gross. Ein Entwickler fängt an, merkt nach Tagen, dass er blockiert ist, und springt zum nächsten Ticket. Je grösser die Story, desto wahrscheinlicher trifft sie irgendwo auf ein Hindernis.
Abhängigkeiten sind nicht geklärt. Das Team kann nicht weiterarbeiten, bis jemand anderes liefert — und weil niemand das vorab geklärt hat, merkt man es erst mitten im Sprint. Warum das so oft passiert und wer es lösen müsste, habe ich im Artikel über Abhängigkeiten auseinandergenommen.
Das Sprintziel fehlt oder ist schwammig. Wenn nicht klar ist, was wirklich zählt, verteilt sich die Energie wahllos. Jedes Ticket ist dann gleich wichtig — also ist keines wichtig.
Stakeholder schieben ständig neue Prioritäten rein. Jedes „Das ist dringend!" von aussen zwingt zu einem Kontextwechsel, den niemand im Team bestellt hat.
Arbeit startet, bevor sie ready ist. Halbfertige Anforderungen führen zu Stop-and-Go: anfangen, nachfragen, warten, woanders weitermachen.
Nichts davon hat mit individueller Disziplin zu tun. Es sind Systemfehler.
Ein ehrliches Zugeständnis
Bevor du jetzt nickst und den Artikel an dein Management weiterleitest: Ein Teil der Unterbrechungen ist selbstgemacht. Menschen greifen auch ohne äusseren Anlass zum Chat, prüfen Mails, wechseln freiwillig das Ticket. Das ist gut belegt und es wäre unehrlich, es wegzulassen.
Nur ändert es nichts am Argument — es verschärft es. Denn selbst die selbst ausgelösten Wechsel folgen einem Muster: Man unterbricht sich dort selbst, wo die aktuelle Aufgabe blockiert, unklar oder zäh ist. Ein Entwickler, der auf ein Review wartet oder eine schwammige Anforderung vor sich hat, sucht sich die Ablenkung, weil das System ihm keinen gangbaren Weg nach vorne zeigt. Die Selbstunterbrechung ist die privatisierte Form des Systemfehlers.
Task Switching ist Fieber
Task Switching ist wie Fieber. Es fühlt sich schlimm an, aber es ist nicht die Krankheit. Es zeigt nur, dass im Körper — hier: im System — etwas nicht stimmt.
Die meisten Organisationen behandeln aber nur das Fieber. Sie sagen: „Unsere Leute müssen sich besser fokussieren, weniger chatten, Deep-Work-Blöcke einplanen." Das ist, als würde man Fieber mit einem Ventilator bekämpfen. Man kühlt, aber man heilt nicht — und die Infektion arbeitet weiter.
Ein Team ohne klares Sprintziel, ohne saubere Vorbereitung und ohne gemanagte Abhängigkeiten muss switchen. Alles andere wäre ein Wunder.
Warum das gerade jetzt teurer wird
Es gibt einen Grund, warum dieses Thema 2026 dringlicher ist als vor drei Jahren: KI hat das Anfangen radikal verbilligt — und damit das Springen.
Die Telemetriedaten von Faros, erhoben über 22'000 Entwickler in mehr als 4'000 Teams, zeigen das in einer Deutlichkeit, die wehtut: Entwickler, die mit KI arbeiten, jonglieren 67 Prozent mehr Pull-Request-Kontexte und rund 18 Prozent mehr Aufgaben-Kontexte pro Tag. Gleichzeitig steigen die „Work Restarts" — Aufgaben, die aus einer späteren Phase wieder auf „in Bearbeitung" zurückfallen — um 14 Prozent. Und 26 Prozent mehr laufende Aufgaben zeigen sieben Tage oder länger überhaupt keine Aktivität: angefangen, Kapazität gebunden, liegengelassen. (Faros verkauft Messwerkzeuge, das sei dazugesagt — aber der Befund deckt sich mit dem, was der DORA-Report 2025 von Google Cloud unabhängig beschreibt.)
Faros nennt das Muster eine Umgebung, „in der es leicht ist anzufangen und schwer, fertig zu werden". Genau das ist Task Switching auf Organisationsebene — nur dass es jetzt von einem Werkzeug beschleunigt wird, das sich alle freiwillig installiert haben.
DORAs Fazit dazu ist das wichtigste des ganzen Reports: KI wirkt als Verstärker. Sie vergrössert die Stärken disziplinierter Organisationen — und die Dysfunktionen aller anderen. Wer schon vorher zu viel parallel hatte, hat jetzt noch mehr parallel, nur schneller.
Der eine Eingriff
Wenn du Task Switching siehst, hast du zwei Möglichkeiten. Du kannst auf die Entwickler schimpfen — dann ändert sich nichts, denn du behandelst das Fieber. Oder du suchst die Infektion. Und dafür gibt es einen konkreten ersten Griff:
Zähl im nächsten Daily, wie viele Tickets pro Person „in Arbeit" sind. Alles über zwei pro Person wird nicht neu angefangen, sondern fertig gemacht: Stop starting, start finishing.
Das kostet nichts. Kein Tool, keine Umstellung, keine Diskussion über Konzentration. Nur eine Zahl und eine Regel. Und sie wirkt doppelt: Sie macht das Ausmass des Problems sofort sichtbar (die Zahl ist fast immer höher, als alle denken), und sie zwingt die eigentlichen Ursachen an die Oberfläche — denn wer nichts Neues anfangen darf, muss sagen, warum das alte Ticket nicht fertig wird. Da steht dann die ungeklärte Abhängigkeit, die schwammige Anforderung, das fehlende Review. Die Infektion, nicht das Fieber.
Task Switching ist der sichtbarste Indikator dafür, dass dein System das Fertigwerden nicht belohnt. Wenn du es siehst, schau nicht auf die Person, die springt. Schau auf das, wovor sie springt.
Nächste Schritte
Wenn die Blocker, vor denen dein Team wegspringt, immer dieselben sind: Dann sind es ungeklärte Abhängigkeiten — und die entstehen vor dem Sprint, nicht in ihm. → Der stille Killer deiner Sprints sitzt nicht im Nachbarteam
Wenn niemand sagen kann, was diesen Sprint wirklich zählt: Ohne Sprintziel ist jede Priorität gleich laut. Warum feste Strukturen die Grundlage sind: → Heartbeat im Scrum Team: Warum feste Strukturen der Schlüssel zur Effizienz sind
Wenn Arbeit startet, bevor sie ready ist: → Die Kunst des effizienten Refinements
Wenn dein Daily nur Statusprosa liefert, statt Blocker sichtbar zu machen: → Warum dein Daily nichts bringt - und warum du es trotzdem behalten solltest
Zähl die Tickets pro Person einen Sprint lang und schreib mir, wo ihr gelandet seid. → Taleon LinkedIn
Quellen
- Microsoft WorkLab — «Breaking Down the Infinite Workday», Work Trend Index Special Report, Juni 2025. https://www.microsoft.com/en-us/worklab/work-trend-index/breaking-down-infinite-workday
- Faros AI — «AI Engineering Report 2026: The Acceleration Whiplash», Telemetriedaten von über 22'000 Entwicklern in 4'000+ Teams. https://www.faros.ai/research/ai-acceleration-whiplash
- DORA / Google Cloud — «State of AI-assisted Software Development», 2025. https://dora.dev/research/2025/dora-report/