u/venkatkm2006

I coach two Scrum teams split across India and the US, both running under a SAFe setup at a large enterprise. For a while both sides kept telling me the same thing, basically: the other team’s status doesn’t match what’s actually in the system. Classic distributed team headache, I figured, and went looking for a distributed team fix.

Took me longer than I’d like to admit to notice the actual issue. We had two systems doing the same job. Engineers logged defects with all the technical detail in one tool. But the reporting that leadership actually looked at lived in a completely separate work-tracking tool. So people would update one and just… not get around to the other. Not because they were careless, just because who has time to enter the same thing twice for no real reason.

I almost went the “let’s tighten up tool discipline” route, honestly. Glad I didn’t, because that would’ve just meant nagging people about a system that was already annoying them.

What actually worked was way less exciting. We set up a simple sync so that logging once, in whichever tool people were already using day to day, pushed the info over automatically. No new habit, no policy, nothing to enforce. Just removed the double entry.
Gaps in reporting basically disappeared within a few sprints. Nobody worked harder, we just stopped making them do the same task twice.

Not sure how universal this is but it’s a pattern I keep running into as a coach - stuff that looks like a “process compliance” problem is often just duplicate effort in disguise. Before pushing for more enforcement on something that isn’t sticking, worth asking whether people are quietly being asked to do double work for it.

Anyone else run into something like this, where the fix ended up being removing a step instead of adding a rule?

I coach two distributed Scrum teams (India + US) inside a large enterprise SAFe setup. Six months in, I kept hearing the same complaint from both sides: “the other team’s status doesn’t match what’s in the system.”
Turned out we had two sources of truth. Engineers logged defects in one tool with rich technical narrative. Program-level reporting lived in a separate work-tracking tool that leadership actually looked at. Nobody was lying — they were just updating one system and forgetting the other existed. By the time a defect showed up in the leadership dashboard, half the story was missing.
My first instinct, honestly, was to lecture people about “tool discipline.” I’m glad I didn’t. Nobody ignores a system because they’re lazy — they ignore it because updating two places for one fact is an unpaid tax on their day, and eventually everyone stops paying it.
So instead of a policy, we built a single-entry sync: log once in the tool you already live in, and a lightweight process pushes the narrative into the other automatically. No new habit to enforce. No compliance metric to chase. Just removed the tax.
Reporting gaps disappeared in about three sprints. Not because anyone tried harder — because we stopped asking them to.
The lesson I keep relearning as an SPC: most “process compliance” problems in SAFe aren’t discipline problems. They’re duplicate-effort problems wearing a discipline costume. If a ceremony, a report, or a tool update isn’t sticking, the first question isn’t “how do we enforce this” — it’s “what’s the hidden double work we’re asking people to do for free.”
Curious if others have hit the same thing — where the “fix” turned out to be subtraction, not another rule.