The world is full of applications that are big enough that companies need multiple development teams to work on them. No matter how these teams are organized (but I’m going to go out on a limb and guess they’re not completely cross-functional, even ignoring the hard parts). The benefits to organizing multiple software teams is they can operate independently, but the downside is that any best practices learned are hard to propagate across teams. After all, the whole point is they only need to interact with each other to inform each other of service-level changes. So how can all these development teams actually learn (and adopt) best practices?
How hard can knowledge sharing across teams be?
Well, for starters, it’s hard enough that Spotify wrote an entire 14-page white paper about it over 10 years ago (and even that didn’t work). Sharing best practices and adaptations between teams requires regular and open communication between teams, so you can bring up problems that warrant changing your approach, or sharing things you’ve tried to improve development. Of course, knowing what’s worth mentioning as something to try that other teams may also want to adopt requires a degree of confidence in what common problems are, and that the ideas you’re proposing can help. Having that sort of insight into issues affecting other teams requires regular and open communication between teams.
So the good news here, is that if you somehow crack this nut, it creates a virtuous cycle that leads to continuous improvement across all teams. The bad news figuring how to crack that nut is difficult. I’ve seen attempts at regularly scheduled meetings between developers on multiple teams, for the express purpose of sharing these best practices. That certainly created regularly scheduled opportunities to share or suggest new practices, but that never seemed to lead to anything, possibly because I don’t think anyone had any perspective on what was worth sharing and what wasn’t. It’s surprisingly easy to blur the border between “best practice” and “strong preference held several opinionated developers,” and people really don’t want to be obligated to adhere to the latter.
Ideally, what you want is to create regular instances of developers “talking shop” with developers from other teams, which then creates this sort of virtuous cycle. However, the problem there is you run into people like me who avoid chit-chat at all costs, and would find any excuse to avoid these get-togethers. In theory, a scrum master could help with this by sharing insights gleaned from retrospectives, but that’s assuming a) your team practices scrum and b) you’re having retrospectives, which in my experience have traditionally been the first ceremonies to get dumped.
Maybe part of the problem is that when it comes to cross-team knowledge sharing, we abandon the cross-functional nature of teams. We get so focused on sharing things between developers on scrum team A and developers on scrum team B, but scrum teams aren’t just developers. Knowledge sharing might be more productive if we defaulted to sharing at the whole team level, with optional deep-dives for role-specific stuff to get into implementation specifics. The best practices that usually stick tend to be more holistic, so trying not to break things out by roles may be the best approach.
Personally, I think platform engineering could help with this. By treating the development platform as a product, best practices could be propagated via feature requests to the platform engineering team. Best practice features get prioritized and added to the platform, and then “adopted” by other teams through the platform updates. Since we’re talking about the development platform, different teams in the organization would likely be hearing about proposed changes relatively early on, so there’s time for development teams to discuss the need for the new features, as well as any proposed trade-offs, before development actually starts (we’re talking about updating an organization-wide development platform – the last thing you want to do is surprise anbody). Relying on platform engineering to “push” best practices seems a little top-heavy, especially for organizations that want to emphasize that they use scrum because they’re agile, but everything’s ultimately being driven by development teams, so I think that perception may not be justified. This does, however, still rely on regular cross-team discussions, prior to changing platform functionality, but at least now these discussions are more focused, and people aren’t coming together unless there’s something to discuss.
Ultimately, spreading best practices across scrum teams requires regular meetings between the teams themselves to talk about how they’re doing things, what’s working, and what’s not. Thanks to teams being independent, that cross-team communication is something that has to be forced. Forcing those discussions is awkward, because there’s no context for what would be relevant for other teams and what wouldn’t. Probably the best way to structure these conversations is as part of the platform engineering development process, but that means developing a platform engineering process first…so…good luck with that.