FL-05
Synchronised Cross-Team Improvement Dip
Flow
Default severity: critical
ProcessMetricsOutputRisk
What it detects
The configured minimum number of teams simultaneously show a rolling average dip below the configured threshold within the same time window — batch release event, not systemic improvement.
Detection formula
FOR each_team T: dip = rolling_avg(T) \< overall_avg(T) * config.flow.dip_threshold // default: 0.7 IF COUNT(teams_with_dip_in_window) >= config.flow.min_teams_for_systemic_dip // default: 3 AND window_days \<= config.flow.dip_window_days // default: 30d THEN FLAG batch_release_eventExamples in practice
- Board policy limits are exceeded or status movement patterns look artificial.
- Work piles up in one column or moves in bulk instead of flowing steadily.
- A team shows the configured minimum number of teams simultaneously show a rolling average dip below the configured threshold within the same time window while dip threshold is set to 0.7.
Suggested response
Inspect board policy, WIP, and status hygiene so flow matches how work actually progresses.
Coaching playbook
Symptom
The configured minimum number of teams simultaneously show a rolling average dip below the configured threshold within the same time window — batch release event, not systemic improvement.
Why it matters
When "Synchronised Cross-Team Improvement Dip" keeps appearing, the team is signalling a repeatable process gap. Left unexamined, the pattern hides where work really stalls and makes improvement metrics harder to trust.
What you can achieve
Inspect board policy, WIP, and status hygiene so flow matches how work actually progresses.
Facilitation questions
- What system change would stop "Synchronised Cross-Team Improvement Dip" from firing again?
- What do the cited issues have in common — same root cause or same workaround?
- Who owns the two-week experiment and how will we verify on the next import?
Run this rule against your own tracker data with Flow Analyzer.