And how transparent is that?

"Everybody knows that."

That sentence is usually where not much is actually known. Just assumed — in different ways, by different people, rarely meaning the same thing. At least I haven't seen it this way yet, when challenged.

Transparency isn't a value you declare. It's something you design. You need to know who owns what, where it lives, when it gets reviewed, what it actually means. Without that, you're not transparent — you're just optimistic. Or delusional.

What I keep walking into: processes nobody has mapped, or when they have, mapped once and never touched again — sitting in someone's drawer, on a drive nobody has access to. User journeys (with no user perspective) that exist across numerous different heads, every single one with a different version of it. Work packages with no connection to the value they're supposed to create. And information that should be visible to the whole team — blocked. By habit, by hierarchy, by ego.

"Need to know basis" does make sense for sensitive data — but only in those cases. Manager, Leader: if you are not working with highly sensitive data, and you can't really trust your own personnel — people you hired, trained, signed NDAs with — then this argument is just blocking your development. And you are the owner of that blockage. If you want collaboration, people need to see the full picture. They can't improve what they can't inspect. They can't inspect what they can't see. That's one of the core pillars that Lean, Agile, and the beloved Scrum are built on. And it's almost always not even heard of. To fix that, I apply logic and try to ink the definitions in their heads.

So when someone tells me things are clear to everyone and they should know what to do, I ask: and how transparent is that? Where does that alignment actually live? Then we challenge that statement — within the team and with stakeholders. If it's transparent, then it's just one more inspection. If not, we openly discuss how to make it — and make it.