In a nutshell about NEXUS
In the spring of this year, a team of our developers attended a training on multi-team scram using the Nexus framework. This turned out to be a very interesting tool, and we want to share with you the impressions of its capabilities.
Nexus is the Ken Schwabers framework, an organic and evolutionary extension of the classic scram for large multi-team projects. It is based on the same familiar scrum basics: roles, artifacts and events, complementing them with similar events and artifacts for identifying and managing dependencies, timely sharing information and domain knowledge between teams and retaining focus on the final product, rather than individual increments.
A new one is added to the standard scrum roles - the Nexus Integration Team , which is responsible for the successful integration of all the increments made and the solution of technical and non-technical limitations between the teams.
')
This group of participants consists of selected team representatives who voice the interests of the team. If the working time of the participants is divided between the NIT and the development team, then the work in the Nexus Integration Team is more priority.
The composition of the integration team may change as needed.
With the stumbling block of the multi-team scramble - cross dependencies between features and commands - refinement sessions are officially added to the process, the time of which is not rigidly defined and selected at any convenient time of the sprint.
The event takes place in several stages: first, NIT splits the backlog content into small and independent parts to the level where one team can complete the feature in one sprint.
Then all dependencies between features and commands are detected and visualized. At this stage, the NIT defines a kind of “roadmap” of features and dependencies: what will be done by what team, in which sprint.
Next, features go down to the command level and are revised in more detail using the same approach: split into smaller parts, select and visualize dependencies.
Planning for Nexus also goes through the following stages:
In addition to the Daily Scrum for each team, the Daily Scrum for the NIT is added - for daily rescheduling of the remaining work on the overall increment.
The classic three questions of the scramble for the integration team are transformed into:
The information obtained during the Nexus Daily Scrum is used for discussion on the Daily Scrum team.
Nexus Retrospective consists of three parts:
It is worth noting that the length of the sprints of the teams in the Nexus may differ, but must be multiple (for example, 1, 2 and 4 weeks or 1 and 3 weeks) to overlap on the overall planning, sprint review and retrospective.
To see a complete picture of the product, the Product Backlog is always saved in the singular, as is the increment. Nexus has no team Sprint Review, and the result of the sprint is the sum of everything the teams have done - Integrated Increment by product. In addition to Sprint Backlog, a new artifact is added - the Nexus Sprint Backlog , which is a feature set for all teams with dependencies between them - a kind of overall sprint plan - and is used to track progress and daily rescheduling by total increment.
Definition of Done is formed by NIT, revised and maintained up to date after each retrospective. Teams may additionally create their own DoD, but the rules must be stricter than the general.
Scaling begins with a well-tuned scram within the same team - the same fundamentals and experience are fractally transferred to the multi-team level. Gradually, the original team is divided into two or three teams and new developers are added iteratively and incrementally. Care must be taken to ensure that the overall increment remains stable and predictable. Otherwise, the amount of effort spent will be incomparably higher, and the complexity of dependencies, integration and communication problems will grow exponentially with the addition of each following command.
Nexus involves working on one product of 3-9 teams. There is also Nexus +, which is the next level of the add-on above the framework (Nexus for Nexus), but you should think about it three times before using it. At some point, the amount of time spent on dependency management outweighs the benefits of adding new commands.
Single source control, continuous integration / build / test / deploy, use of SOLID principles, API's, DevOps concepts, etc. - the more scaling, the greater the number of techniques and approaches you need to use.
Product Owner is responsible for high-level product vision, strategy, prioritization and value determination. Regardless of the scale of the project, there is only one backlog and one PO per product. He or she may have assistants in daily tasks: describe the criteria of the story, explain the details to the teams, seek the help of experts in a domain domain. But the final prioritization word remains for the Product Owner.
Nexus is the Ken Schwabers framework, an organic and evolutionary extension of the classic scram for large multi-team projects. It is based on the same familiar scrum basics: roles, artifacts and events, complementing them with similar events and artifacts for identifying and managing dependencies, timely sharing information and domain knowledge between teams and retaining focus on the final product, rather than individual increments.
Roles
A new one is added to the standard scrum roles - the Nexus Integration Team , which is responsible for the successful integration of all the increments made and the solution of technical and non-technical limitations between the teams.
')
This group of participants consists of selected team representatives who voice the interests of the team. If the working time of the participants is divided between the NIT and the development team, then the work in the Nexus Integration Team is more priority.
The composition of the integration team may change as needed.
Developments
With the stumbling block of the multi-team scramble - cross dependencies between features and commands - refinement sessions are officially added to the process, the time of which is not rigidly defined and selected at any convenient time of the sprint.
The event takes place in several stages: first, NIT splits the backlog content into small and independent parts to the level where one team can complete the feature in one sprint.
Then all dependencies between features and commands are detected and visualized. At this stage, the NIT defines a kind of “roadmap” of features and dependencies: what will be done by what team, in which sprint.
Next, features go down to the command level and are revised in more detail using the same approach: split into smaller parts, select and visualize dependencies.
Planning for Nexus also goes through the following stages:
- At the initial stage, where all teams are present, the Product Owner voices and explains the overall priorities of the sprint, the goal of the overall increment. Representatives of the teams once again adjust the distribution of work on the basis of the dependencies found. Also at this stage the overall goal of the sprint is formulated.
- Next, the teams continue planning individually, and the planning results for all teams are entered into the Nexus Sprint Backlog.
In addition to the Daily Scrum for each team, the Daily Scrum for the NIT is added - for daily rescheduling of the remaining work on the overall increment.
The classic three questions of the scramble for the integration team are transformed into:
- What was successfully integrated before today's Daily Scrum?
- What new dependencies found?
- What information needs to be distributed among teams today?
The information obtained during the Nexus Daily Scrum is used for discussion on the Daily Scrum team.
Nexus Retrospective consists of three parts:
- The NIT identifies problems that affect more than one team and transmits them as additional input to the team retrospective.
- Command retrospective, which necessarily takes into account common problems identified in the first stage
- The final part of the retrospective, where a common vision is formed, how to visualize and track the formulated items.
It is worth noting that the length of the sprints of the teams in the Nexus may differ, but must be multiple (for example, 1, 2 and 4 weeks or 1 and 3 weeks) to overlap on the overall planning, sprint review and retrospective.
Artifacts
To see a complete picture of the product, the Product Backlog is always saved in the singular, as is the increment. Nexus has no team Sprint Review, and the result of the sprint is the sum of everything the teams have done - Integrated Increment by product. In addition to Sprint Backlog, a new artifact is added - the Nexus Sprint Backlog , which is a feature set for all teams with dependencies between them - a kind of overall sprint plan - and is used to track progress and daily rescheduling by total increment.
Definition of Done is formed by NIT, revised and maintained up to date after each retrospective. Teams may additionally create their own DoD, but the rules must be stricter than the general.
Scaling
Scaling begins with a well-tuned scram within the same team - the same fundamentals and experience are fractally transferred to the multi-team level. Gradually, the original team is divided into two or three teams and new developers are added iteratively and incrementally. Care must be taken to ensure that the overall increment remains stable and predictable. Otherwise, the amount of effort spent will be incomparably higher, and the complexity of dependencies, integration and communication problems will grow exponentially with the addition of each following command.
Nexus involves working on one product of 3-9 teams. There is also Nexus +, which is the next level of the add-on above the framework (Nexus for Nexus), but you should think about it three times before using it. At some point, the amount of time spent on dependency management outweighs the benefits of adding new commands.
Single source control, continuous integration / build / test / deploy, use of SOLID principles, API's, DevOps concepts, etc. - the more scaling, the greater the number of techniques and approaches you need to use.
Product Owner is responsible for high-level product vision, strategy, prioritization and value determination. Regardless of the scale of the project, there is only one backlog and one PO per product. He or she may have assistants in daily tasks: describe the criteria of the story, explain the details to the teams, seek the help of experts in a domain domain. But the final prioritization word remains for the Product Owner.
Source: https://habr.com/ru/post/306070/
All Articles