The Nexus Framework book - some issues.

While reading the book "The Nexus Framework for Scaling Scrum" ISBN-13: 978-0-13-468266-2 (In the following "The Nexus Book" or "the book", etc.) I encountered a few issues.

I've gone as far as registering the book at informit.com and looking at the material and opportunities provided there. Not to my surprise it's not worth it.

Lacking a better forum to discuss my issues, I would like to present them here and get some feedback, preferable from the authors.

Firstly though, I want to acknowledge the good work of the authors. I have read the Nexus Book both, in preperation of the SPS assessment and out of, shall we say, some fundamental professional interest.

The book indeed provides solide extended information and context for the Nexus Framework. I consider it worth the price and read.

Nevertheless there are some things I take issue with.

1. Page 9, under the heading of "Nexus extends Scrum", Table 2-1 Nexus Roles, Events, and Artefacts.

"The Sprint" is placed under the event section, suggesting it to be just a "common" event like the others.

I take issue with this because the Sprint event is a bit more fundamental.

(a) The Scrum Guide for instance calls it "... a container for all other events, ..." and thereby acknowledges that the Sprint is not just one event of many.

(b) Strictly speaking, all other (nexus/scrum) events in Table 2-1 are not nessessary. That is, in theory the Sprint as such is the minimal sufficiant event to be agile and produce a "done", valueable piece of software.That of course assumes most excellent skills, cooperation, etc. of all people involved.

(c) I would even argue that the proper planing and handling of the Sprint event is significantly more important (and probably difficult) in a Nexus then it is in a single Scrum. The Nexus book seems to support this, in presenting the notion of different sprint cadences but stressing the need of aligning.

In reality, of course, all the other events are very valuable and corner stones of a working Nexus. Yet without the Sprint event, all the other events lack ... cohesion.

Now, while the book makes it clear that knowledge of Scrum is expected, I still suggest, for the sake of clarity, to add a line about "The Sprint", for instance in subbscript.

2. Page 15, under the heading of "The Nexus Daily Scrum", ditto page 18 "Nexus Sprint Backlog".

The book says about the Nexus Sprint Backlog (NSB):

"During the Nexus Daily Scrum and throughout the day, the Nexus Sprint Backlog may be updated by the Scrum Teams to visualize and manage current inter-team dependencies.

It is not simply an aggregation of the individual teams' Sprint Backlogs, since each team will have work for itself as well as the Product Backlog work that it needs to do. ..." (Emphasis mine.)

Page 18 under "Nexus Sprint Backlog" says:

"The Nexus Sprint Backlog contains the PBIs that have cross-team dependencies or potential integration issues. It does not contain PBIs that have no dependecies, nor does it contain tasks from the individual Scrum Team Sprint Backlogs. ..."

I take issue with the notion, that the NSB does only contain PBIs with dependencies or integration issues.

(a) This this at odds with the Nexus Guide, as I read it.

The Nexus Guide under "Nexus Sprint Planing" says:

"... All Product Backlog items selected for the Sprint and their dependencies should be made transparent in the Nexus Sprint Backlog."

Under "Nexus Artifacts" subsection "Nexus Sprint Backlog" it says:

"A Nexus Spring Backlog is the composite if the Product Backog items from the Sprint Backlogs of the individual Scrum Teams. It is used to highlight dependencies and the flow of work during the Sprint. ..."

(b) It is counter-intuitive and illogical.

If we assume that the Product Backlog (PB) is the (sole) source of valueable work for the product and we further assume that the individual Sprint Logs of the Scrum Teams represent a subset of that PB, then the sum of the individual Sprint Logs of the Scrum Teams would be a subset or a view into the PB also. For transparency reason already, one would wish to have such a view easily available.

For instance, a team could find a dependency of one of its PBI to a completey different PBI somewhere in the middle of the Sprint. How to find out what other team might be working on it? Such information could, of cource, be captured in the PB. But I argue that is to wide a view. Even if the PB allows for different sprint specific views, it still would be simpler to capture some such sprint specific information in a specific and already exisiting construct - the Nexus Sprint Backlog.

