Blood, sweat and mini-teams. How and why did Belka Games change the structure of the project

How, during the change in the structure of the Belka Games teams, it was possible to increase the frequency of the release of updates and set two records for daily revenue, — said Vitaly Kuzmin, director of development of the company.

Vitaly Kuzmin

It has been almost two years since we decided on a bold experiment to rebuild the team of the “Watchmaker“. From the functional division, we moved on to the fashionable, somewhat mystical, completely incomprehensible, but such an alluring structure of mini-teams.

Obviously, each structure has its pros and cons. Some of them can perfectly take root in one company, but in another it will not take off. This note is an attempt to take a look at all the way to mini—teams, gather all our experience together and present it to colleagues. We will be glad if something is useful to you. If you decide to share your experience, it will be absolutely wonderful.

The problems that pushed us to this decision

Let’s go back two years ago. Then we used the good old functional structure.

We are talking about a structure in which project development is distributed among functional departments (for example, between testing departments, development departments, game design departments, and so on). Each department had its own functional lead. Their work was coordinated by project managers, and the producer was in charge of the latter (as well as the fate of the project).

At that time, we were just transferring the “Watchmaker” to a new engine. The course of development was fixed in the roadmap. Of course, we wanted to provide for everything, but the project was eight years old at that time and it had accumulated a decent legacy, so we often had unforeseen tasks. As a result, the scope of versions grew, the release dates dispersed, and PM’s turned gray before our eyes.

As a result — and as the cherry on the cake of this chaos — the key feature of the update was developed longer than planned, and in addition was redone several times on the fly.

The analysis of the situation revealed that the weak point in our case was the existing development structure. She had two key disadvantages, which pushed us to the transformation:

“Bottle necks”. During the operation, the team has grown to 60+ people. Its size did not allow PM-am, producer and functional leads to work effectively. The number of tasks per lead significantly exceeded its capabilities, so we had problems for a long time where we needed to get an appruv from management.
Different staff members worked on different features each time. There was no such cohesion as in the teams that worked together.

Surprisingly, even under these conditions, the project continued to grow steadily in revenue. Success to some extent lulled our vigilance and forced us to close our eyes to acute and obvious problems (as we consider them now and as they, alas, did not seem to us then).

The higher you fly, the more painful it will be to fall. In our case, the end of the first wave of the pandemic has come. Revenue began to adjust, but the problems did not disappear. The developing conjuncture insinuated to us that changes were needed.

The solution, or Vive la révolution!

And in the market at this time, our competitors released updates every month and stimulated the growth of financial indicators, literally stuffing projects with fresh content.

We decided to participate in this rally too. The goal was clear. It was also clear that with the current structure, achieving it was an almost impossible task.

As a future desired structure, we settled on mini-teams.

In many ways, of course, they were inspired by Spotify‘s sensational approach. In short, they divided the team into autonomous squads, small cross-functional self-organized teams of eight people (or less) who sit together and are responsible for the feature they do at all stages (including its support and operation). More information about the approach can be found here.

By the time we took up conceptualization, the approach had its drawbacks, so we moved away from it quite far. Considering that Spotify itself did not use its own structure, we acted sensibly.

When we had our first understanding of the future structure, we recorded it in a presentation for the CEO.

In its framework, we also explained how the transition to a new structure will solve our problems.

The elimination of “bottlenecks” in the face of PM’s and functional leads is solved by the introduction of a team leader in each team, who takes over the entire operating system (maintaining weekly plans, creating and distributing tasks, one-on-one meetings with employees).
We have to get rid of the “bottleneck” in the person of the producer by introducing a feature designer into each team (in fact, a game designer who can make product decisions and leads the feature from concept to release in the prod).
To get cohesive teams, we assign employees to a specific mini-team, usually working together on new features.
To develop the independence of mini-teams, we encourage decision-making and any initiative within them.
In order to better understand the team’s capacity and better configure work on priorities, we set the desired pace of updates (at least once a month).

