The new 2020 Scrum Guide and the Nexus Guide.
As you noticed there is a new Scrum Guide. Recently I took a dive in Nexus. The current Nexus guide dates from 2018. Looking at what has changed in the Scrum Guide, what could this mean for the Nexus Guide? Because Nexus is still Scrum.
First let’s make a summary of some changes in the Scrum Guide:
- It is less prescriptive.
- The Development Team is changed into Developers. So talking about “the team” is always the Scrum Team.
- There are now commitments, described in the Product Goal, the Sprint Goal and the Definition of Done.
- There is mention of accountabilities.
- The Sprint Planning now contains a part where the “why” of the Sprint is made clear.
- Simplification of the Scrum Guide.
What does this mean for the Nexus Guide?
It is less prescriptive
One example of being less prescriptive of the Scrum Guide is no longer mentioning the 3 questions for the Daily Scrum. But also the prescriptive elements of the Sprint Review and the Sprint Retrospective.
If we look at the Nexus Guide it states:
” …. every Retrospective should address the following subject:
- 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?”
Also about the Nexus Daily Scrum:
“During the Nexus Daily Scrum, attendees should focus on each team’s impact on the Integrated Increment and 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?”
The prescribed questions in the Nexus Guide have a clear purpose. But so did the 3 questions for the Daily Scrum in the Scrum Guide. I would vote for removing the questions for the Nexus Daily Scrum and Retrospective from the Nexus Guide and make the goals of the events more clear. When will the event be successful.
In the previous version of the Scrum Guide it was stated that refinement usually took no longer than 10% of the Teams time. This is dropped in the 2020 version of the Scrum Guide. In the Nexus Guide there already wasn’t a set duration. “Refinement of Product Backlog Items by the Nexus continues until the Product Backlog Items are sufficiently independent to be worked on by a single Scrum Team without excessive conflict.” This is the refinement by the Nexus. But the Scrum Team can continue with the refinement of a Product Backlog Item as needed.
The Development Team is changed into Developers
In the Nexus Guide there is 6 time mention of “Development team(s)”. Mostly it is to make clear an event is for “appropriate representatives from individuals Development Teams” like with the Nexus Daily Scrum or that “dependencies of requirements, domain knowledge, and software artifacts should drive the organization of the Development Teams”. Within a Nexus there are several Developers who work together in a Scrum Team and there are several Scrum Teams in a Nexus. I think referring to “Developers from Scrum Teams” or “Developers from a Scrum Team” would make more clear there aren’t separate Development Teams within a Nexus but there are multiple Scrum Teams with Developers, a Scrum Master and a Product Owner. The Product Owner is the single Product Owner for the Nexus. But besides being the Product Owner for the Nexus, he/she is also the Product Owner for the individual Scrum Teams within the Nexus.
Commitments
In my opinion a good change in the Scrum Guide is the addition of commitments for each artifact. It makes clear what the characteristics of the artifacts are. The commitments in the Scrum Guide are:
- Product Goal for the Product Backlog
- Sprint Goal for the Sprint Backlog
- Definition of Done for the Increment
Adding the Product Goal to the Nexus Guide helps the Scrum Teams in the Nexus get even more align with each other. In the Nexus Guide there is a distinction for the Sprint Goal between the Nexus Sprint Goal and the Sprint Goal of the individual Scrum Teams. The Nexus Sprint Goal is the sum of all the Sprint Goals of the Scrum Teams within the Nexus. This distinction is not needed for the Product Goal because a Nexus has only 1 Product Backlog and therefor only 1 (current) Product Goal that describes the long-term objective for the Nexus.
If we look at the description of the Definition of Done in the Scrum Guide:“The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.” The Nexus Guide doesn’t have a definition of the Definition of Done. It is mentioned and it has a separate chapter where is stated who is responsible for a D.O.D. and how to apply a D.O.D.. Here we find a difference between the Nexus Guide and the Scrum Guide.
The Scrum Guide states:” If there are multiple Scrum Teams working together on a product, they must mutually define and comply with the same Definition of Done.”
In the Nexus Guide:” The Nexus Integration Team is responsible for a Definition of Done that can be applied to the Integrated Increment developed each Sprint.”
This could be a discussion about semantics. The Nexus Integration Team is responsible. That doesn’t mean they must define the Definition of Done. The N.I.T. just must be sure there is one. Adding the D.O.D. is created by the Scrum Teams in the Nexus Guide, but keeping the responsibility there is one with the N.I.T., would be a good addition. This way you make more clear everyone in the Nexus needs to contribute to creating a usable increment that meets certain standards.
Accountabilities
In the new Scrum Guide the accountabilities are split into 3 groups: Product Owner, Developer and Product Owner. Also the Scrum Team as a whole is accountable for creating a useful and valuable Increment every Sprint.
The Nexus Guide also knows accountability for the Nexus Integration Team. The N.I.T. is accountable for ensuring that a “Done” Integrated Increment is produced at least once every sprint. The Integrated Increment is combined work completed by the Nexus. So the Scrum Teams are still accountable for creating the “Done” increment and the N.I.T. is accountable for combining those increments into a single Integrated Increment. The N.I.T. is accountable, that doesn’t mean they must do the actual integration.
The accountabilities mentioned in the Scrum Guide don’t change in Nexus. The Nexus Guide refers to the Scrum Guide for the roles. I would change it into the reference to the accountabilities in the Scrum Guide.
The “why” in the Sprint Planning
The Scrum Guide mentions 3 topics that are discussed during the Sprint Planning:
- Why is the Sprint valuable?
- What can be “Done” this Sprint?
- How will the chosen work get “Done”?
The Sprint Planning is also part of the Nexus framework. Also there is a Nexus Sprint Planning. During the Nexus Sprint Planning the Product Owner discusses the Nexus Sprint Goal. The purpose of the Nexus Sprint Goal is to describe what purpose will be achieved by the Scrum Teams during the Sprint. In other words; why is the Sprint valuable. So in a way that already covers that part of the new Scrum Guide. Everyone in the Nexus participates in the Nexus Sprint Planning. So everyone is informed about the “why” of the Sprint. What can be “Done” is discussed during the Nexus Sprint Planning by representatives from each Scrum Team. After which each Scrum Team, interacting with other Teams when needed, plans its own sprint. So perhaps making a bit more clear the first part of the Nexus Sprint Planning is about why the Sprint is valuable would be the only addition in the Nexus Guide.
Simplification
In the new Scrum Guide a lot of elements are removed to simplify the Guide. The goal is emphasize that Scrum is a framework and not a methodology so people who use Scrum can add, and when needed remove again, practices to improve how the Scrum Team works. An example is the use of Kanban with Scrum.
Nexus is already a simple framework. For example if we look at the 2017 version of the Scrum Guide and read the part of the Sprint Review, it showed a long list with elements including in the Sprint Review. This list is dropped and the description of the Sprint Review is simplified in the 2020 version of the Scrum Guide. The Nexus Guide already had a simplified version of what a Nexus Sprint Review is. Part of this is due to the fact Nexus uses Scrum as its building block. Could the Nexus Guide be simplified? Perhaps, but the Nexus Guide already is a compact and simple framework.
This is a short description what I would change in the Nexus Guide. Do you agree with me? Would you make different changes or add other changes?