Geekly Articles each Day
📜 ⬆️ ⬇️

The work of a large distributed team: the advantages of remoteness, problem solving, useful tools


Hello! My name is Aleksey, I am a Vimbox team leader (Skyeng training platform). Not so long ago, I spoke at a conference with a report on the remote work and features of a distributed team. Suddenly, many people became interested in the topic, although I thought that the HYIP had already passed and no one was surprised. Therefore, I decided to share with you the lessons learned during the four years of operation in this format. Since in our company of 55 developers, 51 people are constantly working outside the office, and I myself live in Kaliningrad, I think our experience can be useful to many.


What is the point of remote work, why not sit in the same office?


Remote work has two important advantages:



I note that we do not set goals to save on remote developers. We have all the salaries in Moscow - it cannot be otherwise, because the specialists are well aware of their value and are accustomed to receiving money corresponding to their skills.


How do you conduct interviews? When you can not see the person in person, shake hands?


Like this:



Remote interview has several advantages. The most important thing is comfort. No need to come to the office, to see strangers, to wait for someone on an uncomfortable couch. A man sits at home with a carpet and a cat, it relaxes, helps to establish contact. Comfortable and the interviewer: you can sometimes look at your notes, make notes, if necessary, turn off the microphone.


The second advantage is the ability to record video. For such clips is a lot of applications. First, you can consult if there are doubts: to give another team look, product, to make a joint decision. Secondly, we have a lot of food teams, and if I understand, for example, that a person is good, but he doesn’t have enough experience in the front end, I can throw a record to a backend team, which also needs people; they will not have to hold a separate conversation. The third thing that we are implementing now: if the person did not pass the probationary period, we review the interview, try to understand whether mistakes were made at the stage of employment, and whether we can correct them. Fourth: we are constantly trying to improve the interview process, so we selectively give records to other team leaders, discuss what can be improved.


And yes, before each conversation we warn the candidate about the recording, ask if it is possible to record and promise that the video will not go to the public.


How to trace that a person works remotely and does not sit on YouTube?


Answer: there is no need to follow. We need to hire motivated people who are willing to work. On our part, it is necessary to ensure transparency of workflows for both the developer and the team, team leader and product manager.


I'll start with the most basic: worklogs. There are three reasons why we must lead them in our company:


1 - in our opinion, this disciplines. When I fill out a worklog at the end of the day, I see what I have spent my time analyzing; I have the opportunity to understand what I am doing inefficiently. We want our developers to have the same habit;


2 - if during the sprint we see that much more time was spent on some task than planned, we always carry out an overspent retrospective to understand what happened and how we can correct the situation. There is no purpose to blame the developer - we need to find the cause of the error and improve planning;


3 - we have many teams, sometimes one team orders something else, and it needs to estimate the estimated and final cost of the work: see how much time is spent and multiply by the base rate;


There is also a bonus: I confess that during the trial period we make reviews of worklogs. This makes it possible to understand whether a responsible person is sufficient; This is not the only factor, but a lot can be seen from them. After the trial period, this is no longer going back.


Transparency has several important components: actual statuses, actual remaining estimates, actual backlog. Having provided all this, we get rid of endless questions from the team leader to the developer, from the product to the team leader, etc. from the series “when it will be done”, “how much is left” and “when on sale”. Everything can always be viewed in the task tracker.


Another tool to increase transparency is text stand-ups, which we hold along with video calls. Text, so that all the discussion was saved in the form of letters, it was not necessary to review the video and look for the right minute in it. If you missed such a stand-up, you can still write a report and see what your colleagues are doing.


Here is our scrum board:



I can say for sure that here all the statuses are actual and all the estimates are placed correctly, but readers immediately have a question: why is the empty code review column? Do not you do? We are doing it, but we have found a way to ensure quick passage of code review.


For challenging tasks, motivation is needed. When you need to do something completely simple - the code of the review, deploy, etc., - you just have to poke people. I used to do this before: I saw on the board that several tasks were stuck in the code review, and wrote in a slaka: now let's take it and do it. At some point I got tired of it, wrote a slab-bot over the weekend so that he would stick his wand at the developer. Every morning, the bot publishes a digest about what tasks are stuck in which statuses, and tags people who need to do something:



Here we see that one task is hung on the review code, two are ready for deployment, one is for testing, all the tasks are put down in the estimates. All messages are public, it is immediately clear from them what. Such a transparent system works: since they started, tasks have stopped hanging in statuses.


The bot is not only engaged in poking, but also reports news about our work: the status of the sprint, how much is completed, what progress, the estimation accuracy, publishes information about projects that are important for us. Here is a screenshot; then we were engaged in migration to Angulyar , the project was completed by 91%, you can see how many hours left:



