Contents

1 What is nexus framework?
2 What is nexus in software development?
3 How nexus framework scales scrum?
4 Nexus framework implementation
5 Nexus Implementation Strategy
6 Nexus teams
7 Nexus events
8 Product owner
9 Key takeaways

Scrum, the most common agile way that software development teams work, leads to the question of, ‘How do we scale Scrum beyond a single team?’ If you have problems with cross-team dependencies, risks that affect several teams, or scheduling of deliveries, you might need a scaling framework.

There are numerous methods for organizing multiple Scrum teams. In this article, we will discuss the Nexus framework for scaling Agile and Scrum in depth based on DevCom’s experience. Other frameworks for scaling Agile include LeSS, SAFe, and DAD (Disciplined Agile Delivery), but they are not covered in this article.

What is nexus framework?

Nexus framework was founded in 2015 by Scrum co-creator Ken Schwaber and the Scrum.org team as a guide for scaling Scrum in wide-ranging agile projects. Nexus is often referred to as a nexus methodology for scaling agile practices because it provides a structured approach to managing multiple Scrum teams working on a single product.

As Scrum has become an integral part of many organizations, their projects need to go beyond the typical Daily, Planning, Review, and Retro meeting sessions used in Scrum to be effective. Scrum alone is not enough when multiple teams work on a product. The productivity erodes due to the dependencies between the teams.

To tackle these challenges, the Nexus framework expands on Scrum to facilitate smoother coordination among 3–9 Scrum teams working on a single product. Nexus is applied to 3–9 Scrum groups and guides them on how to cooperate and share work to deliver software in each Sprint with minimal dependencies.

Key Components of Nexus

The Nexus framework introduces several essential components to traditional Scrum, facilitating effective management of cross-team work. These components help address coordination, integration, and communication challenges when scaling Scrum across multiple teams. The core elements include:

⇒ Nexus Integration Team (NIT): A specialized team tasked with coordinating and overseeing the activities of all Scrum teams within the Nexus. This team ensures that product increments from all teams are seamlessly integrated and meet quality standards.
⇒ Nexus Daily Scrum: A modified version of the standard Daily Scrum, where representatives from each Scrum team meet to synchronize work and address cross-team impediments.
⇒ Nexus Sprint Planning: An extended version of the typical Sprint Planning session, during which representatives from each team collaborate to align their tasks and identify any inter-team dependencies.
⇒ Nexus Sprint Backlog: A unified backlog that consolidates the work of all teams within Nexus, providing better visibility and management of cross-team dependencies.
⇒ Nexus Sprint Review and Retrospective: These meetings allow all teams to review the integrated product increment and reflect on the overall process, identifying opportunities for improvement across the entire Nexus.

Benefits of Nexus Framework

The Nexus framework offers several strategic advantages for organizations scaling Scrum across large software development projects. Key benefits include:

⇒ Reduced Cross-Team Dependencies: By facilitating continuous coordination through the Nexus Integration Team and structured events, the framework minimizes dependencies that could otherwise hinder progress.
⇒ Enhanced Collaboration: Nexus fosters a collaborative culture by promoting regular communication and problem-solving across teams through shared meetings and aligned goals.
⇒ Improved Productivity: With a focused approach to integrating work and managing inter-team dependencies, Nexus enables teams to maintain momentum, resulting in faster and more efficient Sprint deliveries.
⇒ Scalable Agility: Nexus provides the ability to scale Scrum without compromising the agility that smaller teams typically enjoy. This allows organizations to expand their development efforts while maintaining adaptability.
⇒ Commitment to Quality: By integrating deliverables through the Nexus Integration Team, the framework ensures that quality remains a top priority, even as projects grow in size and complexity.

What is nexus in software development?

In the realm of software development, Nexus is a framework designed to facilitate the effective collaboration of multiple Scrum teams working on a single product. It upholds the core principles of Scrum while addressing the complexities of scaling to larger teams. With a strong focus on integration and dependency management, Nexus enables organizations to deliver high-quality software products in a more coordinated and streamlined manner.

At DevCom, our extensive experience with the Nexus Agile framework has demonstrated its capacity to significantly enhance the productivity and cohesion of large-scale software development projects. The framework ensures that the collective efforts of all teams result in a fully integrated, functional product that meets business objectives with minimal delays stemming from inter-team dependencies.

How nexus framework scales scrum?

Scrum is a framework from which evolves the process. It is focused on how a single Scrum Team works on a single product and delivers software in small increments. The main difference between the Nexus framework and Scrum is the addition of an integration team that is focused on facilitating the dependencies between the teams.

(Source)

Nexus Process Flow:

Refine the Product Backlog.
Nexus Sprint Planning.
Development work.
Nexus Daily Scrum.
Nexus Sprint Review.
Nexus Sprint Retrospective.

