Scaled Scrum – Fast overview of Nexus

Scaled Scrum – Fast overview of Nexus

Nexus Introduction

If you are working with product and software development, nexus is a framework to scale your scrum setup. We will walk through the Nexus Roles, the events, artefacts, and we will have a look on the rules and techniques binding is together in the Nexus framework.

The purpose of Nexus is to organize your framework if you are working on a single Product Backlog, but you have multiple teams working to meet the goal – typical 2 to 9 teams.

Figure: The Nexus exoskeleton

The Nexus framework build on multiple Scrum teams working on an increment. It use all the Power in the existing Scrum framework, but on top of that, it pays much more attention to the interoperation and dependencies between the scrum teams. The goal is to deliver one integrated increment after each sprint binding all the development “Done” together.

Just to recap we below have a normal Scrum team

Figure: Normal Scrum Team

 It have a Product Owner, a Scrum Master and the team members.

To make multiple teams working on the same product the Nexus framework introduces:

·      Nexus Integration Team: This is a new role, which binds the multiple scrum teams together, it do the coordination, training and Coaching to secure the best possible outcome from the deliveries. This Nexus Integration Team have a Product Owner, a Scrum Master and Nexus Integration Team Members, so very much the same structure as a normal Scrum team.

·      Nexus Sprint Backlog: This is a new Artefact’s, which secure the transparency for the sprint. Each Scrum Team still keeps track on their own Sprint Backlog. The Teams use a single Product Backlog, where indicators will show which team a given backlog item are working on and the new Nexus Sprint Backlog them helps keeping the overview during the sprint.

·      Events: Some events are replaced, some are moved and some are new. We will go through all events when going through the Nexus framework process.  

  

How Nexus works

Just like a normal Scrum Team a Nexus setup is cross-functional and all work may be done be any of the team members in the Scrum Teams. Each individual Scrum Team pick out specific Backlog Items based on dependencies.

So let of have a look at how the framework works:

Product Backlog: Like in a normal Scrum the backlog need to be refined, but it also need to be decomposed, which mean that identification of dependencies are done and the found dependencies minimized if they cannot be removed.

All teams are working together on one single backlog, and just like in a normal Scrum the backlog items have to be cut into thinly sliced pieces of functionality. In Nexus also identify the team likely to be developing the functionality; this should be done as early as possible.

Nexus Sprint Planning: This is a meeting where the refined Product Back log is discussed. Participating in the meeting will be representatives from all the Scrum Teams. They will then select Product Backlog Items for their teams to be working on.

The individual Scrum Teams will plan their own Sprint, but in cooperation and interaction with other teams where dependencies identified.

Sprint Goals will be created from all Scrum Teams in alignment with the overall Nexus Goal.

The will be created individual Sprint Backlogs for all Scrum Teams and a single Nexus Spring Backlog as well. The Nexus Sprint Backlog will show all dependencies between functionality and teams, and will also show which Product Backlog Items each team have selected for the Sprint. In this way the Nexus Sprint Backlog, gives a total transparent overview of the coming Sprint and all its dependencies.

 

Development and test Environment: Common development and test environment is needed, so all teams integrate their work into same common environment. This to secure that integrations are done, and to be able to test integration point cross Scrum Teams. Often we talk about Continuous Integration (CI), which is the practice of merging all development into a common environment one of many times a day. The main aim of CI is to prevent integration problems, referred to as "integration hell" in early descriptions of agile development practise like XP.

Figure: Continuous Integration


Nexus Daily Scrum: If we look at the Nexus exoskeleton again, we see two kind of Daily Scrum meetings. Each team have own Daily Scrums, which is shown as the small circles in below picture, and then we have the Nexus Daily Scrum which is show as the bigger circle.

The Nexus Daily Scrum meeting are representatives for each of the Scrum Teams and they meet daily to identify and discus any integration issues.

The members of the Nexus Daily Scrum meeting then bring back important information to their individual Scrum Teams making sure that integration issues are addressed.

Each scrum team then use their own Daily Scrum meeting to make the day planning, securing that all integration issues are addressed and taken care of which was raised on the Nexus Daily Scrum meeting.

 

Nexus Sprint Review: In a normal Scrum the team have a Sprint review with the Product owner and maybe also other stakeholder, when working in a Nexus all Scrum Teams meet with the Product Owner to review the developed integrated increment. Many do this in a form of a Demo where integrated functionality are show and presented by all teams. The Product Owner should accept the outcome that the Nexus Sprint goal was reached, and it can lead to some changes in the Product Backlog.

 

 Nexus Sprint Retrospective: One of the strong events in Scrum is the Retrospective that is used to look back on what went good and went wrong in the Sprint that was just performed. This gives the team excellent opportunities to perform better in the coming sprints. In a Nexus setup a Nexus Sprint Retrospective as also performed, this is address and identify shared challenges at to make sure collaboration between the team gets better and better. In these, meeting representatives from each of the Scrum Team meets.

After this meeting, the individual Scrum Teams hold their normal Sprint Retrospective including the knowledge and outcome from the Nexus Sprint Retrospective.

The Nexus Sprint Retrospective representatives then meet again to address any action needed based on shared knowledge to get the interaction and collaboration flow better in up-coming Sprint when it comes to integration between the teams.

This short introduction to Nexus should give you are good overview to try it out. 

Will be part of the Scrum Master Advanced certification from www.scrum.as - go check out all our agile courses. And please remember to share with your team

要查看或添加评论,请登录

Steen Lerche-Jensen的更多文章

社区洞察

其他会员也浏览了