First guest author has arrived! Today’s episode is written by Kate Terlecka and will be an introduction to The Nexus Framework, a tool for Scrum scaling. Have fun!
What’s the most fashionable word in current agile world?
Yep. If you don’t scale you’re a lame 1999 oldtimer, not worthy of attention. Only Scrum? But you’re supposed to have BIG Scrum!
There is a reason why creators of two largest Scrum scaling frameworks refused to describe and name them for years. Only when SAFe started being marketed aggressively, they’ve had a change of heart. Bas Vodde and Craig Larman decided to name what they have been teaching for years LeSS (Large Scale Scrum) and Ken Schwaber decided to finally formalize and name Nexus.
Honestly they are both very similar. There are very few differences, they mainly stress different aspects of product development. So whichever you choose, as long as Scrum pillars are in place, you have good chance of creating big Scrum.
So let’s take a closer look at Nexus. To do that let’s think for a moment why do you want to scale?
If you want to scale because of fashion, or you have too many people and are too scared to get rid of them or start a new venture, or you need to put all this middle management somewhere – Nexus is not for you. It won’t help your organization. And neither will Scrum.
But if you want to scale because you need more value delivered, or need to produce faster or have too many specialists to place in one team, then Nexus presents a chance of helping you.
Nexus is used to scale from 3 to 9 Development Teams. It has Scrum as its heart and builds on that. So all Scrum elements are required in Nexus.
Nexus has one additional role on top of Scrum: the NIT.
Nexus Integration Team is a changing team (has to be solid throughout the Sprint, but then can change from one Sprint to another) responsible for making sure work is integrated at least every 24 hours.
How do they do it? By managing dependencies and taking care of any type of integration.
IMPORTANT: NIT isn’t a traditional integration team. They don’t write code stitching modules together. They make sure others have all the knowledge and skills to do it. They manage dependencies of any kind: technical, personal, time, law, competency, business etc. So they have to have individuals skilled in most important tasks in the current Sprint.
Nexus also adds two additional artifacts:
Nexus Sprint Backlog. It’s a tool used to visualize dependencies. It’s placed in some visible spot, where all teams can see if there is anything tangled we need to get rid of.
Nexus Goal – a goal for the whole Nexus for a Sprint – something bigger than a Sprint Goal, giving direction of development.
If it comes to events, almost all have a common and separate part – where team representatives take part. There is one that is for all teams only – the Sprint Review (because we still have one Increment), and there is one new event: Product Backlog Refinement. This time it’s formalized as an event.
And that’s it. There are of course some more details, so if it interested you, take a peek at the Nexus Guide. But before you do it – remember to also read the Scrum Guide, since Scrum is the heart of Nexus and if you don’t master Scrum, your Nexus won’t hold structure. And if you master Scrum, your Nexus will be a piece of cake. With tons of dependencies!
Charismatic mentor, founder of Brass Willow. One of the most experienced Scrum professionals in Poland and a Scrum.org’s Professional Scrum Trainer for seven years now.
Challenges? Her fuel! Took part in many transformations. The Tough Stuff expert. Patient and determined. She wants to change how software is developed and released in Poland.
Hi, it’s me back again. I hope a little break from technical stuff was a pleasant experience. If you would like to a guest author on How To Train Your Java, let’s get in touch. I’m interested in any topic related to Java or software development in general. Meanwhile, next week we will get back to Amazon Web Services again. Stay tuned!