XBA: De-scaling Business Agility

XBA Practitioner certification granted by the XSCALE Alliance

XBA: an XSCALE Pattern Language.


XSCALE Business Agility ("XBA") generates self-directing portfolios of self-managing value streams of self-organizing teams. These rapidly accelerate top-line business throughput by continuously prioritizing bottlenecks in value-flow, work-flow, and the flow of learning across the organization. XBA focuses entirely on the practical aspects of business agility, generating working capabilities, not wishful thinking and text-book learning.

XBA combines de-scalingself-propagating transformation and throughput accounting practice patterns to solve the game-theoretic "Tragedy of the PMO". It forms one of three core practice-pattern languages that, together, cover all the needs of an agile organization. The others are XSCALE Product Management (XPM) and XDevOps (XDO).

Treating these as pattern languages rather than a framework serves the fundamental agile principle of YAGNI. This post outlines the purpose and benefits of the XBA pattern language – its Why, Who, How and What.

Why: "The most efficient and effective method of conveying information to and within a team is face-to-face conversation." – Agile Manifesto Principle 6. Big meetings, long loops, slow learning, tight coupling, prisoners dilemmas and deep hierarchies are bottlenecks no matter how agile the teams in your organization may be. The XPM patterns enable self-organizing teams to manage their own value streams, but that doesn't generate a self-directing portfolio. XBA does this by forming a rotating council of chapter representatives to align stream missions to each other, and to individual competencies and team OKRs, to maximize business throughput across the portfolio as a whole.

Who: Without a command and control hierarchy, value streams must coordinate by direct representation of teams per stream and streams per portfolio. To short-circuit hierarchy, cross-cutting chapter meetings, rather than teams, nominate representatives to participate in council meetings. The council of a stream is called its "Product Squad" after the Lean-UX "Product Team', and likewise cross-stream concerns are coordinated in a "Portfolio Squad". The repeating structure of chapters and councils is made efficient by simple numeric limits on three key de-scaling metrics.

How: XBA combines the Spotify model with practice patterns drawn from the Iroquois Confederacy, the most successful and longest-lived holarchy in history. In particular, Leadership as a Service enables squads and councils to achieve consensus decision-making in a timely way. Governance treaties proposed by chapters are ratified at squad retros without mediation by central authorities, and chapter leaders rotate to prevent the formation of power hierarchies. These patterns can be extended through the fractal "longhouse pattern" to resolve larger cross-cutting concerns.


  • Throughput Accounting is the TOC alternative to cost accounting that optimizes the contribution of each business function to top line throughput rather than blindly attempting to minimize operating expense. While commonplace, cost accounting makes an irrational basis for value stream management because it fails to account for the stream's market and system constraints, and also for the interdependencies of value streams across a portfolio. Throughput accounting continuously identifies and prioritizes the bottleneck that dominates throughput per stream and per portfolio.

  • Mission-Command is a leadership style initially developed by the Prussian Field Marshall Von Moltke as aufragstaktik, later known as blitzkrieg. Google embeds it in their "OKRs" – Objectives & Key Results – and Apple in "DRIs" – Directly Responsible Individuals. Instead of tasking people with steps of a solution, Mission Command distributes responsibility for problems along with the authority to solve them and metrics to track them. XBA attaches responsibilities as BDD acceptance criteria per feature to ensure they are cleanly coordinated across capabilities, systems, and streams even in decentralized, distributed or hybrid portfolios.

  • Self-Propagating Transformation avoids pushing change into pre-existing teams, programs or silos, but generates agile capability by grafting the kernel of a new culture onto the trunk of the old. Adapting Gandhi's patterns, this generates uncompromised agile capability by iteratively converting change recipients into change agents, iteratively doubling by splitting and back-filling, emphasizing learning by immersion, and eliminating risks of value stream disruption.

  • Open Book Management gamifies benefits-realization, rewarding value stream participants proportionately to the stream's achievement of benefits to the business top line. Instead of individual KPIs, incentive pools and targets are defined by the Portfolio Squad per stream and per release. All teams and streams openly share business information and draw from a single P&L.

  • De-Scaling Metrics establish structural limits that assure efficient flow of value to markets, work to production, and learnings across the organization. XBA applies three simple structural metrics by which any team, stream, portfolio or organization may be measured: maximum ceremony size, feedback frequency, and collaboration loop length.

  • Hybrid Models recognize that while the best performing value streams apply uncompromised Agile principles to Design, Delivery and DevOps, the world is far from perfect. XBA supports friction-free interoperation with traditional PMOs and distributed, waterfall, hierarchical or “flaccid Agile” cultures. The key to making these hybrids work is clear delineation of methods, responsibilities and acceptance criteria per value stream; streams that attempt hybrid models internally are notoriously inefficient and risk- and error-prone.

  • Throughput Diagrams chart financials to prioritize work on ecosystem growth. Throughput diagrams combine analytic “Pirate Metric” curves with Lean's Cumulative Flow diagrams, lifting the XPM Stream Kanban to generate an unambiguous Business-Agile dashboard that makes it easy to identify bottlenecks and vary stream priorities to open them, enabling all stakeholders to read their portfolio’s current state and business priorities at a glance.

  • Treaty Governance employs a repeating cycle of ceremonies – chapter meetings, squad retrospectives, and representative councils – to align teams and streams peer to peer without intermediary managers. Nor is there need for an alignment to be ratified by all teams - only those that participate in it. In the Iroquois Confederacy such a decentralized form of governance maintained several hundred thousand participants in a peaceful society for over five hundred years


