Nexus sprint review ; how to run it ?

The size of the Development Team doesn't have a significant impact on the duration of the Sprint Review, in Scrum or Nexus. The Sprint duration has much more of an effect as I would expect that, in a longer Sprint, more work can get done that would need review. There's also a longer period for changes external to the teams that may need to be reviewed and incorporated into the Product Backlog.

In Nexus specifically, I wouldn't look at it as "9 teams presenting to each other". I would look at it as the Nexus reviewing their Sprint with the stakeholders. There is nothing that says that all individuals, or even all teams, must be actively involved.

If space is your primary concern, there are several alternatives. When working in a scaled environment, my preference is to have an event before the Sprint Review with stakeholders for the teams. This is more technically-oriented and lets the teams get into the more technical details of their contributions to the Increment. Then, only appropriate people may attend the Sprint Review. Another option would be to allow remote participation to the Sprint Review to ensure that the key participants can be co-located, with passively interested people able to listen in and observe remotely. Another option would be to scale down the Sprint Review and only invite team representatives rather than the whole team.

In the end, you need to find what works for your team, organization, and stakeholders. If you focus on the intent and purpose of the events, you'll probably end up in an effective place.

Does it really have to be held that way ? 9 teams presenting to each other their part of the increment ?

That isn't what the Nexus Guide says, so the answer is no, it doesn't have to be that way.

Other options include the use of suitable representatives by each team, or better yet, the Product Owner or most impacted stakeholder presenting the integrated increment, and thereby perhaps better evidencing that the increment is Done and fit for immediate release.

So here is a real life situation that I experienced a million of times in my current organization (although leaving in 2 months). Small note is that they have adopted SAFe, but still the setting and mindset would not be different when they would have went for solely Scrum or maybe the Nexus framework.

There are 8 teams working in total. Now for the sake of clarity on the situation I'm not gonna go into the fact that they are working on multiple products. They have tried multiple types of Sprint Reviews (let's just call them NSP's(Nexus Sprint Reviews)).



- One where every developer told what he/she did. As you might imagine, 76 developers talking about what they did is incredibly boring and long. Stakeholders left in confusion. 

- One where the PO's in the Scrum Teams (just proxies, whilst thinking they are full PO's) discussed what the team did that Sprint. Later this "improved" to also discussing what they learned and how this can be adapted. 

- One where more of a timeline was discussed by the actual Product Owner with the input of all the teams was included.

- Even just single teams having separate Sprint Reviews, resulting in stakeholders having the stitch together the entire picture together to get to a basic understanding of the state of the product.



None of these had any form of coordination, let alone integrated product. Every team was just doing a status update, where no one was looking at the bigger picture. Attendees where bored, constantly had to switch their focus. Or just utterly not interested in what was being told. Stakeholders were no actual stakeholders. There was no customer, no marketing, no sales, no user, nobody but managers and interested people. 



With a lot of massages, complaining, crying, and other ultimate desperate attempts I finally got to the point where the first effective NSP has now been planned. Things that have changed:

- Teams have now been organized around a product, instead of the other way around. 

- Teams actively discuss dependencies and try to have them as minimal as possible. 

- The Product Owner actually organizes and facilitates the NSP, where actual stakeholders are invited to share their experience (testing by the stakeholders is done throughout the Sprint, having a closer look into UX).

- They time that was used for telling what was done that Sprint was brought back to an as-short-as-possible timebox, so that actual working product could be demonstrated to get the total state of integrated product clear to everyone at once. 

- More time was left for feedback, questions, discussion on what to do next, quickly going through the release roadmap etc.



Obviously there still are improvement points. There always will be. But the points mentioned lastly might be of effective use for you, too. Hope it helps.

The purpose of the Nexus Sprint Review is to obtain feedback so learnings can be used for the Product Backlog. So, whatever facilitates this best is what you should do. I recommend starting broad and then go narrow. In other words, have everybody there and then experiment and what works best. You will likely quickly find out that you do not need all of your developers present and instead you would rather have your developers developing. Your developers will be relieved they do not have to go to another meeting and you will get a little boost in productivity. Now, your developers will have a good understanding of what goes on in the Nexus Sprint Review because they have experienced it. You may find what works best for one sprint might not work later. So, be sure to continually inspect and adapt. Stay Agile, my friend!