The main catch was that mini-teams were conceived as autonomous and self-sufficient business units. They should have exactly such a number of specialists of all roles, so that they do not have to borrow them from other teams when working on their own feature. And this meant that we had to seriously expand the staff.

We had to prepare reinforced concrete arguments — and understand how to adapt the model with the lowest costs. I’ll run ahead a bit and say that not all teams are 100% staffed, as originally intended. But we have come to a kind of hybrid structure in which we share unloaded resources in a Slack chat. Requests for specialists in it are left by the team leaders of mini-teams.

A short pitch from the CEO, a series of questions and a green light from the head in our pocket. We begin to act.

Mini-teams in our reading

For ourselves, we consider mini-teams to be self-sufficient and (almost) autonomous business units, each of which has a clear specialization and responsibility for a piece in the general scope of the upcoming update. They are self-sufficient, because with their composition they can lead the feature from the idea to the release in the prod. As a rule, the team consists of:

game designer (aka feature-owner, who is responsible for documentation and ensuring that the vision of the feature does not fall into pieces during development);
developers;
artists and UI designers;
animator;
tester.

Each team is led by a team leader. He fully facilitates the development process, and also takes over people management: one-on-one meetings, goals, development plans.

It is also necessary to lead managers, so there is a project manager above the team leaders in the structure. He is responsible for coordinating the work of team leaders, puts together an update from the puzzle elements supplied by mini-teams, and monitors the deadlines for its implementation.

We have divided the mini-teams into three areas of responsibility.

Implementation of bold key features. Major grocery increment, as a rule, are temporary events with new game mechanics.
Operating an existing arsenal of events with old, proven game mechanics.
Work on the technical part. As a rule, it is not related to business logic and is hidden “under the hood”, but it is no less important for the product.

There were also teams formed on a functional basis. For example, narrative designers are not assigned to “feature” mini-teams and connect to them only as needed, because there is no full-time employment in these teams for them.

Functional managers have not gone anywhere. They have gained a proud title of “experts” and are outside the structure of mini-teams. Their main task is to improve the quality of work of specialists in their profile. In other words, the lead developer reviews the developers’ code, the lead UI designer looks at the layouts and makes edits, the lead QA monitors the completeness of test cases, and so on. So that they can fully engage in the development of specialists, we tried to free them from the operating system as much as possible, so the team leaders are engaged in tasks in the task tracker and their distribution.

Below is a diagram of our organizational structure.

We don’t implement mini-teams on every project. The main criterion here is the number of employees. In our opinion, it makes sense to introduce mini-teams if the total number of the team exceeds 50-60 people. In other cases, we keep the functional structure.

Keep in mind: it will not be so easy to sell the whole idea to the team. We are just people, so we really like to resist changes and actively cut down everything that goes against the usual state of affairs. We have held more than one meeting explaining in detail the value of innovations and declaring the goals we pursue. Someone got the idea, someone still perceives it with hostility. Here you can give some tips.

First, enlist the support of team leaders and experts, make them your allies. It will be much easier to sell an idea to line employees through opinion leaders.
Be honest with the team. We have openly said that this is a big experiment for us, and it may well be unsuccessful. We did not rule out the possibility of a “rollback” to the previous structure and discussed it with the team.
Make it clear that the structure is not “nailed down” and rotation of specialists between teams is possible. This is important for employees who do not want to get bogged down in the same type of tasks.

An important nuance

There is an important nuance that helped the whole scheme with mini-teams to earn in full force and closed our needs for the frequency of releases. We call it “parallel development” or “overlapping development”.

The bottom line is that the Alpha mini-team is working on update number 1, and the Bravo mini-team is working on update number 2 at the same time. At the same time, they do not compete for resources and do not overlap in tasks, since each team makes its own feature. The full development cycle of such a turnkey feature takes two to three months on average. Having started development at the right points, we managed to reach the frequency of releases every one and a half to two months.

Weaknesses and problems of mini-teams

