Managing knowledge distribution across a Scrum Team
We are a Product team delivering DevOps tools for internal use within our organization. The work in the product team usually involves installing, configuring, testing, integrating, and deploying the DevOps tools. We were a small team (around 4 devs) until recently. We have now increased to 8 devs. When we were a smaller team, we had decided to become "generalists" i.e. everyone could work on any of the DevOps tools. Now that we are 8 devs, it's going to be difficult to continue with the generalists concept.
Are there any known strategies for managing knowledge across the team?
One option may be to better define the products that are part of your "DevOps tools". A product may consist of multiple tools, but you could organize these tools into discrete products and build teams around supporting teach product.
Another option could be to organize around value streams. Each team may work in multiple tools, but would serve a particular set of end users or customers of those tools. If a customer doesn't use a tool, they may never need to touch that tool for their development. They can become deeply familiar with the people who use the tools and optimize their work for that particular audience.
There may be other options, as well, but I'm not sure that you could split fully. For example, if your tools are on a common platform, splitting out a platform team and having other teams focus on individual tools, small groups of tools, or value streams.
I would recommend Team Topologies. On the surface, it seems like reorganizing your people into better teams would give you what you need, but if your environment and architecture don't support it, splitting into smaller teams could introduce cross-team dependencies which would introduce management complexities.
How much of a generalist does a Developer need to be? Do you have a feeling for that, and of the degree of cross-skilling required before the team's workflow becomes impeded?
Remember that maintaining a range of skills can be expensive, and the cost of being a generalist is not necessarily justified. Often it is enough for a Developer to have one or two additional disciplines. Ideally, this would allow them to assist and smooth the flow of work at the boundary of their core discipline, when bottlenecks or starvation seem likely to occur.
For example, in the workflow you describe of:
installing, configuring, testing, integrating, and deploying
a test specialist might acquire T-shaped ancillary skills in configuration and/or integration only.