DVS Ways of Working
A development value stream does not coordinate through management escalation or ad-hoc meetings. It coordinates through a defined rhythm — a set of recurring events and forums that make work, dependencies, and decisions visible on a predictable cadence.
This rhythm operates at two timescales: the Program Increment (PI), which spans 8–12 weeks, and the iteration (sprint), which spans 1–2 weeks within each PI. The PI is the primary planning and alignment unit. The iteration is the primary delivery unit.
The PI Cadence
The Program Increment structures how a DVS plans, delivers, and improves. Every PI follows the same pattern: a planning event at the start, iterative delivery through the middle, and a structured retrospective at the end.
PI Planning → [Iteration 1 → Iteration 2 → ... → Iteration N] → Inspect & Adapt
↑
System Demo (each iteration or PI boundary)This rhythm is not a waterfall in disguise. Within the PI, teams adapt continuously. What the PI provides is a shared horizon — a defined period within which teams align on goals, surface dependencies, and commit to outcomes. The cadence reduces coordination overhead: instead of negotiating continuously, the DVS negotiates at defined points and then delivers.
PI Planning
PI Planning is the event that opens each Program Increment. All teams in the DVS participate — typically over two days — to align on goals, identify dependencies, and produce a shared plan for the coming PI.
The primary outputs of PI Planning are PI Objectives for each team, a program board showing cross-team dependencies, and a consolidated view of risks. Teams leave with a committed plan they own — not a plan handed to them.
PI Planning is covered in full in PI Planning.
Coordination Within the PI
Once the PI is underway, coordination continues through a set of recurring forums. Each has a distinct purpose and audience. Running them well keeps the PI on track without creating bureaucratic overhead.
PO Sync
The Product Owner Sync brings the product management network together — the Product Manager and all Product Owners — on a weekly or biweekly cadence. Its purpose is to maintain backlog coherence across teams: ensuring that what each team is building remains aligned with the DVS roadmap and with each other.
PO Sync is not a status meeting. It is a working session where backlog priorities are reviewed and adjusted in light of what has been learned since the last sync. Dependencies between team backlogs surface here before they become delivery blockers.
In organizations with strong product management discipline, PO Sync is where the product management network actively shapes delivery direction within the PI — not just monitors it.
Scrum of Scrums
The Scrum of Scrums is a short, frequent coordination event — typically twice a week — focused on cross-team dependencies and flow impediments.
One representative from each delivery team participates, typically the Scrum Master or a senior team member. The format is structured around three questions: what has each team completed, what is planned next, and what is blocking progress across team boundaries.
The Scrum of Scrums does not resolve technical problems. It surfaces them so they can be resolved outside the meeting by the right people. The DVF owns this forum and is responsible for ensuring that impediments raised here are actually resolved — not just acknowledged.
Cross-Team Technical Forums
Beyond the delivery coordination forums, a DVS needs recurring forums for the technical concerns that span team boundaries. These are not optional additions — they are the mechanism by which architectural coherence, security standards, and operational continuity are maintained across a multi-team delivery organization.
Three forums address the most common cross-team technical concerns:
Architecture Forum brings together technical leads from teams and enabling areas to address cross-cutting architectural decisions — reference architecture updates, significant design choices with multi-team implications, and architectural debt that requires coordinated action. This forum operates on a biweekly cadence and produces architectural decision records (ADRs) that provide a shared decision log for the DVS. The System or Solution Architect leads this forum.
Security Sync coordinates security findings, shared responsibilities, and pipeline security concerns across the teams responsible for building and running software. In organizations where security and operations have separate enabling areas, this forum manages the boundary between them. Biweekly cadence is typical.
Release and Operations Sync (sometimes called Prod-sync) coordinates releases, production change management, and operational readiness across teams. As teams approach PI boundaries or significant releases, frequency typically increases. This forum is co-owned by the teams responsible for CI/CD pipelines and production operations.
These forums are lean by design. They exist to resolve coordination problems that cannot be resolved within a single team, not to create governance overhead. Each should have a clear owner, a defined scope, and explicit exit criteria for topics raised.
System Demo
The System Demo is a regular event where teams demonstrate integrated, working software to stakeholders. Unlike team-level sprint reviews, the System Demo shows the product as a whole — integrated across teams, running in a realistic environment.
The System Demo serves two purposes. First, it creates a regular feedback loop with business stakeholders: they see what has been built, and their reactions inform what gets prioritized next. Second, it surfaces integration issues between teams. A feature that works in isolation but fails when integrated with other teams’ work will show up in the System Demo — ideally while there is still time to address it within the PI.
The System Demo is not a presentation. It is a demonstration of working software. Slides explaining what the team has done are not a substitute.
Cadence varies by context. A System Demo at the end of every iteration is common and provides the tightest feedback loop. A demo at PI boundaries is the minimum. The DVF owns this event and is responsible for ensuring it happens on a reliable cadence.
Inspect & Adapt
Inspect & Adapt (I&A) is the structured retrospective that closes each PI. It is more substantial than a team-level retrospective: it examines delivery outcomes at DVS level, identifies systemic improvement opportunities, and produces concrete commitments for the next PI.
A well-run I&A has three parts. The first is a review of what was delivered against PI Objectives — quantitative, not qualitative. Teams assess their own predictability: what was planned versus what was done. The second is a problem-solving workshop where the most significant systemic issues — those that no single team can resolve alone — are analyzed for root causes and converted into improvement items. The third is a retrospective on working practices: what worked, what did not, and what changes will be made.
The improvement items from I&A are not parking-lot items. They enter the next PI as explicit work — in team backlogs or the DVS backlog — with owners and acceptance criteria. Inspect & Adapt without action is a ceremony, not an improvement system.
Prioritization at DVS Level
Prioritization at DVS level operates on two timescales: between PIs and within a running PI.
Between PIs, the Product Manager and product management network maintain the feature backlog — the ordered set of features waiting to enter delivery. Features are sequenced using Weighted Shortest Job First (WSJF): the features with the highest cost of delay relative to their estimated duration are pulled first. This is not a one-time exercise. The backlog is continuously re-evaluated as business priorities shift, as features in delivery produce new information, and as capacity constraints change.
Within a PI, the committed PI Objectives frame what the DVS is working on. Significant reprioritization within a PI — dropping committed features, pulling in new ones — requires an explicit decision involving the Product Manager and RTE. Minor reprioritization within team backlogs is the Product Owner’s call.
The discipline of separating between-PI and within-PI prioritization is important. A DVS that continuously renegotiates its commitments never develops predictability. A DVS that never adjusts within a PI ignores real information. The PI boundary is the primary decision point; within-PI changes are the exception, not the norm.
Capacity management is inseparable from prioritization. The product management network must maintain a realistic view of what the DVS can deliver in a PI — accounting for architectural work, operational overhead, and team capacity. Commitments that consistently exceed capacity are not an ambition problem; they are a prioritization process problem.
See also: DVS Kanban Flow for how features move through the DVS backlog stages.
What Connects the Pieces
The ceremonies and forums described here do not operate independently. They form a system:
PI Planning establishes the shared plan and surfaces dependencies before delivery begins. PO Sync and Scrum of Scrums maintain alignment and resolve impediments as the PI progresses. The System Demo closes the feedback loop with stakeholders at regular intervals. Cross-team technical forums manage the concerns that no single team can own alone. Inspect & Adapt converts the learning from the PI into concrete improvements for the next one.
The DVF is the connective tissue — responsible for ensuring that all these events happen, happen well, and that impediments raised in any of them are tracked to resolution.
A DVS that runs this system consistently — not perfectly, but consistently — builds the organizational muscle that makes predictable delivery possible.