Not because your team is too slow. But because your QA sits in the same location as your developers.

Every Scrum Master knows the pattern: the last two days of a sprint belong to QA. Developers twiddle their thumbs or start new stories that are guaranteed not to finish. The result: carry-over. Sprint after sprint.

The usual response? Form a separate QA team that works "vertically" across multiple Scrum teams. That solves one problem—and creates three new ones.

Over recent years, I've repeatedly observed the same pattern across my projects. It became particularly evident when managing multinational teams for a company-wide data platform in automotive development—there the problem with vertical QA structures showed its full impact: The QA bottleneck at sprint-end isn't a capacity problem. It's a timezone problem.

📌 The QA Bottleneck: A Structural Problem

The root of the problem isn't lacking QA capacity. It's the fact that development and testing happen within the same eight hours.

When your developer makes their last commit at 5 PM, QA can only start testing the next morning. If they find a bug, the fix goes out at midday at the earliest. QA checks it in the afternoon. One bug-fix cycle takes at least 24 hours. Multiply that by the typical bugs at sprint-end—and you understand why two buffer days are never enough.

Anyone browsing the forums on Scrum.org quickly encounters the same discussion: "How does testing happen for stuff developed on the last day of sprint?" The honest answer from experienced practitioners there: Not properly. Not within the same sprint. (scrum.org/forum)

📌 Follow the Sun: A Proven Concept—Newly Applied

The "Follow the Sun" model (FTS) originated in the 1990s. IBM was one of the first companies to set up global software teams that handed work along timezones. The fundamental concept was academically developed by Erran Carmel, Alberto Espinosa, and Yael Dubinsky and published in the Journal of Management Information Systems (Carmel, Espinosa & Dubinsky, 2010). Their research shows: with two locations, productive working time can theoretically increase to up to 16 hours per day.

Carmel introduced the concept of "Calendar Efficiency"—the proportion of available calendar time (168 hours per week) that's actually used productively. A normal 40-hour week uses just 23.8 percent. Overtime improves this by a few percentage points, with known side effects. An optimal FTS configuration can increase calendar efficiency to up to 71.4 percent according to Carmel's analysis.

The approach is primarily used in support today. But it delivers its greatest impact in an area that's surprisingly rarely considered: QA.

❓ Why QA Specifically?

Research literature—summarised in an overview at follow-the-sun.github.io—reaches an interesting conclusion: FTS works best for activities with low handoff dependencies. Testing is perfectly suited for this because the "handoff artefacts" are clearly defined: a build, a test environment, a CI/CD pipeline.

A systematic literature analysis by Kroll et al. (2013) identified 36 best practices and 17 challenges for FTS. The three most important success factors: agile methods, technology for knowledge sharing, and process documentation. Exactly the things that are already present in a well-established QA process.

❓ How It Works in Practice

The idea is simple:

Your development team sits in the DACH region (CET/CEST). Your QA team sits in a complementary timezone—for example, New Zealand (NZST), Australia, or Southeast Asia.

Your developer makes their last commit at 5 PM German time. At 6 PM, the working day begins in Auckland. The QA team has a full eight hours to test against the CI/CD pipeline, document bugs, and prepare results.

When your development team boots up their computers at 9 AM the next morning, the overnight test results are waiting. Bugs can be fixed immediately. The QA in New Zealand checks the fix in their next shift.

One bug-fix cycle: under 24 hours. No overtime. No night shifts.

📌 The IBM Experience: Where FTS Works—and Where It Doesn't

Those interested in the scientific foundation will find two instructive cases in the IBM case study by Treinen and Miller-Frost (2006). The first: a team distributed between the USA and Australia—successful. The second: teams in the USA and India—failed. The reasons for failure: misunderstandings in interpreting specifications, multiple rework cycles, lack of coordination, and—crucially—cultural differences.

These case studies confirm an observation I've repeatedly made over 23 years of project work: timezones are only half the equation. The other half is culture fit.

Incidentally, Wikipedia documents one of the most prominent current FTS successes: Larian Studios developed Baldur's Gate 3 with six studios worldwide—including Ghent, Dublin, Kuala Lumpur, and Quebec—using a Follow-the-Sun model. The result: one of the most successful RPGs in recent years, developed without the typical crunch phases of major game studios.

❓ What This Means for Your Sprint

In a traditional setup, you lose the last one to two days of every sprint to the QA bottleneck. Developers can't continue working because then no QA would be possible.

With a Follow-the-Sun QA model, the equation changes: development and QA run in parallel—but time-shifted. Your team can develop for a full day longer because QA in the complementary timezone always has a complete working day available.

In a 10-day sprint, that's effectively one to two additional development days. This isn't a productivity gain through more pressure. This is a structural advantage through smarter organisation.

💰 What This Costs in Person-Days

Let's calculate conservatively. A typical team: 5 developers, 2 QA specialists, 14-day sprints (10 working days).

If developers must stop developing new features on average 1.5 days before sprint-end—because otherwise QA can't get through—that's:

5 developers × 1.5 days × 26 sprints per year = 195 person-days.

At an average daily rate of $1,200 NZD, that's over $230,000 NZD in lost development capacity. Per year. Per team. Not because someone works poorly. But because the structure doesn't allow otherwise.

A Follow-the-Sun QA model gives you most of that back.

📌 This Pays Off Even for Small Projects

Follow the Sun sounds like it's for corporations with hundreds of developers. Actually, the model pays off from a single Scrum team onwards.

