Draft:The Nexus framework in a Distributed Setup
Submission declined on 11 October 2019 by Cerebellum (talk).
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
|  |
Comment: It's not clear to me that this topic is notable. Many of the sources are either not independent of the subject (scrum.org) or they do not actually discuss the subject - as far as I can tell, that is the case with the academic papers cited, they are about Scrum not nexus. To prove me wrong, please add more sources discussing Nexus specifically, or leave a note on my talk page if any of those academic papers discuss Nexus. Cerebellum (talk) 10:13, 11 October 2019 (UTC)
Nexus is based on the Scrum Framework and, similar to Scrum, it leverages the main points from the Agile Manifesto. Ken Schwaber, co-creator of Scrum, created The Nexus Framework. It was released by Scrum.org in 2015 along with a body of knowledge, the Nexus Guide. The framework was last updated in 2018.[1]
Nexus stands for relationship or connection between people or things.[2] It is a framework for developing and sustaining scaled product and software delivery initiatives.[3] 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 particular goal.[4]
Most products are too complex to be delivered by a single Scrum Team.[4] 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.[5] In those cases, integrating the work of multiple teams for every Scrum 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 more significant product development initiatives (especially those that involve substantial software development) using Scrum.[3] 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”.[4]
Purpose in a distributed setup
[edit]There are plenty of known challenges connected with Globally Distributed Software Engineering (GDSE). Most notable ones are communication, group awareness, knowledge management, coordination, collaboration[6] and many more. Various organizations have already adapted Scrum in a distributed setting.[7]
Scrum, though, has a limitation on the number of teams.[8] 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.[9] Also, integrating and testing the deliverables 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.[10] Nexus pays more attention to dependencies and communication between the different Scrum teams.[4] This is a key characteristic when having multiple teams in a distributed context.
Nexus Roles
[edit]In addition to the traditional 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.[11]
Product Owner
[edit]Just like in standard 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.
Scrum Master
[edit]The NIT Scrum Master is responsible for ensuring that Scrum and Nexus are properly implemented and should act as an enabler for other members of the NIT and the individual Scrum Teams. The NIT Scrum Master can also be a Scrum Master for one or more of the other Scrum Teams but this is not necessary. The NIT 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.[4]
Other NIT members
[edit]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.[4]
Nexus Events
[edit]Most of the Nexus Events follow the structure defined by the Scrum Guide: Sprint, Sprint Planning, Daily Scrum, Sprint Review and Sprint Retrospective.[12] 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, 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.[3]
Refinement
[edit]Refinement of the Product Backlog (PB) has two main purposes: decide which task from PB each team will be going to tackle and point out dependencies between teams that need to be solved for the current Sprint.[3] 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.
Sprint Planning
[edit]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.
Daily Scrum
[edit]Nexus Daily Scrum similar to Scrum Daily Meeting servers the purpose of getting the current state inside each of the Scrum teams by focusing on the impact on the Integrated Increment.[12] 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.
Sprint Review
[edit]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.[3] The result, a revised PB, helps to avoid long periods of misunderstanding.
Sprint Retrospective
[edit]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.[3] 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
[edit]The Nexus Guide defines the following artifacts: Product Backlog, Nexus Sprint Backlog, Nexus Goal, and Integrated Increment.[3]
Product Backlog
[edit]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.[4]
Sprint Backlog
[edit]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
[edit]During the Nexus Sprint Planning event, the Product Owner sets a goal for each sprint known as a Nexus Goal. Consequently, each individual Scrum Team sets their own Sprint goal based on the Nexus Goal.
Integrated Increment
[edit]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. It is the responsibility of the NIT to ensure that the individual Scrum Teams are able to increment their work during the sprint.
Transparency and Trust
[edit]It is essential 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.[13] 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.[4]
Nexus is based on Scrum, which aims to increase transparency within a single team.[4] Nexus, however, takes this one step further and helps to improve transparency across all Scrum teams. While Nexus artifacts are meant for spreading knowledge across teams and resolve the problems, it is important to remember, that the Nexus Framework is as effective as the level of artifact transparency.[3] Insufficient information will result in flawed decisions, which will make teams difficult to lead.[4]
One of the measures for doing this in Nexus is switching members of the team according to the situation.[4] However, distributing a single team can be challenging.[14] In addition, switching team members will lessen the feeling of safety provided by the team. Therefore it is important to acknowledge the social aspects of teams.
Nexus uses Scrum values - Courage, Focus, Commitment, Respect, and Openness to combat these issues.[12] However, the values do not enforce themselves, and it is the responsibility of the Scrum Master to introduce and remind them. This can be done by having a poster with the values on the wall or have each member name some actions which represented the aforementioned Scrum values.[4]
Challenges
[edit]Managing Technical Debt
[edit]Product Owner is the responsible person for choosing which is the most valuable work. Sometimes it can happen, that Product Owner might choose to push in new features, not realizing that ignoring technical debt is not beneficial in the long run.
To tackle this, guard rails[4] can be introduced which determine the percentage of the time, which should be spent on specific issues. For example, it can be defined that 70% of the time must be spent on new features and 30% of the time on fixing old issues.[4] Therefore the Product Backlog must contain all the issues and provide a transparent overview of existing bugs to be fixed and future features to be implemented.
Scaling Product Owner
[edit]When scaling Scrum, it is possible, that Product Owner will not be able to answer all the questions coming from different members of all the Scrum teams, regardless of the team location.[7] This results in long waiting times and is especially noticeable in distributed teams.
To alleviate the issue, each of the Scrum teams can choose a delegate who lessens the workload of the Product Owner.[4] The delegate would still retain the developer tasks, but delegating the Product Owner should take priority. However, there still needs to be only one Product Owner who takes critical decisions about the product. Hence, there should be no such things as “Subordinate Product Owner” and “Master Product Owner”.
Skill Development
[edit]Nexus provides great techniques to spread information about business logic, building the product and the status of the production. However, more information must be shared regarding practices and experiences.[4] If there is no opportunity for informal discussions during breaks, this information will not get shared across teams. This is especially true for distributed teams.
In order to share this information, different measures can be taken, such as organizing hangouts, periodic presentation or discussion groups sharing successes and challenges between the teams. Often, these methods require leaders in specific skills (such as Python or Designing), roles (such as Scrum master) or business domains (such as customer service).
Comparison to Other Frameworks
[edit]In addition to Nexus, there exist other Distributed Scrum Frameworks, most notably Scaled agile framework (SAFe), Disciplined agile delivery, Large-Scale Scrum (LeSS) and Scrum of Scrums. Compared to other frameworks, Nexus is the newest[15], hence it is not as widely adopted as SAFe, for example.[16] A significant difference is that Nexus acknowledges the difficulties of integration of work by different teams and is the only framework with a separate integration team. In addition, Nexus is not as business oriented as SAFe and Disciplined Agile Delivery. Compared to other frameworks, the number of teams supported also differs. While Nexus and Scrum of Scrums support up to 9 and 10 teams respectively, then the other frameworks can support up to hundreds of people. According to the 13th Annual State of Agile Report, SAFe is the most popular scaling method.[17]
| Framework | Date of
Release |
Product Owner
Control |
Scale | Sprint Length
for Teams |
Team Level
Frameworks |
Key Positives[16] | Key Negatives[16] |
|---|---|---|---|---|---|---|---|
| Nexus[18] | 2015 | Single Product Owners
with Delegates |
Small
(3-9 teams) |
Can be different
for teams |
Scrum | Puts a lot of attention
to integration and has a separate integration team |
Still growing and being adopted,
limited scalability |
| SAFe[14] | 2011 | Central & top-down on ideas,
but distributed in ownership |
Large
(Enterprise) |
Common | Scrum / Kanban / XP | Offers a complete general
overview which is good for large enterprises to start with |
Seen as prescriptive and
not "agile enough" in its structures |
| Disciplined Agile Delivery[19] | 2012 | Mixed, but usually central
(Chief Product Owner) |
Med - Large | Can be different
for teams |
Scrum / Lean | A lot of content, strong
in architecture, dev ops and design |
Vague in some areas about
"how" to actually implement it |
| LeSS (Huge)[20] | 2013 | Centralized priorities with
distributed coordination |
Med - Large | Common | Scrum | Good Product Owner
scaling, is not prescriptive and offers only "suggestions" |
Very agile oriented, and has
many specialization layers, which might be hard to sell in traditional organizations |
| Scrum-of-Scrums[21] | 2001 | Distributed with light
coordination |
Small
(5-10 teams) |
Common | Scrum | Simple and relies
on standard Scrum |
Limited in scaling and likely
not suitable for large scale |
References
[edit]- ^ "Nexus Guide Change History". Scrum.org. Retrieved 2019-06-05.
- ^ "nexus | Definition of nexus in English by Oxford Dictionaries". Oxford Dictionaries | English. Retrieved 2019-06-05.
- ^ a b c d e f g h "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 g h i j k l m n o p 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.
- ^ "Nexus at a European Bank". valueglide.com. Retrieved 2019-06-05.
- ^ 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.
- ^ a b Paasivaara, Maria; Durasiewicz, Sandra; Lassenius, Casper (2009). "Using Scrum in Distributed Agile Development: A Multiple Case Study". 2009 Fourth IEEE International Conference on Global Software Engineering. IEEE. pp. 195–204. doi:10.1109/icgse.2009.27. ISBN 978-0-7695-3710-8.
- ^ Ken Schwaber; Mike Beedle (2002). Agile Software Development with Scrum. Pearson Education International. ISBN 978-0-13-207489-6.
- ^ Gutwin, Carl; Penner, Reagan; Schneider, Kevin (2004). "Group awareness in distributed software development". Proceedings of the 2004 ACM conference on Computer supported cooperative work. Chicago, Illinois, USA: ACM Press. pp. 72–81. doi:10.1145/1031607.1031621. ISBN 9781581138108.
- ^ Phalnikar, Rashmi; Deshpande, V.S.; Joshi, S.D. (2009). "Applying Agile Principles for Distributed Software Development". 2009 International Conference on Advanced Computer Control. pp. 535–539. doi:10.1109/icacc.2009.93. ISBN 978-0-7695-3516-6.
{{cite book}}:|journal=ignored (help) - ^ "Approaches to Scaling Agile". 2016-09-03. Retrieved 2019-06-05.
- ^ a b c "The Scrum Guide-The Definitive Guide to Scrum:The Rules of the Game" (PDF). Scrum.org. Retrieved 2019-05-21.
- ^ Hinds, Pamela J.; Bailey, Diane E. (2003). "Out of Sight, Out of Sync: Understanding Conflict in Distributed Teams". Organization Science. 14 (6). Institute for Operations Research and the Management Sciences (INFORMS): 615–632. doi:10.1287/orsc.14.6.615.24872. ISSN 1047-7039.
- ^ a b Richard Knaster; Dean Leffingwell (20 July 2018). SAFe 4.5 Distilled: Applying the Scaled Agile Framework for Lean Software and Systems Engineering. Pearson Education. ISBN 978-0-13-517127-1.
- ^ "Scaling Agile for Enterprises: A Comparison of SAFe Agile, Nexus, Disciplined Agile 2.0 (DAD), and Large Scale Scrum (LeSS)". Smartsheet. 2016-11-22. Retrieved 2019-06-03.
- ^ a b c "ASK Matrix". Agile Scaling. Retrieved 2019-06-05.
- ^ "13th Annual State of Agile Report". State of Agile. Retrieved 2019-06-05.
- ^ McFadyen, John (2017-10-05). "Scaling Scrum: Enterprise Scrum Compared with Other Leading..." Agile Centre. Retrieved 2019-06-03.
- ^ Ambler, Scott W., 1966- (2012). Disciplined agile delivery : a practitioner's guide to agile software delivery in the enterprise. IBM Press. ISBN 9780132810135. OCLC 794176281.
{{cite book}}: CS1 maint: multiple names: authors list (link) CS1 maint: numeric names: authors list (link) - ^ "Overview - Large Scale Scrum (LeSS)". less.works. Retrieved 2019-06-03.
- ^ "Scrum of Scrums". Agile Alliance. 2015-12-17. Retrieved 2019-06-05.
- in-depth (not just passing mentions about the subject)
- reliable
- secondary
- independent of the subject
Make sure you add references that meet these criteria before resubmitting. Learn about mistakes to avoid when addressing this issue. If no additional references exist, the subject is not suitable for Wikipedia.