A reminder for organizing the remote work of the development team

In connection with the situation with coronovirus, the need for remote work has sharply increased. Many companies and managers were not ready to organize the remote work of development teams. Managers are justifiably afraid that in remote mode the team will work inefficiently, or employees will actively use only a small part of the keyboard.



Not only that, even if the developer works day and night, he works hard, not seeing what is happening, the leader begins to believe that the developers do not work.

If you somehow managed to work with poorly set processes and move development in the office space, then when you switch to the remote mode of operation, everything starts to fall apart. In some companies, there is a situation where people are asked to quarantine ahead of schedule.

Initially, the text was prepared for official use, but decided to reformat it into an article with the rationale for each item.

So, let's go.

1. Iron. Headset Webcam. Accessible internet.

Many employees at home may not have a computer. This may seem surprising, but many developers do not have computers at home. Many do not have a headset. Absolutely. If you ask to buy a headset, they will take the cheapest one for work. Or they will communicate with the microphone built into the laptop with all the noise of the fan, poor audibility and other artifacts.

You need to make sure that everyone at home has the opportunity to work from home. Ask to connect to the Internet. At the company's expense, provide a headset if necessary. Purchase a set of headsets with a good microphone and headphones, and provide an opportunity to get a headset for free for those who don’t have a headset or poor quality headset / microphone at home. It is also important to purchase webcams (more on this below)

2. Corporate messenger with support for audio-video communications.

It's hard to believe (no, not hard), but even today, a huge number of companies without corporate messengers. Especially if the company is up to 200-300 people. They work as teams in Telegram, WhatsApp, call up on Skype, Discord, etc. etc. In addition, any personal messenger is bad in that it will necessarily distract part of the staff, as they will not have the opportunity to "disconnect" (separate) personal messages and work messages. It seems to many managers that this is not a problem, especially since the other part of the employees, on the contrary, believes that it is very convenient when both personal and working in one messenger. It also often happens that some employees call themselves what they want, some are Latin, some are Cyrillic, some are generally nicknames. Also, part of the information is completely lost, etc. etc. A very common argument of managers:“It’s convenient for me to transfer the task by forwarding a message with the customer.” All the same, tasks should be set through the tracker, not the message forward.

. Slack, Teams. , . . .. , , , .

(I prefer Teams because of the concept, Teams that group channels by teams, but this is better for anyone. The main thing is that there is ONE messenger in the whole company. By the way, Teams announced six months of free use in connection with the coronovirus). Many are trying to implement RocketChat, etc. as a free alternative to Slack, Teams, but if you do not establish high-quality audio-video communication in it, then there is no point in introducing such free tools, since instant messengers will still multiply for text and calls.

Small simple phoning rules:

1. , , . , , , 2-3 , .
2. , . . . , Jira .. « »
3. . , « 5 », « », « » .. .. , / . , . ( , , « ?» — 5 ).
4. Remove the cats from the room. (I understand how difficult it is to follow this advice, if I close the door, the cat begins to yell heartbrokenly under the door from the fact that without it something interesting can happen in the room. It’s necessary to lock it in the kitchen.) If the cat is calm, it doesn’t get into the camera and not distracting, you can leave. :)

3. A single tracker. Unified rules for working with the tracker. Transparent team.

Often in companies bred zoo trackers. Jira, Azure DevOps, Redmine, Trello, etc. etc. Time is written off too anyhow. Tasks can be planned with an assessment for several days at once. There is an illusion of planning and due to the lack of transparency, managers do not understand the progress on tasks, do not trust the developers, and the developers are confident that the managers, to put it mildly, are “bad people who do not understand anything”.

1. .
2. . . . « » « ».
3. . .
4. 7 . 4 .

The rationale for this paragraph of the article draws on one large separate article. If you take the main:

Example:



(A recommendation, everyone can have their own cases, the main thing is that there is such a recommendation at the company level. People and backlog are synthetic, created for the article, unfortunately fictitious people could be started only as mailboxes)

Epic, Feature , User Story - task dividing clear to business-understandable elements, each of these levels should have its own separate board. This level is worked out and written by PM, analysts, etc.

Task is an engineering level, it should also have its own separate board. Only Timlids and developers strictly decompose (paint) this level. For example, RP, if desired, can read, but cannot set tasks at this level, since potentially it may not even understand why this is necessary. RP can use this level solely to understand how heavily loaded the command is (see below).

