What do team development and Scrum of Scrums have in common? They deal with the growth and optimization of teams. Basically, before I scale agile methods, the team should be optimally developed. You can see when a team is optimally developed here or in our blog article.
What is Scrum of Scrums?
Scrum of Scrums is especially successful when all Scrum team members work towards a common goal, trust each other, respect each other, and work well together. This requires team development beforehand.
You may know the phrase
"Small enough to remain nimble and large enough to complete significant work within a sprint"
So when is the right time to scale? What is the optimal team size and what do you need to consider when developing a team?
Before we go any deeper, a quick note. We recently had 11 international senior agile practitioners as guests in one of our webinars, asking one question: How do you scale agile methods the right way?
The result of this is the following fantastic video recording that answers some of the key questions when scaling agile, for example:
- Should you start your agile transformation rather bottom-up or top-down?
- How do you align leadership on a common goal and vision?
- How do you choose the right agile framework – and why is that actually not that important?
My recommendation: take a look! The video is rather long, but every single minute is worth it.
First, the history of Scrum of Scrums
Jeff Sutherland and Ken Schwaber were looking for a method to make working agile with several teams possible. It was important that not everyone works for themselves, but that all work together in a coordinated way. It acted as a milestone in agile development. Jeff Sutherland also wrote the book "Agile Can Scale: Inventing and Reinventing SCRUM in Five Companies", which was published in 2001.
Scrum of Scrums and the scalability of agile methods have been gaining more and more acceptance since then. However, it can be said that the COVID-19 pandemic probably gave the biggest push to agile development - at least for its application in areas other than software development. In principle, agile methods can always be applied when requirements and technologies are complex. The Stacey matrix and the Cynefin framework will help you classify them. In the Scrum @ Scale Guide , you can find all information about scaling.
As a tip: you should only scale when your individual team is working well together and functioning as a whole. If you are already struggling with Scrum at the individual team level, then you should not scale either. Develop the team first and address their issues before you start scaling.
Purpose of Scrum of Scrums
Scrum of Scrum is the first logical extension of Scrum when moving from agility in a team towards agility of a whole company. A key requirement for scaling is the right team composition. The following questions should be answered:
- Who works in what position on the team?
- Who works together with whom?
- Who harmonizes particularly well together?
- Who has which role?
We have found that role clarity plays a very crucial role. By the way: If you want to know with which levers you can create innovation in a team, watch this video . Teams also always need enough time and space to evolve. You can also check out Tuckman's phase model for team development here:
- Forming (entry and discovery phase),
- Storming (dispute and argument phase),
- Norming (regulation and agreement phase) and
- Performing (work and performance phase).
The goal is to coordinate smaller, nimble and autonomous teams that are fully focused on customer needs and wants. You can also take a more detailed look at the topic of customer centricity here That's why you should get into your customer's customer journey pretty early at any time. Just be your customer and start a change of perspective. In practice, customers unfortunately still quite often have to adapt to the processes of the collaborating company. Especially in public authorities, but also in some larger companies or corporations. However, this is not the idea of Scrum.
"Growth" does not equal "scaling"
Dominic Price writes in"Unlearning these five fallacies will make you more innovative"about the 5 fallacies you should break away from to become more innovative:
- Growth" does not equal "scaling"
- "Transformation" does not equal "evolution"
- "Disrupting" does not equal "disrupted"
- "Tenure" does not equal "initiative"
- "Outputs" do not equal "outcomes"
In summary, efficiency is good, but effectiveness is better. Therefore, always pay attention to effectiveness.
From experience we can say: the more people work on the same problem, the more difficult it is to come to a solution. Especially if they are cross-functional and autonomous team members. However, the solution for teams getting bigger is scaling. The Scrum guide provides a foundation for teams and companies that need support in this area. Scaling Scrum beyond individual teams, however, requires a different approach - the Scrum of Scrums technique(SoS-technique)).
Source: RFC professionals
Structure and process of Scrum of Scrums
Scrum of Scrums team structure
Communication is the be-all and end-all in the agile world. It is the key to success. Communication channels can quickly suffer the larger the team is. Information arrives incorrectly or not at all. Sooner or later, this also affects the trust in the team, where there is a lack of closeness and it becomes more challenging to pursue a common goal.
The goal is to develop the team in such a way that all obstacles are removed (Scrum Master) and it works in flow In theory, a "perfect team" with optimal performance consists of 4.6 people according to Hackman and Vidmar's research. Teams that are too small might not be sufficient to solve a problem. In turn, when teams are too large, personal relationships and quickness with respect to the customer's ability to act and interests suffer.
In some cases, it is required to split the team. But beware, there are some things to consider here. You are interfering with an already established system. Competencies between the teams should be distributed in a balanced way, functioning interfaces have to be redefined and tasks have to be redistributed or redefined. Unexpected dependencies and newly emerging bottlenecks can delay the process as a whole here. Again, it is important to communicate openly and give the team time and space. Patience and adjusting in the right places is also very important.
The Scrum of Scrums technique requires coordination when multiple teams are formed. The following diagram shows one possibility:
Other roles in the Scrum of Scrums
The Chief Product Owner: The Chief Product Owner is responsible for the overall vision of the product. He prioritizes the product backlog and is the interface and mouthpiece to the customer.
The Scrum of Scrums Master: He permanently contributes to a higher efficiency of Scrum of Scrums. He focuses on progress and obstacles that are visible to other teams, empowers and supports the team in accomplishing their tasks. He is also called Servant Leader .
Scrum of Scrums meeting
Team members designate one person to attend the Scrum of Scrums meeting on behalf of the Scrum team. Depending on where the focus is within the project, the team can always designate a different representative. Usually, the person closest to the topic is designated. If the focus is on user experience, a representative should be sent who is knowledgeable about that. If the focus is on testing, the representative should be from testing. In some cases, if the SoS team becomes too small, it may be advisable to have two representatives per team to attend the meeting. Often the Scrum Master then accompanies the person designated by the team. When the work of the Scrum of Scrums meetings is coordinated in a meeting at a higher level, it is called a Scrum of Scrum of Scrums meeting.
Frequency and timebox of Scrum of Scrum meetings
The team determines the frequency of the Scrum of Scrums meeting. For the sake of simplicity, one usually sticks to the specifications of the dailies, which take place daily and usually last max. 15 minutes..
Depending on the size and number of teams, however, these are more often longer meetings that do not take place so frequently, for example 2 to 3 times a week. In contrast to the daily meeting, problems that arise in the Scrum of Scrums meeting are solved directly if possible or at least addressed. Problems that arise in this meeting are very significant problems and can quickly affect more than 100 people.
Agenda for the Scrum of Scrums meeting
A good agenda for a Scrum of Scrums meeting is very similar to the agenda of a Daily Scrum. Since the Scrum of Scrums meeting does not take place every day in practice and since each person represents their whole team in the meeting, the questions are answered in a slightly modified way:
- What has your team accomplished since we last met?
- What will your team have accomplished by the next meeting?
- Are there any obstacles that are making the team's work difficult?
- Could anything your team does get in the way of another team?
The last question here deals a lot with process and the potential impact on other teams. Addressing this question can be very helpful. It considers several scenarios in advance to create a smooth collaboration. This is where silo thinking is virtually broken down. The answer to the last question is particularly important, because it is imperative that representatives pass on the findings to their own teams.
In addition to answering the questions, the meeting also provides the time and space to discuss and address any issues, problems or challenges that have arisen previously. In the meeting, progress is documented and a common understanding is created. Solutions and actions are recorded so they can be tracked.
In order to remain on a factual and neutral basis in the meeting, no names are mentioned in discussions. The length of the topics is also clearly outlined from the importance of the topics. The goal is to create an objective view from the meta level, but still change perspectives.
So Scrum of Scrums is a great way to scale if you already work with Scrum and want to develop towards corporate agility. If you want to learn more about how to evaluate the Scrum Master Performance, have a look at this article right now.
Scrum of Scrums and SAFe - two different concepts
Scrum of Scrums, SAFe and LeSS are all different frameworks to scale agile, with different approaches to implement leadership and build a roadmap. If you want to learn more about the other concepts, I highly recommend checking out our blog posts on SAFe and LeSS. SAFe and LeSS to read.
By the way, if you want to avoid the 7 biggest mistakes organizations make when scaling agile methods I highly recommend to have a look at Project Scagile, right now.
Within Project Scagile, you will get the secret best practices of 11 senior agile practitioners from their agile transformations in a video format. I highly recommend to check it out!