The problem with this though is when you end up assigned to "their" project, and you curse how un-unit-testable "their" code is. At which point it's "your" code too.
I don't even bother with that struggle you described anymore.
Get assigned ticket for new feature. Write test outlining how it would work with the assumption that the existing code does what it says it does.
If you find - surprise! - the code doesn't do what it says it does, create a ticket and recurse.
Compared with trying to make the tiniest possible change and running into gotcha after gotcha, this is a far more sane and sanitary procedure. It takes longer, but in the end "your" code meets requirements and you can prove it.
