Follow-the-Sun-Entwicklung: Wie Hamburg + Ho Chi Minh City = Engineering rund um die Uhr

Ein Sprint muss nicht pausieren, wenn Ihr europäisches Team seinen Arbeitstag beendet. Follow-the-Sun-Entwicklung verlängert produktive Engineering-Stunden über Zeitzonen hinweg und verkürzt Lieferzyklen, ohne dass jemand außerhalb der normalen Geschäftszeiten arbeiten muss. Für Unternehmen, die schneller liefern möchten, ohne den Personalbestand zu erhöhen, ist dies eines der am wenigsten genutzten Modelle in der verteilten Softwareentwicklung.

Die Herausforderung besteht darin, dass die meisten Teams, die behaupten, dieses Modell zu nutzen, es in der Praxis nicht tun. Dies sind die tatsächlichen Anforderungen des Modells – und wie Gradion es zwischen Hamburg und Ho Chi Minh City umsetzt.

Was ist Follow-the-Sun-Softwareentwicklung?

Follow-the-Sun (FTS) ist, in den Worten von Carmel, Espinosa und Dubinsky, Forschern, deren Arbeit das akademische Fundament für dieses Modell legte, eine Art globaler Wissens-Workflow, der darauf ausgelegt ist, die Time-to-Market zu verkürzen. Die Arbeit wird zwischen geografisch verteilten Teams übergeben, sobald jeder Standort seinen Tag beendet. Das eingehende Team übernimmt direkt. Die Entwicklung geht weiter.

Mit zwei Standorten verlängert sich die produktive Arbeitszeit auf 16 Stunden pro Tag. Mit drei Standorten auf 24. IBM hat diesen Ansatz Mitte der 1990er Jahre als Pionier eingeführt. Der erste Versuch scheiterte – nicht weil die Idee falsch war, sondern weil die täglichen Übergaben nicht konsequent durchgeführt wurden.

Das ist die Erkenntnis, die die meisten Beschreibungen verfehlen. Follow-the-Sun ist keine Zeitzonen-Regelung. Es ist eine Disziplin. Die Zeitzone ist die Voraussetzung. Die Disziplin ist das, was die Ergebnisse liefert.

Warum Hamburg und Ho Chi Minh City?

Hamburg arbeitet im Winter nach CET (UTC+1) und im Sommer nach CEST (UTC+2). Ho Chi Minh City arbeitet ganzjährig nach ICT (UTC+7). Der Versatz beträgt im Sommer 5 Stunden und im Winter 6 Stunden.

Gradion betreibt außerdem einen Engineering-Hub in Cairo. Ägypten arbeitet ganzjährig nach EET (UTC+2); die Sommerzeit wurde 2011 abgeschafft. Damit liegt Cairo in derselben Zeitzonenzone wie Hamburg: im Sommer identisch, im Winter eine Stunde voraus.

Im FTS-Sinne bilden Hamburg und Cairo zusammen einen westlichen Anker – keine zwei unabhängigen Übergabepunkte. Sie teilen das europäische und MENA-Morgenfenster, vertiefen die gemeinsame Engineering-Kapazität auf der westlichen Seite und erweitern Gradions Marktabdeckung in der MENA-Region. Die Arbeit wird am Ende des europäischen und MENA-Tages nach Osten an HCMC übergeben und kehrt am folgenden Morgen zum westlichen Team zurück.

Dies schafft ein natürliches Überschneidungsfenster. Hamburg und Cairo starten um 09:00 Uhr Ortszeit. HCMC ist zu diesem Zeitpunkt um 14:00 ICT – mitten am Nachmittag, in voller Produktion. Ein strukturiertes Sync von 09:00 bis 11:00 CET gibt beiden Seiten gemeinsamen Kontext. Die westlichen Teams übergeben dann die Arbeit. HCMC trägt sie bis in den Abend.

Wenn HCMC um 18:00 ICT schließt, ist es in Hamburg bereits 12:00–13:00 CET des folgenden Tages. Die erledigte Arbeit wartet bereits. Die Überprüfung beginnt. Der Zyklus geht weiter.

Sechzehn produktive Engineering-Stunden. Niemand arbeitet außerhalb der normalen Arbeitszeiten. Keine Heldenleistungen erforderlich.

Hier spiegelt der Gradion-Fußabdruck auch etwas Tieferes wider als reine Zeitzonen-Mathematik. Hamburg bringt deutschen Engineering-Rigorismus, strukturierte Architekturentscheidungen, disziplinierte Dokumentation und präzise Übergabestandards. Cairo ergänzt den westlichen Anker durch MENA-Marktnähe und Engineering-Tiefe. HCMC bringt Liefergeschwindigkeit, hohes Output-Volumen, schnelle Iteration und ein erfahrenes Engineering-Team, das auf Bewegung ausgelegt ist. Zusammen decken sie nicht nur mehr Stunden ab. Sie decken mehr Terrain ab.

Was macht es in der Praxis funktionsfähig?

Kroll et al. (2013) haben 36 Best Practices in Follow-the-Sun-Implementierungen untersucht. Ihre Erkenntnis: Die Qualität der Übergabe ist der mit Abstand entscheidendste Faktor. Schlechter Kontexttransfer ist der Punkt, an dem FTS scheitert – nicht Zeitzonenlücken oder kulturelle Unterschiede.

In der Praxis erfordert ein funktionierender FTS-Workflow vier Dinge:

