Kerio's experience is that it makes sense to share some developers among teams. Let me tell you how we manage one such group, what problems we face and how we learned to overcome them.

One of my teams, the Autobuild, has a wide range of responsibilities (source code management, build infrastructure, build scripts, installers, customizations of our Linux distribution, virtualization, and a few more). If we wanted to have an expert for every area in every product team, it would require several new hires; yet substitutability, expertise sharing and code sharing would still suffer. ("How do you conduct a code review when there's only one person in the team who barely understands the technology?")

On the other hand, having these developers outside product teams has drawbacks. ("What do you do when every product team plans to use the shared team exclusively?") We invented "reversed scrum": Product owners attend Autobuild team's planning sessions, bringing their requirements and prioritizing them across the whole company. We have also learned that a shared "resource" cannot be as flexible as a product team, thus we try not to put them onto the critical path - if they (for whatever reason) need to work on someone else's project for a few days, your project doesn't halt.

Unfortunately, the shared team's work for a product lacks an assigned cost, and product managers spend their own team's time more responsibly than the shared team's. ("Well, we don't need it that much, but they could do that for us anyway, let's ask.") You know, communism doesn't work. Though responsible management is a remedy, the ultimate solution is naturally not having the shared team, and a reasonable compromise is having the shared team work more on the shared stuff than on per-product features.

Even worse than struggling with planning, we were not able to foresee all the little yet urgent requests from product developers, which - together with unplanned firefighting of broken builds - consumed almost 50% of the team's time in some sprints, and still the work on new product features wasn't smooth and quick enough.

Hence we realized that our product teams had grown enough, so they needed and could afford to have someone on the team who would learn and do the simple but often urgent changes that would otherwise require slow and relatively expensive planning or communication with the Autobuild team. The shared team still develops the shared parts, and also becomes the mentor to the product teams.

Most of the installers have been recently handed over to product teams. As you might guess, the Autobuild team discovered that one of the product developers didn't ask and made injudicious changes to the installer, so his code had to be heavily reworked; well, that's life and that's what code reviews are for. Besides this one-off mistake, we keep the quality, our development is faster, and the Autobuild team now has enough resources to work on company's source code repository migration to GIT.

To sum up, for Kerio it is reasonable to have a shared team, working for multiple projects, despite the problems it always brings. We adjusted scrum planning, and we watch the problems, and continuously balance what part of work (and workforce) we have on the shared team.