Most conversations about AI and Agile stay abstract: faster, cheaper, leaner — without a real programme to test the claim against. This article uses one. It is a field case I led: a public-health mobile application built for a leading life-sciences company in France, delivered the classical way — a discovery week on client premises, Design Thinking, a distributed nearshore squad, sprint after sprint. I still remember walking out of that first week with a clickable prototype in my hands; that part of the job hasn't dated at all, whatever the delivery model underneath it. The client and delivery vendor are intentionally not named here, in line with how the underlying engagement documentation itself was written; what matters is the shape of the programme, not the logo.
The first half below is what actually happened. The second half is a deliberate projection: the same scope, the same governance intent, rebuilt around spec-driven development and AI-augmented delivery practices as they stand today. The numbers in Part II are planning assumptions, clearly labelled as such — useful for sizing a conversation with your own steering committee, not a certified estimate.
Part I — The classical Agile journey, as delivered
A one-week discovery on client premises
The programme began with a full week of discovery on the client's premises in France. The team — a Scrum Master, a Business Analyst and a UX/UI Designer — worked in direct contact with doctors, virologists and mathematicians from the client's own scientific teams, who had already built the epidemiological model the application needed to expose. That proximity mattered: it built trust and a shared vocabulary between a technical delivery team and a scientific client organisation that had never worked together before.
The week ran as a structured Design Thinking sprint: mind-mapping the problem space, wireframing in Figma, iterating toward interface designs and user workflows, and converging on a clickable prototype. By the end of the week the team walked out with a first list of features, an estimation and timeline, and — critically — a first sprint backlog for the MVP phase, ready to hand to the delivery squad.
A one-week discovery on client premises turned a scientific model into a clickable prototype, a feature list and a first sprint backlog — the artefacts a distributed team needed to start building with confidence.
The nearshore virtual squad
Once discovery closed, the team flew back to a nearshore delivery centre in Romania and reformed as a distributed virtual squad. Ten people, fully cross-functional: 1 Scrum Master, 1 Business Analyst, 1 UX/UI Designer, 2 front-end developers, 2 back-end developers, 2 QA engineers and 1 DevOps engineer. On the client side, governance stayed lean by design: one Product Owner and one executive Sponsor, aligned with the delivery squad through the Scrum Master and the Business Analyst who had been on the ground in Paris.
Client side: Product Owner and Sponsor. Delivery side: Scrum Master, Business Analyst, UX/UI Designer, front-end, back-end, QA and DevOps — 10 FTE in a single nearshore squad.
This is the part of "nearshore Agile" that rarely makes it into a slide, and it's the part I've spent most of my career arguing for: the people who ran discovery did not hand off to strangers. The Scrum Master and Business Analyst who had sat across the table from the client's virologists were the same people grooming the backlog with the squad every sprint after. Continuity of context, not just proximity of time zone, is what made the handoff work.
MVP, then three more releases
Delivery ran in iteration mode, MVP-based and time-boxed — sprints of two to four weeks, opening with a daily stand-up and closing on a potentially shippable increment, exactly as the team's own delivery model describes it.
| Release | Scope | Cadence |
|---|---|---|
| MVP | Core forecast map and weekly case-trend view, built from the client's mathematical model | ~1 month from discovery kickoff |
| Release 2 | Additional countries and features beyond the initial France scope | Following sprints |
| Release 3 | A COVID-19 extension module, added as the pandemic reshaped the product's relevance | 2 sprints |
| Release 4 | Native iOS and Android availability, beyond the initial web/mobile-web scope | Following sprints |
What this model got right — and where it strained
The classical model delivered. An MVP shipped in about a month from a standing start; the client got a working, trusted relationship with a distributed team it had met for exactly one week; and the roadmap kept extending gracefully, including an unplanned pandemic-driven module built in just two sprints. That is a genuinely strong outcome for 2020-era delivery practice.
The model's strength was continuity of context across the handoff from discovery to delivery. Its cost was that every one of those ten people had to be staffed, ramped up and kept busy for the life of the programme — regardless of how the workload actually moved sprint to sprint.
It also strained in predictable places. The discovery week's outputs — wireframes, workflows, a feature list — were rich but still narrative: they had to be re-read, re-interpreted and re-negotiated by the squad sprint after sprint, with the Business Analyst as the human bridge between scientific intent and engineering backlog. Testing and environment work were largely manual and person-dependent. And little of the design system or specification logic carried forward automatically from one release to the next — each extension re-earned its estimation and its own sprint of ramp-up.
Part II — The same programme, rebuilt for spec-driven, AI-era delivery
Spec-driven development flips the default artefact of a programme like this. Instead of a narrative backlog that a human re-interprets every sprint, discovery produces a structured, versioned specification — features, user flows, data contracts, acceptance criteria — that both humans and AI coding agents build directly against. The spec becomes the executable source of truth, not a slide deck that everyone privately reinterprets.
Discovery, compressed, not skipped
The on-premises week does not disappear — direct contact with the client's scientists is still the fastest way to earn trust and extract tacit knowledge no document captures. What changes is what happens inside it. AI-assisted transcription and synthesis turn workshop conversations into structured requirements in near-real time; AI-generated wireframe variants let the UX/UI Designer explore three interface directions in the room instead of one after the fact; and the week's output is authored directly as a machine-readable spec rather than a set of slides a remote team will later transcribe into a backlog. A realistic compression: one week on premises becomes two to three days.
A four-person AI-augmented squad
The ten roles of 2020 do not survive unchanged — several merge, augmented by AI tooling that absorbs the mechanical part of each role and leaves the judgment part with a person.
| Dimension | 2020 — classical Agile | 2026 projection — spec-driven, AI-augmented |
|---|---|---|
| Delivery team size | 10 FTE | 3–4 FTE |
| Discovery duration | 1 week on premises | 2–3 days, hybrid |
| Time to MVP | ~4 weeks | 2–3 weeks |
| Full 4-release roadmap | ~6 months | ~3–4 months |
| Core practice | Narrative backlog, re-interpreted every sprint | Versioned spec as executable source of truth |
| Governance | PO + Sponsor + Scrum Master as human bridge | PO + Sponsor + Spec Lead, with AI-generated traceability from spec to code |
The roadmap compresses by roughly half, not by an order of magnitude — and that ceiling is deliberate, not a shortfall of the tooling. AI collapses engineering time: scaffolding, refactoring and test-writing that used to consume most of a sprint. It does not collapse the calendar time that was never engineering time in the first place — native app-store review cycles for the Release 4 iOS/Android rollout, clinical and regulatory validation of anything a patient reads, multi-country coordination for Release 2, and the client-side governance cadence that a Sponsor and Product Owner reasonably expect for a health-facing product. A programme that claimed to fold six months into six weeks would be quietly cutting one of those, not genuinely accelerating all of them.
What this might cost — and the assumptions behind the number
The naive calculation — roughly 60% fewer people delivering in about half the elapsed time — implies delivery cost falling by around 80%. That figure is not credible, and using it would undersell the real economics of AI-era delivery. Three offsetting factors matter:
- AI-augmented profiles are more senior by necessity — someone directing a coding agent and reviewing its output responsibly commands a premium over a traditional mid-level developer, typically 20–30% more per head.
- AI tooling, model inference and agent-governance overhead are a new, non-trivial cost line that simply did not exist in the 2020 baseline.
- Client-side governance, regulatory review and human accountability for anything patient-facing do not compress at the same rate as engineering throughput — and should not.
Netting those factors against the smaller team and shorter timeline, a defensible planning assumption is a 45–60% reduction in total delivery cost versus the 2020 baseline — a strong number, but well below what the naive headcount-times-duration math would suggest. Treat this as an order-of-magnitude planning assumption to open a budget conversation, not an audited estimate.
What doesn't change
None of this touches who is accountable for what ships. In a regulated, health-facing programme, a human still has to own clinical accuracy, data governance and the decision to release. AI compresses discovery, generates code against a spec, and drafts its own test coverage — but the specification it builds from, and the judgment call to trust its output, remain a human responsibility on both sides of the engagement.
AI changes who does the work and how fast. It does not change who is accountable for what ships to patients.
The practical implication for any leader reading this as a template: invest the savings from a smaller, faster delivery team into governance capacity you didn't have before — spec review, AI-output auditing, regulatory sign-off — rather than treating the whole delta as margin. That is what separates a genuinely faster delivery model from a faster path to the same old failure modes. I still bring this exact case to clients weighing a similar bet — the maths is the easy part; the discipline to reinvest the savings is the part people skip.
Alin Popovici
Executive advisor, transformation and delivery leader — and a guest lecturer on complex-programme leadership for the Executive MBA at Bucharest Business School (ASE Bucharest, in partnership with CNAM Paris).