When is the Best Time To Split My Scrum Dev Team?
There comes a time when it makes sense to split your scrum dev team. This happens as a company wants to create efficiency in the workplace. When a scrum team is too large, productivity declines as team members will tend to be counterproductive and step on each other’s toes. As the number of individuals grows, natural subgroups will start to form, but compared to proactively solving the problem, these natural subgroups don’t hold the same value.
The length and the order of daily meetings is a valid indicator of when your scrum team is too large. It’s important to save valuable time by conducting meetings with information that is applicable to everyone in participation. When a scrum team starts to have meetings with various instructions for multiple different people, you will find that your team is too large. A split is often recommended once you’ve hit 7-8 people.
Once you have decided that your team is in need of a split, the question arises of
“How should I effectively split my scrum dev team?” Zibtek uses a practical agile style process with three fundamental steps.
Steps to Split Your Scrum Dev Team:
Step 1: Create Maturity Metrics
The first step to take when splitting your software engineering team is to analyze the performance of each team member. In this process, you will rate each individual on a scale of 1-5 in each area of expertise, 1 being the weakest area, and 5 being phenomenal or an expert in that specific skill.
It’s important that the scoring scale isn’t too large because it will oftentimes be difficult to determine a specific score when given a wide range. For example, the brain will provide a less accurate score with a range of 10 because our brains analyze better on smaller scales.
The skills that you decide to evaluate fully depends on the requirements for your project. Some of the skill sets that we have found beneficial to assess in a typical web project are MongoDB, Angular, Node, UI, and communication.
It’s crucial to take the time to individually evaluate each engineer and all of his/her skill sets. This process of scoring each team member for the multiple different areas of expertise is what Zibtek calls creating “maturity metrics”.
Through developing maturity metrics, and assessing the strengths and weaknesses that each team member exemplifies, it will be clear to identify which skill sets you can utilize for each team. After this step, it will become more direct as to how to begin setting up efficient and versatile teams.
How maturity metrics can help a career path for an engineer:
Not only can maturity metrics play a role in diverging a sizable, counterproductive team, but it can also assist the engineer in finding a career path, as well as motivating themselves to improve in certain skill sets. Through the visual representation of being “scored” on a variety of skills, it will be apparent what to work on and strive towards. This process of creating maturity metrics is ultimately training goal-oriented, driven coders.
Splitting Your Scrum Development Team
Step 2: Arrange The Teams
Now that each member of the scrum development team has been evaluated and scored, it is time to start arranging teams. The goal is to construct a team that has high scoring engineers for each skill, as well as teams that have a similar total when adding up all of the maturity metrics.
By balancing the variety of skill sets amongst multiple different teams, the company will find itself to be more efficient as each team will be able to approach all aspects of the project, instead of simply specializing in one skill. The most efficient way to begin this process is to place all of the names and scores in a spreadsheet, as this image depicts.
This spreadsheet will provide a clear depiction of which team needs which skill set. With the numbers being visually placed in a systematic format, it’s a convenient way to hypothesize which engineers’ skills will complement each other. This process is solely data-driven, which may seem as though there should be no room for error, but there are often other factors that come into play which is the reasoning for the third step of this process.
Step 3: Consider Other Factors
The final step of this process is to take into consideration all of the other factors that could result in a successful team. Oftentimes certain personalities or situations can play a role in the efficiency of the group. There may be certain scenarios, such as engineers who rely on each other for questions or advice as well as personalities that clash. All of which could play a role while choosing how to split the team. It is vital to maintain or create a strong work environment, especially during this time of change when the team is dividing.
Although this whole procedure initially started with using data and numbers, it is key to finish the system by incorporating human interactions and emotions. You want the engineers to have positive experiences with the people they work with. Ultimately, this final step is integral to the whole process because it’s the key component of transforming this procedure into a practical agile approach.
How does this process fit into Zibtek’s practical agile style?
Through this unique process, it is apparent how Zibtek incorporates this practical agile method into every aspect of the company. The style is used not only with customer relations but also amongst the company to create a positive working environment. We have found that including employee needs in our data-driven process results in the most productive progression.
This procedure taken to split the team follows along with a phrase in the Agile Manifesto that states, “Individuals and interactions over processes and tools”. We have implemented this phrase into the actions we have taken to divide teams, but we have not taken it to an extreme. Our process doesn’t solely rely on the friendships within the company or the situations employees find themselves in. As a company, we have made an effort to divide our team systematically through maturity metrics, but also incorporating agile methods, thus resulting in a practical agile approach.