Archived from: VK @dodopizzaio / Habr
Author: Anton Bevzyuk
Published: January 31, 2019

Introduction

Dodo Pizza announced plans to “expand our IT team from 49 to 250 developers” in autumn 2018. This article explains the business rationale behind this significant expansion.

Background: Dodo IS and Scale

Dodo Pizza operates as a franchise with over 450 pizzerias across 12 countries, including the USA, UK, and China. The foundation of their franchise model is Dodo IS, an integrated information system managing core business processes in each location.

The development team works simultaneously on multiple systems: mobile applications, websites, CRM, ERP, HRM, and call center platforms. The author notes that “dozens of companies dedicate themselves solely to CRM development,” yet this represents just one component of Dodo IS.

Five Urgent Business Goals

1. Global Expansion Requirements

Adapting systems for 12 different countries demands substantial engineering effort. Examples include configuring cash registers for local tax rates, integrating with regional equipment, and implementing country-specific fiscal procedures. The mobile app currently operates only in Russia and requires localization.

2. Inventory and Stock Management

Current inventory systems lack adequate audit capabilities, resulting in “inadequate data, projection errors, ingredient losses and write-offs.”

3. Product Innovation Complexity

Launching new products like half-and-half pizzas and customizable pizza builders requires coordinated changes across the website, mobile app, kitchen order tracking systems, and inventory logic.

4. Multi-Location Management

Franchisees operating pizzerias in multiple cities need integrated management interfaces and consolidated statistics—currently available only for individual locations.

5. Continuous Improvement Requests

Partners, managers, and customers across all 12 countries submit ongoing feature requests and improvements.

System Stability Challenges

With pizzerias operating 24/7 globally, downtime carries significant costs. The article states: “one minute of downtime costs us about $1,500,” a figure that has doubled annually alongside revenue growth. Technical priorities include decomposing the monolithic system, reducing database workload, and improving failure recovery.

Future Vision

The company is exploring:

• Speech recognition for customer order taking
• Personalization systems for customized customer experiences
• Predictive sales analytics to optimize inventory and reduce waste
• Intelligent delivery routing for faster courier assignment
• Open API enabling third-party pizza ordering applications
• Supplier integration providing transparency on ingredient sourcing and storage conditions
• “Pizzeria of the Future” in China featuring WeChat ordering, digital screens, QR codes, and cashier-less operations

Why 250 Developers Specifically?

Rather than selecting arbitrary numbers like 300 or 500, the company set an ambitious yet achievable goal. Discussions with the CFO revealed that 250 developers over 2 years represented an optimal balance—ambitious enough to drive meaningful change while remaining feasible within financial constraints.

This target influences all organizational decisions: developer onboarding, backlog prioritization, investment allocation, and compensation structures.

Scaling Framework: LeSS Huge

Currently operating with 11 teams where product owners maintain detailed knowledge of all tasks, the company recognizes this model becomes impossible with 50 teams. They’ve adopted LeSS (Large-Scale Scrum), specifically implementing the “LeSS Huge” framework—described as “implementing principles, components, and elegancy of Scrum for 250 people as simply as possible.”

This represents the first LeSS Huge implementation in Russia, with ongoing preparation for the organizational transformation ahead.

Why We Split Into Requirement Areas

When the company had 9 teams working on one product, everyone knew each other and could quickly agree. Despite working on the same product, each team had its own context. Sometimes a team had to postpone other tasks to take on something urgent. With 9 teams, this was still manageable.

Coordinating a backlog with 9 teams creates significant overhead. The Dodo IS system consists of multiple functional areas — back office, mobile applications, kitchen displays, ordering system, etc. Different business indicators are relevant to different areas.

Areas (or Requirement Areas) are organized not by components but by end-to-end user scenarios. Each area can have multiple products and focuses on:

1. On one hand, on customer scenarios where the company can gain traction, acquire customers, and increase retention
2. On the other hand, on business processes where achieving results in any scenario requires IT intervention

This led to dividing into two areas: Management Area and Digital Products Area (later renamed “Acquiring and Retaining Customers”).

Requirement Areas

B2C Area develops features for end customers. Teams focus on revenue and LTV, average check, conversion, and engagement. This area has 4 teams with freedom to experiment within boundaries, as solving the problem requires cooperation with the company.

Teams:

• My Little Coders
• Traction for Abstraction
• Dodo
• nostress

B2B Area develops tools for franchisees. Teams focus on operational efficiency, Labor Cost, Unit Cost, revenue, and EBITDA. Features include pizzeria management tools, kitchen displays, delivery tracking, TV screens, shifts, courier mobile app, and more.

Teams:

• Game of Threads
• Infrastructure
• Fast & Furious
• Dodo!
• Code Monkeys

Each area has an Area Product Owner (APO) who manages the overall direction. The APO doesn’t block teams; rather, they guide teams and set priorities. Within this context, each team has autonomy to decide implementation details.

What Changed

Each area now has its own sprint planning. Sprint planning becomes more manageable focused on area-specific context.

Sprint reviews became more focused. All teams continue to participate but only watch reviews from their area.

Challenges Encountered

1. Teams didn’t immediately divide evenly. Some B2B teams had Android specialists while B2C had iOS expertise. Joint task forces like “Just Talk” and “Traveller” emerged to address cross-area needs.

2. Community building. Some communities hadn’t formed yet; with growing teams, building communities takes time.

3. Shared infrastructure work. In the first year, significant effort went into technical foundation work that wasn’t specific to any area. Some features impacted multiple areas and required dedicated focus.

4. Realized that separating areas from company-wide practices takes time. Building communities is challenging when everyone was already busy.

Benefits Observed

• Overall Sprint events became faster. Sprint planning for 4 B2C teams takes less time than 9 combined. B2B Sprint Review for 7 teams takes about 30 minutes (instead of over an hour). PBR became more focused :)

• Focus. Teams work in smaller area contexts where everything connects. When teams previously spent time understanding unrelated areas, this was waste. Maximizing valuable feature work became possible.

• Multi-Team PBR became more effective. Several teams could coordinate on related backlog items, understanding how their work connected.

Conclusions

• Don’t delay. We waited 8 months, but should have divided sooner given the growing coordination overhead.
• Prepare roles. Having APOs ready helps smooth the transition.
• LeSS Huge works well for product development. Features connect within and across areas.
• Community building matters. “Just Talk” helped, but other practices needed more experimentation.
• Remember from the LeSS guides: “LeSS Huge adoptions take months or years, infinite patience, and sense of humor.”