Before deciding on what to choose, be it Scrum, Kanban, XP, squads, tribes, guilds, clans and what not, it's worth mentioning that your eventual setup will depend a lot on the nature of the projects themselves and on the skills of the people you have.
- You say projects aren't necessarily related to each other, but then you mention Scrum Of Scrums, which makes more sense when you have multiple teams working on the same product and they need to synchronize, coordinate and plan together. What are the characteristics of these projects? Are they independent? Part of the same product? Related but different products? All of them?
- You then have 12 people and you mention 3 Scrum teams, with variable number of members. Do you have all the skills needed in each team? Or will someone have to be shared between the teams because they have some particular skill or knowledge?
I've seen this situation before and it feels like driving many cars on multiple lanes at different speeds, but then also having to reach certain points in the road at the same time, or changing the drivers of the cars while driving, and reaching the finish line with a different type of car than the one you started with. Not fun!
You will have issues with dependencies (be it for people skills or for software dependencies) which can turn into blockages or introduce delays if not managed properly. And it will make it also harder to plan if you use sprints, for example, because you need to plan many (possible unrelated things) each sprint, and if projects have different lifetimes you will inevitably change structures of the teams and which will impact predictability and people finding their pace so any estimates or plans you make might be impacted because your yesterday's weather changes all the time.
So my advice (before trying to make something from the above list of approaches fit into your teams, and possibly struggle with making it work for your particular situation), would be to do the analyze I mentioned above regarding the projects and the skills, lay out and visualize the current process you are using, then use principles from Kanban and Lean to keep progress on all lanes. Spend less time on estimating and planning sprints and instead, use daily meetings to get an understanding of priorities, figure out the order in which to do your activities, work on them until your next daily, when you regroup and repeat. This will cause people to naturally group themselves around the work that needs to be done and not necessarily work together because of the boundaries their team membership imposes on them.
This may look like a lack of structure until you figure out the best way to work, and it may certainly take a while until things start running smoothly, so you need management's support (or at least understanding) on this approach.