Distributed development. MS-1 Experience (Wargaming)

How distributed project work is built in the MS-1 mobile development studio (Wargaming), — in his column on App2Top.ru told Vadim Gilvarg, program manager of World of Tanks Blitz.

World of Tanks Blitz

About me

My name is Vadim. In the studio, I am responsible for the composition of the development team, hiring and developing project managers, and helping the team leaders of the teams working on the project develop. In general, I am responsible for the entire procedural part within the project, for how the project is done.

Vadim Gilvarg

Before MS-1, I was engaged in casual games, and also worked in an outsourcing company, where I developed projects for the needs of customers (mobile applications, websites, etc.). I initially joined the World of Tanks Blitz team as a project manager, scrum master. Here he was engaged in the development of camouflage for tanks, game modes, in-game events and other functionality.

About the team

Today, the MS-1 studio employs more than 360 people. We are developing World of Tanks Blitz, as well as the mobile shipboard online action game World of Warships Blitz. In addition, today we have two Unreal Engine projects in development in the shooter and action genres.

Our team is distributed among 5 offices — in Minsk, Moscow (mobile “Tanks” are mainly being developed here), Shanghai (World of Warships Blitz is being worked on here), Berlin, and most recently we opened a new office in Vilnius, where new projects are mainly being developed.

Roadmap as a live tool

So, distributed development. Even before the pandemic, we were able to try out some practices and implement them in our work.

So, our team does not form and approve a detailed roadmap, which we blindly follow throughout the year. Our roadmap is a living tool that can change literally every day. We practice an Agile approach and believe that it is at least impractical to plan for a year ahead in a rapidly developing industry: this entails a large number of missed opportunities and an untimely reaction to market changes. It also does not give flexibility in terms of responding to positive or negative feedback on some previously released features.

For example, we are releasing some kind of feature that shows itself very well. It is quite possible that after looking at the analytics, we will decide in the near future to focus on strengthening and developing the success of this particular feature, and not on something else that was originally planned. Conversely, if a feature has shown itself negatively, it is quite possible that similar features should be reviewed — replace them with something else that our users will like more. Thus, the feedback we receive from our users greatly affects how we will fill the project in the future.

Backlog as a basis

The basis of our development is a grocery backlog. To create it, we use an online platform that every studio employee has access to. At any time, you can go into it, see the release dates, the plans of each team for any of the next planned versions, follow the direct links and check the status of tasks, i.e. understand what we are planning and at what stage the development is.

One of the important processes is the mechanism of getting features into this backlog. To do this, we use a special tool, the so—called backlog of ideas – a large list that can be replenished by any member of the team. After passing the review stage, the proposed idea, if it is really worthy, can get to the very top of our product backlog, and one of our teams will be able to take it into development.

In addition to the backlog of ideas, we have a backlog of features, where there are ideas that seemed promising to us and that we would like to show to users in the near future. If a situation suddenly comes when our feature backlog turns out to be empty, we can always go back to the ideas backlog and take something most interesting from there.

Our toolkit

We use channels in Slack to communicate. Some of them have rules of use: this means that only certain things can be written in them in a certain format. Others do not have any rules – the current status of work, the exchange of data necessary for development, etc. can be discussed here.

Naturally, when we introduced Slack, there was not such a large set of channels, we worked them out gradually — some were removed, some were added. Today we have a certain set of channels that allows our team to communicate effectively, so a new employee will be able to quickly understand in which of the channels you can ask a question in order to get the necessary information.

Inter-team distribution

We conditionally divided our product into semantic units, which we called systems. There are more than a hundred of them in total. The systems are distributed among the product owners, each with about a dozen such systems. And in turn, for product owners, these systems are distributed between two or three development teams.

For example, we have an idea to make some kind of feature. After it passes the review and rises to the very top of the backlog, we look at which system it belongs to. For example, to the system of training players, therefore, this feature goes to the development of the product owner, who is in charge of this system. And he, in turn, distributes the feature between the teams.

Our custom framework

We share the values of Agile and over the years have formed an understanding that Scrum is a very convenient and useful thing. However, being an excellent tool for one team, it was poorly suited for coordinating the work of 15-20 teams.

