How We Helped Tesco Mobile Ship Weekly Instead of Monthly

The challenge

Releases were monthly, production bugs were a recurring problem, and the QA process was a bottleneck rather than a safety net. The test suite depended on live API availability — any instability in the API team's environment meant delayed feedback, flaky runs, and developers sitting idle. Quality was reactive, not preventative.

What we did

1. 1

   Embedded full-stack delivery team

   We took end-to-end ownership — engineers, QA, a business analyst, and production deployments — so Tesco Mobile had one team accountable for the full delivery lifecycle, not a patchwork of vendors and internal contributors pointing at each other.

2. 2

   Decoupled QA from the API team

   We introduced a mock-based Appium strategy that replaced live API dependency with controlled mock services. Tests that previously required a stable end-to-end environment now ran in isolation. Developers got feedback in minutes, not hours — and the API team's release schedule stopped being a blocker for mobile QA.

3. 3

   Two-week sprints with data-driven decisions

   Every sprint was structured around business analytics data, not gut feel. We ran demos at the end of each cycle so stakeholders had continuous visibility — no waiting until a monthly release window to see what the team had shipped.

4. 4

   Engineering knowledge transfer

   We ran engineering talks inside Tesco Mobile throughout the engagement — explaining how the QA model worked, why we made the decisions we did, and how the team could evolve it after we stepped back. This wasn't a handover at the end; it was woven into the work from the start.

The outcome

Stack & approach