You cannot place different levels on the same board. At the same time, all technical tasks that are not clear to business, such as “database refactoring”, “code refactoring”, etc. etc. should be tied to the specific tasks of the business. This will justify the need and timeliness of engineering work.

Planning:

Provide visually clear information on how busy people are on projects and why it’s physically impossible to take more tasks on iteration. This is especially important if you have a cross-functional team (a team of highly specialized specialists), and not a team of generalists (a team of full-stack developers).



Don't confuse people planning with StoryPoint. StoryPoint can be used to evaluate tasks at a higher level and distribute by iterations, and inside the iteration, the work of the whole team can be made transparent to everyone.

In order for Role planning in a cross-functional team to work, you need to specify people and roles:



Also, this visualization can be used to make it clear that we won’t be able to close the taken volume of tasks and why:



This will allow the manager to see transparently and clearly what is happening inside the team and make appropriate decisions in advance (remove the task, or leave the task, and in retrospect lay more time for the next sprint, plan to hire another backend of developers.

It is extremely important to divide engineering tasks into maximum at 4 o’clock. In especially large cases, you can 7-8 hours. Such decomposition solves a number of problems.

1. Make sure that the technical expert and the developer understand the problem in the same way and did not miss / forget anything.
2. Improving the accuracy of the forecast as a consequence of the 1st paragraph.
3. The manager can see the progress on his tasks every day, instead of not understanding for several days what the developer is doing. And it makes the work on the task transparent for the manager, allows you to increase confidence in each other between managers and developers.

You do not trust me?

Very often, developers or managers do not want to provide the necessary transparency of their work. They respond to a request for transparency in the spirit of “Do you not trust me?” Moreover, many executives try to close information between developers as much as possible, supposedly for security purposes. I saw teams where the leader brought to a state of complete absurdity, when the backend and frontend were rigidly separated and they even could not see each other's tasks, not to mention the code. And this is on a bare REST API without Swagger, etc. tools.

"You do not trust me?" a very dangerous argument. Trust is not a tool and not a goal. Trust is very important, but it must be earned. At the same time, "Trust" in itself is useless in principle. But if you understand each other’s work, understand what the ultimate goal is and understand who does what and can synchronize with each other and help each other, you will gain trust as an important side artifact.

4. Standups (flies). General business hours. Work uniform at home.

Many people, working at home, are damp. In general, this is normal - it is healthy human laziness. Not only that, many good developers are lazy in nature. Moreover, it was healthy laziness that allowed some people to become good developers.

The problem with working at home is that the schedule may start to go astray. You can sleep longer under the pretext that you will do the work later (what's the difference when I do it?). But this only works if you are not working in a team. But teamwork is not like dragging sand - you can't drag your sand block when you want. Teamwork involves collaboration.

If you do not do your part of the work, then you can block the work of other people. (Personally, I worked for 1.5 years from home alone on one project. At first it was cool. Then I stopped noticing time, then I got the disgusting feeling that I fell asleep at work and woke up at work, after 1.5 years I got into the office and got a huge the pleasure of working in the office despite the fact that the one-way trip took an hour to travel).

1. . (, ).
2. 15 . - , . .
3. .
   
   (, 12 16 , 4 ). , , , , .
4. (Recommendation) In particularly difficult cases, at first you can enter not only morning, but also evening volatiles to synchronize with each other. As a rule, it is pointless to carry out morning and evening flies. But the first time for peace of mind can be maintained, in a month there will still be a desire to cancel.
5. (Recommendation) Wear a work uniform daily. When working at home, at first it is easy to separate work from personal life. But gradually the border is blurred. Dressing allows you to psychologically distance yourself from the "work mode" and "rest mode".
6. (Recommendation) Communicate with the camera. If the background is not very good and you do not want to show the apartment, then you can deploy the computer / camera to the wall (where you can hang a poster).

Communication with the camera solves two problems:

1. — . , . . , . .
2. . , , , . «» . / , , .

It is clear that this list is not complete. That these points are needed not only for distributed work, but also for work in the office, and that for a full-fledged healthy development process, you need to write a lot more points. Here I tried to single out the very minimum of what prevents both managers and employees from switching to a remote mode of operation.