Happy New Year.

This time, my writing is no longer being elaborated, so please allow me to be so brief and go straight to the article.

Why?

Scrum is a modern, new software development framework and the Agile philosophy is also very new and dynamic! This is what I acknowledge. But in all Scrum theories, there is one thing in common: a team of 3 to 9 people

Well, so now there are 3 to 9 people in the company sitting in code, what do we need many programmers for? And why are we in fact thirsty for programmers (ignoring layoff because it’s actually a layoff, but it’s not that they’re not thirsty for human resources)?

The answer is in the following image:

With 1-2 teams working with 1 product, we only need to use Scrum.

With a team that has to take care of 2 or more products…. Who cries this pain? (Bloody music pops up)

With many teams working on many products, we will have to learn project portfolio management.

As for many teams working on the same product, we must apply Scaled Scrum.

So what is Scaled Scrum?

Scaled Scrum

Scaled Scrum is the coordination and balance of Scrum teams to make 1 product effectively.

Indeed, this is a picture of a Scrum team making a product

The dark cloud represents the team’s difficulties and problems. We can see that the cloud currently covers only part of the project

And after a while, the product swelled, Scrum team members were running at 100% capacity. Therefore, the company recruits more people to have more resources for development. At that time, there were 3 Scrum teams and things became like this:

Oh, why is it more difficult to increase people? The reason is that it will take time to transfer, train as well as communicate between teams. If each Scrum team still does the same uncoordinated pattern, the impendiment will increase.

Seeing the difficulty increase, instead of finding the cause, the company decided to increase to 9 Scrum Teams for excess human resources. And disaster struck:

Clouds covered the entire project because literally, the teams spent most of their time arguing.

As a result, the original Scrum is no longer relevant. We need Scrum-based models/framework for development.

Typical Scaled Scrum models/frameworks

Above are 4 Scaled Scrum models that I would like to introduce to you: Scrum of Scrums, Nexus Framework, LeSS (Large Scaled Scrum) and SAFe (Scale Agile Framework)

Scrum of Scrums

Scrum of Scrums is the simplest Scrum application scale model. The way to implement as shown is to combine 5 Scrum teams together, each Scrum Team is in charge of 1 Product Owner. And the Product Owners will gather together into a Product Owner Council and be managed by a Chief Product Owner. The Chief Product Owner will act as a bridge between the Stakeholders and the rest of the Product Owners. In addition, we have another role, the Scrum of Scrums Master, to ensure the model will run properly.

Regarding events, every event is like Scrum, except that we will have more Daily Scrum of Scrums after the individual Daily Scrums.

The model is said to be ideal for 4-6 Scrum teams.

Personally, I think this is a model worth referencing for micro-service products, but between services, there must be a small break and as little interdependence between teams as possible, and communication can be effective. looks a bit layered, leading to a bit of inflexibility.

Another point that I also feel is not good is that in the general Scrum, after the private Scrum. As such, individual Scrums can end at different times, leading to a general Scrum that can only begin when the individual Scrum ends at the latest, and the difficulties encountered by different teams may be repeated many times. in a joint Scrum meeting. As such, this will take a considerable amount of time.

Nexus Framework

Nexus model as you can see above, we will have a model that closely resembles Scrum. The differences can include:

• Backlog Refinement: The activity of analyzing Product Backlog Items, clarifying their interdependencies and providing a way to predict which Scrum team will do which PBI.
• Nexus Daily Scrum: An activity to find out what are the dependencies between PBIs, or between teams that communicate with each other. Its result is the input for individual Daily Scrums of teams.
• Nexus Integration Team: The team in charge of ensuring that each Sprint has 1 done Integrated Increment delivered at the end of the Sprint. That is, play the role of an inspector, not a person who directly performs the integration. The team will include:
  • Product Owner: Of course
  • Nexus Scrum Master: Selected by 1 Scrum Master of one of the member teams (can arrange 1 Scrum Master for each team or 1 Scrum Master for all teams). Play a role in ensuring Nexus is running properly during software development. And this is also the highest rank Scrum Master of the team
  • Developer members: Can be taken from Scrum teams or made a separate team. Highest priority is given to ensuring the integration work is completed. Selection criteria are experience, skills in the integration and know-how of the Product. These developers may vary from Sprint to Sprint.

The process of a Sprint will go like this:

• The items of the Product backlog will be compacted and analyzed to clarify the dependencies between them
• Nexus Sprint Planning takes place with the participation of all parties. In the process Sprint Planning of individual Sprints also takes place.
• The result is a Nexus Sprint Backlog that includes the team member’s Sprint Backlogs, as well as the teams’ PBI dependencies.
• Then there are 3 to 9 teams working under the coordination of the Nexus Integration Team.
• During the Sprint, the Nexus Daily Scrum takes place first and the odd Daily Scrum takes place later.
• At the end of the Sprint, when all the PBIs are in the Sprint Integration Increment, the PBI is reintegrated and checked to make sure it’s done.
• Nexus Sprint Review will follow shortly. This is an event that will replace all single Sprint Reviews of teams
• After the review, Nexus Retrospective will take place. In the process Retrospective of individual teams also happens in parallel.

It can be seen that, in terms of diagrams and implementations, Nexus is much more like Scrum than Scrum of Scrums. Nexus also has the advantage of focusing more on product knowhow and focusing on communication difficulties between teams and interdependencies between tasks. But the downside is that the Nexus is still a bit too ideal and the Product Owner is only 1 person. Although it is possible to assign a number of people to do some of the PO’s work, when the PO is not available for some reason, it is the biggest difficulty and interdependence.

LeSS(Large Scaled Scrum)

We see that LeSS follows the above model to look like Scrum. But there are some differences:

• Depending on the project with 8 or more teams, there will be 1 Product Owner or 1 Product Owner council.
• Sprint Planning is divided into 2. Planning 1 will include PO and team representatives. Planning 2 all participate.
• Daily Scrum: In case of need to share information, people on one team can sit in the Daily Scrum of another team. And there is another meeting if necessary called “open space town hall meeting”.
• Product Backlog Refinement: Sounds very Nexus but not Nexus =))) This meeting at LeSS is optional and is only for checking the output of the teams.
• Sprint Review: At this meeting, the teams will present their output in the last Sprint and receive feedback from the PO and stakeholders.
• Overall Retrospective: Takes place after each team’s single Sprint Retrospective. Also includes Product Owners, Scrum Masters and representatives from each developer team

SAFe(Scale Agile Framework)

This is a framework applied at the company level. You can see this model is divided into many different levels, using Lean, Kanban, XP, … a lot of Agile practices and frameworks. The level that is most similar to Scrum is Program and Team.

You can read more about SAFe summary at this link:

https://www.agilest.org/scaled-agile/safe-framework/

summary

You can see that we have and are having different solutions to be able to apply Agile to a project with many people involved in development. Each model/framework has its own pros and cons. Please consider and apply the reasonable model.

Thank you for reading the article. Wishing you a healthy and successful year of the Rabbit 2023.