We started thinking about how to adapt this framework, which is quite convenient and effective, in our opinion, to our own needs. It turned out that in parallel with us, other companies around the world began to face the same problem, and as a result, scaled Scrum frameworks began to appear: LeSS, SAFe, Nexus and the like.

While working on our own solution, we came up with some practices ourselves, borrowed some from existing frameworks. As a result, we got our own scaled Agile framework. By the time we formed it and started working on it, the team of Jeffrey Sutherland, one of the authors of the Agile Manifesto and Scrum, released their Scrum@Scale framework, which turned out to be very similar to what we created ourselves.

In short, we do not use ready-made tools, but monitor what is happening in the Scrum alliance, look for interesting frameworks and methodologies that are not related to Agile, as well as development approaches used in companies around the world, and choose interesting techniques that could be useful and effective for us, then we introduce them into our development process.

We consider the basic Scrum ceremonies to be very correct tools, as they allow the whole team to look in one direction. Daily Stand-Up, Sprint Planning, Sprint Review and Sprint Retrospective are the four main Scrum ceremonies scaled to the development level of each new version of our game.

We have planning for each version, during which the product managers of each team declare some set of features for the version and commit to deliver it at the end of the development of this version. We also have a Version Demo — this is an analogue of Sprint Review, during which teams demonstrate functionality, show developed features and take feedback. At this event, the integrity of what has been done is evaluated, as well as opinions are expressed whether it will be interesting to our users.

In addition, we are holding a retrospective. On it, we select the key points that marked the development of this version. This allows us to identify problems that were made due to the fact that we did not have an appropriate process that allows a structured approach to solving certain issues. And so we gather after each version — we identify the key successes and difficulties that we had to face, as well as set plans for the future.

Thus, we have Scrum ceremonies at the feature team level and scaled scrum ceremonies at the project team level. This allows us not to lose focus, not to forget that we are not each working on our own feature, but we are making one big game.

Communication language

We have quite a lot of people in our team who do not speak Russian. Naturally, we use English to communicate with them — besides, a large number of people from other countries who are native speakers of different languages work in the MS-1 studio. Therefore, English, which is known by most people working in our industry, is a very convenient communication tool.

Conversely, a person who does not know English can also work in MS-1, we will just try to find him a team in which English is not much in demand and where the intersection with English speakers is not significant. But at the same time, we will try to teach him as quickly as possible, for which it is planned to attend language courses. As a rule, even people who know little English, coming to our team, gradually improve their level.

Communication first of all

We regularly conduct so-called teams health checks, during which team managers monitor the state of the team, its motivation, the convenience of tools, etc. They have become especially useful on the remote. One of the criteria in this monitoring is the fan. Unfortunately, we have to admit that the fan indicators have now sunk, the feeling of team unity has also decreased.

Therefore, we focused on looking for alternatives to live communication in the office. And our managers started offering a lot of activities. For example, spending time together playing online games. The manager can also conduct full-fledged team building activities, online quizzes, meetings. Sometimes people themselves gather on a Friday evening with a cup of tea or a glass of beer and talk about abstract topics, as if they were doing it in a bar.

We use voice chats, which allows us to emulate the situation of being in a room. This is not an exchange of technical information or the transfer of working materials, but only a repetition of the moment in which you, sitting at a desk in the office, can raise your head and say: “Oh, guys, do you want to tell me a funny case that happened to me yesterday?” or “Has anyone encountered such a problem?” This does not require opening Slack, searching for the appropriate channel, or describing the problem. You just raise your head and ask: “Has anyone done this before?” And in response to him: “Yes, I had such a case, go show me.” Thanks to the use of such tools, we managed not to lose the spirit of collective creativity, which allows our teams to brainstorm together, refine their features.

Therefore, for those teams that have similar approaches to development and are trying to unlock the potential of their entire team, I would advise paying attention to the ease of communication. Small and not directly related to making money for business activities are extremely important. They are the foundation on which the effectiveness of the team stands, its productivity, motivation and desire to make the product better.