How to organise teams to deliver with Nexus
With 10 scrum teams all working on related but not similar products, any ideas how we can eliminate dependencies with Nexus or a similar?
We have 10 scrum teams and 5 products. The products are related. Usually to deliver value changes must be made on 2 or more products and so 2 or more teams.
We'd prefer to be able to deliver any requirements across and product as a single group. We do not want to manage dependencies and competing priorities. We'd prefer to work on 5 or so priorities and have the people needed to work solely on 1 priority at a team within a team.
My understanding on Nexus is that the Integration Team would manage this, I'm not sure how cumbersome that would actually be.
The problem is that key people across the group are silos. Also if we create temporary teams to deliver then it's time consuming to "form" and then disband, not really feasible. I believe permanent teams would be better but then not all value will require the same skills and knowledge so the team would need to change with each deliverable.
I'm aware that this could partially be an architecture issue.
i'm aware of cognitive load on developers too.
Team Topologies has some suggestions.
Frameworks to scale Scrum, like Nexus and LeSS, are designed to help solve problems around multiple teams working on a single product. The implication is that there is a single Product Owner and a single Product Backlog and multiple teams working toward a Product Goal. It doesn't sound like this is your situation.
My first question would be if the dependencies are necessary. If you have separate products, is it possible to eliminate dependencies between those products? If you have 10 teams and 5 products, it seems like you should be able to set up an environment where each team is dedicated to a single product and some products may have multiple teams working on them. Although frameworks like Nexus and LeSS are designed for 3 or more teams, you may be able to take some lessons for cases where there are only two teams working on the product.
If, for some reason, this isn't possible, a different perspective could be to look at your product portfolio (the set of these closely related products) as a single product. Nexus doesn't have the terminology for this, but the individual products could be what LeSS Huge calls Areas.
Depending on how many total people you have, you may also want to look at FAST Agile and, more generally, dynamic reteaming. Willem-Jan Ageling has written about fluid Scrum Teams, which takes these ideas and applies them to a context that is closer to Scrum. If you can get your priorities down to the equivalent of a Sprint Goal, you can form dynamic teams each Sprint around achieving each priority and creating a temporary (fluid) team to take on each priority.
Breaking down the silos will be key. If the teams choose to adopt dynamic reteaming, they can make sure that a dynamic/fluid team has some expertise in the product(s)/area(s) impacted by the work and some people who are new and want to learn. Pairing and mobbing techniques can be used to disseminate knowledge. If you can't break down the silos, though, you'll be more limited in how you can organize the around the work.
My understanding on Nexus is that the Integration Team would manage this, I'm not sure how cumbersome that would actually be.
The teams in the Nexus would manage this themselves , not the Nexus Integration Team. The NIT is there to ensure that the teams in the Nexus have the necessary focus. It's important that any encumbrance is minimized.
I'm aware that this could partially be an architecture issue.
You could well be right, and that's what you ought to deal with first, before you even think about Nexus or LeSS or scaling.
In Scrum, scaling happens as a last resort. The first option is to descale the challenge, so that it reduces to one or two teams that require no scaling accommodation. The best work is done by teams that are altogether unencumbered. That could involve first descaling product architecture, solutions architecture, business architecture, infrastructure, and many other things.
Thank you both.
I'll look into the frameworks and maybe try to take something from each.
I've been trying Dynamic teams for a few weeks not, it's not ideal, as we know if can take some time for teams to gel and trust. Metrics go out the window too, difficult to forecast. People coming from other teams which may not be fully practicing Scrum, management wanting the people back for other projects etc.
Dependencies are a nightmare as we all know.
To compound the problem we have multiple POs which have all be siloing the work into teams and even individuals where the can.
Changing the Architecture would be great, breaking the silos would be great, reducing the bottlenecks by removing the silos would be great. All of which take time, pressure is on to deliver as is the usual.
I'll come back here after looking at the other frameworks.
Have you considered creating value stream maps to make the dependencies more transparent, showing where work is stopped because of this? And measure flow efficiency? From there, you might work with leaders and teams to start removing dependencies. This may even call for people to self-organize into feature teams.
I've had a very quick look at the frameworks, interesting.
I do wonder, as a Scrum Master, how Scrum works with dynamic teams, I'm thinking of the lack or metrics and the human element of switching between working in different dynamics regularly (this could be a good thing).
I'm thinking now of using a nexus model, static Scrum Teams, pulling in the dependencies (people) when dependencies are identified as a low ceremony dynamic team, the people still use their static Scrum Team.