Value Optimisation · EST. 2011 · APAC

Dependencies killing delivery across the ATO. A Nexus pilot exposed the real structural failure and fixed it.

The Situation

Over five years, ZXM supported the Australian Taxation Office (ATO) to establish product value streams and mature how the agency managed delivery across its portfolio. The engagement built consistency across value streams, producing measurable gains in transparency, traceability of team output to strategic goals, and a reduction in defect rates.

That improvement created a new visibility problem. Once executives could see dependency flows clearly, the coordination failures between value streams became visible — and significant. Portfolio executives engaged ZXM to address them.

The dependency problem had three faces: collaboration across value streams was ad hoc, feature prioritisation at the portfolio level lacked a shared mechanism, and coordination between product teams had no formal structure. Business Owners and portfolio executives needed a model that could make cross-value stream integration explicit and governable.

What the diagnostic found

Before any coordination model was designed, ZXM mapped the existing integration points between value streams to locate where dependency management was failing and why. The diagnosis identified two distinct failure modes: dependencies within a value stream were being managed informally by individual teams, and dependencies between value streams had no governing structure at all.

ZXM assessed the Nexus Framework — a scaling complement to Scrum developed by Scrum.org — against these specific failure conditions. Nexus addresses integration coordination structurally: it creates a Nexus Integration Team responsible for cross-team dependency management and establishes shared planning, review, and Daily Scrum events that surface integration issues before they become blockers (Schwaber, 2021).

The framework was piloted across one major programme at the ATO, selected because its value stream had external dependencies with three other delivery areas. ZXM worked with programme leadership to establish the Nexus structure, define the integration team’s accountabilities, and embed the coordination cadence into the existing delivery rhythm.

What changed

The Nexus integration structure changed where dependency conversations happened. Dependencies that had previously surfaced as escalations or late-delivery surprises were now visible at the team level, resolved in the Nexus Daily Scrum before they produced downstream delays. Cross-value stream feature prioritisation gained a shared forum. Integration issues were identified and addressed within the sprint, not after it.

An unexpected finding emerged from the cycle time data. The transparency the Nexus structure created exposed a structural limitation that had not been the subject of the engagement: functional teams — those organised by discipline rather than by product or value stream — were generating significantly more coordination overhead than cross-functional teams.

What held

The Nexus pilot was assessed as successful across all primary objectives. Dependencies between value streams were surfaced and resolved within the sprint cycle rather than escalating as programme-level issues. Cross-functional product teams, now operating within the Nexus coordination structure, delivered integrated software increments inside the two-week cadence.

The cycle time data collected during the pilot produced a finding the engagement had not set out to generate. Functional teams — organised by discipline rather than by end-to-end value delivery — could not produce a working software increment independently within a two-week sprint. Every increment required handoffs to at least one other team, which added wait time, created defect loops, and obscured the state of releasable software from portfolio executives. Specifically, the data showed:

Functional teams carried more team-to-team dependencies than cross-functional equivalents
Each handoff introduced additional lead time before working software could be produced
When a functional team identified a defect, it was returned to the originating team, shifting that team’s capacity from building to rework
No functional team could produce a releasable increment within a two-week cycle
Throughput per team was lower, and integration effort was higher, than cross-functional teams of equivalent size

This evidence reached portfolio executives directly, via data rather than advocacy. The structural case for cross-functional team design was no longer theoretical.