XPM: Breadth-first Program Management

XPM Practitioner certification granted by the XSCALE Alliance

XPM: an XSCALE Pattern Language.

XSCALE Product Management ("XPM") aligns tech, design and business leaders, breadth-first, into a team of peers who continuously convert business drivers and constraints into maximum impact release plans. XPM forms one of XSCALE's three core practice-pattern languages along with: XSCALE Business Agility and XDevOps.

Treating these as pattern languages rather than a framework serves the fundamental agile principle of YAGNI. This post outlines the purpose and benefits of the XPM pattern language – its Why, Who, How and What.

Why: "The best requirements, architectures and designs emerge from self-organizing teams" –The Agile Manifesto, Principle 11. Agile Delivery is a hill-climbing algorithm that can responsibly and efficiently deliver the wrong product features, or the right features at the wrong time, or to the wrong market, or to meet a business driver that isn't the bottleneck and therefore has no impact. When design, business and tech stakeholders disagree, or when there isn't enough analytic data for them to make good choices, or when political forces dominate, Product Ownership become scapegoats whose defensive prioritization is certain to miss the global maximum of business value. And that crimps top line business throughput.

Who: The XPM Product Squad is a self-organizing team of business, design and technical stakeholders collaborating to make tradeoffs between their various drivers and constraints. In XPM, Product Ownership functions by applying Leadership as a Service to reconcile the Product Squad's clearly defined individual responsibilities with its need to make consensus decisions in a timely manner and avoid political anti-patterns.

How: XPM applies Ecosystems Thinking to focus scope on maximum product impact and Throughput Accounting to focus priorities on the current market bottleneck. It works scientifically and breadth-first to reduce a value stream's drivers and constraints to epics, then to break epics into features for which it derives budget and ROI numbers that enable logical tradeoffs in release planning. It uses a consistent weekly cadence to continuously drive and adapt to learnings of its stream's Feature and Systems Squads.


  • Pirate Canvas shows you which market bottleneck your product has to attack next. It measures and maximizes the market fit of your business case, quantifies the real business drivers and constraints, and generates an "Epic Landscape" that aligns all stakeholders to a common vision on a single sheet of paper.

  • Impact Mapping questions the business value of your Epics. It forces you to understand where you have assumptions and gaps in your subject matter expertise that must be filled to avoid building an irrelevant or needlessly limited product. And takes your Product Squad one step further into aligning their frames of reference, which is critical to avoiding subsequent analysis paralysis.

  • Behavior Mapping starts with patterns for mapping epics to features. It elaborates the INVEST properties per feature in a normal form, then categorizes acceptance criteria according to cross-cutting themes. The themes represent categories of acceptance criteria covering all testable interactions between the system interface and key user personas, architectural dependencies, non-functional attributes and business rules.

  • Acceptance Matrix compiles the output of Behavior Mapping breadth-first. It aligns the stakeholders via simple sanity-checking questions and generates closure on all features that might reasonably represent behaviors of an Epic relevant to specific release goals.

  • Business Bingo generates quick consensus on actionable numbers for feature cost, business value, risk and priorities. It starts with metric probes that represent a consistent basis for comparison and brings sanity-checking conversations up early, before any delivery dollars are spent, to prevent surprises later on.

  • Release Refactoring maximizes ROI across multiple value streams for multiple release goals. Using the numbers derived from Business Bingo, it grades features per Epic to empower stakeholders to make trade-offs to maximize market impact. It's a simple numbers game that replaces what's often weeks of political pushing and shoving with a few hours of rational collaboration.

  • Leadership as a Service is a protocol that eliminates politics and speeds the flow of learnings between teams and streams. Already a part of the Agile Planning Poker game, XPM applies LaaS to make sure prioritization and acceptance criteria tradeoffs are made by consensus while still ensuring they're made in a timely manner observing all individual team member responsibilities. 

  • Throughput Accounting uses the components of ecosystem growth, rather than cost minimization, as the basis for feature prioritization. Combining McClure's Pirate Metrics with Lean's Cumulative Flow diagrams, makes it easy to identify bottleneck constraints by eye and immediately vary priorities to account for them.

  • Set-Based Design is a collaborative method for exploring the design space breadth-first. Multiple design probes are evaluated in parallel, yielding learnings in a BDD format. These learnings each eliminate huge ranges of design alternatives.

  • CRC Carding aligns the remaining choices with architectural constraints and user experiences. These choices are then refactored into a common base for the next breadth-first reduction. Each step reduces the range of design ambiguity and misalignment, rapidly zeroing in on the maximum potential for market impact.   