• Strukturierte Übergabedokumentation. Jede Aufgabe, die zwischen Standorten übergeben wird, muss ihren aktuellen Status, offene Blocker, getroffene Entscheidungen und die nächste erforderliche Aktion enthalten. Eine mündliche Übergabe über Zeitzonen hinweg ist keine Übergabe. Es ist eine Annahme, die Stunden kosten wird.
• Feste Überschneidungszeiten. Das Überschneidungsfenster dient nicht dem Aufholen. Es dient der Abstimmung. Blocker lösen. Prioritäten bestätigen. Unklarheiten beseitigen, bevor das empfangende Team ohne Unterstützung arbeitet. Bei Gradion ist dieses Fenster fest, nicht flexibel.
• Async-first-Kommunikation. Außerhalb des Überschneidungsfensters arbeiten beide Teams asynchron. Entscheidungen können nicht auf ein Live-Gespräch warten. Dokumentation, asynchrone PR-Reviews und schriftliche Architekturentscheidungen sind kein Overhead. Sie sind das Betriebssystem.
• Continuous-Delivery-Infrastruktur. Automatisierte Pipelines, gemeinsame Umgebungen und Testabdeckung sind nicht verhandelbar. Ein Build, den nur das Hamburger Team ausführen kann, bedeutet jedes Mal eine sechsstündige Verzögerung, wenn HCMC ihn benötigt.

Was Follow-the-Sun nicht ist:

FTS wird häufig behauptet und selten praktiziert. Treinen und Miller-Frost (2006) dokumentierten in einer IBM Systems Journal-Fallstudie sowohl erfolgreiche als auch gescheiterte FTS-Implementierungen. Der häufigste Fehler: Teams, die parallel statt sequenziell arbeiten. Beide Standorte waren aktiv. Keiner baute auf dem Output des anderen auf. Das Ergebnis waren Doppelarbeit, Merge-Konflikte und Koordinationsaufwand, der den Zeitzonenvorteil vollständig zunichte machte.

Ein Anbieter, der sein Modell als Follow-the-Sun beschreibt, aber seinen Übergabeprozess nicht beschreiben kann, betreibt kein FTS. Er betreibt ein verteiltes Team mit besserem Marketing.

Die Unterscheidung führt zu unterschiedlichen Ergebnissen. Parallel verteilte Entwicklung skaliert Kapazität. Follow-the-Sun-Entwicklung skaliert Geschwindigkeit. Erstere fügt Engineers hinzu. Letztere komprimiert den Kalender.

Das Gradion-Modell in der Praxis

Gradions Setup wurde von Anfang an nach FTS-Prinzipien konzipiert – nicht nachträglich auf eine bestehende Struktur aufgesetzt.

Das Hamburger Team verankert Kundenbeziehungen, Architekturentscheidungen und Sprint-Verantwortung. Cairo stärkt den westlichen Anker und erweitert Engineering-Tiefe sowie MENA-Marktabdeckung in derselben Zeitzonenzone. HCMC trägt das primäre Engineering-Volumen als vollwertiger Delivery-Partner – kein Ressourcenpool.

Übergaben werden schriftlich dokumentiert. Überschneidungsfenster sind geschützt. Asynchrone Kommunikation ist der Standard, nicht der Ausweichplan.

Für Kunden bedeutet das: Ein Blocker, der um 17:00 CET gelöst wird, wartet nicht bis 09:00 Uhr des folgenden Morgens. Er wird noch am Abend in HCMC aufgegriffen. Das Ergebnis liegt bereit, wenn Hamburg und Cairo öffnen.

Über einen Sprint, über ein Quartal hinweg ist diese Kompression messbar. Sie ist auch der Grund, warum das Modell Governance erfordert – nicht nur Geografie – um die Lieferung im großen Maßstab zu sichern.

Was Sie einen Follow-the-Sun-Anbieter fragen sollten

Wenn Sie prüfen möchten, ob ein Anbieter wirklich nach FTS-Prinzipien arbeitet, stellen Sie drei Fragen:

1. 1. Wie dokumentieren und übergeben Sie Arbeit zwischen Standorten am Ende des Tages? Wie sieht das Übergabedokument aus?
2. 2. Was ist Ihr festes Überschneidungsfenster und wer muss daran teilnehmen?
3. 3. Wie gehen Sie mit einem Blocker um, der nach der Übergabe auftritt?

Ein Anbieter, der alle drei Fragen konkret beantwortet, betreibt das Modell. Ein Anbieter, der seine Zeitzonenabdeckung beschreibt, aber nicht seinen Übergabeprozess, tut es nicht.

Follow-the-Sun-Entwicklung ist eine Entscheidung für ein Betriebsmodell. Die Geografie macht es möglich. Die Disziplin lässt es funktionieren.

Quellen

• Carmel, Espinosa & Dubinsky (2010), Follow-the-Sun Software Development, Journal of Management Information Systems
• Treinen & Miller-Frost (2006), IBM Systems Journal, successful and failed FTS case studies
• Kroll et al. (2013), systematic literature review, 36 FTS best practices identified
• Wikipedia, Follow-the-sun (citing Carmel, Dubinsky & Espinosa, 2009, Hawaii International Conference on System Sciences)
• Timezone offsets: CET UTC+1, CEST UTC+2, EET UTC+2 year-round (Egypt abolished DST 2011), ICT UTC+7