Nicht weil dein Team zu langsam ist. Sondern weil deine QA am selben Ort sitzt wie deine Entwickler.

Jeder Scrum Master kennt das Muster: Die letzten zwei Tage eines Sprints gehören der QA. Die Entwickler drehen Däumchen oder fangen neue Stories an, die dann garantiert nicht mehr fertig werden. Das Ergebnis: Carry-over. Sprint für Sprint.

Die übliche Antwort darauf? Ein separates QA-Team bilden, das „vertikal" über mehrere Scrum-Teams arbeitet. Das löst ein Problem – und schafft drei neue.

In den letzten Jahren habe ich in meinen Projekten immer wieder dasselbe Muster beobachtet. Besonders deutlich wurde es bei der Steuerung multinationaler Teams für eine konzernweite Datenplattform in der Fahrzeugentwicklung – dort zeigte sich das Problem mit vertikalen QA-Strukturen in voller Schärfe: Der QA-Engpass am Sprint-Ende ist kein Kapazitätsproblem. Es ist ein Zeitzonenproblem.

📌 Das QA-Bottleneck: Ein strukturelles Problem

Die Wurzel des Problems ist nicht mangelnde QA-Kapazität. Es ist die Tatsache, dass Entwicklung und Test in denselben acht Stunden stattfinden.

Wenn dein Entwickler um 17 Uhr seinen letzten Commit macht, kann die QA erst am nächsten Morgen testen. Findet sie einen Bug, geht der Fix frühestens mittags raus. Die QA prüft ihn am Nachmittag. Ein Bug-Fix-Zyklus dauert so mindestens 24 Stunden. Multipliziere das mit den typischen Bugs am Sprint-Ende – und du verstehst, warum zwei Tage Puffer nie reichen.

Wer sich auf Scrum.org in den Foren umschaut, stößt schnell auf dieselbe Diskussion: „How does testing happen for stuff developed on the last day of sprint?" Die ehrliche Antwort der erfahrenen Practitioner dort: Gar nicht richtig. Nicht innerhalb desselben Sprints. (scrum.org/forum)

📌 Follow the Sun: Ein bewährtes Konzept – neu angewendet

Das „Follow the Sun"-Modell (FTS) hat seinen Ursprung in den 90er Jahren. IBM war eines der ersten Unternehmen, das globale Software-Teams aufsetzte, die Arbeit entlang der Zeitzonen weitergaben. Das grundlegende Konzept wurde von Erran Carmel, Alberto Espinosa und Yael Dubinsky wissenschaftlich aufgearbeitet und im Journal of Management Information Systems publiziert (Carmel, Espinosa & Dubinsky, 2010). Ihre Forschung zeigt: Mit zwei Standorten lässt sich die produktive Arbeitszeit theoretisch auf bis zu 16 Stunden pro Tag steigern.

Carmel führte dafür den Begriff der „Calendar Efficiency" ein – der Anteil der verfügbaren Kalenderzeit (168 Stunden pro Woche), der tatsächlich produktiv genutzt wird. Eine normale 40-Stunden-Woche nutzt gerade einmal 23,8 Prozent. Überstunden verbessern das um wenige Prozentpunkte, mit den bekannten Nebenwirkungen. Eine optimale FTS-Konfiguration kann die Calendar Efficiency laut Carmels Analyse auf bis zu 71,4 Prozent steigern.

Der Ansatz wird heute vor allem im Support eingesetzt. Aber seine größte Wirkung entfaltet er in einem Bereich, der überraschend selten betrachtet wird: der QA.

❓ Warum ausgerechnet QA?

Die Forschungsliteratur – zusammengefasst in einer Übersicht auf follow-the-sun.github.io – kommt zu einem interessanten Schluss: FTS funktioniert am besten für Tätigkeiten mit geringer Abhängigkeit bei der Übergabe. Testing ist dafür prädestiniert, weil die „Handoff-Artefakte" klar definiert sind: ein Build, eine Testumgebung, eine CI/CD-Pipeline.

Eine systematische Literaturanalyse von Kroll et al. (2013) identifizierte 36 Best Practices und 17 Herausforderungen für FTS. Die drei wichtigsten Erfolgsfaktoren: agile Methoden, Technologie für den Wissensaustausch und Prozessdokumentation. Genau die Dinge, die in einem gut aufgesetzten QA-Prozess ohnehin vorhanden sind.

🛠️ So funktioniert es in der Praxis

Die Idee ist einfach:

