Scaled Scrum is just Scrum

I’ve always been a believer that, rather than focusing on scaling agile, you should just focus on being Agile.

However, over the last few years, a number of frameworks have emerged with the aim of ‘scaling’ Agile. SAFe and LeSS are two such examples of scaling frameworks.

Scrum.org has now also thrown its hat into the scaling ‘ring’ by recently launching Scaled Professional Scrum, otherwise known as the Nexus Framework. Steve Porter from Scrum.org and Richard Hundhausen from accentient.com, the presenters of the talk I attended, described Nexus as the “exoskeleton of scaled Scrum”. They said that the core tenet of Nexus is to continually identify and remove dependencies between teams who are working on the same product.

Nexus Scrum Framework. Courtesy of Scrum.org https://www.scrum.org/Resources/What-is-Scaled-Scrum

Nexus is designed for three to nine teams. These teams must all be working on the same product. If there are more than nine teams then Steve and Richard recommend that multiple Nexuses are implemented.

The framework builds on Scrum by introducing some new roles, events and artifacts.

Nexus Sprint planning is the first of the new events and is the first meeting of the new sprint. The Nexus Sprint planning has appropriate representatives from each of the individual teams that make up the Nexus. The aim of the meeting is to work out at a high level which Product Backlog Items (PBIs) are to be worked on by each of the teams and to identify any dependencies between them. There is no specified timebox for this meeting, but the advice is to keep the meeting as short as possible. From this planning session results a Nexus Sprint Backlog containing an aggregation of all the PBIs for all of the teams involved. Steve and Richard suggested that this would only be possible to do with a really well groomed backlog. If the PBIs are not well understood beforehand, then it would be difficult to come up with the Nexus Sprint Backlog. Once the Nexus Sprint Planning is over, the individual teams can commence with their own planning sessions. The aim by the end of the Nexus Sprint is to deliver a potentially shippable increment for the product as a whole. Needless to say, the Definition of Done is shared across all teams.

The Nexus Daily Scrum is another new event: appropriate team members get together to discuss the plan, any issues the teams are facing and a plan to resolve those issues. We were explicitly told that this should not be considered a Scrum of Scrums. However, to me, it did feel like the kind of things they were describing would be most people’s interpretation of a Scrum of Scrums.

Then there is the Nexus Sprint Review, which is a coordinated Sprint Review across all teams within the Nexus.

A Nexus Sprint Retrospective has also been introduced. Again this consists of appropriate representatives from all of the teams. This retrospective is preceded firstly by a sync between the reps, which is used to discuss whether there is anything in particular all of the teams should focus on in their retrospectives. Once this focus area has been agreed then the teams proceed with their own retrospectives.

The most significant thing that has been introduced as part of Nexus is the Nexus Integration Team or NIT. Scrum.org’s definition of a NIT is “A Scrum Team whose primary work is to coordinate and guide the work of the Nexus Scrum Teams. The Integration Team consists of a Scrum Master, Product Owner, and people with other necessary skills.” Steve and Richard described the NIT as the “servant leadership team”. This team is “can be seen as the Scrum Master or problem solving task force” for the Nexus. They attend all events at the Nexus level and they are also “accountable for the work” within the Nexus. As the NIT is considered a team within the Nexus they also have their own ceremonies and artefacts like the other teams.

There is only one Product Owner for the whole Nexus. Steve and Richard advised that the PO is likely to have to delegate some responsibility to others as there is no way that they will be able to attend planning sessions for each of the teams. So, in other words, the PO is represented by a series of proxies. However, they advised that these proxies should not be given the title of Product Owner, so that it is clear that there is only one person “who has the final say.”

To many of us who have worked on products where multiple teams are contributing, this kind of pattern is nothing new. I am sure we have seen higher level planning type sessions that helps to identify the most appropriate work for the teams. A scrum of scrums to help manage dependencies and deal with issues. And possibly a combined retrospective to help action improvements at a programme level. You may even have a team helping to coordinate the delivery teams.

It seems like Scrum.org has seen this sort of pattern repeating in larger product development programmes and has translated this into a formal framework and added a brand to it. As I said previously, I don’t think the pattern described in Nexus is anything radically new and therefore feel that this type of pattern would naturally emerge. However, I do think that Nexus will help guide those who have not developed at a larger scale previously.

One of the things that encouraged me about Nexus is that it seemed fairly light weight. I was also encouraged by the message that Steve and Richard both kept repeating, that “Scaled Scrum is just Scrum”.

At the time of talk there was only one company officially using this scaling approach and actually calling it a Nexus. It will be interesting to see how it does in comparison to the likes of SAFe and LeSS.

If your organisation is using a scaling approach, then please get in touch, we would love to hear about your scaling experiences.