Agile Scrum is one of the most effective delivery frameworks ever built for software teams. It is also one of the most frequently broken when teams grow beyond a certain size.
What works for 10 people often falls apart at 30, 40, or 60. Standups stretch into status meetings. Sprint planning creates confusion. Ownership becomes unclear. Product-Oriented Delivery, or the POD model, is a response to this scaling problem.
It reorganizes large teams into small, autonomous, cross-functional units. Each POD owns a defined product area. Each POD has clear accountability and the authority to make decisions on its own.
This guide explains what the POD model is, how it differs from standard Scrum, what roles it requires, and how to implement it step by step.
What Is Product-Oriented Delivery?
Product-Oriented Delivery (POD) is a team structure and working model.
A large development effort is broken into small, self-governing, cross-functional teams called PODs. Each POD owns a specific product area or capability end to end.
The term POD stands for Product-Oriented Delivery. A POD is a small group of autonomous team members with complementary skills working toward a shared product goal.
The model is sometimes described using the “squad” terminology popularized by Spotify. PODs and squads are structurally similar, with minor variations in governance. (Source: Kniberg, H. and Ivarsson, A., “Scaling Agile @ Spotify with Tribes, Squads, Chapters and Guilds,” Spotify, October 2012, blog.crisp.se)
The defining traits of a POD are autonomy, cross-functionality, and clear ownership. A POD should be able to plan, develop, test, and deliver its product area without major external dependencies. If it constantly waits on another team for a schema change or a security review, it is not truly autonomous. The typical POD size is eight members, plus or minus two.
Research on team effectiveness shows that teams above 10 to 12 members struggle to maintain shared context and mutual accountability. Below five, the team often lacks the complementary skills needed for genuine autonomy. (Source: Hackman, J.R., “Leading Teams: Setting the Stage for Great Performances,” Harvard Business School Press, 2002; Dunbar, R., “Neocortex size as a constraint on group size in primates,” Journal of Human Evolution, Vol. 22, 1992)
Why Standard Scrum Fails at Scale
Understanding the POD model requires understanding what it is trying to fix.
A typical large-scale Agile failure starts as a growth story. A team of 15 builds something useful and ships. A second team joins. Then a third. Shared ceremonies expand to include everyone.
By the time the program hits 40 or 60 people, several problems are predictable.
Distributed Accountability
With multiple Scrum teams contributing to a shared release, nobody has clear end-to-end ownership.
When a feature fails in integration, the question “who owns this?” has no clean answer. Collective responsibility becomes functionally the same as no responsibility.
Ceremony Overhead
Daily standups, sprint plannings, reviews, and retrospectives designed for 10 people become unwieldy at 40.
A 40-person daily standup where each member speaks for two minutes runs over an hour. The signal-to-noise ratio collapses, and people attend because they are required to, not because they get value from it.
Invisible Work
When the team is too large for anyone to know every member and their current work, progress becomes invisible to leadership and to peers.
Dependency tracking takes over as the primary management activity, replacing value delivery.
Budget Focus Over Value Focus
As programs scale, financial governance intensifies.
Status reporting shifts toward budget and forecast accuracy. The link between individual work and business outcomes becomes abstract. Teams optimize for looking busy rather than showing delivered value.
The POD Model: Structure and Roles
POD Composition
Each POD is a cross-functional unit containing every skill needed to deliver its product area, from requirements to production.
Composition varies by context, but a typical software delivery POD includes:
- A product owner or delivery lead
- One to two frontend engineers
- One to two backend engineers
- A QA engineer
- A DevOps or SRE resource
- A UX designer
The principle is that every skill required to deliver a feature sits inside the POD. External dependencies are kept to a minimum.
A POD can go from requirement to production without waiting for a shared engineering pool, a central QA team, or a separate release management function.
POD Leadership Roles
The POD Lead is the primary accountability owner for the POD.
They manage team communication, internal planning, agile ceremonies, and act as the single point of contact for stakeholders. The POD Lead provides the context that classic Scrum usually splits between Scrum Master and Product Owner.
The Product Owner inside a POD owns the product backlog for that domain.
They prioritize work, accept or reject delivered features, and keep the team focused on the highest-value items.
In data platform or engineering organizations, the POD structure often includes a technical lead (architect or senior engineer), someone who combines product judgement with deep technical context.
Support Roles Across PODs
Not every skill needs to live full time in every POD.
Some capabilities, such as enterprise architecture, information security, data architecture, content strategy, and specialized QA expertise, are more efficient as shared services.
These shared service roles contribute to PODs on a needs basis. They provide specialist input where required without creating bottlenecks in the normal delivery flow.
POD vs Classic Scrum: Key Differences
| Dimension | Classic Scrum | POD Model | Practical Effect |
| Team size | 5 to 9 per team; many teams at scale | 6 to 10 per POD; multiple PODs | POD assigns product area ownership more explicitly |
| Ownership | Scrum team owns sprint backlog | POD owns a product area end to end | Clearer accountability; fewer hand-off disputes |
| Ceremonies | All-team ceremonies at program level | POD-level ceremonies; cross-POD sync | Avoids single 40-person standup |
| Stakeholder contact | Scrum Master filters access | POD Lead manages direct contact | Faster feedback loops |
| Skill composition | Often skill-siloed teams | Cross-functional by design | Fewer inter-team handoffs that create queues |
| Decision authority | Requires scrum team consensus | POD Lead and team decide locally | Faster decisions without program-level consensus |
Implementing the POD Model: A Step-by-Step Approach
Step 1: Diagnose the Current Failure Modes
Before restructuring the team, identify the specific problems the restructure is meant to solve.
Are ceremonies unproductive? Are integration failures creating accountability confusion? Is velocity declining as the team grows? Is stakeholder feedback not reaching contributors?
The POD model solves a specific set of problems. If 12 people are delivering well under classic Scrum, a POD restructure is unnecessary overhead.
The model is warranted when scale is genuinely causing the problems it is designed to fix.
Step 2: Define Product Areas and POD Scope
Map the product to distinct functional domains that can be independently owned and delivered.
For a large enterprise platform, this might be authentication, reporting and analytics, data ingestion, and user management, each owned by a different POD.
The scope definition must be clean enough that PODs can work in parallel without constant cross-POD dependencies.
If every POD’s work requires a shared database schema change every sprint, the domain boundaries are wrong.
Step 3: Staff PODs with Complementary Skills
Assemble each POD with the skills needed to deliver its domain from requirements to production.
Resist the temptation to under-resource individual PODs to avoid reorganizing existing team structures. A POD that lacks QA capability or a DevOps resource will routinely block on those functions, which defeats the autonomy model.
Identify which capabilities should be shared across PODs rather than embedded. Specialized architecture, security, and UX research usually sit in this shared layer.
Define a clear service model for how those resources will be allocated.
Step 4: Establish POD-Level Ceremonies
Each POD runs its own sprint ceremonies.
That includes the daily standup, sprint planning, review, and retrospective. These are the standard Agile ceremonies, now scoped to the POD rather than the full program.
Cross-POD synchronisation requires a separate layer of ceremonies.
A program-level standup, sometimes called a “scrum of scrums,” brings one representative from each POD together. It surfaces cross-POD dependencies without imposing full-team participation. It should be short and focused on blockers, not on status.
Step 5: Connect PODs to Customer and Stakeholder Outcomes
The POD model’s core claim is that connecting teams to customer outcomes improves both delivery quality and team motivation.
POD Leads should maintain direct interaction with the stakeholders and customers relevant to their product area, not filtered through a program management layer.
This requires deliberate access design. Who attends sprint reviews? Who accepts delivered features? Which customer voice reaches the POD backlog?
A POD that knows it is building a real-time monitoring portal for 40 million users behaves differently than a POD that thinks it is delivering “module 3.2.1 of the billing integration.” The former has a mission. The latter has a task list.
Step 6: Define Cross-POD Integration Governance
Autonomy within a POD is not the same as independence between PODs.
Multiple PODs working on different domains must integrate their work into a coherent product. Integration failures are one of the primary risk points in any POD implementation.
Define explicit integration checkpoints. These are moments where PODs synchronise on API contracts, data schemas, shared infrastructure, and release dependencies.
They should be lightweight and frequent rather than comprehensive and infrequent. The goal is early visibility into integration risk, not a waterfall phase at the end of the program.
What to Expect: Benefits and Challenges
Benefits Organizations Typically See
- Faster release cycles: PODs delivering in parallel.
- Clearer accountability: Defects trace back to a single owning POD.
- Better customer connection: Sharper product judgement from direct customer contact.
- Improved team effectiveness: Stronger team effectiveness at the 6 to 10 size range.
- Reduced overhead: Ceremony overhead proportionate to POD size.
Challenges to Anticipate
- Transition resistance: Established teams resist restructuring.
- Domain boundary disputes: Shared services and databases cause unclear ownership.
- Inconsistent POD effectiveness: Some PODs adopt the model more effectively than others.
- Over-autonomy at program level: PODs without program visibility drift technically.
POD Model for Data Teams
The POD model is increasingly applied in data platform and analytics engineering contexts, not just in traditional software product development.
A large data platform organization building a data lake, analytics layer, BI tooling, and data governance capabilities can structure itself as multiple PODs.
Examples include an ingestion and pipelines POD, an analytics and modeling POD, a governance and cataloging POD, and a self-service tooling POD. Each operates independently on its domain.
Cross-POD integration governance covers the shared data contracts and infrastructure.
For data engineering teams that have grown beyond the size where a single Scrum team can maintain visibility, the POD model provides the structural clarity that preserves delivery effectiveness at scale.
Final Thoughts
The POD model is not a replacement for Agile principles. It is an application of them at scale. The core Agile values still hold: individuals over processes, working software over documentation, customer collaboration, and responding to change.
The POD model provides the organizational structure that preserves those values when team size would otherwise erode them.Implementation requires discipline. Domain boundaries must be genuinely clean. PODs must be genuinely cross-functional. Integration governance must be genuinely lightweight. Done half-heartedly, the model produces its own form of overhead without the promised benefits. That includes PODs that cannot make decisions, PODs missing critical skills, and integration phases that become waterfall.
Done well, it scales Agile delivery in a way that keeps team members connected to customer outcomes, gives clear accountability at every level, and preserves the quality and velocity that made Agile worth adopting in the first place.