Dein Entwicklungsteam sitzt in der DACH-Region (CET/CEST). Dein QA-Team sitzt in einer komplementären Zeitzone – zum Beispiel Neuseeland (NZST), Australien oder Südostasien.

Dein Entwickler macht seinen letzten Commit um 17 Uhr deutscher Zeit. Um 18 Uhr beginnt in Auckland der Arbeitstag. Das QA-Team hat volle acht Stunden, um gegen die CI/CD-Pipeline zu testen, Bugs zu dokumentieren und Ergebnisse bereitzustellen.

Wenn dein Entwicklungsteam am nächsten Morgen um 9 Uhr den Rechner hochfährt, liegen die Testergebnisse der Nacht bereit. Bugs können sofort gefixt werden. Die QA in Neuseeland prüft den Fix in ihrer nächsten Schicht.

Ein Bug-Fix-Zyklus: unter 24 Stunden. Ohne Überstunden. Ohne Nachtschichten.

🛠️ Die IBM-Erfahrung: Wo FTS funktioniert – und wo nicht

Wer sich für die wissenschaftliche Basis interessiert, findet in der IBM Case Study von Treinen und Miller-Frost (2006) zwei lehrreiche Fälle. Der erste: Ein Team verteilt auf USA und Australien – erfolgreich. Der zweite: Teams in den USA und Indien – gescheitert. Die Gründe für das Scheitern: Missverständnisse bei der Interpretation von Spezifikationen, mehrfache Nacharbeitszyklen, mangelnde Koordination und – ganz wesentlich – kulturelle Differenzen.

Diese Fallstudien bestätigen eine Beobachtung, die ich in über 23 Jahren Projektarbeit immer wieder gemacht habe: Zeitzonen sind nur die halbe Rechnung. Die andere Hälfte heißt Culture Fit.

Wikipedia dokumentiert übrigens einen der prominentesten aktuellen FTS-Erfolge: Larian Studios entwickelte Baldur's Gate 3 mit sechs Studios weltweit – darunter Ghent, Dublin, Kuala Lumpur und Quebec – im Follow-the-Sun-Modell. Das Ergebnis: eines der erfolgreichsten RPGs der letzten Jahre, entwickelt ohne die typischen Crunch-Phasen großer Game-Studios.

📌 Was das für deinen Sprint bedeutet

In einem klassischen Setup verlierst du die letzten ein bis zwei Tage jedes Sprints an den QA-Stau. Die Entwickler können nicht weiterarbeiten, weil sonst keine QA mehr möglich ist.

Mit einem Follow-the-Sun-QA-Modell ändert sich die Gleichung: Entwicklung und QA laufen parallel – aber zeitversetzt. Dein Team kann einen vollen Tag länger entwickeln, weil die QA in der komplementären Zeitzone immer einen ganzen Arbeitstag zur Verfügung hat.

Bei einem 10-Tage-Sprint sind das effektiv ein bis zwei zusätzliche Entwicklungstage. Das ist kein Produktivitätsgewinn durch mehr Druck. Das ist ein Strukturvorteil durch intelligentere Organisation.

📌 Was das in Personentagen kostet

Rechnen wir konservativ. Ein typisches Team: 5 Entwickler, 2 QA-Spezialisten, 14-Tage-Sprints (10 Arbeitstage).

Wenn die Entwickler im Schnitt 1,5 Tage vor Sprint-Ende aufhören müssen, neue Features zu entwickeln – weil die QA sonst nicht mehr durchkommt – dann sind das:

5 Entwickler × 1,5 Tage × 26 Sprints pro Jahr = 195 Personentage.

Bei einem durchschnittlichen Tagessatz von 800 Euro sind das über 150.000 Euro verlorene Entwicklungskapazität. Pro Jahr. Pro Team. Nicht weil jemand schlecht arbeitet. Sondern weil die Struktur es nicht anders zulässt.

Ein Follow-the-Sun-QA-Modell gibt dir davon den Großteil zurück.

📌 Das lohnt sich nicht erst bei Großprojekten

Follow the Sun klingt nach Konzernen mit hunderten Entwicklern. Tatsächlich lohnt sich das Modell ab einem einzigen Scrum-Team.

Der Grund: Das QA-Bottleneck trifft kleine Teams härter. In einem 5+2-Team hat ein einzelner verlorener Entwicklungstag mehr Gewicht als in einem Programm mit zehn Teams. Der relative Kapazitätsverlust ist höher.

