Dependency and Change Notification Board¶
Coordination surface — instantiates Concurrent Cross-Functional Integration
A live shared surface that shows current cross-team dependencies, interface versions, and changes — and pushes each change to the owners it affects until they acknowledge and act.
A Dependency and Change Notification Board is the live coordination surface that keeps cross-team dependencies visible and turns every change into targeted, owned action. It shows, in the present tense, who depends on whom, which interface versions are current, what changed, and what is blocked — and its defining move is that a change doesn't just display: it is routed to the specific owners it affects, tracked to acknowledgment and closure, with dependent evidence flagged stale. It is the active notification layer, distinct from the Shared System Model or Digital Thread, which holds the authoritative underlying model; the thread is the truth, the board is the nudge that makes people act on it.
Example¶
A bank runs a multi-year core-modernization program with parallel streams: payments, fraud, the new core ledger, the customer app, and regulatory reporting. Dependencies are dense and shifting. The board shows, live, each cross-stream dependency, its owner, the current interface version, what changed this week, and what is blocked. When the core-ledger team changes an account-identifier format, the board doesn't merely post it: it identifies the four downstream consumers — payments, fraud, reporting, and the app — notifies their owners, and tracks each acknowledgment and impact action to closure. A reconciliation test that had passed against the old format is flagged as stale evidence.
The board's rule is that every alert carries a required action and a named owner, not just a stream of activity — which is what keeps it a coordination surface rather than a firehose people learn to ignore.
How it works¶
- Publish current state. Dependencies, owners, interface versions, and blocked work, kept live.
- Flag change and identify impact. For each change, determine which dependencies and evidence it touches.
- Notify the specific owners and drive action to closure. Require acknowledgment; track impact actions until closed.
- Flag stale evidence. Mark tests, approvals, and artifacts that a change has invalidated, so nothing sits falsely green.
Tuning parameters¶
- Notification precision — targeted to the actually-impacted vs. broadcast to all; precision is what prevents alert fatigue.
- Action-binding — alerts that require an owned action vs. purely informational posts.
- Refresh latency — how live the board is; staleness quietly destroys trust in it.
- Staleness aggressiveness — how readily dependent evidence is marked invalidated after a change.
- Access and visibility — who sees what, controlled so the board routes change impact rather than surveilling activity.
When it helps, and when it misleads¶
Its strength is closing the archetype's core gap — that "a decision by one function invalidates another's work without prompt notice." It makes change propagation active and owned, an information radiator[n1] for dependencies rather than a passive log someone has to think to check.
Its failure modes are a dashboard without action (a pretty board where nothing happens), an alert flood that trains people to ignore it, an outdated board no one trusts, and watermelon status — green on the surface, red underneath. The classic misuse is repurposing it to rank or surveil team activity instead of routing change impact, which corrodes the candor it depends on. The discipline that guards against it is binding alerts to owned actions, keeping the board current, and targeting notifications to the streams actually affected.
How it implements the components¶
integrated_value_stream_and_dependency_map— the live board of cross-stream dependencies, owners, versions, and blocked work is the dependency map in operating form (the Shared System Model or Digital Thread holds the authoritative underlying trace).change_propagation_and_impact_rule— flag change, identify impact, notify owners, require acknowledgment, close actions, and flag stale evidence — that loop is this rule.
It surfaces and routes change but does not define or version the interface contracts (Interface Control Document and Contract Test), hold the authoritative shared model (Shared System Model or Digital Thread), or resolve the escalated bottleneck it may reveal (Cross-Functional Swarm on Integration Constraint).
Related¶
- Instantiates: Concurrent Cross-Functional Integration — the board is the archetype's live change-propagation surface.
- Consumes: Shared System Model or Digital Thread supplies the authoritative dependencies and versions the board makes live.
- Sibling mechanisms: Shared System Model or Digital Thread · Cross-Functional Swarm on Integration Constraint · Interface Control Document and Contract Test · Integration Build or End-to-End Increment · Big-Room Planning or Concurrent Set-Based Workshop · Integrated Product or Service Team · Cross-Functional Design Review · Integrated Readiness and Release Review
Editorial Notes¶
Form Classification¶
Form family: Control, Automation & Runtime
Rationale: The live board detects dependency impacts and invalidated evidence, pushes targeted notifications, requires acknowledgment, and tracks corrective actions to closure, so it is operational change-routing control.
Nearest alternative: Monitoring, Sensing & Alerting — It continuously exposes current dependencies and versions, but automatic impact notification and closure-driving action go beyond observation alone.
Review outcome: Adjudicated after independent review; high confidence.
Origin Attribution¶
Primary origin: Organizational & Management Science
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Agile management cohered information radiators that keep shared project state and dependencies continuously visible.
Related originating lineages:
- Computer Science & Software Engineering — Software configuration and incident tooling supplied versioned interfaces, targeted change notifications, and acknowledgement tracking.
Review resolution: Agile management cohered information radiators that keep shared project state and dependencies continuously visible. The retained ambiguity accurately marks a synthesis of management information radiators with software-style invalidation and acknowledgement.
Attribution caveat: The board extends the management information radiator with active software-style dependency invalidation.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; medium confidence.
Notes¶
[n1] Information radiator (Alistair Cockburn): a highly visible, always-current display of project state that a team absorbs passively rather than having to seek out. This mechanism extends the idea with active, owned change notifications so the radiator also pushes impact to the people who must respond. ↩