Some time ago, Crossuite was just a simple calendar with the option of making an appointment with a doctor. Now it’s a digital multidisciplinary platform with more than 10,000 experts in 13 countries. As the project grew, so did our team. At the beginning, one developer and one client were enough for us. Today, 45 people work at Crossuite. However, at a certain point in our operation, we realized that the meetings were no longer within the time limit. That transparency wasn’t what it used to be and people were less involved and proactive. That there were too many of them and therefore it was difficult to synchronize them. So the time came to scale our processes.
What does scalability mean?
The definition changes depending on what we associate it with. Generally, however, it’s the ability of a process, network, software or organization to handle an increased workload or increasing requirements without a significant reduction in performance, efficiency or quality. The advantage of a scalable entity is that it accommodates the needs and requirements of its users or clients.
On the Crossuite project, we develop a product through Scrum. It’s an agile framework that just fits us. When we began to perceive the need to change development processes, we didn’t ask what we would exchange Scrum for. Rather, we tried to work out how we could develop it into such a form that it could handle a larger number of people, requirements and more complex dependencies between functionalities.
Our goal was to achieve a way of development in which the team would be able to continue to function well, deliver regularly and meet business requirements. This is regardless of the fact that there’s an increase in its size or in the volume of requests.
There are several scalable frameworks. Some examples include:
- Scaled Agile Framework (SAFe) (37% of Scrum users use it, according to a 2021 survey)
- Nexus
- Large-Scale Scrum (LeSS)
- Scrum@Scale
We opted for Nexus.
Why Nexus?
Nexus won because it’s based on Scrum itself. Therefore, it means only a small change compared to what our people are already used to. There’s also no need for new roles and all the teams involved are working on a single product. It has one product owner and one common backlog.
Refinement meetings, which aren’t an official event in Scrum, have become a mandatory event in the case of Nexus. This was also one of the decision-making criteria for us. We assessed the need for joint refinement meetings, when individual teams discuss and evaluate the complexity of the requirements entering development in the next sprint, as necessary. So we decided on a joint retrospective, where we unanimously agreed that we want and need them. At the same time, Nexus allows you to support Scrum with a Kanban board, and doesn’t mind when the team isn’t in one location, which happens in our team too.
How is Nexus different from Scrum itself?
Scrum diagram:
Nexus diagram:
So what’s changed?
From the point of view of the diagram, there was no big change 🙂 From the point of view of reality, however, the change was bigger, although it didn’t significantly affect people on the project.
-
Smaller teams
Large teams were divided into smaller ones and we joined the Slovak developers with development teams in Ukraine and Belgium. Today we have a total of 7.
-
Added Proxy Product Owners
We kept the Product backlog and one Product Owner, but two Proxy Product Owners were added to them. Yes, I know, it’s not an ideal solution. With Nexus and Scrum, we should avoid using a proxy. However, in our case, our Product Owner is also our sponsor, client and founder of Crossuite. 🙂 Thanks to this, visions, short-term goals, strategies and market successes/failures are regularly communicated to us. The disadvantage is his occasional unavailability.
However, we put our heads together in the team and agreed that the advantage of a detailed business view, understanding the requirements and communicating them to us, outweighs the negative situations that the intermediary role of a Proxy Product Owner can bring.
-
New integration team
In addition to the three roles existing in Scrum, we’ve also added the Nexus integration team. These are the people responsible for ensuring the compatibility of the work of individual Scrum teams. They check, for example, whether each sprint has brought us a joint increase in the product that meets the sprint goal. They’re also in charge of educating and guiding people in the individual Scrum teams.
Thus, its main task is to ensure smooth development, remove obstacles, guide mutual communication and coach people in the individual Scrum teams so that they are able to deliver the desired joint result and don’t hinder each other.
The Nexus integration team is composed of a Product Owner, a Scrum Master and appropriate representatives of the Scrum teams. Each member should have the skills and knowledge necessary to effectively address any issues that Nexus may face. The composition of the Nexus integration team may change over time to reflect current needs. In practice, this means that different team members can participate in Nexus daily Scrum meetings.
-
Edited events
Nexus adds or extends Scrum-defined events.
Cross-team refinement
Nexus introduces, for example, the concept of cross-team refinement, i.e. the refinement and division of requirements into smaller meaningful units between representatives of individual teams. The product backlog must therefore be broken down so that dependencies are transparent, identified between teams and removed or minimized.
Subsequently, this cross-team refinement is complemented by team refinements, where the individual teams go into more depth. They prepare their own user stories, evaluate them and define requirements in order to achieve the “definition of ready” status and be able to plan them.
Nexus planning
In Nexus, planning takes the form of Nexus planning. The Nexus integration team and/or individual representatives of the Scrum teams and the Product Owner participate in it. Their task is to coordinate all the activities of the individual Scrum teams for the next sprint.
The result of Nexus sprint planning is:
- Nexus sprint goal – is consistent with the product goal and describes the value to be delivered by the team as a whole (all teams) at the end of the sprint,
- sprint goal for each Scrum team – is in line with the Nexus sprint goal,
- one common Nexus sprint backlog – presents the work of all teams and clarifies the dependencies between teams,
- sprint backlog for each Scrum team – clarifies the work they’ll do to achieve their defined goal.
Nexus planning is not usually attended by all team members, which is why the creation of a sprint backlog for each Scrum team takes place on a separate team planning.
Nexus daily Scrum
Daily Scrum starts with Nexus daily Scrum, where we discuss how the individual teams are progressing in relation to meeting the sprint goal. We talk about the various obstacles and dependencies that may have occurred between individual teams. Subsequently, we interpret the necessary situations and solutions on the team daily Scrum. The team’s work schedule for the day is adjusted accordingly.
Nexus sprint review
Nexus sprint review is the only event that doesn’t have a continuation in the teams.
During this event, Nexus presents the results of its work to key stakeholders. It also discusses the progress that has been made towards the product target, even if it isn’t possible to present all completed works. Based on this information, we further talk about what the Nexus team should have done differently, better, and what, on the contrary, was excellent or went even beyond. The product backlog can be modified to reflect these discussions.
Part of the sprint review is a demo, where anyone from the team who worked on the functionality can be the presenter. We consider it a small show where the joint work of the individual teams is also presented to such stakeholders with whom the Nexus team otherwise doesn’t come into contact.
The conclusion of the sprint review is a short vision of the upcoming business goals from our product owner. This allows us to better understand and plan the next sprint.
Nexus sprint retrospective
The Nexus sprint retrospective takes place, again, on several levels.
First, individual representatives of Scrum teams, Scrum Master, Product Owner meet and discuss the problems that block the individual teams and how this affects them.
Separate team retrospectives follow where identified issues are addressed (if applicable to the given team). Similarly, there’s a team retrospective focused only on this particular team.
If the situation requires it, the meeting of team representatives continues, where problems have been identified within the first level, or new problems have arisen for them from the team retrospectives. Action points for their solution or their monitoring and adaptation are defined.
The retrospective concludes the sprint and is followed by new planning.
Scrum and Nexus comparison in a table:
| Scrum | Nexus | |
| Team | 1 | 3 – 9 |
| Roles | Developers, Product Owner, Scrum Master | Developers, Product Owner, Scrum Master, Nexus Integration Team. |
| Events | sprint
refinement (optional) sprint planning daily Scrum sprint review sprint retrospective |
sprint
cross-team refinement (mandatory) Nexus sprint planning Nexus daily Scrum Nexus sprint review Nexus sprint retrospective |
| Artifacts and commitments | Product backlog/Commitment: Product Goal
Sprint backlog/Commitment: Sprint Goal Product Increment/Commitment: Definition of done |
Product backlog/Commitment: Product target
Nexus sprint backlog/Commitment: Nexus sprint goal Integrated product increment/Commitment: Definition of done |
Since the introduction of Nexus, we’re currently running sprint number 9. We have three-week sprints and one of the biggest challenges was to reconcile multilingual teams that aren’t at the same location.
An example is a new team with members from 3 countries on two continents and a 9-hour time difference. In addition to this complication, there were also a few people who haven’t had experience with agile development. Therefore, we focused mainly on coaching people and gaining mutual trust during the first three sprints. Today, processes run smoothly.
How do my colleagues rate the changes?
Erik (Architect):
„For me, the biggest benefit is that the meetings are shorter, as there are only two to four of us in a core team. On the other hand, there’s a couple more meetings, as Nexus planning, retro and refinement have been added. However, it still saves time. I see another advantage in that people are more focused on their tasks and are less distracted by tasks from other teams.“
Aďa (QA):
„Pros:
Standups and all meetings are more to the point, more detailed and can be better adapted to the needs of people in the team (whether in terms of time or content).
- People collaborate and communicate more closely, finish things. Perhaps also because they have no one to delegate responsibility to, for example, in terms of precisely defined features and user stories.
Cons:
- Rivalry between teams, such as sentences like: “This is your bug, not ours.”
- A smaller overview of the project overall and what’s being done in other teams.“
Maťo (proxy product owner):
„In ‘ordinary’ Scrum, we were seasoned as a team and that’s why the transition to Nexus was easy-peasy. Mirka only needed to explain it about four times. This was followed by a division into teams and division of responsibilities. The result is that everything’s running great now, even though we suddenly have several “proxy product owners”. In principle, I feel that the project as such isn’t more complicated, although it’s difficult to believe that this is the case.“
And how do I evaluate it as a Scrum master?
The most difficult task was at the beginning. I had a lot of questions in my head and they cost me a few nights of sleep 🙂 How do we divide people into teams? Will we have component teams or feature teams? How many will there be? Are we sure we need proxy product owners or can our customer as product owner do it himself?
I very much appreciate the proactivity and involvement of the people in the core team with whom we dealt with these issues together. We described the problems, what we were going to solve, and I presented them with a proposal and possible problem situations. We then dealt with the division of people, communication with them and the coaching on Nexus itself, together.
I would compare it to a house. If it’s built on good foundations, it’s also easier to remodel or add floors and extensions. Thank you to the people who have been with me for these foundations and continue to build our Crossuite house successfully 🙂 And what will happen after Nexus? I don’t know. But I know that if another change of processes is needed, we’ll manage it together.
