I was working on a project that utilized the Nexus framework and scaled Scrum. A Nexus serves as a development unit in scaled Scrum, forming a relationship or connection between people. Software development is already a difficult task, and it becomes even more challenging when multiple teams are working on the same product with numerous dependencies. Aside from grappling with various roles, artifacts, and events, I encountered three major challenges in my day-to-day work:

  1. The Singular Product Owner and Nexus Sprint Planning - According to the Scrum Guide, ultimate decision-making power lies with a single Product Owner. Multiple teams conduct their own sprint planning sessions after the Nexus Sprint Planning. This makes it challenging for the Product Owner to participate in each team’s planning if they occur simultaneously. The Product Owner can’t address domain knowledge questions or make prioritization decisions for multiple teams at the same time. If meetings are scheduled asynchronously, the Product Owner would waste significant time. Additionally, resources like a Scrum Master, Senior Architect, or designer may be shared among different teams. Some organizations even designate a group of Product Owners, complicating decision-making as no one has absolute authority over the scaled product.

  2. Challenges in Visualizing Product Backlog Refinement - New dependencies can arise, which need to be identified and minimized. Unfortunately, existing tools like JIRA and Trello don’t offer easy ways to visualize the progress or resolution of these dependencies. Scrum Masters may not fully grasp the complex technical implications, making it difficult to manage dependencies effectively.

  3. Reviewing Nexus Sprint Through the Lens of Velocity - Integration work is inevitable, and it can impact the team’s Velocity. Since each team has its own estimation baseline and agenda, it’s unclear who should take responsibility for overlapping work. Time-consuming integration tasks like setting up servers, automating tests, and resolving git code merge issues are crucial but may slow down the team’s progress. These tasks may not be fully accounted for in story points, which can mislead senior management when they see a drop in Velocity. Additionally, even if each team completes their stories based on the Definition of Done, post-integration in the empirical world could introduce new issues, requiring additional cross-team discussions.

The Mindset of the Nexus Integration Team Is the Answer - The most important factor in managing the complexity and unpredictability of software development is having the right mindset. Meetings, tools, and shared work are merely symptoms of a more fundamental challenge: getting everyone on the team, including organizational leaders, to understand and embrace agility.

Have you worked in a scaled Scrum environment before, such as SAFe or LeSS? I welcome any comments and look forward to learning from your experiences.