From AAA Structure to On-Demand Agile: Scaling a Tier-1 Co-Development Team from 8 to 35

Context

After Metro Awakening I moved to a very different kind of work. Vertigo had been organised around structured AAA production, with a plan, milestones and established vendor workstreams. The Tier-1 platform partner worked the opposite way: requirements arrived on demand, priorities changed with the client, and the work was free-to-play games and an AI content project that had to ship and then keep changing.

Nothing in the AAA playbook fitted that. The main problem was not any single title. It was that the delivery processes for this kind of programme did not exist yet.

My role

I was the Senior Producer dedicated to this client. My job was to create the operating model from scratch: take a team used to structured AAA and make it work in a super-agile, client-driven way, and then scale it.

What I did

• New processes, built from scratch. Replaced plan-driven AAA delivery with Scrum, so that the team could take in changing client requests and still deliver predictably.
• Scaling the team. Grew a single Scrum team from 8 to 35 FTE while the programme was running, keeping the way of working intact as people joined.
• Two external studios, fully integrated. A UX/UI studio and a co-development studio, assigned by the client. I set up all the processes with them and integrated them completely into our production pipeline, so they worked as an extension of our own resources and effectively scaled the team up.
• Daily themed syncs. Communication ran on a daily rhythm of themed meetings: a design sync, a tech sync, a production sync and syncs with partners.
• Stakeholder management. On the client side: three project producers, a developer relations engineer, a QA lead and the heads of separate services. Inside Vertigo: the agency director, the creative director and the game director.
• Getting the team through the change. The team found the switch from a familiar flow to super-agile cycles hard, which caused misunderstanding and conflict. I agreed a "good enough" quality criterion with the client. It gave us room on quality and let us work in the cycle the client expected.
• Three free-to-play projects. Delivered three projects. One game is released and supported live. The other two are completed and not yet released: an unannounced IP with an AI-powered content editor (AI generation of content in the platform’s editor, for the desktop version of the platform) and an unannounced mobile remake of a flagship VR IP. The games first ran on server-side rendering and later inside an app from which they were launched.
• Live-service iteration on data. Used A/B testing to decide what to change after launch, instead of relying on opinions.

Result

• A Scrum team scaled from 8 to 35 FTE.
• Two externally assigned studios (UX/UI and co-development) run simultaneously and fully integrated into the production pipeline.
• Three free-to-play projects delivered, one of them launched and supported live; the other two completed and not yet released.
• A repeatable way of working for on-demand, client-driven development, where there had been none, including a "good enough" quality criterion agreed with the client.

A note on confidentiality

The client and the unannounced projects are covered by NDA, so this case does not name them. Details can be discussed in an interview, within what the agreements allow.

What I would take from this

• Process is a product too. When the client's way of working changes, the delivery model has to be redesigned deliberately, not stretched.
• Scaling a team is mostly scaling its habits. Growth from 8 to 35 worked only because the way of working was clear before the new people arrived.
• In live service, data replaces debate: A/B tests settle most of the arguments about what to build next.
• A shared definition of "good enough" ends many quality arguments. Agreeing it with the client turned a conflict inside the team into a delivery rule.