We try to do this on all major interesting projects - for ourselves and for business, so that any colleague can see it.


But we also need to increase engagement - daily meetings, planning and retrospective, one-on-one, wimboxing and quarterly presentations (this is not really boring). Recently they started playing Counter-Strike, they first played inside the team, and the other day they beat marketing.


We have a tool that allows you to hold many online meetings, especially those that are held in the format of a brain storm. This is a standard retro board that many people use to conduct online retrospectives, but we went a little further and use it for other purposes.


Here is an example of our refactoring mitap:



In this case, the task of assessing the technical debt of the project is being solved. Previously, it was traditionally done by tmlid. He listed the weak points, said that they should be corrected, estimated the level of debt. Then I realized that we have a lot of repositories, a lot of code, and I cannot cope alone, because I do not work with all this volume directly. The idea came to make an assessment of the debt all together. In the screenshot, each column is one project. Every developer for a few days remembers all the crutches that he has ever met in him, all his claims to the code, and writes all this in the cards. Then we gather and discuss these cards one by one. Potential solutions are converted into tickets in Djir, then they are prioritized, in the end we have a prioritized list of tickets, which completely formalizes the entire technical duty of the team.


The second example is standard retrospectives on processes, task evaluation, they allow you to conveniently share feedback and prioritize tasks with the built-in voting tool, plus the history of retrospectives in one place.



Working in the office, I go to the smoking room and dining room, where I can talk, discuss, be aware of everything that is happening. But at home I am isolated, I see problems in the Jir, nothing is interesting to me. How to be?


Indeed, there is such a problem, but it seems to me that we have learned how to solve it. Now I will go from smaller ways of communications to big ones.


Let's start with tickets in Djir. We use standard Agile practice, with us almost all tickets are formulated not by tasks (what needs to be done), but by problems (user experience). This is important when working remotely. Here is an example of a fix:



When a developer takes this task, he does not just fix a button that does not work in IE11, he knows that there is a specific corporate client who is ready to pay 15 million rubles to work for him. He knows the context, it adds motivation, plus leads to the fact that often offered alternative, more effective solutions.


Next - the sprint. We plan the sprints with the whole team, it’s not only development, it’s still QA, analyst, product. The last one at the beginning of each iteration presents us all the product tasks, says what problem, how to solve it, what we will come to, how it will affect the users, protects its task before the team. Everyone knows what standard questions the product should answer: why do we do this task, is there an alternative solution, does this really help us? The whole team is in the context of where we are going in the next two weeks. Thus, we avoid simple distribution of tasks.


Quarterly plans: this is not as scary as it sounds; quarterly presentation lasts only 45 minutes, comes in the form of an interactive presentation, which prepares the product. There are video, polls, interviews, it allows the whole team to find out what we will do during the quarter or year. Sometimes in the framework of the sprint the whole picture of the project is not visible, the quarterly presentation allows you to evaluate how your little piece fits into the big story.


Recently introduced a new format - analytical stand-up. The developer cannot communicate directly with users, so we have our own analyst in the team, who once a week talks about all the news that has happened to our product: how the feedback has changed, how one feature or another has come, and what metrics we will improve in the near future. As a result, the whole team is aware of how our users behave, what is happening with them, how they react to our work.



Plans of other teams - each team publishes plans in the form of a beautiful presentation so that all neighbors are informed. These presentations can not be done in Excel, they should be done briefly, concisely, clearly and with pictures so that anyone can come in, look and understand who does what. This is often just interesting.


Well, finally - Gosh Live. Our director once a month gathers all employees online and talks about global results and plans, after which a Q & A session takes place.


And when do you work, if you have all the time of the meeting?


I threw a typical developer schedule:



This is our standard 10-day sprint, there are purple meetings, with the exception of quarterly ones. It can be seen that most of the time it takes work, not communication, and if it were office work, there would be no clear boundaries between work and communication.


How to deal with time zones?


The biggest time gap is now - +7 from Moscow. This is not a problem for meetings in 11 in Moscow, and further cases are solved by agreements. If it happens that you need to get an answer right in a minute, then something is wrong with the processes, they need to be rebuilt. We do not have situations when it is necessary to solve the working moment here and now. If it is force majeure, then it does not tied to time zones, it can still happen in the middle of the night.


But what about personal communication?


We know about this problem, employees have such a request, we are trying to solve it.


Twice a year, we invite all developers to the Moscow office, pay for flights and accommodation, try to make teams come, so that people who work together but haven’t seen each other for half a year (or even never) communicate. Last year, for the first time, we tried the hackathon format, collected all the development in one place for three days. The hackathon received feedback: everything is cool, but there is little communication, there are too many codes; This year we will change the focus.


