Skip to content

Instantly share code, notes, and snippets.

@itraveso

itraveso/Nexus Guide Summary.md

Last active September 10, 2020 12:39
Show Gist options
  • Star 2 You must be signed in to star a gist
  • Fork 1 You must be signed in to fork a gist
  • Save itraveso/5194533ba67f1e3fe3f53215afb9fed0 to your computer and use it in GitHub Desktop.
Save itraveso/5194533ba67f1e3fe3f53215afb9fed0 to your computer and use it in GitHub Desktop.
Download ZIP
A Summary of the Nexus Guide in preparation for SPS exam
Raw
Nexus Guide Summary.md

Nexus Guide summary

Notes and summary of the Nexus Guide by Ken Schwaber made in preparation for the SPS™ certification exam.

Useful links and resources for SPS™ exam preparation

Nexus Overview

Purpose of the Nexus Guide

To define a framework to develop scaled product and software delivery initiatives using Scrum as its building block. Developed by Ken Schwaber and Scrum.org

Definition of Nexus

Framework consisting of:

✅ Roles

✅ Events

✅ Artifacts

✅ Rules

1 single product backlog 📜 🔗 👥 by 3-9 teams to build an integrated increment

Nexus Background

Integration and coordination of work to deliver a done increment by several teams

Dependencies

Dependencies arise between multiple teams, and they relate to:

  • 📃 Requirements (Overlapping and affecting each other)
  • 💡 Domain Knowledge (The teams have the right knowledge to do the job)
  • 💻 Software & Test artifacts

📉 dependencies == 📈 productivity

Nexus Framework

Consistent with Scrum, but it pays more attention ⚠️ to dependencies and interoperation between scrum teams

Nexus™ Framework for Scaling Scrum

Roles

Scrum Roles + the Nexus Integration Team (NIT)

Artifacts

Scrum Artifacts + Nexus Sprint Backlog

Events

Appends all the Scrum Events minus Sprint Review ❌ (replaced by Nexus Sprint Review)

Nexus Process Flow

A nexus consists of multiple cross-functional teams working together to deliver an integrated increment at least a the end of each sprint. Teams self-organize to pick up work based on dependencies.

✏️ Nexus Refinement: decompose and identify dependencies

🔖 Nexus Planning: Discuss & select PBL for each team, then they plan their own sprint and realign on an integrated goal and sprint backlog on top of their own

🔁 Nexus Daily Scrum: Appropriate representatives meet to identify integration issues and dependencies, then they take this info back to their own daily scrums

✔️ Nexus Sprint Review: Integrated demonstration to stakeholders with adjustment & feedback gathering

⏪ Nexus Retrospective: Appropriate representatives meet to discuss cross-team issues, then normal sprint retro for each team, then appropriate representatives meet again to re-align and plan the follow up.

Nexus

Roles, events & artifacts inherit the purpose from the corresponding Scrum roles

Nexus Roles

A nexus consists of:

  • 1 NIT
  • 3-9 teams

Nexus Integration Team

✅ Accountable for ensuring a Done Integrated increment is produced at least once/sprint. It consists of:

  • 🎩 THE PO:

    • ☝️ The single PO for the whole Nexus
    • 💶 Maximizes the value of the product
    • 📊 Manages BL

  • 👂 A SM:

    • ☑️ Ensures the Nexus framework is understood and enacted
    • 🔛 May be SM in 1 or several scrum teams

  • 👥 1 or more NIT members:

    • 💻 Professionals skilled in the use of tools, practices and field of Sys Eng.
    • 🔛 Often they are also part of the individual scrum teams
    • ☝️ Nexus work takes priority over scrum team work
    • 🔀 Membership may change over time
    • 🔦 Coaches, consults and highlights awareness of cross-team issues
    • ⬆️ They use bottom-up intelligence to achieve resolution

Nexus Events

🕐 Duration is guided by the duration of the corresponding Scrum event. 👀 Inspection and adaption will help with time-boxing them.