The Nexus Guide, as cited above, could, on the other hand, be read in such a fashion, that it indead implies to only have the dependent or otherwise issue prone PBIs captured in the NSB. In this case however it is not clear where, for transparency reasons, the other PBIs are captured. Having those only inside the local Sprint Backlogs lacks transparency. Ditto for the PB.

I take especial issue with this, because the Nexus Book, as I read it, argues on a general level. While it might well be appropriated to do as the book suggests in a specific context, it's questionable as a general rule.

3. Page 45, "Optional Practice: Using a Cross-Team Refinement Board to understand dependencies", ditto page 53: Dependencies counter intuitiv arrows, not flow. Add. explanation needed.

I take issue with the way dependencies are represented.

This is not specific to the Nexus Book alone. This kind of representation can be found outside of Scrum, and I'm familiar with it, but that makes it not less anoying.

The matter is also presented in Cross-Team Refinement in Nexus and Visualizing the Nexus Sprint Backlog.

The figures found in the papers are similar to the Nexus Book.

For example:

(a) Figure 2. Dependencies can be visualized on a Cross-Team Refinement board. https://www.scrum.org/resources/cross-team-refinement-nexus, page 3.

(b) Figure 2. Nexus Sprint Backlog. https://www.scrum.org/resources/visualizing-nexus-sprint-backlog, page3.

The issue I have with this is, that the notation is both illogical and in violation of the K.I.S.S. principle.

Specifically, the orientation of the arrows in (a) is illogical, in so far as that an arrow would be assoziated with some kind of flow. The flow would be understood as to be in the direction of the arrow.

That is not the case with the notation as presented in the Nexus Book or the paper.

In (a) PBI 7 would depend on PBI 4. The notation is not obviously understandable from the figure alone. It in fact needs further explanation, which is given in text both in the paper and in the Nexus book.

If now, instead of this representation of dependencies, the value stream would be depicted, those same dependencies would still be visible but better understandable from the figure alone.

That is, the green arrow would not point to PBI 4 but at PBI 7 instead, and would have the number 4 written in it. This depicts the same information, but already suggests that PBI 7 has an inbound PBI 4.

I don't assume that this will be greeted with much enthusiasm, given that this kind of notation is far to common. Still, Scrum.org has found it necessary to launch into Scrum+Kanban (e.g. https://www.scrum.org/resources/kanban-guide-scrum-teams), and the Kanban Guide (and the „concept“ of Kanban itself) do go on in some lenght about „flow“ - Work Flow, Value Flow, etc.

As for (b) … my issue is basicly the same: Illogical and complicated.

If we assume that the figures represent physical whiteboard with some sticky notes on it, how would a note place on top of an other note be understood?

I don't know if I'm up against some cultural thing here. But as far as I'm aware, even in the U.S. this probably would be understood as: The PBI on top has some kind of priory over the one(s) below, maybe blocking them.

So, both the paper and the Nexus Book explain that, e.g. PBI 4 placed over the bottom-left corner means that PBI 4 blocks PBI 1 but PBI 1 placed over the bottom-right corner of PBI 4 means 1 is depending on 4.

If the only information given by this notation is -again- dependency, why so complicated? Why not just go with the old „put a sticky not on it“? What I mean to say is:

If we just put a note with PBI 4 on top of PBI 1 (so that PBI 1 is partial hidden by it) and vice versa a note with PBI 1 beneath PBI 4, would that not be good enough? What kind of information would be lost?

On a different angle: That particular practice has a slight smell – the smell of an electronic tool unable to place a virtual sticky note with the same ease as a one could do with a physical note.

Again, the prime issue I have is the whiff of general, „best practice“ this has. But in general I don't see why one should make things more complicated than absolutly necessary.

At the whole, seeing a notation as in (a) and (b) makes me … edgy. Given the background of the authors and especially the association with Scrum.org, I wonder why they have choosen to present the subject in such a manner.

As indicated, I would appreciate feeback&hints of as to what I might have missed or failed to grasp.