Single project, multiple team does it work?

It's worked a zillion times for others', and I have personal experience with it myself.

Scaling beyond single team Scrum is not for the feint of heart. My suggestion is to get a good Scrum coach who has experience in this area to help your organization.

IMO, the most proven and best literary resources for Scaling Scrum are here:
http://www.scrumcrazy.com/My+Preferred+Agile,+Scrum,+and+XP+Resources
^^ "See the "Scaling and Spreading Scrum" section.

I would strongly encourage you to avoid SAFe and DAD. Those processes are heavy weight, ineffective, not Agile at all, and expensive.

Yes, you can certainly have multiple teams working from the same backlog. Holding the associated Scrum events can however become an issue, as you have already surmised.

This is because the teams will need to collaborate on creating a potentially releasable increment...which implies that they will need to synchronize their sprints to accommodate shared integration points. That would make for a very busy Product Owner, who would have to attend planning, review, and retrospective sessions for different teams on the same day.

The most common solution is for the Product Owner to appoint proxies who can act on his or her behalf. In practice, proxying often tends to fall to business analysts who are able to explain scope but this is only a small facet of what product ownership is about. Such proxies need to liaise closely with the PO on matters of value and prioritization, and prepare for the Scrum events carefully.

All of the above are good suggestions.

What I have done in the past when managing multiple teams in a single backlog is to hold regular backlog refinement meetings throughout the Sprint/release. This helps spread the time needed for the team to get a good understanding of the stories at the top of the product backlog throughout the Sprint/release as opposed to doing it all in the 1st half of Sprint planning. This time saved allows the PO to be able to support multiple teams as they don't need to spend as much time in the 1st half of planning and they only need to be "available" to the development team during the phase 2 of Sprint planning.

For Sprint reviews, instead of holding individual reviews, I hold one large review for the 3 teams involved. The Sprint review meeting that has a lot of good feedback not only from the stakeholders, but the other teams feedback to each individual teams work in the Sprint.

> ...hold regular backlog refinement meetings throughout the Sprint/release

This is a good point, and has reminded me of something else that should be done. Don't defer the PO's approval of completed backlog items until the Sprint Review. Encourage a continual process of review and approval throughout the Sprint.

This not only de-risks the Sprint Goal, it makes the Sprint Review simpler and potentially quicker. Coupled with effective backlog grooming and short enough Sprint cycles, it can become plausible for a PO to attend multiple team events on the same day.