# Agile at scale: beyond the Spotify model > The "Spotify model" (Squads, Tribes, Chapters, Guilds) dominated large-scale agile discussions for years. But here's a secret: even Spotify no longer follows the Spotify model. - Date : 2025-10-02 - Lecture : 9 min - Catégorie : strategie-ia - Tags : Agile at scale, Spotify model, Product organisation, Coordination, Team autonomy, Agile transformation - URL : https://www.adservio.fr/en/insights/articles/agile-a-grande-echelle-au-dela-du-modele-spotify ## TL;DR - Copying a framework's structure (Spotify's or any other) without understanding its underlying principles reproduces a cargo cult: same dysfunctions, new labels. - Five lasting principles matter more than structure: autonomy, alignment, transparency, learning and customer focus. - Team Topologies, product-led organization and Value Stream Mapping structure the organization around value flows rather than traditional org charts. - Coordination at scale rests on decoupling (contractual APIs, feature flags, contract tests, asynchronous communication) rather than piling on synchronization points. - A successful transformation moves in stages: diagnosing constraints, running localized pilots on 1-2 teams, then adaptively scaling validated practices, never a mechanical replication of an external model. ## Introduction The "Spotify model" (Squads, Tribes, Chapters, Guilds) dominated large-scale agile discussions for years. But here's a secret: even Spotify no longer follows the Spotify model. Agile at scale isn't about copying a framework, it's about adaptive principles applied to your unique context. ## Why frameworks fail ### The cargo-cult trap Large-scale agile transformations mainly fail because of a mechanical application of frameworks without contextual adaptation. At Adservio, we regularly observe this issue during our strategic advisory engagements. Organizations copy the external structure (Squads, Tribes, Chapters, Guilds) without understanding the underlying principles that let it emerge. The result is predictable: an agile bureaucracy that reproduces the same dysfunctions under new labels. A typical example: an organization renames its waterfall teams "agile squads," but keeps exactly the same endless meetings, just rebranded. ### The principles that matter Adservio's experience with organizations undergoing transformation shows that success rests more on anchoring fundamental principles than on replicating structures. These principles form the foundation of durable, contextualized agility. Instead of copying structures, focus on: Autonomy: teams hold the decision-making power needed to execute their mission, without systematic validation from multiple layers of hierarchy. Alignment: every contributor understands the strategic vision and can articulate how their day-to-day work directly contributes to it. Transparency: information flows freely across the organization, without political hoarding or departmental silos. Learning: the organization cultivates a culture of experimentation where fast failure is valued as a vector of learning. Customer focus: every decision and iteration is measured against the value delivered to the end customer, measurable and tangible. ## Adaptive organizational architecture Organizational structuring is a major strategic lever for large-scale transformations. Adservio advocates an architectural approach that reflects value streams rather than traditional org charts. ### Pattern 1: Team Topologies The Team Topologies framework, developed by Matthew Skelton and Manuel Pais, proposes an organizational taxonomy that optimizes interactions and reduces cognitive load. This approach proves particularly relevant for growing technology organizations. 4 team types: Stream-Aligned Teams, aligned to a business value stream (for example Checkout, Search or Recommendations squads), which build features directly; Enabling Teams, which develop other teams' capabilities in technical excellence or security; Platform Teams, which provide self-service infrastructure (cloud platform, data platform); and Complicated-Subsystem Teams, which absorb specialized technical complexity such as ML infrastructure or payment processing. ### Pattern 2: Product-Led Organization The transition from a project organization to a product organization represents a fundamental paradigm shift. At Adservio, we support our clients through this transformation by establishing clear ownership and a long-term product vision. A product organization enables strategic continuity and holds teams accountable for business outcomes, unlike projects that end artificially with no guarantee of maintainability. In practice, an e-commerce platform can structure its org chart around product lines, buyer experience, seller experience, platform, each broken down into dedicated teams: discovery, conversion and retention on the buyer side; onboarding, catalog and analytics on the seller side; identity, payments and data on the platform side. ### Pattern 3: Value Stream Mapping Value Stream Mapping identifies and optimizes the end-to-end value-creation flow. This approach, which we deploy systematically at Adservio, reveals the bottlenecks and hidden wait times that impact organizational velocity. Organizing around value streams aligns teams to the full customer journey rather than siloed functions, drastically reducing handoffs and organizational inefficiencies. A typical Order-to-Cash value stream links discovery, purchase, processing, fulfillment and support, each stage owned by a dedicated team: this kind of reorganization commonly cuts the end-to-end lead time from 15 to 3 days. > Related read: [How to Build and Use a Product Map Inside Your Organization](https://www.adservio.fr/en/insights/articles/comment-creer-et-exploiter-une-cartographie-produit): A six-step method for building a product map: scoping, customer value, inductive/deductive mapping, then rollout and governance in a BI tool. ## Coordination at scale Multi-team coordination is one of the major challenges for agile organizations at scale. Adservio's expertise shows that effective coordination rests on architectural and organizational decoupling rather than piling on synchronization points. Anti-pattern: synchronize everything, The temptation to maintain constant alignment through intensive synchronization rituals paradoxically creates more misalignment. This approach generates a coordination overhead that paralyzes team autonomy. Its typical symptoms: a daily standup with 50 people, mandatory synchronization across all teams, or releases coordinated across 20 teams at once. Pattern: decoupling and clear interfaces, Service-oriented architecture with explicit interface contracts lets teams evolve autonomously while maintaining system integration. This approach, central to our engagements at Adservio, drastically reduces cross-team dependencies: each team exposes a clear contractual API, for example a Checkout service guaranteeing 99.9% availability and under 200ms p95 latency for creating an order or checking its status, which other teams consume directly, with no synchronization or cross-team meeting needed for every change. Pattern: async communication > sync meetings, Prioritizing asynchronous communication over synchronous meetings is a major efficiency lever. Our analyses at Adservio show that high-performing organizations spend less than 20% of their time in synchronous meetings. In practice, this means replacing a weekly 2.5-hour cross-team daily (30 minutes × 5 teams), a one-hour weekly sync and a two-hour joint sprint planning with a real-time shared dashboard, an asynchronous Slack channel and occasional pair programming when needed, typically cutting meeting time by 90% while improving collaboration. ## Alignment mechanisms Strategic alignment at scale requires clear mechanisms that translate vision into concrete action while preserving autonomy. At Adservio, we deploy alignment frameworks that balance strategic direction with operational decentralization. 1. North Star Metrics, The North Star Metric is the organization's strategic point of convergence. This single metric, which we help our clients define, guides decentralized decisions while ensuring overall coherence. An effective North Star must reflect fundamental customer value and be influenceable by every team through their specific contributions. At Netflix, for example, the chosen North Star is monthly viewing hours, fed by four drivers each owned by a distinct team: content quality, personalization, playback performance and discoverability. 2. Distributed OKRs, The OKR (Objectives and Key Results) framework allows a cascading strategic breakdown while leaving teams autonomy over the "how." In our engagements at Adservio, we structure OKRs to create both vertical alignment and horizontal coherence. Effective OKRs create a direct line of sight between individual team objectives and corporate strategy, while avoiding a mechanical cascade that would destroy autonomy. A company objective such as "become the e-commerce leader in France," measured by indicators like monthly active users, NPS or delivery time, cascades into distinct team objectives: the Checkout team, for example, sets out to eliminate checkout friction (conversion rate, abandonment rate, journey duration), while the Logistics team aims for ultra-fast delivery (share delivered under 24h, delivery cost, return rate). 3. Inner Source, The Inner Source model transposes open-source principles to the enterprise environment. This practice, which we systematically encourage at Adservio, fosters cross-team collaboration while maintaining clear ownership. Inner Source eliminates code silos and accelerates innovation by letting any team contribute to the components it depends on, without waiting on the owning teams' roadmaps: in practice, any team can clone the repository of a service it doesn't own, submit a pull request, for example adding an express checkout option to the Checkout service, and have it reviewed by the owning team, without waiting for that team to add the request to its own roadmap. ## Delivery at scale Continuous deployment at scale is a major competitive differentiator. Adservio's approach favors deployment autonomy to maximize velocity while maintaining system stability. Pattern: decoupled Continuous Delivery, Decoupling deployment cycles lets each team iterate at its optimal pace, unconstrained by organizational dependencies. This independence, a pillar of our architectures at Adservio, eliminates the traditional bottlenecks of release trains. Each team sets its own deployment cadence based on its technical maturity and business constraints, creating an adaptive system rather than a uniform one: one team might deploy ten times a day, another five times a day, a third twice a week, never waiting on the others, with no release train, easy rollback and fast feedback at every cadence. Pattern: feature flags, Feature flags decouple deployment from feature activation. This technique, systematically recommended by Adservio, enables granular rollout control and instant rollback without redeployment: each team can activate its own feature independently of the others, for a subset of users, without depending on neighboring teams' deployment schedules. Pattern: contract tests, Contract tests advantageously replace costly, brittle end-to-end tests. This approach, at the heart of our engineering practices at Adservio, enables decoupled interface verification while maintaining system confidence. Instead of end-to-end tests that couple everyone together and slow down release cycles, contract tests verify in isolation and quickly that each service meets its consumers' expectations: the owning team of an API defines the expected contract (for example, that creating an order returns a 201 status with an order ID), and the consuming team automatically verifies it honors that contract, without ever having to spin up the entire system. ## Lightweight governance Technical governance at scale must balance architectural coherence with decision-making autonomy. At Adservio, we advocate documented, transparent governance over process-heavy, centralized governance. Anti-pattern: Architecture Board, Centralized architecture committees create decision-making bottlenecks that paralyze organizational agility. This hierarchical approach to technical decisions is incompatible with the velocity requirements of modern organizations: a committee that approves every technical decision, a heavyweight process with 50-page documents, and decisions that take weeks are the typical symptoms of this bottleneck. Pattern: Architecture Decision Records (ADR), ADRs are a distributed governance mechanism where decisions are documented in a standardized, accessible way. This practice, systematically deployed by Adservio, builds organizational memory while preserving team autonomy. Every significant architectural decision is captured in a lightweight format that spells out the context, the alternatives considered and the anticipated consequences, for example, adopting GraphQL for a public API in the face of proliferating REST endpoints, with the expected benefits (precise data fetching, strong typing), the identified risks (learning curve, caching complexity) and the team responsible for implementation. Pattern: lightweight RFCs, Lightweight RFCs (Requests for Comments) let teams solicit structured feedback for high-impact decisions. At Adservio, we use this format for cross-cutting architectural changes that require multi-team alignment. The RFC process fosters asynchronous collaboration and informed decision-making without creating paralyzing bureaucracy: a typical RFC documents the problem (for example, a MongoDB database hitting scalability limits under transactional load), the proposal (migrating to PostgreSQL for ACID transactions), the estimated impact on affected teams, the alternatives ruled out and why, before sign-off from the technical leads. > Related read: [Software architecture decisions: who should be involved?](https://www.adservio.fr/en/insights/articles/decisions-architecturales-logicielles-qui-doit-etre-implique): Andrew Harmel-Law on decentralizing architecture decisions: advice not permission, ADRs, five software revolutions, and how to build organizational trust. ## Metrics that matter Measuring organizational performance should reflect outcomes rather than activity. At Adservio, we guide our clients toward metrics that correlate directly with business value and adaptive capacity. Vanity metrics (lines of code, story points) create perverse incentives and mask the true indicators of organizational performance. Don't measure: Lines of code (optimizes for verbosity rather than simplicity); story points completed (gamification with no link to value); number of commits (encourages artificial fragmentation). Measure: Lead time (idea → production): ability to turn an idea into delivered value. Deployment frequency: pace of iteration and feedback. Mean time to recovery (MTTR): system and organizational resilience. Change failure rate: process quality and maturity. Customer satisfaction (NPS): alignment with perceived value. Business outcomes (revenue, retention): tangible business impact. DORA Metrics, DORA Metrics (DevOps Research and Assessment) form the scientifically validated reference framework for evaluating software delivery team performance. Adservio uses these metrics as a baseline to benchmark and improve delivery performance. The highest-performing organizations (DORA elite performers) deploy multiple times a day, with a lead time under one day, an MTTR under one hour and a change failure rate under 15%,a useful reference point for gauging your own trajectory and setting realistic improvement targets. ## Transformation: where to start? Large-scale agile transformations often fail from excessive initial ambition. Adservio's approach favors an incremental transformation guided by experimentation and learning rather than a fixed master plan. Phase 1: identify the constraints, The Theory of Constraints teaches us that improving a system must focus on its primary bottleneck. At Adservio, we start every transformation with a thorough diagnosis of systemic constraints. This diagnostic phase, typically run over 2 to 4 weeks, reveals the real organizational drags beyond surface symptoms, by systematically asking where the bottlenecks lie (approvals that take weeks, an overloaded centralized team, blocking dependencies) and what's preventing autonomy (skills gaps, fragile shared infrastructure, overly rigid processes). Phase 2: localized experiments, A big-bang approach to organizational transformation carries unacceptable risk. Adservio recommends a controlled experimentation strategy with pilot teams that serve as a learning lab, chosen for their high motivation, supportive leadership and measurable business impact, and given full autonomy, dedicated support and protection from surrounding bureaucracy. These pilots validate transformation hypotheses in a real environment while limiting the blast radius of potential failures; results are measured after about three months. Phase 3: scaling what works, Scaling up must rest on empirical proof of success rather than theoretical convictions. At Adservio, we structure this phase around spreading validated practices and removing systemic obstacles: documenting what worked in the pilots, training other teams, adjusting organizational structures and clearing blocking processes, never imposing a uniform model. Scaling isn't mechanical replication but a contextual adaptation of the principles proven effective in the pilots, letting each team adapt the approach to its own context. ## Conclusion Agile at scale transcends the mechanical application of pre-established frameworks. Adservio's experience with organizations undergoing transformation shows that success rests on anchoring fundamental principles rather than replicating structures. Agile at scale isn't about following a framework: it's: Giving autonomy to the teams that create value, by removing approval bottlenecks and distributing decision-making power as close as possible to execution. Aligning on clear objectives that create strategic coherence without constraining tactical and operational autonomy. Eliminating dependencies and silos through an organizational and technical architecture that favors decoupling. Measuring what really matters, prioritizing outcome metrics over activity metrics. Continuously learning and adapting, by cultivating a culture of experimentation and incremental improvement. The perfect "model" doesn't exist. There is only your model, adapted to your unique context, evolving organically as you learn from your experiments and your failures. The key to success lies in this capacity for contextual adaptation rather than conformity to an external blueprint. ## FAQ ### Why doesn't the Spotify model work as-is in most organizations? Because organizations often copy the external structure (Squads, Tribes, Chapters, Guilds) without understanding the underlying principles that let it emerge at Spotify, even Spotify has since evolved its own model. The result is an agile bureaucracy that reproduces the same dysfunctions under new labels. ### What are the team types in the Team Topologies framework? Four types: Stream-Aligned Teams, aligned to a business value stream; Enabling Teams, which develop other teams' capabilities; Platform Teams, which provide self-service infrastructure; and Complicated-Subsystem Teams, which absorb specialized technical complexity. ### How do you start a large-scale agile transformation without overhauling everything at once? In three phases: first, a 2-to-4-week diagnosis of systemic constraints; then localized pilots with one or two motivated teams over about three months; and finally a scaling phase that spreads validated practices and adapts the principles to each team's context, never a mechanical replication.