Thoughts on Nexus

How familiar are you and the organization with Agile and Scrum? You can buy a book and try to make it work but without real word experience it won’t be easy.

Nexus is recommended when you have 3-9 teams not just  concurrent sprints.

You are going to fall flat on your face if you have no applied knowledge or experience. As the guide says easy to learn hard to master. Nexus adds a layer of difficulty on top of tradtional scrum.

Why do you need to scale? What’s the driver? How many teams do you have? Are you already doing something like Lean Software Development.

As dumb as this is going to sound I decided to do Nexus Scrum because it is one of the “easier” scaled scrums to implement but not without experience.

Good luck.

we are shortly going to be embarking on number of sprints to deploy a product (the sprints will be concurrent but have different team members)

How important do you think it will be to integrate work on a regular basis in order to assure transparency? What’s the best way for this to be co-ordinated and managed?

Very first question before going to be scale is, do you think you can achive the same work with teams you already have ? In addition this, dependencies are getting as an obstacle? Finally, as @Ian mentioned you need to create an integrated work each sprint?

I would recomend you thinking twice these items then decide to scale.

I would recomend you thinking twice these items then decide to scale.

Indeed. Scaling ought to be viewed as something of a last resort, since it introduces co-ordination dependencies such as complexities around integration. Improving the ways-of-working of a single team ought to be the first recourse. There is also a danger of scaling inefficient practices when it is done precociously.

How many Scrum Teams will be working on the same product?

Although the Scrum Guide doesn't specifically mention multiple teams, they can still work on the same product without introducing a scaling framework.

For instance, two co-located teams working on the same product should be able to collaborate effectively without any scaling framework.

If there isn't the need to introduce a full scaling framework, it is still sensible to consider how the teams will co-ordinate.

You might choose to run sprints on the same cadence, and consider adjusting some of the events. e.g. the first part of the Sprint Planning held with all teams, holding a shared Sprint Review, and perhaps holding a combined retrospective before or after each team has its own Sprint Retrospective.