Draft:The Nexus framework in a Distributed Setup
 | Draft article not currently submitted for review.
This is a draft Articles for creation (AfC) submission. It is not currently pending review. While there are no deadlines, abandoned drafts may be deleted after six months. To edit the draft click on the "Edit" tab at the top of the window. To be accepted, a draft should:
It is strongly discouraged to write about yourself, your business or employer. If you do so, you must declare it. This draft has not been edited in over six months and qualifies to be deleted per CSD G13.
Where to get help
How to improve a draft
You can also browse Wikipedia:Featured articles and Wikipedia:Good articles to find examples of Wikipedia's best writing on topics similar to your proposed article. Improving your odds of a speedy review To improve your odds of a faster review, tag your draft with relevant WikiProject tags using the button below. This will let reviewers know a new draft has been submitted in their area of interest. For instance, if you wrote about a female astronomer, you would want to add the Biography, Astronomy, and Women scientists tags. Editor resources
Last edited by Asimionconstan (talk | contribs) 6 years ago. (Update) |
Definition and purpose
Nexus is a framework for developing and sustaining scaled product and software delivery initiatives [1]. It is built on top of Scrum framework. The framework consists of roles, event, artifacts and the guidelines that connect them all. Approximately three to nine Scrum Teams work on a Single Backlog to build an Integrated Increment that meets a certain goal [2]. Ken Schwaber and Scrum.org developed Nexus.
Most products are too complex to be delivered by a single Scrum Team [2]. Products that combine hardware and software or ones that have extremely sensitive time-to-market often require efforts from coordinated teams. Companies that face such challenges need more than one Scrum Team working on a single product. In those cases, integrating the work of multiple teams for every Sprint adds much more complexity because of the dependencies at scale.
The Nexus Framework helps to solve this by enabling organizations to plan, launch, scale, and manage larger product development initiatives (especially those that involve substantial software development) using Scrum [1]. Nexus helps by simplifying and managing the connection, communication and dependencies between the different Scrum Teams and thus, provides a transparent overview of how the teams interact and work together. Most important qualities for scaling in a uniform way, are transparency and communication. They are both enforced by Nexus. Using the framework, “scaling Scrum to larger, more complex products is still Scrum” [2].
Purpose in a distributed setup
There are plenty of known challenges connected with Globally Distributed Software Engineering (GDSE). Most notable ones are communication, group awareness, knowledge management, coordination, collaboration [3] and many more. Various organizations have already adapted Scrum in a distributed setting [4].
Scrum, though, has a limitation on the number of teams. Having more than two Scrum teams, especially in a distributed environment, extremely increases the challenges of GDSE.
When multiple teams are involved, communicating the work that affects the other team is crucial. Also, integrating and testing the deliverables in order to achieve an integrated product is extremely important. The Nexus framework can be used successfully in a distributed context in order to reach those goals. The fact that the framework stimulates transparency and communication between each of the team members is crucial when they are allocated in separate physical places and probably within multiple different time zones. Nexus pays more attention to dependencies and communication between the different Scrum teams [2]. This is a key characteristic when having multiple teams in a distributed context.
Nexus Roles
In addition to the normal roles defined in Scrum, Nexus defines the Nexus Integration Team (NIT) which is responsible for ensuring that an Integrated Increment is produced every sprint. The individual Scrum teams perform the work and the NIT makes sure that the work done by different scrum teams can be integrated. The role of the NIT is therefore not to work directly on the product but rather facilitate cooperation between Scrum Teams as needed. The NIT itself consists of the following members.
Product Owner
Just like in normal Scrum the product owner is responsible for managing the backlog and is ultimately responsible for the product being created. In Nexus the product owner takes a step back from the individual Scrum teams and focus on ensuring that integration between teams can be achieved.
Nexus Scrum Master
The NIT Scrum Master is responsible for ensuring that Scrum and Nexus are properly implemented and should act as an enabler for other members. The NIT Scrum Master can be a Scrum Master for one or more of the other Scrum Teams. The Nexus Scrum Master should be in frequent contact with the other Scrum Masters in the Nexus and facilitate in solving any issues regarding cooperation between the teams [2].
Other NIT members
Other NIT members bring in needed expertise in specific fields, such as Software Architecture or Continuous Integration. They can be members of Scrum teams, from other parts of the same organization or even contractors hired for a certain period. The makeup of the NIT should evolve with the needs of the Nexus and is not set in stone. In a distributed setting it is important that every location is represented in the NIT, this allows those representatives to efficiently relay issues or problems present at their location [2].
Nexus Events
Most of the Nexus Events follow the structure defined by the Scrum Guide [5] : Sprint, Sprint Planning, Daily Scrum, Sprint Review and Sprint Retrospective. Nexus is aiming to make these events suitable for large scale project with teams that are both locally and globally distributed. According to the Nexus Guide [1], the events are the following: Refinement, Nexus Sprint Planning, Nexus Sprint Goal, Nexus Daily Scrum, Nexus Sprint Review and Nexus Sprint Retrospective. Each of these events is analyzed in the following paragraphs.
Refinement
Refinement of the Product Backlog (PB) has two main purposes: decide which task from PB each team will going to tackle and point out dependencies between teams that need to be solved for the current Sprint. One of the Refinement goals is to make sure the tasks of each Nexus team are sufficiently independent in order to avoid the misunderstanding created by the needs of coordination in both locally and globally distributed environments.
Nexus Sprint Planning
The Nexus Sprint Planning event starts with common meetings of representatives from each Scrum team. The Product Owner (PO) presents the Nexus Sprint Goal and is in charge of the task prioritization from the PB. Adjustments are made to the planning according to both the Nexus Sprint Goal and the other discovered team dependencies. The Sprint Planning continues on each Scrum team individually and when further dependencies are revealed, inter-team communication should be used to share them. In this way, this event tackles a very important part of locally and globally distributed software, minimizing communication issues.
Nexus Daily Scrum
Nexus Daily Scrum servers the purpose of getting the current state inside each of the Scrum teams by focusing on the impact on the Integrated Increment. In this event, the work of the previous day is presented and if that was successfully integrated, followed by possible new dependencies and how to share them across the affected Scrum teams. The Nexus Sprint Backlog is updated after each daily meeting, serving the purpose of having daily coordination between teams, one of the most important aspects in large scale team both locally and globally distributed.
Nexus Sprint Review
Nexus Sprint Review is a meeting that takes place at the end of the Sprint, having the purpose of providing feedback from stakeholder on the integrated software resulted after fulfilling the Sprint Goal. The result, a revised PB, helps to avoid long periods of misunderstanding.
Nexus Sprint Retrospective
The final presented event is the Nexus Sprint Retrospective which is split into three parts: inter-teams meeting to tackle and share issues resulted from the current Nexus Sprint Review, intra-team meeting to concretely address the issues tackled in the inter-team meeting and another inter-team meeting to synchronize the proposed actions from each team. When looking from the large-scale distributed software perspective, the main points that should rise from this event are the amount of unfinished work according to the Sprint Planning, the technical debt generated by the current Sprint, the integration ratio of the newly added code and the deployment status of the newly incremented software.
Nexus Artifacts
The Nexus Guide [1] defines the following artifacts: Product Backlog, Nexus Sprint Backlog, Nexus Goal, and Integrated Increment.
Product Backlog
A single Product Backlog, which is managed by the Product Owner, is shared by all Scrum Teams. In order to improve the autonomy of the teams, dependencies between Product Backlog Items (PBIs) should be minimized, this allows the teams to pull PBIs without worrying about creating dependencies across Scrum Teams [1].
Nexus Sprint Backlog
The PBIs that have potential integration issues or dependencies between Scrum Teams are contained in the Nexus Sprint Backlog. This is done to highlight possible issues and where there is a need for cross-team cooperation. This list should be monitored closely and updated daily.
Nexus Goal
The Product Owner sets a goal for each sprint known as a Nexus Goal. This goal is the sum of all Sprint Goals for each of the individual Scrum Teams [1].
Integrated Increment
Just like in normal Scrum an Increment to the product is created every sprint, to emphasize the fact that, in Nexus, the Increment is the integrated work of all the Scrum Teams the name Integrated Increment is used.
Transparency and Trust
It is important to maintain transparency throughout the teams in order to avoid miscommunication between team members and to keep the amount of technical debt known at all times [5]. Establishing rules to achieve transparency is especially important in a distributed setting where members of different teams do not have the opportunity to have random conversations at the coffee machine, for example [1].
References
- ^ a b c d e f "Online Nexus Guide-The Definitive Guide to Nexus: The Rules of the Game". Scrum.org. Retrieved 2019-05-21.
- ^ a b c d e f Kurt Bittner; Patricia Kong; Eric Naiburg; Dave West (4 December 2017). The Nexus Framework for Scaling Scrum: Continuously Delivering an Integrated Product with Multiple Scrum Teams. Pearson Education. ISBN 978-0-13-468271-6.
- ^ Jiménez, Miguel; Piattini, Mario; Vizcaíno, Aurora (2009). "Challenges and Improvements in Distributed Software Development: A Systematic Review". Advances in Software Engineering. 2009. Hindawi Limited: 1–14. doi:10.1155/2009/710971. ISSN 1687-8655.
{{cite journal}}: CS1 maint: unflagged free DOI (link) - ^ Paasivaara, Maria; Durasiewicz, Sandra; Lassenius, Casper (2009). Using Scrum in Distributed Agile Development: A Multiple Case Study. IEEE. doi:10.1109/icgse.2009.27. ISBN 978-0-7695-3710-8.
- ^ "The Scrum Guide-The Definitive Guide to Scrum:The Rules of the Game" (PDF). Scrum.org. Retrieved 2019-05-21.