Creating Effective Scrum Teams: Guide How To Split Teams
Diving into the dynamics of Scrum teams, we’ll explore the profound impact of team size and the transformative benefits of strategic team splitting.
In Insider, we had a scrum team structured with 17 people in a scrum team. When we first started to support and came to the team, we were greeted by a complex environment. To list the main ones in this complexity: Communication difficulties, coordination difficulties, and loss of time in decision making It was very difficult for us to be a team in scrum events.
Some Problems We Are Experiencing
To elaborate on these communication difficulties a bit;
- When talking about a common topic together, the topic gets distracted due to the large number of people.
- It becomes extremely difficult to set a schedule that suits everyone to align
- Different ideas may come from each person and decision making is difficult.
- Alignment cost during the sprint.
- Following up on the work done
- The entire team with affiliated teams is not aware of the situations
Moreover, when looked at from another perspective, we were experiencing team focus problems, lack of ownership, and productivity losses. The team was dealing with 5 different Key Results at the same time. Everyone was working on completely different things in completely different jobs, and it became meaningless to align. Choosing a sprint goal in planning and directing the team towards it was extremely difficult. Scrum Dailys cannot be done within 15 minutes, and when they are done within 15 minutes, most of the team members cannot contribute. On the other hand, the problem it created was that the team could not deliver the Key Results to the target because they tried to do 5 main tasks at the same time, which caused a negative atmosphere on the partner side. It would not be wrong to say that it also destroyed the morale of the scrum team.
First, we tried to overcome this issue by getting fewer Key Results. The first thing this would solve was to allow the team to work more focused. We tried this for 2 sprints. We were partially successful. We were able to achieve our goals as a team and achieve results. But why do I say partially? Because the daily routines within the team still cannot be done on time, the goal of the sprint goal cannot be discussed and embraced by everyone. Communication difficulties continued to be experienced. If I were to show you this with a diagram;
As you can see, the diagram tells us this. While 3 people can only communicate with 3 different combinations when communicating among themselves, when this number increases to 14, it leads to 91 different combinations of communication lines.
Moreover, in our case, this number was 17. Naturally, it was becoming difficult to make alignment and make decisions in this crowded team. In retros, it was quite difficult to create action items with such a crowded team. Either you cannot get everyone’s opinion on a subject, or those people were holding themselves back from giving feedback, saying that whatever I said would take too long to catch up. In light of these, team ownership had not yet reached a sufficient level.
Creating interdependent teams
After considering all these, the team decided to split into two. However, this division would not be a correct division. Because this division would involve dividing the team into frontend and backend. The initial thought was as follows. Let two different teams do what they will do during 1 sprint and combine the tasks that will be completed at the end of the sprint. But when one team did the job first and the other team did it later, things started to take longer. It became necessary to do tests by repeating the same job. When a task could not be done, both teams failed. While it was intended to establish 2 independent teams, it actually became 2 teams that were completely dependent on each other. had arrived. As a result, the effort to establish 2 new effective teams turned into 2 inefficient teams.
This inefficient division situation was abandoned in a short time and the old crowded team situation was returned. But returning to this crowded team position could not solve the problems above. As a crowded team, the problems would continue. An additional situation here was that the team was not very keen on a division again. Problems were continuing, but the team didn’t know how to do it because there were bigger problems when they were divided. It had been committed once, and no one wanted it to happen again and again.
This situation could not continue forever. The problems were not solved. We could not organize effective scrum events. As the Scrum Master, I expressed that this situation could not continue like this during the retros and that the team had to make a new division by writing the problems I wrote above on the cards. I had 1–1 meetings with the people in the team. In fact, everyone was complaining about having a crowded team and wanted to split up. For this reason, I created a skill matrix based on my own observations. So, what is this skill matrix?
The Skills Matrix
The skills matrix is a table that helps you monitor and record the skills of team members. The skills matrix is a simple table with people’s names listed on one side and a selection of relevant skills in the top columns.
A number or a color at the intersection of each row and column indicates each individual’s skill level for that task. Below you can see an example of a skills matrix that uses both a color-coded and numbered system.
If you do not have enough insight to make a skills matrix in a team or if you have not spent time with the team, you can get opinions from leading people in the team and also get 360-degree feedback. After applying, you can also make an evaluation of the results. So what is 360-degree feedback?
360 Degree Feedback
360-degree feedback is the process of getting feedback from other people as well as an employee’s direct supervisor.
In typical employee evaluations, the boss rates the employee on a number of performance factors. The employee may have an opportunity to do a self-rating as well. The feedback is discussed, goals may or may not be set, and he or she lives to tell about another year with the company.
In contrast, with 360-degree feedback, the employee’s boss, team members, and other people who have regular contact with the person are asked to provide an anonymous evaluation of him. Some companies choose to have clients provide feedback ratings as well. These evaluations are compiled, and a full view of his performance is generated.
For example, some questions you can ask are:
- Attends all rituals and contributes actively (by sharing ideas, giving feedback and comments)
- Communicates with self-confidence and shares feedback
- Takes responsibility to get the committed things done
- Asks for team’s help without hesitation
- Contributes to the team’s success and produced value
New and Correct Division
Based on the skill matrix above, I talked to the people on the team. The expected situation was that the team would make decisions within itself, and that’s what happened. This time, the division was not frontend — backend, but a division that included every department. Developers, QA’s, frontend-backend developers 2 They were divided into separate teams equally and with equal knowledge. The important thing here is that we also made the work we did independently. The product backlog was separated from each other. Two different independent teams were created. This happened with the approval of all team members.
Benefits of Small Teams
We organized the split situation in the first planning meeting and immediately separated all scrum events. Of course, this had an immediate effect. Let’s explain these effects in headings.
Communication and Collaboration
While the normal number of people before the split was 17, suddenly turning into a compact team of 7 people showed immediate improvement in communication and collaboration. Scrum events started to take place in accordance with the timeline. The team created working areas together and started to support each other in solving problems together.
Here, an increase was observed in the number of times we reached the sprint goal goal. It was difficult to focus on one goal with a crowded team, and the whole team could not control and failed. After switching to small teams, we experienced an increase in reaching our sprint goal goals, and the team started to focus completely on the work done. Here, scrum. We observe that the focus and commitment values have visibly improved. Also, as written in the Scrum guide, “Everyone focuses on the work of the Sprint and the goals of the Scrum team.” and “People personally commit to achieving the goals of the Scrum team.” We have reached the situation.
Adaptation to change
During retro, the decision times for decisions were shortened. The whole team started to contribute. Everyone started to express their own opinion. If we were to change something or take action on an issue, action was taken immediately. While we could not make decisions on 1 issue, we have now reached the stage of being able to make decisions on multiple issues. Openness between team members is much better now.
Productivity increase
Since the focus of the teams is now on one key result as a target at the upper level, we have become a more focused team, confident and willing to do it ourselves. Here, we observed that the courage value, one of the scrum values and ownership, developed within the team and carried the key results to the finish one by one.
Customer satisfaction
The comments that came after we delivered the key results of the teams’ main goals to our partners one by one were very positive. We clearly explained what we did and our expectations in the reviews. They shared with us what they expected from now on and we shaped our backlog accordingly. We also see how it helps the transparency of the team.
Final note.
By harnessing the power of effective team splitting, we unlocked new potentials in Scrum dynamics, fostering improved communication, increased productivity and high customer satisfaction. Aim for 10 people or less, not a team of 17, and increase productivity.
If you like this article, we recommend you to read our OKR Refinement article and follow us on Insider Engineering Blog to read more about our Agile Best Practices, AWS solutions at scale, and engineering stories.
