Scrum, being 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, scheduling of deliveries, you might need a scaling framework.

You can organize multiple Scrum teams in many different ways. In this article, we will go in-depth of the Nexus framework for scaling Agile and Scrum, based on DevCom’s experience. There are other frameworks for scaling Agile such as LeSS, SAFe, DAD (Disciplined Agile Delivery) and, but they are not covered in this article.

Contents

1 What is Nexus Framework?
2 How Nexus Framework Scales Scrum?
3 Nexus Framework Implementation
4 Nexus Implementation Strategy
5 Nexus Teams
6 Nexus Events
7 Product Owner
8 Key Takeaways

What is Nexus Framework?

Nexus framework was founded by Scrum co-creator Ken Schwaber and the Scrum.org team in 2015 as a guide for scaling Scrum in wide-ranging agile projects.
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 the 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.
Nexus framework uses Scrum as its building block and extends it for better management of multiple Scrum teams who work on a single product. Nexus is applied to 3–9 scrum groups and guide them on how they have to cooperate, and share work to deliver software in each Sprint with minimal 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 deliver 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.

At the point when you implement the Nexus, there are no significant changes in Scrum fundamentals itself. Nexus is much the same as adding any new practices to Scrum, 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 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 to form teams 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 teams those tasks that belong to other than their component. 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 for ensuring that the combined work completed by a Nexus is produced at least once every Sprint.
⇒ Scrum Master – accountable for Scrum teams doing Scrum and Nexus correctly and maximizing the value delivered by the development team. Responsible for delivering “Done” Increments of potentially releasable products.
⇒ Development Team – accountable for creating Integrated Increments that are ‘Done’. NIT ensure the Scrum Teams within the Nexus understand and implement the practices needed to detect dependencies, and frequently integrate all artifacts to 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 NIT provides a focal point of integration for the Nexus. Integration includes resolving any technical and non-technical cross-team constraints that may impede a Nexus’ ability to deliver a constantly 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

Refinement results in a Product Backlog that is granular enough for Scrum teams to pull work without creating unmanageable dependencies. During Refinement, the Scrum teams should focus on these 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. The Scrum teams review the PBIs and make any necessary adjustments needed for the work from the Refinement event. All of the Scrum teams should participate and contribute to minimize communication issues; however, only the appropriate representatives (those who feel that they can make a contribution to refining the PBIs) from each of the Scrum teams need to attend.
⇒ Formulating the Nexus Goal. The Nexus Goal is a Sprint objective that is met through the implementation of PBIs by multiple teams.
⇒ Scrum team Sprint Planning. Once the Nexus Goal for the Sprint is understood, each Scrum team will conduct its individual Sprint Planning events in which the members create their own Sprint Backlogs. As they identify dependencies with other teams, they work with those teams to minimize or eliminate the dependencies. Most Sprint planning should take 8 hours.

In some cases, this will mean that the sequence of work across teams may have to be adjusted to let one team finish its work before another starts.

3. Nexus Daily Scrum

Nexus Daily Scrum meeting encompasses the main questions:

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

Typically it is held at the same time and place.

4. Nexus Sprint Review

The Sprint Review includes the following elements:

⇒ Attendees include the Scrum teams and key stakeholders invited by the Product Owner;
⇒ The Product Owner explains what Product Backlog items have been “Done” and what has not been “Done”;
⇒ The Development Teams discusses what went well during the Sprint, what problems it ran into, and how those problems were solved;
⇒ The Development Teams demonstrates the work that it has “Done” and answers questions about the Increment;
⇒ The Product Owner discusses the Product Backlog as it stands. He or she projects likely target and delivery dates based on progress to date (if needed);
⇒ The entire group collaborates on what to do next so that the Sprint Review provides valuable input to subsequent Sprint Planning;
⇒ Review of how the marketplace or potential use of the product might have changed what is the most valuable thing to do next;
⇒ Review of the timeline, budget, potential capabilities, and marketplace for the next anticipated releases of functionality or capability of the product.

The result of the Sprint Review is a revised Product Backlog that defines the probable Product Backlog items for the next Sprint. The Product Backlog may also be adjusted overall to meet new opportunities.

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

5. Nexus Retrospective Meeting

5.1. NIT Retrospective

Because there are common scaling dysfunctions, every 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, particularly code, frequently (ideally, continuously) and successfully integrated?
⇒ Was the software successfully built, tested, and deployed often enough to prevent the overwhelming accumulation of unresolved dependencies?

When issues are discovered, the representatives need to 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

Each Scrum team may use a board to visualize items that need to be worked on. Besides that, it is recommended to formally keep track of such records in a structured way. At most, it takes 4 hours to discuss with the team how a Sprint went.

Product Owner

The Product Owner is responsible for maximizing the value of the product.

The Product Owner is the sole person responsible 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 do the above work, or have the Nexus team do it. However, the Product Owner remains accountable.

Key Takeaways

Scaled Agile works, and using a scaling framework help 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.
By adding the Nexus framework on top of Scrum, it 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, 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!