Of course, every system has drawbacks, and the one we designed is no exception. Let’s go through the main ones.

Large “transaction costs”. Each mini-team should have synchronization points for coordinated work and understanding what it is going to and at what stage it is. Our teams synchronize via Slack chat, Asana project and Google Meet meetings. Just the number of such meetings is a sore point. We started with such a set:

the general call of all team leaders and experts on Monday morning;
fifteen-minute videos with the team every working day (Monday to Friday);
summing up and planning on Friday evening.

Over time, the mini-teams became more and more independent, so we began to hold daily meetings three times a week — on Monday, Wednesday and Friday. In some teams, they tried to “collapse” dailies on Fridays and planning in one meeting. Well, the experts were allowed to visit the daily and planning in an optional mode (if they are invited personally or they themselves consider it necessary to raise some important issue).

The need to write TK for two or three updates ahead. If this is not done, then the team will simply have nothing to do. Ideally, the team should coherently and clearly mint releases one after another. For example, by the time UI specialists have finished designing feature “A”, the technical specification for feature “B” must be approved by the producer.

Did it work out for us? Again, not fully. But we believe that we have made a lot of progress in this regard. The current planning horizon for the project is six months. This means that we know what features we will be doing in the next six months, and there is a ready-made TOR for each of them.

Lack of flexibility. Firstly, it is difficult to rebuild plans with continuous production, when a feature is made for features. Mobile gaming is a fickle environment, and sometimes it was necessary to abandon a half—finished feature if faith in it disappeared or a better feature idea came up. Secondly, some features did not “shoot” the first time and required serious improvements. We tried to give these improvements to the team that originally made the feature, since it is she who has the highest expertise and the lowest entry threshold. Since the teams alternate releases, sometimes we had to wait two or three months for improvements, and all this time one producer was sad somewhere.

Let’s talk about the pros

Above, we have already highlighted the vulnerabilities of the old functional structure: leads, PM’s and producers were overloaded with tasks, teams did not work, processes slowed down. In the new one, we hoped to rally the teams, reach a stable pace of releases and unload leads and management, where possible. Let’s discuss what we have come to in order.

Harmony. Our mini-teams have a permanent staff, and thanks to this, internal processes are honed. The animator always knows in what form it is better to transfer animations to the programmer. The programmer, in turn, prepares the base for the animator in advance. Thanks to the harmony, it is much less necessary to find out something and get distracted: integration happens on the fly.

Engagement. Even in large companies, when expanding the staff, it is more difficult for employees to realize their influence on the product and contribution to the common cause. When you have 20 testers in the department, it is more difficult to realize that you are doing something important and useful for the sake of a global goal, and many people just start “working the job”. In the mini-team, the sense of purpose returns: the department has clear KPIs, the work of one directly affects the work of the others, and thanks to this, everyone is maximally involved in the process.

There are fewer bottle necks. Now all operational tasks are distributed to teams through team leaders. Functional leads have ceased to be bottlenecks — and moreover, now they have more time to improve processes and develop employees in their field.

Releases — more often. Each team works on its own task list independently of each other, their areas of responsibility do not overlap. By the deadline, each team gives its own features, and thanks to this, the builds go into release in a timely manner.

Results

Have we achieved our goals? Definitely, yes. The transition to a new structure, coupled with other changes, helped the mature “Watchmaker” to find his new financial potential. Largely due to the more frequent deliveries of new content to the prod. Recall that from a longer development cycle, we came to updates every one and a half to two months. As a result, we “broke” the daily revenue ceiling twice and set historical records for it.

Are mini-teams a panacea, a solution to all problems? Definitely not. For mature teams, the transition will definitely be painful. And, of course, it must be justified: you must clearly understand what problems you are solving. If there is an established organizational structure that allows you to solve your business problems, think 10 times before “loosening” it.

We decided for ourselves that the scheme is working, and at the moment we are trying to implement it on another project — adopting the experience of the pioneers, applying successful practices, but twisting them and adapting them to the current reality.