Compromises in setting up teams in a scaled framework

Making the first steps setting up a scaled framework with agile teams in a complex environment does not always allow to set up teams by the book. Rather than dragging people from their current activities and having everybody dislike agile, before we have even really started using and living it, I try to make compromises.By working in very short sprints of one week, I allow team members to switch between teams with every start of a new sprint. For the one sprint however, they commit to be fully engaged in the sprint backlog and team activities of the one single team.Product owners can plan with the team members' knowledge for some sprints. The team can make the experience i.e. every other sprint what they are capable of on their own and build confidence and where they still need more knowledge transfer and help. Multi skilled team members can learn step by step to let go their „baby“ and still be engaged in the field of the product.An alternative in the same situation might be:If there is a huge overlap in skills needed for one and the other team or part of the product, try putting the teams to ether being one team. Build rather large teams in the beginning covering two backlog (should not be more). Creating a team backlog rather than a product backlog allows the others to learn about the other parts of the product by just being in the team and does not force team members to leave one or the other part of the product without their experience and knowledge.Forcing the teams into a decision for one or the other might lead to the opposite - double work by only making one part transparent or frustrated „left alone teams“ and multi skilled team members with feelings of guilt.What else have you tried?