1. Nexus
1.1. Reasons for scaling:
1.1.1. too complex products (HW+SW)
1.1.2. speed of delivering
1.2. Nexus is..
1.2.1. Exoskeleton that simplifies and manages connections and dependencies between many Teams
1.3. usually members of the Scrum Teams
1.4. Principles Nexus is based on:
1.4.1. The key to scaling is reduce or eliminate dependencies between the Teams
1.4.2. Feature Teams are ideal for sharing work across Teams, but they don't work in all circumstances, and a Nexus may be a mixture of component and feature Teams
1.4.3. Scaled Scrum Is Still Scrum
1.5. Exoskeleton
1.5.1. 3 to 9 Teams
1.5.2. Roles
1.5.2.1. Development Team
1.5.2.2. Product Owner
1.5.2.3. Scrum Master
1.5.2.4. Nexus Integration Team
1.5.3. Events
1.5.3.1. The Sprint
1.5.3.2. Nexus Sprint Planning
1.5.3.3. Sprint Planning
1.5.3.4. Nexus Daily Scrum
1.5.3.5. Daily Scrum
1.5.3.6. Nexus Sprint Review
1.5.3.7. Nexus Sprint Retrospective
1.5.3.8. Sprint Retrospective
1.5.3.9. Refinement
1.5.4. Artifacts
1.5.4.1. Product Backlog
1.5.4.2. Nexus Sprint Backlog
1.5.4.3. Sprint Backlog
1.5.4.4. Increment
2. Practices
2.1. Opening the code base
2.1.1. Trunk-based development
2.1.2. Continuous integration
2.1.3. Automated API-based testing
2.1.4. Code review
2.2. Form Self-Organizing Teams
2.3. Using pairing and internship to grow Scrum Teams
2.4. User Story Mapping
2.4.1. for understanding capabilities and dependencies
2.5. Cross-Team Refinement Board
2.5.1. ro understand dependencies
2.6. Connecting PBIs to value delivery
2.7. Organizing Teams around personas
2.7.1. organizations may find difficult to be able to work on avery PBI
2.8. Connecting PBIs to value delivery
3. Structures
3.1. 3 important structures:
3.1.1. Team strcuture
3.1.2. Work structure
3.1.3. Architecture structrure
3.2. Ideal
3.2.1. Ideal situation when any Team can work on any item in a Product Backlog
4. Events
4.1. Nexus Sprint Planning
4.1.1. formulate the Nexus Goal and forecast
4.2. Nexus Daily Scrum
4.2.1. happens before Daily Scrums
4.2.1.1. focal point for interacting with external members of the NIT giving a single point of contact with all the Scrum Teams
4.2.2. representatives from each Scrum Team
4.2.2.1. the right people
4.2.2.1.1. occurs when Nexus cannot deliver a fully integrated, completed increment that is done
4.3. Nexus Sprint Review
4.3.1. replaces Sprint Review
4.4. Nexus Sprint Retrospective
4.4.1. helps share experiences and coordinate their resolution
4.4.2. Nexus Retrospective (part I) + Scrum Teams Retrospectives + Nexus Retrospective (part II)
4.4.3. Nexus Team members+anyone
4.4.4. Activities
4.4.4.1. representatives identify inter-team issues
4.4.4.2. Sprint Retrospective
4.4.4.2.1. representatives meet again
4.5. Refinement
4.5.1. is a mandatory event in Nexus
4.6. The Sprint
4.6.1. Teams working on different cadenses
5. Nexus Integration Team
5.1. Roles in NIT
5.1.1. Product Owner
5.1.2. NIT members
5.1.2.1. NIT Scrum Master
5.1.2.1.1. with deepest technical and coaching skills
5.1.2.1.2. has overall responsibility for ensuring the Nexus framework is enacted and understood
5.1.2.1.3. is often a Scrum Master in one or more Scrum Teams
5.1.2.2. may work on Scrum Teams in the Nexus, but Nexus Team work is the first focus
5.1.2.2.1. accountable for Nexus Sprint Backlog
5.1.2.3. sometimes they come from other parts of the organization, or even outside the organization
5.2. Accountability
5.2.1. transparent accountability about integration in Nexus
5.2.2. is like a Scrum Master for the Scrum Teams
5.2.3. accountable for a releasable integrated Product being delivered at least at the end of every Sprint
5.3. Activities
5.3.1. developing tools and practices for integration
5.3.2. coaching Scrum Teams in removing dependencies
5.3.3. serving as coaches and consultants to help with coordination
5.4. Modes
5.4.1. Normal Mode
5.4.2. Emergency Mode
5.4.2.1. acts like another Scrum Team in the Nexus
5.4.2.1.1. it is represented on Nexus Daily Scrum
5.4.2.1.2. may halt the development and start Scrumbling or Descaling