The reason: the QA bottleneck hits small teams harder. In a 5+2 team, a single lost development day carries more weight than in a programme with ten teams. The relative capacity loss is higher.

And: a QA team in a complementary timezone doesn't need to be large. Two experienced testers in Auckland working against your CI/CD pipeline are perfectly adequate for a Scrum team in Berlin.

The entry barrier isn't team size. It's process maturity. You need a functioning CI/CD pipeline, automated deployments to test environments, and a clean test data strategy. Without these foundations, a timezone offset makes little sense—then your QA team spends eight hours testing against a broken environment.

📌 The DevOps Bonus: QA Plus Troubleshooting

The model becomes particularly interesting when your QA team doesn't just test.

In a DevOps approach where QA specialists also bring basic troubleshooting skills—log analysis, monitoring checks, first-level incident response—you gain an additional advantage: your European development team sleeps. Your QA team in New Zealand tests the new features—and simultaneously monitors the production environment.

When an alert comes at night, someone sits at the computer who knows the system. No on-call duty. No night shift. No response time of hours.

This isn't a replacement for a full ops team. But it's a pragmatic extension that kills two birds with one stone: QA capacity and night coverage. Particularly for SMEs who can't afford a dedicated 24/7 operations team, this is considerable added value.

📌 Which Timezone Works?

Mathematically, three regions work particularly well for a development team in the DACH region:

New Zealand (CET+11 to +12) – nearly perfectly complementary. 5 PM Berlin = 6 AM Auckland. Full eight hours of QA before your team boots up their computers in the morning.

Australia (CET+8 to +9) – works, with more afternoon overlap. Good when synchronous coordination is more important.

Southeast Asia (CET+5 to +7) – temporally in the window but with significantly less offset. Better suited for teams needing more overlap.

India (CET+3:30) is too close. Your QA team works in the middle of your working day. This shifts the bottleneck, it doesn't solve it.

South America (CET-4 to -6) has the same problem—just the other way around. 5 PM in Berlin is noon in São Paulo. No night offset, no structural gain.

Research on location selection confirms this: Visser and van Solingen (2009) developed a routing model for FTS that identifies not only optimal timezone offset but also the "natural ease of communication"—culture and language—as an equally important factor.

📌 Culture Fit: The Underestimated Success Factor

And here's where the wheat separates from the chaff.

The IBM case studies show it clearly: the USA/Australia team worked, the USA/India team failed. Not because of timezone—which was even similarly unfavourable. But because of cultural differences in communication.

A QA team in Auckland writes you a bug report that clearly states what's broken. Direct communication. Independent working. Constructive handling of errors. New Zealand's work culture is strongly European-influenced—with the pragmatic directness that German-speaking teams appreciate.

Anyone who's worked with offshore teams where "Yes" doesn't mean "Yes, understood" knows: culture gap costs more than any timezone saves.

Van Solingen and Valkema (2010) examined the influence of the number of FTS locations on speed and accuracy in a controlled experiment. Their result: more locations increase speed, but accuracy suffers—a strong argument for starting with two locations and keeping complexity deliberately low.

🚀 Prerequisites: What You Need Before You Start

FTS in QA isn't a plug-and-play model. Based on best practices identified in the literature and my own project experience, there are clear prerequisites:

Technically you need a functioning CI/CD pipeline, automated deployments, a shared issue tracking system (Jira, Azure DevOps), and a clearly defined test data approach.

Process-wise you need a clean definition of done, structured handoff protocols, and a test automation strategy. Research by Kroll et al. (2014) on handoff management identifies nine aspects crucial for efficient handovers—including communication quality, knowledge transfer, and clearly defined time rules.

Culturally you need teams that can work independently, write bug reports that are understandable without follow-up questions, and a work culture where errors are openly addressed.

Without these foundations, FTS in QA won't work. This isn't a limitation—it's a quality threshold that should be reached anyway.

📌 Further Resources

Those wanting to delve deeper will find the most important references here:

• 🔹 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. – The fundamental scientific work on FTS with formal definition and analysis of success conditions.

• 🔹 Treinen, J. J. & Miller-Frost, S. L. (2006): Following the Sun: Case Studies in Global Software Development. IBM Systems Journal, 45(4), 773–783. – Two IBM case studies (USA/Australia successful, USA/India failed) demonstrating the importance of culture and communication. (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. – Comprehensive overview with 36 best practices and 17 challenges.

• 🔹 Kroll, J., Richardson, I., Audy, J. L. & Fernandez, J. (2014): Handoffs Management in Follow-the-Sun Software Projects. HICSS, 331–339. – Nine key aspects for efficient handoff management.

• 🔹 Visser, C. & van Solingen, R. (2009): Selecting Locations for Follow-the-Sun Software Development. IEEE ICGSE, 185–194. – Routing model for location selection with dimensions of timezone and communication ease.

• 🔹 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. – Controlled experiment on the influence of location numbers.

• 🔹 Overview site: follow-the-sun.github.io – Good academic overall view of the state of the art.

• 🔹 Wikipedia: Follow-the-sun – Current overview with reference to the Larian Studios success case.

📋 Conclusion: Structure Beats Capacity

The QA bottleneck at sprint-end is one of the most persistent problems in agile teams. Most solution attempts tackle the wrong point—they increase capacity instead of changing structure.

Follow the Sun in QA isn't a revolutionary concept. It's a pragmatic application of a 30-year-old principle to a concrete, measurable problem. Research provides the theoretical foundation, practice shows: it works—when culture fit and process maturity are right.

Start with a question: How many development days does your team lose per sprint to the QA bottleneck?