Und: Ein QA-Team in einer komplementären Zeitzone muss nicht groß sein. Zwei erfahrene Tester in Auckland, die gegen deine CI/CD-Pipeline arbeiten, reichen für ein Scrum-Team in Berlin völlig aus.

Die Einstiegshürde ist nicht Teamgröße. Sie ist Prozessreife. Du brauchst eine funktionsfähige CI/CD-Pipeline, automatisierte Deployments auf Testumgebungen und eine saubere Testdatenstrategie. Ohne diese Grundlagen macht ein Zeitzonenversatz wenig Sinn – dann testet dein QA-Team acht Stunden lang gegen eine kaputte Umgebung.

📌 Der DevOps-Bonus: QA plus Troubleshooting

Besonders interessant wird das Modell, wenn dein QA-Team nicht nur testet.

In einem DevOps-Ansatz, in dem QA-Spezialisten auch grundlegende Troubleshooting-Skills mitbringen – Log-Analyse, Monitoring-Checks, First-Level-Incident-Response – gewinnst du einen zusätzlichen Vorteil: Dein europäisches Entwicklungsteam schläft. Dein QA-Team in Neuseeland testet die neuen Features – und überwacht gleichzeitig die Produktionsumgebung.

Wenn nachts ein Alert kommt, sitzt jemand am Rechner, der das System kennt. Kein Bereitschaftsdienst. Keine Nachtschicht. Keine Reaktionszeit von Stunden.

Das ist kein Ersatz für ein vollwertiges Ops-Team. Aber es ist eine pragmatische Erweiterung, die zwei Fliegen mit einer Klappe schlägt: QA-Kapazität und Nacht-Coverage. Besonders für KMUs, die sich kein dediziertes 24/7-Operations-Team leisten können, ist das ein erheblicher Mehrwert.

🛠️ Welche Zeitzone funktioniert?

Rechnerisch passen drei Regionen besonders gut für ein Entwicklungsteam in der DACH-Region:

Neuseeland (CET+11 bis +12) – nahezu perfekt komplementär. 17 Uhr Berlin = 6 Uhr Auckland. Volle acht Stunden QA, bevor dein Team morgens den Rechner hochfährt.

Australien (CET+8 bis +9) – funktioniert, mit mehr Überlappung am Nachmittag. Gut wenn synchrone Abstimmung wichtiger ist.

Südostasien (CET+5 bis +7) – zeitlich im Fenster, aber mit deutlich weniger Versatz. Eher geeignet für Teams, die mehr Overlap brauchen.

Indien (CET+3:30) ist zu nah. Dein QA-Team arbeitet mitten in deinem Arbeitstag. Das verschiebt den Engpass, es löst ihn nicht.

Südamerika (CET-4 bis -6) hat das gleiche Problem – nur andersherum. 17 Uhr in Berlin ist 12 Uhr in São Paulo. Kein Nachtversatz, kein Strukturgewinn.

Die Forschung zur Standortwahl bestätigt das: Visser und van Solingen (2009) entwickelten ein Routing-Modell für FTS, das neben dem optimalen Zeitzonenversatz auch die „natürliche Leichtigkeit der Kommunikation" – also Kultur und Sprache – als gleichwertigen Faktor identifiziert.

📌 Culture Fit: Der unterschätzte Erfolgsfaktor

Und hier trennt sich die Spreu vom Weizen.

Die IBM-Fallstudien zeigen es deutlich: Das Team USA/Australien funktionierte, das Team USA/Indien scheiterte. Nicht wegen der Zeitzone – die war sogar ähnlich ungünstig. Sondern wegen kultureller Differenzen in der Kommunikation.

Ein QA-Team in Auckland schreibt dir einen Bug-Report, der klar sagt, was kaputt ist. Direkte Kommunikation. Eigenständiges Arbeiten. Konstruktiver Umgang mit Fehlern. Die neuseeländische Arbeitskultur ist stark europäisch geprägt – mit der pragmatischen Direktheit, die deutschsprachige Teams schätzen.

Wer schon einmal mit Offshore-Teams gearbeitet hat, in denen „Ja" nicht „Ja, verstanden" bedeutet, weiß: Culture Gap kostet mehr als jede Zeitzone einspart.

Van Solingen und Valkema (2010) untersuchten in einem kontrollierten Experiment den Einfluss der Anzahl von FTS-Standorten auf Geschwindigkeit und Genauigkeit. Ihr Ergebnis: Mehr Standorte erhöhen die Geschwindigkeit, aber die Genauigkeit leidet – ein starkes Argument dafür, mit zwei Standorten zu starten und die Komplexität bewusst niedrig zu halten.

