Nexus Scrum - Scaling Questions
Dear community,
In our organization, we use SCRUM principles across the board, and all non-development team members have passed your certifications (PSM, PSPO, ...).
Last year, with several SCRUM teams and a single product, we adopted Nexus and everything went well. However, as the company and customer base have grown, our PO is now overwhelmed with interactions with stakeholders.
I'd like to hear your opinion on the best way to deal with this situation? Should we use Key Account Managers outside the SCRUM framework to provide information to the PO? Or would it be better to introduce Project Managers who can gather customer requirements and pass them on to the PO and maintain this ongoing relationship with the customer? What is the most correct and effective way to approach this?
Has your Product Owner created a stakeholder map? With so many stakeholders, it can be overwhelming, yet some have more stake and power than others. This map helps classify these people to determine where to focus and where to spend less time.
Rather than putting a middle person between your Product Owner and customers, which may impact transparency, I would rather see the Product Owner delegate some tasks to other Scrum Team members (e.g. user story writing, refinement). It is important for the Product Owner to think strategically and talk to customers rather than being an order taker.
as the company and customer base have grown, our PO is now overwhelmed with interactions with stakeholders.
Why would that growth prove overwhelming? Is the ability of the Nexus to experiment, and respond in a timely way to emerging stakeholder needs, somehow constrained?
The primary distinction between Scrum and the Nexus framework lies in their scalability and focus. In my perspective, if a Product Owner (PO) can effectively manage the Scrum Product Backlog (PBL) across multiple teams without encountering issues regarding stakeholder demands, then they are likely to encounter minimal challenges in handling a Nexus product backlog. This is because the PO delineates the developmental tasks in a rolling wave planning approach.
The management of stakeholders, as Chris highlighted, necessitates a strategic approach, such as mapping out stakeholder power-interest matrices. It appears that the maturity level of your product owner aligns with either a Scribe or Proxy Product Owner archetype, as discussed by Robin Shuurman in the article "Growing Product Owner: Five Product Owner Maturity Levels."
Drawing from my experience as a former Business Analyst and a self-managed Scrum Master, I employ the MENDELOW Matrix to assess stakeholders based on their interest and influence. Those stakeholders holding significant power and interest within the organisation dictate actions, prompting a focus on how tasks are to be accomplished rather than why. The Scrum framework underscores the Product Owner's authority in maximising product value, implying that their decisions should be respected throughout the organisation. Therefore, it is imperative to evaluate how your organization perceives the role of the Product Owner.
For a "Scribe or Proxy" PO, aligning with stakeholder interests and power dynamics becomes paramount in prioritising the Nexus backlog. Conversely, a matured PO akin to a Sponsor or Entrepreneur determines value propositions autonomously, prioritising the PBL accordingly. This approach cascades into the respective Nexus team Sprint Backlog, fostering continual adaptation as new insights emerge.
In addressing an overwhelmed Product Owner grappling with stakeholder demands, several strategies prove beneficial:
-
Delegation of responsibilities while retaining accountability, in line with the Scrum value of Courage (seek help).
-
Prioritisation of tasks and requirements based on importance and urgency, focusing on high-value items aligned with the product vision.
-
Effective stakeholder management through clear communication, transparent progress updates, and negotiation of priorities.
-
Collaboration with developers, Scrum Master, and stakeholders to share workload and gather input on decision-making.
-
Time management strategies, including dedicated periods for backlog refinement, stakeholder engagements, and sprint planning.
-
Cultivation of a culture of continuous improvement, encouraging reflection, optimisation, and experimentation.
-
Provision of support by the Scrum Master and developers, offering assistance, feedback, and problem-solving aid.
These recommendations are offered based on personal insight and can be tailored to suit individual circumstances as deemed appropriate.