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:
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.
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.
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.
These are the Nexus additions as I understand them:
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:
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.
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.
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.
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.
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.
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:
Tweaked or un-tweaked, Nexus and Nexus+ are really useful.
Separate blog post experience reports on Nexus and Nexus+ are based on implementations at:
John Coleman has been knocking around with agility since 2004, starting with a mission critical piece of work back then against advice and taking on ever more scary work since then :). A speaker, consultant, coach and trainer on all sorts of agility.