XDO temp.png

XDO: Scientific DevOps

XDO Practitioner certification granted by the XSCALE Alliance

XDevOps: an XSCALE Pattern Language.

XDevOps ("XDO") extends agility to all the functions of a value stream. It's a starter culture for self-propagating transformation based on Kim's "Three Ways", Extreme Programming, Git Workflows, 3D Kanban, Behavior Driven Development, CI/CDD, Infrastructure/Pipeline as Code and Game Without Thrones.

XDO forms one of three core practice-pattern languages that, together, cover all the needs of an agile organization. The others are XSCALE Product Management and XSCALE Business Agility.

Treating these as pattern languages rather than a framework serves the fundamental agile principle of YAGNI. This post outlines the purpose and benefits of the XDO pattern language – its Why, Who, How and What.

Why: "Continuous attention to technical excellence and good design enhances agility" –The Agile Manifesto, Principle 9. DevOps is grounded in Beck's XP mantra of flattening the cost of change curve. Scrum doesn't require continuous attention to technical excellence and good design, which makes it a problem for agile to solve. XDO applies YAGNI and the 9th principle to all functions of a value stream through Kim's "three ways":

DevOps CoC.png
  1. Continuously improving flow of value by prioritizing bottleneck constraints.

  2. Continuously improving flow of work by shortening and accelerating feedback loops.

  3. Continuously improving flow of learning by scientific experimentation and merciless refactoring.

A key difference between XDO and Kim's Phoenix Project ways is an emphasis on Mu Hin Shu learning ecosystems over Shu Ha Ri training hierarchies. Learning ecosystems continue DevOps beyond the scope of a change program to rebase the organization's culture upon it.

Who: XDO provides training and coaching for self-organizing teams of Developers, Testers, Business Analysts, Designers, Architects, Managers, Operations and Change Leaders. It varies team responsibilities and missions via rotating councils of chapter representatives using the "Game Without Thrones". This arrangement answers the longstanding DevOps question of whether and when to merge delivery and operations into a single team. As these two functions have different constraints, competencies and cadences, XDO empowers chapters and councils to address the question continuously via Leadership as a Service.

How: XDO coordinates the work of delivery and operations teams in a 3D Kanban on daily and weekly cadences. This helps minimize overhead for product, quality and portfolio management workflows. Small, autonomous squads aligned by small chapters and small councils continuously self-manage using mission-command, pairing, mobbing and stand-ups instead of command-and-control and big-room meetings.


XDO's weekly cadence synchronizes ceremonies for feature reviews, chapters, councils and retros. Its daily cadence walks the wall to balance planned work against root cause analysis of operational incidents. Stream councils include Ops chapter representatives working as peers to business and design stakeholder so that Leadership as a Service enables them to continuously adapt priorities to stream bottlenecks.


  • Continuous Integration / Continuous Delivery & Deployment (CI/CDD) enables multiple Feature delivery teams to release asynchronously without tripping over each others’ feet or siloing ownership of technical components. It enables XP's "Merciless Refactoring" to continuously pay down technical debt while strictly maintaining BDD acceptance criteria across the system.

  • Behavior Driven Development (BDD) makes sure ecosystem design and operational constraints are consistently maintained even when many independent and distributed teams continuously vary system behaviors. It dramatically reduces the cost of ownership of quality automation and enables design, delivery and operations functions to operate autonomously without losing alignment.

  • Git Workflows provides the most effective methods to coordinate the work products of delivery and operations teams . Proven on enormous scales in the development of the Linux kernel, in XSCALE these git workflows are tailored by treaty to empower teams and streams to share ownership of their codebases, data environments, infrastructure as code and pipeline as code across teams and streams

  • Extreme Programming is a self-reinforcing language of small-team engineering practice patterns that applies continuous feedback to pay down technical debt and maximize effective collaboration. Critical XP practice patterns not found in Scrum include test-first delivery, promiscuous pairing, shared ownership via DVCS, merciless refactoring, sustainable pace, self-documenting code and “You Aren't Gonna Need It" (YAGNI).

  • Game Without Thrones is a pattern language derived from the Haudenosaunee Great Treaty Of Peace that minimizes politics while speeding the flow of learnings within and between teams. It replaces Scrum roles with DRIs and Leadership as a Service to optimize the three "de-scaling metrics": meeting size, collaboration loop length, and feedback frequency. It maximizes direct participation in decision-making across hierarchy through its rotating system of chapters and councils.