That's a good way to do it, especially if you think that there may be difficulties across the organization that one team will be able to surface. Here are some things to look out for:
- shared dependencies, including other teams and people
- KPIs that make different roles compete against each other
- people working on multiple projects, rather than the one the team is focusing on
- product owners and analysts who are used to providing the teams with more technical solutions, rather than descriptions of the problem they're trying to solve
- a project which turns out to be too big and weighty to be easily adopted by a newbie Agile team.
Your first Agile team should ideally be working on a small, "quick win" project, especially if it's risky. Try to avoid anything with lots and lots of dependencies; even experienced Agile companies struggle with those.
Most people doing this leave the operations team out until the end, but there's a growing movement to embrace them (devops). If you can, do it.
Richard Durnall has written some excellent "expansion patterns" in this presentation, for when you've got the first team going and want to grow it. You may also find his post on the order in which different bits of the company break during an Agile adoption useful.