I was working on a project that used the Nexus framework and used scaled scrum. A Nexus is a relationship or connection between people that serves as a development unit in a scaled Scrum. Software development is difficult, and it’s even more difficult when different teams work on the same product with numerous dependencies. Aside from various roles, artefacts, and events, I discovered three major challenges in my day-to-day work:
With only one Product Owner, Nexus Sprint Planning is possible. - According to the scrum guide, the ultimate decision is made by only one Product Owner. Multiple teams perform their sprint planning after the nexus sprint planning, making it difficult for the Product Owner to join them. If each team’s sprint planning happens simultaneously, the Product Owner won’t be able to respond to domain knowledge and prioritize decisions simultaneously. The Product Owner would waste a lot of time if the meetings were scheduled asynchronously. Furthermore, some resources, such as the same Scrum Master, Senior architect, and designer within the same product, may be shared among various teams. Worse, some organizations may designate a group of product owners to maximize value, leading to other issues in practice because no one has absolute control over the scaled product.
Refinement of the Product Backlog Visualization - New dependencies may emerge, which should be identified and minimized. However, there are no good tools for quickly visualizing the dependency’s progress or resolution. Cross-team refinement boards are missing from JIRA and Trello. It might be frustrating to keep chasing down status and finding the proper person with the technical abilities to understand why it’s an issue. Due to the complexity, the scrum master may not have a thorough understanding of the intricacies of the implications to assist in the management of dependencies.
Review of the Nexus Sprint with a dash of Velocity - There is integration work to be done, which may result in a decrease in Velocity. However, given that each group has its estimation baseline and agenda, whose team should be in charge of the overlap work? Some integration tasks, such as installing servers, automating tests, and resolving git code merge disputes, take time. These are important yet time-consuming roles that could help both sides. The values aren’t entirely reflected in tale points, but they result in a slower burndown rate. Senior management would then go to great lengths to figure out why the Velocity is decreasing. Furthermore, even if each team completed their stories according to the Definition of Done, following integration in the empirical world, certain faults would be integrated, necessitating extra cross-group conversation to resolve the issues.
The thinking of the Nexus Integration Team is the answer. - The most important aspect of dealing with software development complexity and unpredictability is having the correct mindset. Meetings, tools, and shared work are just symptoms of a more fundamental problem: getting everyone on the team to embrace change. Not just the self-organized development team but also the organization’s leaders must grasp agility.
Have you worked in a scaled scrum before, such as SAFe or LeSS? Any comment is appreciated, and I look forward to gaining knowledge from it.