How many times a week is the norm? About production meetings

I have often encountered complaints from development teams about the huge number of online meetings, conferences and calls during the working day. Sometimes an analyst, showing a calendar completely filled with various kinds of similar activities, asked in a suffering voice – and when to work? Today we will try to determine where all these calls come from, how much time to plan for them, and how to reduce their number. Let's go.

Elena Malysheva answers

Elena Malysheva answers

My name is Sultanov, and I am a team leader (heavy sigh). I try to protect the team from unnecessary calls. Sometimes it even works. And I also have channelwhere you can discuss this and other articles. Subscribe, it's interesting there. Probably.

Where does the discontent come from?

People working in IT are very proud of their field of activity, because it, this field, is unique. Free, creative, it is a world without dictates and prohibitions, a world where everything is possible. And it is they, that is, IT specialists, who decide what this world will be like.

However, if we look at any other sphere of human activity, we will see approximately the same thing there. The automotive sphere is a perfect fit – when it was just developing, there were few cars, without exaggeration, each car was unique, few people knew how to service and repair cars, and even less how to design them. And each of these people not only thought, they physically felt that the automotive sphere is unique, free, creative, a world without dictates and prohibitions… and so on. Familiar letters?

Skilled people were paid huge amounts of money, their every word was listened to, and they were quickly executed, the main thing was that there was a result. Since knowledgeable people usually worked alone, with two or three assistants at most, such people had few production meetings. Accepted the task – completed the task. A person buying a car did not pass any exams, he just took it and drove most often to the first pole.

But the number of cars was growing, and design solutions were becoming more complex. There appeared separate people calculating the processes inside the engine, separate people designing the car itself (except for the engine), separate people assembling the car, testing it. Control services appeared. Well, managers appeared, because it was necessary to somehow coordinate the work of this whole crowd. Even a separate profession of vehicle operator – driver – also appeared.

And then, as the number of people involved in the processes increased, the number of hours spent on coordination through production meetings also increased dramatically.

This is exactly what modern IT specialists cannot understand. The sphere, which was completely new until recently, is developing, there is an increasing division of labor, the allocation of narrow specialists. No one pays for a conditional “hello world” anymore, projects have become much more complicated, standard methods for solving recurring organizational and technical problems are being developed before our eyes. Platforms are created for specific types of activities. Accordingly, the problem of coordinating a large number of participants in the process arises, hence the calls. As before, when a programmer received a task from a business, he spent six months doing analytics, architecture, implementation, testing, deployment, bug fixing alone – this will no longer happen. The time of loners is long gone, we must accept the new reality.

What is the norm and how to determine it?

For reference, I refer you to my old article, where I determine how much time a team spends on SCRUM rituals. If my reader is lazy (and he is), I will remind you that rituals take 15% of a team's time. For some it is a little more, for others a little less, but that's about it. This is an unattainable minimum, from which one should start.

Next, I will take my team, which has a designer, two analysts, a front-end, 4 back-ends and testers, and I will calculate in general and approximately.

Let's try to sketch out a communications map and classify employee meetings.

Approximate map of employee communications in a team

Approximate map of employee communications in a team

As we can see, the analyst and front-end developer do most of the communication, and back-end developers communicate a little less. who whine the most about phone calls, and testers. Well, and comparatively little communication falls to the designer.

Now we can see what this communication consists of. Let's take the analyst as the key character of the team:

1. Communication with the designer – setting and accepting tasks. These are usually the longest meetings, because you need to go through the entire design and make adjustments. It takes about 6 working hours per sprint.

2. Communication with the front-end developer – setting and accepting tasks. About 4 hours per sprint.

3. Communication with the back-end developer – setting and accepting tasks. About 4 hours per sprint.

4. Communication with the tester – acceptance and discussion of testing results. About 2 hours per sprint.

Let me emphasize – the total time of meetings is described here, not their number. Many questions arise, but they are usually resolved in 10-15 minutes, no more.

We sum it up and get something around 16 hours, that is, two working days per sprint. This is not a small amount, because there are only 10 working days in a sprint, of which 1.5 days are spent on SCRUM rituals, that is, 6.5 days out of 10 days of the sprint are left for direct work. By means of linear extrapolation, we get data on other team members:

– designer 8 hours of meetings per sprint;

– front-end developer 16 hours;

– back-developer 12 hours;

– tester 12 hours.

Wait, the meticulous reader will cry out, these figures are certainly horrifying, greatly reducing working hours, but this is not at all like the whole days of calls that team members generally complain about, demonstrating a completely filled calendar. How does this happen?

And here we come to the phenomenon called “side activities”, they are indicated at the top of the communication diagram. There are no arrows on purpose, since absolutely all team members are subject to these activities. They are divided into two categories:

– general calls, where you have to be part of a large group, sometimes even the whole company (management and HR really like to organize these to tell everyone how well they did their job). Usually you only have to listen, but it's still hard to work;

– informal requests for help, consultations, support from neighboring teams and colleagues. Often turn into get-togethers where people just talk, without any result. A kind of analogue of a smoking room when working remotely.

What to do with all this disgrace?

If nothing is done with work meetings, and their reduction usually leads to a sharp drop in the quality of work, then external meetings, which eat up much more time, can be worked on if there is a will from the top management. And for the top management to have it, long-term, thoughtful and persistent work of the team leader is needed.

Group meetings are actually easy – they need to be recorded and posted as videos. Those who need them will watch them, but usually no one needs them, which once again emphasizes the highest value of such meetings.

It is more difficult to deal with requests for help, but it is also possible to work with them. Firstly, such requests must necessarily go through the team leader. Secondly, a strong moderator must be present at the meeting to prevent them from degenerating into “smoking room chatting”. Thirdly, each meeting must have a recorded result. And fourthly, and in general the most important, it is necessary to systematize such work by organizing centers of competence and inter-team interaction, where everyone can ask for help in a completely planned manner, and receive such help.

But how to properly organize teams, their interaction and competence centers, we will discuss in the next article.

Always!

Always!

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *