In Scrum, it’s the Product Owner‘s responsibility to manage the project’s budget, therefore we could assume s/he assigns the appropriate resources to the team. However it’s quite usual in organisations to have a Department’s manager who builds teams according to project needs.
This situation is not opposite to Scrum best practices but decisions should be agreed, the functional manager has the ‘authority’ but the Product Owner needs to influence the decision. It’s highly important PO feels confident and at ease with the team.
One important consideration when forming teams in Scrum is the balance onseniority levels. In Scrum everyone is a team member, but technically speaking, we all know developers could be junior or senior depending on their years of expertise and capabilities. Keep in mind that Scrum teams are self-managed so if you have all juniors in your team, it’s likely you’ll lack control and you’ll be clarifying what to do all the time. On the other hand, if all seniors, your team might be corrupted and moved more into the technical viewpoint rather than focusing on creating value to the customer.
Last but not least, it’s interesting to make multidisciplinary teams in Scrum. Having a feature working on back-end does not add any value until front-end is finished. Therefore, why having both teams separated? And not only back-end or front-end, we can include devOps, UX, web design, QA, etc. In the end, Scrum is about building a product that works, not about building slices of a product that does not work until all pieces are matched together.
To finish with, Scrum teams may change along the way – perhaps because someone leaves, perhaps because project needs require so – but it’s crucial to always keep the same balance and environment. In the end, it’s all about people.