I manage a team with seven developers with more than ten products and 20 integrations between products. I took over the team a year ago, and we have worked hard to spread knowledge across the team. A year ago, every developer was basically a silo for several products and integrations, making us very vulnerable. This has improved much, and we are in a much better place today. This has been handled organically and ad hoc through co-developing and pair programming.
Recently, some developers have suggested a more structured approach to ensuring all our products and integrations are well known in the team. They want every developer to have a specific range of responsibilities regarding systems they can be asked to make changes to. So development in system X can only be done by developer x, y, or z - and not by the developer a, b, or c.
First I thought this was a great idea - everybody should not know everything. But giving it more thought, I can also see some downsides to this approach. It becomes significantly harder to plan sprints and make sure work is divided evenly with these restrictions. We could end in a situation where developers have nothing to do at the end of a sprint, whereas others are overburdened. This does not feel like a team taking responsibility for a sprint. Also, we can be forced to but less valuable work in the sprint to make sure there is work for everyone.
Are there any best practices or experiences you can share regarding having a flexible team without too much vulnerability? For example, is it realistic to ask developers to work in many products if there is an exact language and framework, common code practice, well-documented code, well-tested code, and good review processes? Or do we have to assign certain developers to certain products?
Of course, scrum is just a framework that you can customize according to your needs, but as far as I experienced, it doesn't work for a team with multiple projects. For this kind of scenario, kanban is a better approach.
Besides, learning a project is learning a specific historical era; it can not be achieved by only reading. A developer should read the code and the documentation, talk to the previous developers/business stakeholders, practice solving problems with some real issues. And this takes time. If you multiply this with multiple products and keep the turnover rate of the developers, you will see that it will not be feasible to achieve what you have in mind.
What I would recommend could be preparing a runbook for each project and doing pair programming sessions with a navigator & driver model and try to achieve to have at least 2 developers mastering a product and optionally others to know at an introductory level which at least help them to build and debug it. Here's my article about this approach.