When you implement Nexus, there are no significant changes in Scrum fundamentals. Nexus is much the same as adding any new practices to Scrum, as well as additional roles, events, and artifacts, only where necessary to enable successful software development initiatives. Nexus augments Scrum to allow Scrum to scale effectively. This is accomplished by boosting straightforwardness and transparency by working from a single Product Backlog. The thing that matters is that more attention is paid to dependencies between Scrum Teams, who are responsible for delivering “Done” Increments at every Sprint.

A definition of “Done” is rigorous criteria that can be applied to the Integrated Increment developed each Sprint, and which is followed by all Scrum Teams of a Nexus.

Nexus framework implementation

The Nexus framework presumes Scrum experience. Organizations that already work with Scrum will be able to implement Nexus easily. To start a Nexus, organizations should first identify the teams in their Nexus, an initial Nexus Integration Team, a single Product Backlog, a definition of “Done”, a Sprint cadence.

Nexus Implementation Strategy

1.	Define the Scrum teams (keep the focus on features, rather than components).	1.1. Hold a meeting and define how to form teams; 1.2. Assign team members (ideally self-made teams); 1.3. Define the key player(s)/representative(s) from each team.
2.	Define the Environments and repos for development (based on # of Clients(tenants) and access level).	2.1. Make a list of current repos; 2.2. Reorganize repos and review environments to shorten the lead time of tasks; 2.3. Make one common codebase (if possible);
3.	Define the Nexus Integration Team (Members of Scrum teams. May vary depending on info to be disseminated and resolved as a result of Nexus Daily Scrum).	3.1. Define people responsible for integrations mainly and dependencies resolution; 3.2. Assign the role of a Scrum master within each team.
4.	Teach and explain Scrum & Nexus framework.	4.1. Hold a meeting for all Scrum teams and review the basics; 4.2. Facilitate meetings when necessary.
5.	Define tools to work with and within.	5.1. Define productivity and project management tools to work with and within and integrate (set up).
6.	Define the “Definition of done”.	6.1. Agree with the NIT on the term; 6.2. Create a formal document.
7.	Define Product backlog/refine product backlog with Product Owner (PO) or/and reps.	7.1. Record functional requirements using one of the tools above; 7.2. Create a template with required fields to be filled in (e.g. name, description, acceptance criteria, constraints).
8.	Get Product Owner’s approval & let her prioritize the backlog.	8.1. Involve PO to groom and refine the backlog; 8.2. Continuous collaboration with PO to work on the Product backlog (write stories, tasks using a template 7.2).
9.	Organize NIT to estimate backlog using relative points.	9.1. Hold the first part of the meeting to acquire an estimation technique. 9.2. Hold a second part of the meeting to make rough estimates for Product backlog items (PBIs).
10.	Implement Nexus Sprint Planning.	10.1. Define Sprint cadence; 10.2. Define dependencies, integration issues that may appear; 10.3. Scope to be defined: approximately at least 2 Sprints ahead and current; 10.4. Hold a meeting to help NIT members with Sprint planning in teams.
11.	Implement Sprint Planning within each Scrum team.	11.1. Use absolute estimates for tasks and subtasks during Sprint planning; 11.2. Facilitate Sprint planning for each team; 11.3. Create a document template.
12.	Implement Nexus Daily Scrum and Daily Scrum for each team.	12.1. Define the time, facilitate Nexus Daily Scrum meetings (try to keep them timeboxed); 12.2. Define the time, facilitate Daily Scrum meetings (keep them timeboxed).
13.	Implement Nexus Sprint Review (max 4h).	13.1. Hold a Nexus Sprint Review (including demo recording if needed) with Scrum team members, PO, other stakeholders.
14.	Implement Nexus Sprint Retrospective and Retrospective meeting for each Scrum team (create a document of templates) (max 1h and 3h).	14.1. Hold a retrospective meeting for NIT; 14.2. Create a template document; 14.3. Facilitate retrospective meetings in Scrum teams. 14.4. Create a template document.
15.	Implement Nexus Refinement event on a regular basis of the Product Backlog.	15.1. Define the frequency (as often as needed; e.g. 2t/week).
16.	Implement Estimation in story points (depending on the PO initiative and willingness to forecast).	16.1. Start tracking Scrum teams velocity (after 3 Sprints); 16.2. Track progress using the Sprint burndown chart.
17.	Implement visual dependencies and their forecast among tasks.	17.1. Visualize dependencies among user stories, tasks (e.g. flag and link); 17.2. Define dependencies for current Sprint and two Sprints ahead.
18.	Start project management activities to support the project.	18.1. Create documents which could be handy (E.g. Project Charter, Risk management Matrix, Stakeholder management, Team management (incl. Team member info, DISC test, motivation test, team health check)); 18.2. Define project KPIs and create a template to track them. Usually they include velocity, Sprint burndown, CSAT. Other may include budgetary calculations; 18.3. Define reports for project health checks with PO and key stakeholders; 18.4. Review the testing strategy within tasks and flow (manual, unit tests, automation) if they aren’t part of the default flow.
19.	Strategy to deliver more value and maximize the outcomes after implementing the steps above (TBD).	19.1. Hold a meeting with key stakeholders (PO, CEO others); 19.2. Collect and discuss requirements that align with business strategy.

Nexus teams

A Nexus consists of approximately 3 to 9 Scrum Teams, and a Nexus Integration Team constituted of 1–2 members from each scrum team that are responsible for planning the vision of the overall product and coordinating the Teams.

It is recommended that teams be formed based on feasibility. Feature teams make the most sense as they may work on any product backlog item.

However, the current workflow leans toward component teams, which may lead to bigger dependencies among them. To reduce the risk, it is a valid point to delegate tasks to teams that belong to other than their component. Knowledge knowledge-sharing process will be essential in this case and reduce the lack of information when integrating.

Nexus Integration Team (NIT) consists of members from:

⇒ Product Owner: Accountable for maximizing the value of the product and ensuring that the combined work produced by Nexus is delivered at least once every Sprint.
⇒ Scrum Master: Responsible for ensuring that the Scrum teams adhere to Scrum and Nexus practices correctly, maximizing the value delivered by the development teams. The Scrum Master is also responsible for facilitating the delivery of “Done” increments of potentially releasable products.
⇒ Development Team: Accountable for creating integrated increments that meet the definition of “Done.” The NIT ensures that the Scrum teams within the Nexus understand and implement the necessary practices to identify dependencies and frequently integrate all artifacts to achieve the definition of “Done.

Nexus Integration Team role:

⇒ The Nexus Integration Team is accountable for ensuring the definition of “Done”.
⇒ Integrated Increment (the combined work completed by a Nexus) is produced at least once every Sprint.
⇒ The Scrum Teams are responsible for delivering “Done”.
⇒ The Nexus Integration Team serves as the focal point for integration within the Nexus. This includes addressing both technical and non-technical cross-team challenges that may hinder the Nexus’ ability to consistently deliver an Integrated Increment.
⇒ Membership can vary over time depending on the impediments the Nexus experiences.

Team members have to produce the max result for each Sprint. A regular health check for the Teams is recommended as well as for software. Once a month one may hold a quick questionnaire to monitor the teams’ productivity within each Scrum team.

Questions for the team members:

⇒ Are they delivering value?
⇒ Is the Product easy to release?
⇒ Are team members having fun?
⇒ Is the Product healthy?
⇒ Is it sustainable and supportable?
⇒ Are team members learning?
⇒ Do they understand the product goals?
⇒ Do they feel like pawns or players?
⇒ Do they feel ownership?
⇒ Is their velocity adequate?
⇒ Do they feel they have a suitable process?
⇒ Do they feel supported?
⇒ Are they working well as a team?
⇒ Does the company contribute to employee development?

Nexus events

1.Refinement

Backlog refinement ensures the Product Backlog is sufficiently detailed and granular, allowing Scrum teams to pull work items without encountering unmanageable dependencies. During this process, Scrum teams should concentrate on addressing the following key questions:

⇒ What work will each team pull?
⇒ In what order does that work need to be done to deliver the greatest business value earliest, while minimizing risk and complexity?

2. Nexus Sprint Planning

Nexus Sprint Planning consists of:

⇒ Validating Product Backlog. Scrum teams review the Product Backlog Items (PBIs) and make necessary adjustments based on the outcome of backlog refinement. While all Scrum teams contribute to the refinement process to minimize communication issues, only key representatives—those who can effectively contribute to refining the PBIs—are required to attend the refinement sessions.
⇒ Formulating the Nexus Goal. The Nexus Goal is the shared objective for the Sprint, which is achieved through the collaborative implementation of PBIs by multiple Scrum teams. This goal aligns all teams’ efforts toward a common outcome.
⇒ Scrum team Sprint Planning. Once the Nexus Goal is defined, each Scrum team conducts its own Sprint Planning session. During this, the team members create their individual Sprint Backlogs. As dependencies with other teams are identified, teams collaborate to minimize or resolve these dependencies. Nexus Sprint Planning typically takes around 8 hours.

In some cases, the sequence of work across teams may need to be adjusted, allowing one team to complete its tasks before another team can start its dependent work.

3. Nexus Daily Scrum

Nexus Daily Scrum meeting encompasses the main questions:

⇒ Was the previous day’s work successfully integrated? If not, why?
⇒ Have any new dependencies been identified?
⇒ What information needs to be shared across the teams in the Nexus?

Typically, it is held at the same time and place.

4. Nexus Sprint Review

The Nexus Sprint Review includes the following elements:

⇒ Attendees: Scrum teams and key stakeholders invited by the Product Owner.
⇒ Product Owner Update: The Product Owner explains which Product Backlog Items (PBIs) have been completed (“Done”) and which have not.
⇒ Development Teams’ Feedback: The Development Teams discuss what went well during the Sprint, any challenges encountered, and how those challenges were resolved.
⇒ Demonstration of Increment: The Development Teams demonstrate the completed work (“Done”) and answer questions about the Increment.
⇒ Product Backlog Overview: The Product Owner reviews the current state of the Product Backlog and, if necessary, provides projections of target and delivery dates based on current progress.
⇒ Collaboration on Next Steps: The entire group collaborates on what to focus on next, ensuring the Sprint Review informs the subsequent Sprint Planning session.
⇒ Marketplace Review: The group reviews how changes in the marketplace or potential product use might impact what should be prioritized next.
⇒ Release Plan Review: There is a discussion of the timeline, budget, potential capabilities, and marketplace considerations for future releases of the product.

The outcome of the Sprint Review is a revised Product Backlog, which defines the likely Product Backlog Items for the next Sprint. The Product Backlog may also be updated to reflect new opportunities or changing priorities.

This activity should not take more than 3 hours to complete.

5. Nexus Retrospective Meeting

5.1. NIT Retrospective

Due to common scaling challenges, every Nexus Retrospective should address the following questions:

⇒ Have they met the Nexus Goal? If not, why not?
⇒ Was any work left undone? Did the Nexus generate technical debt?
⇒ Were all artifacts, especially code, integrated regularly (ideally, continuously) and without issues?
⇒ Was the software successfully built, tested, and deployed often enough to prevent the overwhelming accumulation of unresolved dependencies?

When issues are identified, representatives from the Nexus Integration Team (NIT) should ask?

⇒ Why did this happen?
⇒ How can the issue be fixed?
⇒ How can recurrence be prevented?

After the Nexus Retrospective meeting, it is important to define the action items to work on within all Scrum teams. The NIT has to keep track of such items and may use a table below.

5.2. Scrum Teams Retrospective

Every Scrum team can use a task board, such as a Scrum or Kanban board, to visualize tasks and track progress. It is also recommended to keep a formal, structured record of this information for better organization and accountability. The Sprint Retrospective, where the team reflects on the Sprint’s progress and outcomes, is time-boxed to a maximum of 3 hours for a one-month Sprint. For shorter Sprints, this meeting is adjusted proportionally to take less time.

Product owner

The Product Owner is responsible for maximizing the value of the product and is the sole person accountable for managing the Product Backlog. Product Backlog management includes:

⇒ Clearly expressing Product Backlog items;
⇒ Ordering the items in the Product Backlog to best achieve goals and missions;
⇒ Optimizing the value of the work the Nexus Team performs;
⇒ Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum teams will work on next;
⇒ Ensuring the Scrum teams understand items in the Product Backlog to the level needed;
⇒ Define the Nexus goal for each Sprint (similar to milestone).

The Product Owner may delegate the above tasks to the Nexus team, but ultimately, the Product Owner remains accountable for ensuring these responsibilities are fulfilled.

Key takeaways

Scaled Agile works, and using a scaling framework helps you get a quick start.
Scaling Scrum is just Scrum. You don’t change how you work as a Scrum team, nor do you change the work being delivered.
Adding the Nexus framework on top of Scrum provides teams with a way to deal with cross-team dependencies and ensure that they are all working together toward a common goal and product increment.
If you know Scrum really well, the Nexus framework is the “no-brainer” framework for scaling software development teams, and you might never need anything else.
Nexus is a useful discussion framework for those who already have several Scrum teams in place that are functioning together.
Alternatively, if you want to describe your process, the Nexus framework is a good starting point so you don’t miss any perspectives.
As always, when it comes to scaling agile, remember these three important things:

⇒ Adapt the method to fit your organization.
⇒ Constantly reflect on the situation.
⇒ Improve how you work together.

Do you have more suggestions for “beyond the team” techniques? Want help implementing these ideas?

Since 2000, DevCom has adapted industry-standard Agile methodologies designed to create timely, effective, and efficient solutions to achieve our client’s goals. These methodologies represent an iterative development model in which the overall effort is broken into multiple releases in order to achieve the goals outlined for a particular phase. We put a lot of emphasis on three elements of the development lifecycle: Initial Project Assessment and Planning, Quality Project Management, and Quality Assurance.

Our development approach reduces project risks and works to control time-to-market and budget. We share that experience and knowledge with our new clients so that everyone can succeed when scaling.

Get better results through teamwork Contact us at DevCom today!