It is easier and faster to ask a person in the office!


It seems that communications in one room are super-efficient in terms of speed: I can shove Petya, who knows everything about his module, and he will tell me everything at once. Why do we think that remote work is more efficient?


The answer is simple: weak is cheap, and live communication is expensive . You sit in the office, work, do the task, then a colleague pokes in the shoulder and asks a question, you get distracted, you begin to answer. Yes, there is the practice of a red folder, which you can put on the table so that you are not touched, but it also does not work as well as you would like. Let's change the situation: a person approaches a neighbor and starts to talk with him quietly about something, you hear some keywords like “wimbox”, think that now they will decide something without you, involuntarily start to listen and distract from their task . Or go to the kitchen, see Gleb, your upbringing does not allow you to just pass by, you say: “Hi, Gleb, how are things with analytics?” And Gleb talks about all his tasks for 15 minutes. You lost 15 minutes with him. In the office, the line between work and communication is blurred, and communications are often empty.


But this does not mean that if we turn into weak, our communications will immediately become more effective. To maintain efficiency, we use some of our methods. First of all, tough conventions .



In the weak we have a clear hierarchy of channels. There are some common ones where all employees sit. Next are the horizontal directions, in them more than 100 people in each. Then the channels of the teams, then the channels for their specific tasks and projects. Each team also has a channel for ideas and bugs. This is done so that the information noise is directed to one stream. A separate type of channels is integration: automatic messages appear there, if the server has fallen or something else has broken, those who can fix it subscribe to them.


We are trying to make communications super-targeted. If we have a channel for the whole team, it is intended only for what everyone needs / is interested in, you cannot post there for individual projects. Any message is always addressed to specific people who need it. In large channels, it is forbidden to use the @channel and @here . Each channel must have a clear description and naming convention: the name of the team, the division of the team, the goal. There is even a special slak-police, which resorts in two minutes, if, for example, to call the channel not according to conventions. They are responsible for ensuring that everyone has an avatar with a photo. I saw other teams, where instead of avatars with faces, standard Slak badges were used. Immediately there was a feeling that this was an internal technical tool, and not communication with people.


Finally, another hint - we create tags in such a way that if someone does not know what the team name of a team is, you can make a request using certain rules and find all the people who respond to it.



But what about the exchange of experience in a team?


There is an opinion that if you put the senior and junior together, then after some time the junior will become a middle, middle - senior, etc. This is partly true, we just tried to implement the exchange of experience in a distributed team.


First of all, the wimboxes mentioned above are used for this. These are meetings where the developers of our Vimbox platform share their achievements, talk about the implementation of interesting projects with the rest of the team.


Wimboxing must be properly organized. If you make such appointments and ask “Who wants to speak?”, Then it is highly likely that no one will. We ask another question - “Who wants to hear about what?” And the team members say: I want to listen to Gleb, because I am interested in learning about his analytical tools. Or: I want to listen to Dima, because he did an interesting search task. Then we vote for each topic, if we have collected enough votes, then we say to the person: you will have to tell. While we have not received bounce, we hold it once a week or two.


The trivial thing is a separate channel in the slaka, where everyone shares read useful articles and interesting books.



Once or twice a month we hold general development meetings, where we tell global things, for example, about the implementation of alerts in the infrastructure.


We use the same retrospective tool with the team leaders, we also hold meetings in the conference team’s format, where everyone shares positive experiences and discusses problems (there is a chance that some other team leader has already encountered this problem and can suggest a solution). All meetings, meetings and wimboxing are recorded on video: firstly, people may not have time, and secondly, even if there is time, you can save it by watching the recording in an accelerated mode.


How do you handle incidents?


It is clear that if the team is sitting in the same room, and suddenly something has fallen, all those present begin to repair it urgently. In remote mode, we use the OpsGenie tool. If something happens, he first calls the responsible duty officer, then the rest of the team - calls on the phone, collects all, begin to correct.


Surely there are unsolved problems!


Yes, I told you about what we have already coped with, but in fact, polls show that there are things that we just have to deal with. Namely:


- training


- offline meetings


- know what is happening in the neighboring departments


If you implement remote development, you will likely also encounter these problems.


Tools for effective remote work



Separately, I want to recommend the book Remote: Office not Required . It describes in detail the solution to the problems of a remote developer, as well as there are many interesting things about the organization of teamwork. Well, the comics in the topic .


Oh yeah, I almost forgot. Our team always needs cool full stack , frontend developers and not only !


')

Source: https://habr.com/ru/post/349598/

More articles:


All Articles