Both the Agile testing quadrants and the Test automation pyramid tell us that several different types of developer (and of course other) types of tests are needed. Going for 100% unit tests is no end in itself. However, unit tests are critical for the overall testability of the system and its component parts, and are the primary spots for executing the large number of checks that usually arise from applying fundamental testing techniques.
To become better at whatever types of tests the particular system requires, we need to write them. So, the first and obvious step would be to actually spend time creating the tests. Next, some inspection and adaption are needed. Are the tests useful? Are they easy to maintain? Are they easy to create? If not, something about them needs to change, and since we’re talking about complex tests, they need a fair share of code and infrastructure. Working with the latter must be allowed to take time, and one way of ensuring that this time is available is to plan for test design and implementation during the (sprint) planning meetings.
How to make that work cross team? It’s about solving the exact same problem as cross-team architecture and company wide coding conventions or best practices. Use the same forum. If the end product is so complex that it’s composed of subsystems delivered by multiple teams, doing cross-team continuous delivery can drive the process of developing best practices and knowledge sharing across teams.