We have invented Nexus!

How does our way of scaling Scrum at eSKY compare to Nexus, the new Scrum.org’s framework? This is the question we asked ourselves recently – and that I’ll try to answer in this post.

But first, a bit of context:

We have invented Nexus…

For a long time, we’ve been doing well with “standard”, single-team-scale Scrum. However, due to our rapid growth in the last 12 months, we had to finally start to scale. Through a lot of experimentation, we’ve iteratively developed our own framework for scaling Scrum (of course, still evolving).

Mariusz, one of our Scrum Masters, went to the Agile Coach Camp Poland unconference recently, where, by an interesting coincidence, Kate Terlecka was revealing the first details about Scrum.org Nexus framework. And guess what? It turned out, that the way we work at eSKY is strikingly similar!

This doesn’t come as a surprise. The best frameworks (and even the Agile philosophy itself!) aren’t invented, they’re discovered, similarly to design patterns. The wise people at Scrum.org aren’t fantasizing “the only true way” in their ivory towers, they just consolidate and polish what already is proven to work for companies around the world – Kate illustrated this nicely in her Nexus introductory article.

… with our own flavor

There is one important observation that I’d like to add to Kate’s article, though: a framework like Nexus is, inevitably, a generalization. The processes of Nexus co-inventors are similar (otherwise it wouldn’t emerge as a pattern), but not identical.

If you adopt an existing, established framework you may try to do it by the book. However, in the case of Nexus, there are no adopters yet – there are only co-inventors. In effect, probably no company at the moment does a “canonical” Nexus.

So, what are the differences in our case?

The comparison

I won’t describe the two frameworks here in detail. Take a look at the Scrum.org Nexus page and at “Our way of scaling Scrum at eSKY” presentation if you need. I’ll focus only on what the similarities and differences are (at the time of the publication of this post – our methodology is continuously changing and the Nexus specification is still being finalized at the time of this writing).

Product Backlog

Our approach to the product backlog is identical to the Nexus one. We have a single backlog for the whole product, shared by all the teams. Teams don’t specialize in any areas of the backlog – any team can work on any requirement from the backlog (bigger requirements are often split among many teams to be done in parallel).

Scrum.org’s Nexus introduction doesn’t specify how the backlog refinement is done in Nexus – in our case it is done by representatives of all teams, to make the refinement meeting more manageable.

Nexus Sprint Planning and Nexus Sprint Backlog

Our sprint planning is also similar to the Nexus one. First, the representatives of all teams meet together, to do a higher-level planning and to decide how to split the work from the product backlog among the teams. Next, the second, lower-level phase of the planning is run separately by each of the teams.

What’s slightly different, is our sprint backlog. In Nexus, there’s a single Nexus Sprint Backlog shared by all the teams. In our case, each team has its own, separate sprint backlog, but we also have an additional task board, shared by all the teams and used for high-level coordination between them. Items on this board are more coarse-grained than items in the sprint backlogs. The board is also shared not only by a single “Nexus” (a single product), but by all the products (“Nexuses”) in the whole company, so it is a bit higher level than the Nexus Sprint Backlog. However, the total number of our Scrum Teams in the whole company is 11 at the moment, so it is not that many more than the upper boundary for a single Scrum.org’s Nexus.

Nexus Integration Team

We don’t have explicitly designated Integration Team as in Nexus. However, we have several points of coordination among Scrum Teams, that together fulfill similar needs.

First of all, we have cross-team technical communities of practice (frontend, backend, QA etc.) that have their own technical leads and meet daily to discuss coordination issues at the code level, as well as decide about coding standards, shared components, etc.

Second, every line of code passes a cross-team code review process (it is obligatory that the code produced by a Scrum Team is reviewed by a different team working on the same product).

And third, in addition to the technical communities of practice, we have also a Scrum Masters community of practice. Our Scrum Masters meet once a week, mostly to share knowledge and discuss good practices, but it is also possible to discuss cross-team coordination issues during these meetings if needed.

Sprint, Integrated Work, and Integrated Increment

This is the same as in Nexus. All the teams work on a shared code base and integrate regularly into a single master branch during a Sprint. All the teams also share a single Definition of Done.

Because the code is integrated regularly during a Sprint into a single code base, also the increment produced at the end of a Sprint is a single, integrated one and includes merged work of all the teams working on a given product.

Nexus Daily Scrum and Daily Scrums

We run both team daily scrums, and cross-team daily scrum, as in Nexus. The cross-team daily scrum is run in front of a coarse-grained, cross-team and cross-product task board mentioned in one of the previous sections. The only difference with Nexus is a different order of meetings: Scrum.org’s diagram shows the Nexus daily scrum first while our approach is to run team daily scrums first. Our practice shows that much more often there is a need to bring some information from the team daily scrum to the cross-team daily scrum, than the other way round.

Another difference from the Nexus, or rather an addition to it, is that apart from team and cross-team daily scrums we run also technical communities of practice daily scrums, described in one of the earlier paragraphs.

Nexus Sprint Review

We run Sprint Review in the same way as in Nexus: there is a single sprint review for the whole product, presenting a unified product increment created by all the teams during a Sprint.

Nexus Sprint Retrospective

Different than in Nexus, that has both joint Nexus retrospective (two rounds) and individual team retrospectives, we run only team retrospectives. However, this doesn’t mean that teams don’t share their insights with the other teams. Because there are a couple of different points of coordination between the teams, e.g. technical communities of practice and Scrum Masters community of practice, there are frequent opportunities for such an exchange (although less formal than in the case of a dedicated retrospective meeting).

However, the idea of more formal joint retrospective is something we’re experimenting with right now – at the moment as a part of our Scrum Masters community of practice, but we’re also considering running “proper” cross-team retrospectives in future.

What do you think about the differences between our framework and Nexus? Are they only cosmetic, or do they matter in your opinion? Do you see any similarities to your methodology? Please share below in the comments!