🚀 Voraussetzungen: Was du brauchst, bevor du startest

FTS in der QA ist kein Plug-and-Play-Modell. Basierend auf den in der Literatur identifizierten Best Practices und meiner eigenen Projekterfahrung gibt es klare Voraussetzungen:

Technisch brauchst du eine funktionierende CI/CD-Pipeline, automatisierte Deployments, ein gemeinsames Issue-Tracking-System (Jira, Azure DevOps) und einen klar definierten Testdatenansatz.

Prozessual brauchst du eine saubere Definition of Done, strukturierte Handoff-Protokolle und eine Testautomatisierungsstrategie. Die Forschung von Kroll et al. (2014) zu Handoff-Management identifiziert neun Aspekte, die für effiziente Übergaben entscheidend sind – darunter Kommunikationsqualität, Wissenstransfer und klar definierte Zeitregeln.

Kulturell brauchst du Teams, die eigenständig arbeiten können, Bug-Reports schreiben, die ohne Rückfrage verständlich sind, und eine Arbeitskultur, in der Fehler offen benannt werden.

Ohne diese Grundlagen wird FTS in der QA nicht funktionieren. Das ist keine Einschränkung – das ist eine Qualitätsschwelle, die ohnehin erreicht werden sollte.

📌 Weiterführende Quellen

Wer tiefer einsteigen möchte, findet hier die wichtigsten Referenzen:

• 🔹 Carmel, E., Espinosa, J. A. & Dubinsky, Y. (2010): „Follow the Sun" Workflow in Global Software Development. Journal of Management Information Systems, 27(1), 17–38. – Die grundlegende wissenschaftliche Arbeit zu FTS mit formaler Definition und Analyse der Erfolgsbedingungen.

• 🔹 Treinen, J. J. & Miller-Frost, S. L. (2006): Following the Sun: Case Studies in Global Software Development. IBM Systems Journal, 45(4), 773–783. – Zwei IBM-Fallstudien (USA/Australien erfolgreich, USA/Indien gescheitert), die die Bedeutung von Kultur und Kommunikation belegen. (IEEE Xplore)

• 🔹 Kroll, J., Hashmi, S. I., Richardson, I. & Audy, J. L. (2013): A Systematic Literature Review of Best Practices and Challenges in Follow-the-Sun Software Development. IEEE ICGSEW, 18–23. – Umfassende Übersicht mit 36 Best Practices und 17 Herausforderungen.

• 🔹 Kroll, J., Richardson, I., Audy, J. L. & Fernandez, J. (2014): Handoffs Management in Follow-the-Sun Software Projects. HICSS, 331–339. – Neun Schlüsselaspekte für effizientes Handoff-Management.

• 🔹 Visser, C. & van Solingen, R. (2009): Selecting Locations for Follow-the-Sun Software Development. IEEE ICGSE, 185–194. – Routing-Modell zur Standortwahl mit den Dimensionen Zeitzone und Kommunikationsleichtigkeit.

• 🔹 Van Solingen, R. & Valkema, M. (2010): The Impact of Number of Sites in a Follow-the-Sun Setting on Working Speed and Accuracy. IEEE ICGSE, 165–174. – Kontrolliertes Experiment zum Einfluss der Standortanzahl.

• 🔹 Übersichtsseite: follow-the-sun.github.io – Gute akademische Gesamtübersicht über den State of the Art.

• 🔹 Wikipedia: Follow-the-sun – Aktuelle Übersicht mit Verweis auf den Larian Studios-Erfolgsfall.

📋 Fazit: Struktur schlägt Kapazität

Das QA-Bottleneck am Sprint-Ende ist eines der hartnäckigsten Probleme in agilen Teams. Die meisten Lösungsversuche setzen an der falschen Stelle an – sie erhöhen Kapazität, statt die Struktur zu ändern.

Follow the Sun in der QA ist kein revolutionäres Konzept. Es ist eine pragmatische Anwendung eines 30 Jahre alten Prinzips auf ein konkretes, messbares Problem. Die Forschung liefert die theoretische Grundlage, die Praxis zeigt: Es funktioniert – wenn Culture Fit und Prozessreife stimmen.

Fang mit einer Frage an: Wie viele Entwicklungstage verliert dein Team pro Sprint an den QA-Stau?