TL;DR
How to share developers between multiple agile projects?
You don't. Doing so is inherently non-agile.
This smacks of an X/Y problem, where X (the real problem) is likely to be an executive mandate to "do more with less" without prioritizing projects based on both business value and resource constraints. However, you or your organization may have decided to solve for Y by looking for a silver bullet that will make the impossible possible.
There is no silver bullet. Make sure you're solving for X, rather than Y!
Your General Options
In an agile practice, you can generally choose between:
- Fixed, cross-functional teams that work on different projects, but only one at a time.
- Product-based teams, where the teams are formed around each product. Note that each product will have its own separate Product Backlog, and each team will work from exactly one Product Backlog.
- Feature-based teams, where teams are formed around features (rather than projects), who may either share a single Product Backlog or have one backlog per feature team.
How you delineate projects, products, and features can complicate this, but the distinction between a single product with many features and multiple products should be your guiding principle. A great deal depends on correctly conceptualizing the project, and not being afraid to split off related projects when they no longer fit within the bounds of a single product or team.
You Must Address Resource Constraints.
In all cases, you can't really do what you seem to be trying to do, which is spread the peanut butter ever thinner without adjusting your resource constraints. Specifically:
- 20 team members are not enough to support 100 concurrent projects. One team, one project! is a hard rule with all agile frameworks.
- Unless you've done a better job abstracting your architecture or building cross-functional teams than you've described here, you don't have five products, you have twenty! As a general rule,
5 products * 4 platforms = 20 product backlogs
.
- This would require at least 20 teams unless you prioritize and sequence the deliverables.
- You might also consider cross-functional teams that can build one product from one backlog that targets multiple platforms (think PhoneGap as an example), but you still don't have enough people to staff for five such teams.
There are other problems with your conceptual approach, too, but they all boil down to the fact that you're trying to do too much with too little. No matter how you structure your projects, you can't do them all at the same time with the resources you have. You either need to add resources, prioritize the use of your available resources, or (ideally) do both.