Developing complex softwares with big teams requires a good development management system. If we only depend on some feature partitions or verbal division of tasks, we could end up working on overlap issues and meet some difficulties when trying to merge all the works from every developer. Beside using version control systems like Git, we should also use a development framework such as Scrum to make our development process easier and structured.

What is Scrum?

Taken from KnowledgeHut, Scrum is a framework for developing, delivering, and sustaining complex products. It is essentially a framework wherein people can address complex, adaptive problems.

Scrum is an iterative incremental framework for effectively managing product development. - The co-creators of Scrum, Jeff Sutherland, and Ken Schwaber

With the iterative development, Scrum makes progress towards the goal through successive refinements. Based on the collected requirements they write the code and are aware that it might be weak in some areas. After this, the team iteratively refines those specific areas until the product is satisfactory. In each successive iteration, further details are added and the software is improved. Usually, the work of each iteration is improved in the upcoming iterations. Another thing that is the main concept of Scrum is that Scrum uses incremental processes because the software is built and delivered in pieces. Each increment represents a complete subset of the final software to be delivered.

Ok, that’s Scrum, but what about Scrum of Scrums?

On bigger projects, we might need to use the Scrum of Scrums method that is implemented as a technique to scale individual Scrum teams to the enterprise level. Scrum of Scrums itself is a technique to scale scrum up to large groups over 12 people, where the groups are divided into Agile teams of 5-10. Each daily Scrum includes a designated member as “ambassador” in order to participate in a daily meeting with ambassadors from other teams, called Scrum of Scrums.

Depending on the context, ambassadors may be technical contributors, or each team’s Scrum Master, or even managers of each team. - Jeff Sutherland, one of the creators of the Scrum

With the role of ambassadors from each team, in our case we have the Scrum Master and the Product Owner, in the beginning of the Sprint we held the Sprint Planning to discuss about what would we do in that Sprint. After we discussed the big picture of the to-do-list, the ambassadors had to make some agreements on which to-do is taken by each team. These agreements are important and should be well-documented so the division of responsibilities are clear in that Sprint. After that the development phase proceeded otherwise as a normal Scrum with daily stand up meeting. Every few days the ambassadors had to report their team progress and difficulties to the other ambassadors, they also had to communicate with the stakeholders such as the Project Lead or Clients if they need to confirm about something. In the end of the Sprint, the ambassadors were responsible to lead the Sprint Review with the Project Lead or Clients.

In the Industri Pilar’s project development, our development team consists of two small teams with 5 members each and 2 teaching assistants. Thus we use the technique Scrum of Scrums to make our development process easier. For each small team, there will be selected different Scrum Master and Product Owner in every sprint. I got the opportunity to be the Scrum Master on the Sprint 2. From all of my previous experiences in developing softwares, I have never been a Scrum Master or Product Manager before. So this opportunity is a whole new experience for me. While being a Scrum Master, I also have to be a full-stack developer and dev ops engineer in the project.

How do I implement the Scrum of Scrums?

With the other team’s Scrum Master, the first thing that we did was discussing how to utilize the GitLab’s features for the project management systems. We also made some new rules and conventions to make our development process synchronized. Based on the GitLab blogs that we read, we decided to utilize the groups, projects, milestones, labels, epics, and issue boards on our GitLab repository.

In the GitLab, Industri Pilar itself is a group that consists of 3 projects that are the mobile project, backend project, and web (frontend) project. Each project has their own repository, settings, boards, and so on. To synchronize the 3 projects, we defined the rules and conventions on the group level, so all of the projects inside the group will have the same rules and conventions.

The next thing that we did was we created the “Sprint 2” milestone. This milestone could show us how our sprint was going in the burndown chart. We also added the Sprint’s timeline in the description box.

After that, we created the labels that we would need in the development process. We split the labels into 3 functions: for labelling the phase, for labelling the team, and for labelling the issue type. For the phase labels, we used 3 different phases: to-do, doing, and on review. These phases showed us whether the issue is a to-do, is currently being developed by someone, or waiting to be reviewed by others. For the team labels, they showed us which team is responsible for that particular issue. The last one is the type labels that show us whether the issue is a new feature or bug.

The next thing that we created was the epics. Taken from the GitLab blogs, epic is a collection of user stories that describe a larger user flow, typically consisting of multiple features. Epics contain a title and description, much like an issue, and allow us to attach multiple child issues to indicate hierarchy. We defined one epic as a PBI that contains several issues and tasks. In each epic, there is a business value, a user story, and some acceptance criteria. We could also link the related issues to the specific epics.

After that, based on the epics that we created, we split the epic into several issues with the detailed information about the problem description, tasks, assignee, labels, deadline, related epic and milestone. Later we could assign each team member to their issues so they can start working on the issues with the given information. After they implemented the solution to the issue, they could create the merge request that automatically closed the issue if the code was merged. This automation helps us to manage the issues properly.

With some setup and settings, we could utilize the GitLab’s features to help the project management. As we can see, here in the issue board we could watch the progress of each issue. That’s all from me, I hope this blog could help you to manage the projects that use Scrum of Scrums methodology.