How Do Nexus and LeSS Differ?

John Coleman — November 9, 2018

This article discusses the growth of agility for customer-facing products with 3+ teams, probably tens of teams with Nexus and/or LeSS.

Background:

In this article, I compare and contrast the more advanced maturity patterns of Scaled Professional Scrum, Nexus with Scrum Studio all in one corner, and LeSS. They have a lot in common.

Nexus and LeSS are the only patterns that are based on real Scrum with 1 Product Owner, 1 Product Backlog for each real customer-facing product. Not a Team Product Owner to be found… To learn more on that topic of Product Owners at the team level in a multi-team scenario see Michael James’ video.

Large Scale Scrum (LeSS):

LeSS’s optimizing goal is adaptiveness (agility, cheap & easy change) because (a) we are all poor at predicting what will hit the mark and be great value for customers so we need to cheaply & easily adapt to discover our way. and (b) the outside world changes (competitors, technologies, …). so we need to cheaply adapt for that. – Craig Larman. With adaptiveness, the delivery of better value and the shorter end to end customer cycle times come for free. With adaptiveness, we can “turn on a dime for a dime”. Multi-learning as cited in The New New Product Development Game, is at the heart of adaptiveness. See my article “50 lightbulb moments with Bas Vodde…”. In addition, the “take a bite” approach of LeSS (perhaps unintentionally as its designed to reduce complexity) is another way to reduce complexity and/or risk with small bets.

Nexus:

The optimizing goal for Nexus is to deliver better value faster, as opposed to just deliver faster. With Scrum Studio, adaptiveness is also within reach. What a lot of people do not realize is that Scaled Professional Scrum adds 50+ complementary practices to Nexus, some of which overlap with guidance from LeSS. One typically only delves into these practices during Scaled Professional Scrum Training. Nexus is an instantiation of Scaled Professional Scrum, in the same way, Professional Scrum is an instantiation of Scrum.

Nexus extends the benefits of Scrum to larger and more complex Products (requiring 3-9 teams). Nexus is not intended to directly address the broader organizational agility problem that LeSS seeks to solve. The Nexus Guide was published in 2015, but the techniques evolved over since 2007 (since the publication of the Enterprise and Scrum).

Let’s compare and contrast Scaled Professional Scrum, Nexus with Scrum Studio, and LeSS.

Comparison / contrast of Nexus and LeSS:

Nexus with Scrum Studio and LeSS have a lot in common. They both deprecate non-Scrum roles. The both have 1 Product Owner and 1 Product Backlog per Product. They are both focused on Agile Product Management. They are both based on real Scrum.

Adoption considerations:

Nexus has a quicker startup as it can deal with component teams, and evolve towards feature teams, coached by the misnamed Nexus Integration(should be coaching) Team. LeSS has more upfront asks for the organization, but in essence, it’s possible in a huge context to not necessarily start with perfect cross-component teams. Beyond Budgeting tends to be part and parcel of both Nexus with Scrum Studio and LeSS. Both help to “flip the organization”. LeSS has an ask to eliminate projects, but in essence, LeSS doesn’t expect this to change immediately, but to work as if projects aren’t there, e.g., the business still thinks there are projects, but as they are integrated into one backlog, and the teams have no idea about these. I cringe that Nexus still supports projects in the long term, artificial constructs to fund work and create unstable short-lived teams; but it means those folks not ready for LeSS still have a real Scrum option of Nexus (probably without Scrum Studio) and aren’t left entirely to (what I call) Trojan Horse options (most of them feature release trains), which can only help to deliver whatever we’re delivering faster. 2nd class is still better than steerage.

Day to day experience:

Both options provide a much better alternative to Scrum of Scrums. Most if not all events are scaled, and attendees should be clear about what each event is about and who should attend. Both make Product Backlog Refinement (PBR) mandatory. LeSS is leaning toward the deprecation of single team PBR in favour of multi-team PBR. LeSS has more meat on the bone for what to do with roughly 8 teams or more per product, product definition, coordination, and the overall retrospective including (optional) management. Both are technical excellence-oriented, although Craig’s Certified LeSS Practitioner class is clearer about the need for technical coaches and mob programming for teams as they launch for at least three months. I agree as I can’t see how lunch & learns to manage to educate teams of people. There are nuanced differences in Sprint Planning (including how work is selected), Product Backlog Refinement and Sprint Retrospective which I won’t go into here.

Projects:

One can argue that every sprint is a project. I’m not talking about those. I’m talking about multi-sprint type projects. LeSS requires a journey away from projects. I can understand why, as the Definition of Done gets compromised. I heard a programme director last year who apparently wanted LeSS, that he “didn’t care about quality right now”, the nub of basic Scrum. This is the stuff John Seddon worries about, failure demand from short-term thinking. Short-term to medium-term outsourcing is also a big no-no. Dinesh Sharma has a wonderful LeSS case study on long-term outsourcing that would have made Deming proud. Nexus is tending towards the same route on projects, but still tolerates projects in the long term. LeSS is stronger on volunteering, no one gets volunteered. In my BaDa strategy, I have a “#RespectingNoIsland“, where people get to continue their work as they normally do. If I detect Team members who are likely to never support Scrum, for their benefit and their colleagues’ benefit, I ask those NoNos to stay out of the change, and I prefer to deal with their work as dependencies, even if I desperately need them. The exception for me would be where Tipping Point Leadership exists, which is a bit heavy handed.

Support:

OK, so Scrum.org is stronger on the training front, its training is consistent. I have had arguments with people who attended Bas’s CLP and not Craig’s and vice versa. I saw one other LeSS trainer’s CLP and it focused on something else again. To be fair to LeSS, this is because it has much more material, 3 thick books, 2 of which are not for the faint-hearted. The LeSS community is very active but less so for ordinary practitioners; it’s more aimed at advanced practitioners. Maybe that’s appropriate. Scaled Professional Scrum and Nexus are understated. SPS/Nexus has quite a number of trainers. The Scrum.org community is aimed at ordinary practitioners and has a very active blog, a series of Scrum Tapas videos, and a series of webinars known as Scrum Pulse. It is possible to attain adaptiveness via Nexus & Scrum Studio if Nexus has evolved to use feature teams, still requiring the Nexus Integration Team (NIT – or what I prefer to call the Nexus Coaching Team) just like a high performing team still needs its Scrum Master.

Full compare/contrast:

I was able to use Nexus as soon as it came out in July 2015 with Scrum, Kanban and Lean Startup teams on the same rhythm. I have been trying to find a true case study for LeSS since 2012. Maybe I’m there, I’m not sure. Another false start? Let’s see.

One thing is for sure, if I can’t use LeSS for Deep & Narrow, I will at least use Nexus & Scrum Studio. Indeed if Nexus & Scrum Studio was something I was erroneously forced to use for “global consistency”, it wouldn’t be the end of the world. Each region/business unit has its own subculture typically; hence only sometimes the same solutions work.

But honestly, I am hoping for LeSS. Why, because it’s got the most support for advanced practitioners, it’s like Top Gun for agilists, and it properly deals with scale over 81 teams where Nexus+ hits its limit. And because LeSS discourages status dashboards, leaders are prompted to visit teams and maybe even mob with them (because the gemba of value creation in LeSS is the code not the team room). And most of all, LeSS has the edge on multi-learning. No other framework is so focused on multi-learning, whether it’s to extend the definition of done at scale to be at close as possible to be potentially shippable and/or to make teams more and more flexible to take on work from other product areas, or even to expand the definition of the product, where we don’t even need project portfolio management because we have a broad product definition as close as practically possible to how the customer would perceive the product. Project portfolio management is not needed because projects don’t exist in LeSS. Product portfolio might be needed but not if you expand the definition of the product. So portfolio management is not actually a gap in LeSS.

If you can’t establish what’s needed for LeSS, shouldn’t you still go further and maybe try Nexus instead? And is there a point at which, having started with Nexus, you might want to start evolving your practices toward LeSS?

If you don’t want both Nexus and LeSS, at least try one of them. Other approaches essentially corrupt Scrum in a multi-team context with Team Product Owners, people volunteered to teams without discussion, Product Owners writing stories/refining the Product Backlog feeding stories to the teams, the Product Owner clarifying requirements, expecting the Product Owner to be Superman / Wonder Woman, or Scrum Masters coordinating work.

Here is a quote from Bas Vodde, co-creator of LeSS:

I look at Nexus as LeSS’ little brother. I don’t mean that negatively as the framework-basics are mostly the same (with some odd names in Nexus). Nexus mostly stops there, just like Scrum stops there. In LeSS we don’t as we’ve experienced that the organizational context is a key factor for successful change. Of all non-LeSS approaches, Nexus makes most sense and stays best true to Scrum.

I would like to thank PSTs who are also in the LeSS community, in particular, those who helped me to be more precise with the compare/contrast Venn diagrams.

I would like to thank Wojciech Walczak in particular for his idea of using themes for the Venn diagram (initially I just had the full comparison/contrast version).

If you spot any errors, please comment below. Thank you.

If you’re not ready for real Scrum, ahem… this is Scrum.org.

There are the Trojan Horse or “#AgileFrameworksSucks” options; for more information see here.

(120)