Nexus images copyright of Scrum.org.
Nexus+ images were made up by the blog post author.
Note – blog post author modified his application of Nexus so it’s no longer Nexus technically.
I use I am the Change; it’s a meta-framework and a set of patterns for agility transformations.
I develop agility change chefs so I leave a legacy long after I leave the building. When I partner with
Many would say there is no need for any more frameworks. I call that black and white thinking. I simply ask my clients when we go over 3 teams per product, “how will we synchronize the work?”, after first educating them on some of the options including:
- no pattern at all
- Scouts and Champions, a network effect
- Nexus and Nexus+
- LeSS and LeSS Huge
- Scaled Agile Framework – see my previous post When is SAFe safe?
- etc.
If using a pattern, I prefer to
Nexus, at the core of Scaled Professional Scrum, was published by Ken Schwaber and Scrum.org in 2015. I made the mistake for some time of thinking that Jeff Sutherland also published Nexus but Jeff Sutherland did not. Jeff Sutherland’s modular Scrum at Scale™ framework is about guidance. Nexus and Scaled Professional Scrum were collaboratively developed by Ken Schwaber, David Dame, Richard Hundhausen, Patricia Kong, Rob Maher, Steve Porter, Christina Schwaber, and Gunther Verheyen.
To understand more about Nexus, check out the Nexus Guide under Resources as www.scrum.org and Simon Kneafsey’s post about Nexus+.
Ken Schwaber and Roman Pichler taught my Certified Scrum Master course in June 2006. I had been playing with Scrum before then but I clearly remember my road to Damascus moment that 2nd day in London, UK. I was living in Ireland then.
I also play a “Nexus game” at my Scrum training days, to see Nexus in action every few weeks, and I try different variations to try to make it fail. I am curious to know the weakness of all patterns, including my own.
{{cta(‘047ac8f2-ff1a-4a65-894c-2234d7c1ebf8’)}}
Nexus with a twist
The Nexus format in this post is essentially the same as normal Nexus with additions of Kanban or The Lean Startup in “sprints”. The Nexus Integration Team(NIT) is accountable for minimizing dependencies across all teams in the Nexus, and is accountable for a combined potentially shippable increment. I jokingly called it “KanScrumUp”. So it’s Nexus with some tweaks. So perhaps this is not a fair account on Nexus.
Why did I tweak Nexus? Well, I had a number of teams per product that wanted a choice of Scrum, Kanban as per the 2016 Essential Kanban Condensed Guide, or the Lean Startup. The teams wanted a pattern. I wasn’t aware of a pattern for those methods. So I modified Nexus as above. And in one Nexus+, I added the Architecture Owner role to reduce organizational “anti-bodies” while still urging emerging design by self-organizing teams.
Nexus, the exoskeleton of Scrum, has made some optional portions of Scrum mandatory
These are the Nexus additions as I understand them:
- Product Backlog Refinement (PBR) is an event, not a fudge activity like it is in Scrum – enough Refinement meetings have been performed during a Sprint if the Product Backlog items are ready and selectable with minimum dependencies during the Sprint Planning meeting. Hence, the notion of ready work (perhaps against a “definition of ready”) is strongly hinted at.
- PBR Part 1 is about decomposing Product Backlog items into enough detail in order to understand which teams might deliver them, and in what sequence over upcoming Sprints.
- PBR Part 2 is focused on dependencies
- Nexus Integration Team – accountable for integrated increment, minimizing dependencies & cross-team issues
- The (single) Product Owner
- A Scrum Master
- One or more Nexus Integration Team Members – a Development Team member from each Scrum Team – 3 to 9 like a normal Scrum Team, with member evolving over time. Each NIT member can float if primary responsibilities are satisfied.
- Nexus Goal – the sum of all the work and Sprint Goals of the individual Scrum Teams within the Nexus. The Nexus should demonstrate the functionality that they developed to achieve the Nexus Goal at the Nexus Sprint Review.
- Nexus Sprint Backlog, the composite of individual Scrum team backlogs (each of which is maintained by its individual Development Team)
- Events are appended to, placed around, or replace (in the case of the Sprint review) regular Scrum Events to augment them, e.g.,
- Nexus Sprint Planning
- Nexus Daily Scrum which informs each Development Team Daily Scrum about integration issues, dependencies and information sharing, e.g., cross-team issues
- Combined Nexus Sprint Review of the “Integrated Increment”
- Combined then separate/break-out by Scrum Team then recombined Nexus Sprint Retrospective
- Stronger guidance than Scrum that technical excellence is needed – in software terms, this usually means the likes of continuous integration, test automation, XP / Software Craftsmanship practices. Nexus is more about software. I also use Nexus for non-software products.
I’m curious why PBR and technical excellence are watered down in Scrum. Was it just that at scale more rigour was needed? To my mind, even at a team level, Scrum needs the same rigour.
I believe that the lack of these additions is why Scrum is broken in 90% of the implementations I recover from WaterScrumFall. What I see is a world is full of coping mechanisms. I love Nexus and Nexus+ because it allows me to slowly dissolve the functional silos away, very gently, particularly when combined with Toyota Kata, with baby step improvements every sprint (or more frequently) as part of the normal daily work.
Nexus has a new role, an often misunderstood role because of its unfortunate name. The new role is Nexus Integration Team, with a regrettable NIT acronym. It could be full time, but it’s usually part-time. It’s not what is says on the tin, rather it’s accountable for minimizing dependencies between Scrum Teams and for a combined potentially shippable increment at the end of the sprint. It also coaches Scrum Teams on technical excellence, sometimes leading by example, coding up tooling & infrastructure if it helps the Nexus. It is quite different to the SAFe System Team in that respect.
The Nexus guide doesn’t say this, but my feeling is that the Sprint Planning meeting needs some kind of team agreement for what happens while the Nexus Integration Team is doing its thing during the events. Self-organizing teams lose their rhythm while the NIT is busy; I guess that it is a minor weakness in Nexus, easily overcome with a team agreement….
I like the way the Nexus events are run:
- The Sprint planning starts with the NIT, and then each team plans, and uses dependency boards typically – the visualization is simple
- The NIT Daily Scrum happens first so all Scrum Teams are informed about integration issues for example
- Product Backlog Refinement is an event – see here how well scrum.org handles this
- Only one Sprint Review for the whole Nexus
- Sprint Retrospective is split into three parts – issues across the Nexus, individual Scrum Team Retros, then combined actions – but I much prefer to run a mini-Kaizen within the time box so the actions are just done, with no homework for the following sprint
Most of all, I like the way Nexus Scrum Teams can still be component / platform teams (not necessarily feature teams), as the NIT is accountable for integration, the NIT usually having a Development Team member from each team to worry about integration. That said, all Scrum Teams are still cross-functional, and continuous integration and test automation are pre-requisites to using Nexus.
Nexus can also be a temporary coping mechanism for not progressing on a feature team journey just yet, if for whatever reason you genuinely cannot make it happen right now, bearing Larman’s laws in mind. In fact, that’s why I started using Nexus, when an initiative that was very keen to progress with LeSS ended up with too many odd numbers like 0.25 of a particular type of SME on a cross-functional feature team, and we lacked time to get that balance right in that context. The plan for that initiative was always to get to LeSS at some point.
I also catered for the avoidance of an early “antibody reaction” in the context of Disciplined Agile being the company standard, by adding Architecture Owner to the roles along with Product Owner and Scrum Master / Flow Manager (for Kanban teams). I strive to let the change infection take hold without being noticed at first, and let it creep up.
My Nexus implementations are usually enhanced but never diluted. Nexus is a framework after all. You’ll just have to trust that I do minimal additions for the context.
Nexus +
Many critique Nexus as being limited to 3-9 Scrum Teams, but you can also use Nexus+, in effect Nexus of Nexus, up to 81 Scrum Teams. That should be big enough for most situations. You could even have Nexus of Nexus and LeSS, where some work streams / clusters are not ready for LeSS yet. I like that the Nexus style retrospective attains closure before sprint end. My one criticism of Nexus+ is the lack of visible support for it. I more or less had to figure it out on my own.
Nexus, if you adapt it with permission, gives the flexibility due to its NIT of using other methods than Scrum. That gives Nexus real power. Ironically, while at a course for a competing pattern, “the penny dropped” that Nexus’s NIT encourages Development Teams re-organization to minimize dependencies, if taken to the nth degree, producing Feature Teams. But while the NIT is accountable for minimizing dependences, Nexus leaves it to the teams to self-organize so they minimize dependencies, nudged / coached by the NIT. The NIT also coaches on good engineering practices and builds infrastructure if needed. The NIT might even build normal value-delivery-stuff if it helps reduce dependencies or makes a combined shippable increment more attainable.
I was inspired by a conversation with an experienced agilista with lots of banking experience, too humble to be named, to give rhythm to communities of practice (CoP), with a kind of formalized informality, by including the CoPs in the Nexus+ rhythm and the Nexus+ Sprint Review.
I usually add Toyota Kata to Nexus+ by adding baby steps of improvement towards the Challenge in Sprint Planning and how we did with those baby steps and the Sprint Goal in the combined Sprint Review. More on Toyota Kata at the Mike Rother’s Toyota Kata web site.
Scrum.org Certifications
Nexus is hosted on Scrum.Org, along with its frankly better testing of practitioners. I am a CSP but I have also done PSM I, PSM II, PSM III, PSPO I, (PSPO II and PSD imminent), SPS, and while the tests still have a few bad questions, and while 50% of my training attendees get 100%, it’s not easy to get 100%. One needs training or lots of skill and experience to attain 96-100%. I quite like what Scrum.org is doing. PSM I has 80 questions for 60 minutes. PSM II has far less questions for 90 minutes, really long questions and really long answer options. My PSM III manual marker was impressed with my essay question answers in the tightly time-boxed test, and it was scored on the same day. I also received helpful feedback. A hotel maid called to the room and continued to talk to me during my test; this upset my PSM III test time-box but it was all good even so. I found myself writing and writing so much, leaving not much time for the 2nd half of the test. PSPO II looks like it will be as difficult as PSM III. I’ll try to avoid interruptions for that.
It’s useful to not have to take time out of work if you already “know your onions”. Kudos to scrum.org for allowing that. Learning isn’t isolated to two-day training courses, it’s continuous.
“Getting” Nexus
I did not have to attend a course on Nexus or Nexus+. If you get Scrum, then just remember that Nexus and Nexus+ is still Scrum and remember what the differences are. I teach Nexus and Nexus+. I developed a Nexus game for training. I modified my instances of Nexus for Kanban and The Lean Startup with Ken Schwaber’s permission; all that matters is that all teams in the Nexus are in some kind of learning cycle. Many misunderstand that Kanban also has cadences for its learning time-boxes.
If you never use Nexus, what I love most of all about it is if you pass the Scaled Professional Scrum Test, you have by default “nailed” (your understanding of ) Scrum.
I like that Nexus, like LeSS has a single Product Owner, except when you get to Nexus+/LeSS Huge when the equivalent to Area Product Owners are needed. There is an onus on Scrum Teams to learn the business domain and to become flexible and to become Feature / Service oriented.
Where to from here?
I think Scrum and Nexus/Nexus+ are still missing a trick by not promoting Monte Carlo probabilistic forecasting. I love the way Troy Magennis’s free Throughput Forecaster bakes risks into the forecast answers. Burn-ups are no good if we did the easy stuff first, or even if we were smart and did the tricky stuff first. Risks are potential issues, sorry to state the obvious.
Nexus’s weakest link is its lack of visible support for Nexus+; I had to figure it out for myself.
Conclusion
I use “I am the Change”, and I start with the purpose of the change, understanding the current situation, and how we will measure progress. I believe in most situations that change has to be supported from the top, as the top drives the structure. I am clear that the change is not just for teams, it starts with the questions leaders ask, for example, asking to load more work onto already over-burdened teams or unknowingly starting new projects just by asking questions.
Later, after we select methods for our toolbox, we look at synchronization patterns. In doing so, I recommended SAFe only in two contexts so far, but I am more open to recommending SAFe as per a previous post. In most cases, regardless of method choices, the portfolios / business units end up deciding to use (tweaked) Nexus or Nexus+ to:
- have a rhythm for delivering value without the need for post-sprint integration/testing
- visualize dependencies
- generate positive peer pressure
- implement Toyota Kata (Improvement Kata & Coaching Kata) – not part of Nexus admittedly
- keep the focus on the daily work, as when the chips are down that’s what it’s all about
- provide metaphorical scaffolding for a move to another pattern, e.g., nudging the organization towards LeSS and LeSS Huge in a Scrum context
- get Scrum, Kanban and Lean Startup teams on the same combined Sprint Review rhythm
Overall take on Nexus
- simple, understand Scrum, understand Nexus; if you understand Nexus, you’ve nailed Scrum
- learnable in under a half day, but it takes longer to master it
- malleable for Kanban and The Lean Startup
- agility without necessarily having Feature teams
- fantastic scaffolding for growing good agility, and maybe even a permanent solution
- adaptable for Toyota Kata due to the joint events
- like any framework, proper training, practice and support helps
Tweaked or un-tweaked, Nexus and Nexus+ are really useful.
Separate blog post experience reports on Nexus and Nexus+ are based on implementations at:
- a bank business unit that handles a significant proportion of all card transaction authorizations for that country, and
- a payments company that is the “plumbing” behind payments in a number of countries.
John Coleman,
London, UK
