The challenge of Nexus, Scaled Professional Scrum (SPS)

I am in a project running with scaled scrum using Nexus framework. Nexus means a relationship or connection between people, which is a unit of development in a scaled Scrum. Software development is complex, and it’s more challenging with multiple teams build on the same product with many dependencies during the integration. Other than more roles, artefacts and events, here are three main issues I found in day to day work:

1. Nexus Sprint Planning with only one Product Owner

According to the scrum guide, there is only one single Product Owner who has the final say. After the nexus sprint planning, multiple teams run their individual sprint planning, then it becomes tricky logistically for Product Owner to join all of them. If the individual team’s sprint planning happens concurrently, then it is impossible for him/her to answer questions on domain knowledge and priority decisions at the same time. If the meetings are arranged asynchronously, then it would be quite a time consuming for the Product Owner. Furthermore, some resources may be shared among different teams, such as the same Scrum Master, Senior architect and designer within the same product. Even worse, some organisation may assign a group of product owners to take the same role of maximising the value, which would lead to other problems in practice with nobody has the final say of the scaled product.

2. Visualising of the Product Backlog Refinement

New dependencies may emerge, which should be visualised and minimised. However, there are no great tools in the market existing yet to help easily visualise the dependency’s status, whether it is in progress or if it is resolved. JIRA and trello are lack of features for cross-team refinement board, and it could be frustrating to keep chasing up for status as well as finding the right person who has the technical skills to understand why it is an impediment. Due to the complexity, the scrum master may not have enough understanding of the full picture either on the details or the impacts to help manage the dependencies.

3. Nexus Sprint Review with a drop of Velocity

There is integration related work to do, which could lead to a drop in velocity. However, which team should do the overlap work is a question, while different teams have a different estimation baseline and different agenda. Some integration work is time-consuming, such as the deployment of servers, setting up automated test and resolving git code merge conflicts. These are necessary but time-consuming work, which could be benefits to both teams, while the values are not fully reflected in story points, but only lead to a drop of burndown velocity. Senior management would then cause a lot of troubles on addressing why the velocity decreases. Furthermore, even if each team completed their stories according to the Definition of Done, some defects would be merge after integration in the empirical world, which requires further discussion across teams to resolve the issues.

Nexus Integration Team mindset is the solution

Overall, having the right mindset is the most important part to deal with complexity and unpredictability in software development. The three issues I mentioned above, including meetings, tools and shared work are only symptoms of a more fundamental problem, which is having everybody in the team to embraces changes. Not just the self-organised development team, but also leaders of the organisation to understand agility.

Do you have experience in a scaled scrum, such as SAFe or LeSS? Any feedback is welcome and I look forward to learning from your feedback.