Refinement

  • 📌 Mandatory
  • 👍 Helps identifying & forecasting which team will deliver which PBI
  • 🔀 Helps identifying the dependencies
  • 🔄 Continues until PBIs are independent enough
  • 🤷‍♂️ Number, Frequency and attendance depends on dependencies and PBL uncertainty
  • 🔁 It's continuous as necessary

Nexus Sprint Planning

  • 🚦 Coordinates activities of all scrum teams for a single sprint
  • 🚩 PBL should be refined with dependencies id'd, remov'd or minimiz'd prior
  • 2 parts:
    • ☝️ Appropriate reps from each scrum team meet to validate and decide what each team will do & PO discusses the Nexus Sprint Goal (purpose that will be achieved by all the teams)
    • ✌️ Individual Scrum Teams Sprint Planning
  • 🏁 Finishes when all individual teams Sprint Plannings have finished
  • ➕ Generates a Nexus Sprint Backlog with the combination of the all the individual sprint backlogs
  • ⤴️ Dependencies are transparent on the Nexus Sprint Backlog

Nexus Daily Scrum

Appropriate representatives of individual dev teams meet to inspect current state of integrated increment and discover new cross team issues. Should discuss:

  • ♻️ Was the previous day’s work successfully integrated? 🤷‍♂️ If not, why not?
  • 💣 What new dependencies or impacts have been identified?
  • 💁 What information needs to be shared across teams in the Nexus?

↕️ Nexus Sprint Backlog is adjusted at least during this.

⤵️ Output of this will feed into the team's daily scrum.

Nexus Sprint Review

  • ‼️ Replaces Sprint Review
  • 🏁 Held at the end of the sprint
  • ☑️ Review the integrated increment with stakeholders to gather feedback and adjust PBL
  • 🆕 New techniques might be necessary to maximize stakeholder feedback
  • 📜 Results in a revised PBL

Nexus Sprint Retrospective

  • 🔄 Occurs after Nexus Sprint Review and before Nexus Sprint Planning.

  • Consists of 3 parts:

    1. 🔍 Appropriate reps from each team meet & id issues that impacted more than 1 team. Makes shared issues transparent
    2. 👀 Each team holds their own Sprint Retrospective, using the input from part 1
    3. ✏️ Appropriate reps from each team meet to realign and agree on tracking/visualizing actions.

  • Should answer / address:

    • 🚧 Was any work left undone? Did the Nexus generate technical debt?
    • ✅ Were all artifacts, particularly code, frequently (as often as every day) successfully integrated?
    • ✅ Was the software successfully built, tested, and deployed often enough to prevent the overwhelming accumulation of unresolved dependencies?
    • Why?
    • How can tech debt be undone?
    • How can this be avoided in the future?

Nexus Artifacts

Provide transparency & opportunities for I&A

Product Backlog

  • 📜 1 PBL to rule them all.
  • 🎩 PO is accountable for it
  • ⏩ PBIs are "ready" for Nexus Sprint Planning when teams can select items to be done with no or minimal dependencies

Nexus Sprint Backlog

  • ➕ Composite of PBIs from Sprint Backlogs of the Scrum Teams.
  • 🔆 Highlights dependencies and flow of work during sprint
  • 🔄 Updated at least once/day during Nexus Daily Scrum

Integrated Increment

  • ➕ Represents current sum of all integrated work completed by a Nexus
  • 👍 Must be usable and potentially releasable (meets DoD)
  • 🔍 Is inspected at Nexus Sprint Review

Artifact Transparency

The NIT works with the Scrum Teams to ensure transparency is apparent across all artifacts. Software must be developed so that dependencies are detected and resolved before death by tech debt

DoD

  • ✅ NIT defines the DoD for the Nexus
  • 🔛 All teams adhere to DoD
  • 🛃 Individual teams may choose their own DoD so long as it complies with the Nexus'

End Note

🚫 Nexus is immutable. Can be partially implemented, but the result: ❌ Nexus

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment