Who will benefit from this article?
The article will be useful for leaders and members of small project teams of 5-10-15 people.
What to use and why?
We personally use Slack to communicate and share information.
Most of what is written below, in one way or another, can be organized in other messengers.
Reasons we use Slack:
- Convenience in organizing group chats (channels)
- The presence of threads - the ability to create dialog branches
- Differentiation between working dialogues and non-working ones. Work in Slack. Other - in telegram / watsap / wherever
- Reactions availability
- Reminders availability
- The ability to integrate Slack with many tools
If there is any Slack alternative for which all 6 points above would be true, please tell me in the comments. And for such an alternative, tell me what cool features it has and often used in your team.
What are the rules of communication in the team and why?
1. Do not communicate in PM
We leave communication in PM only for two cases:
- Discussing something that requires privacy.
- Memasiks / jokes and other flood.
For everything else, we use common communication channels.
Now I will tell you what it is for. I will tell you a little later how to organize common communication channels in such a way that there is no mess and chaos.
Why is this rule needed?
This rule is needed to:
- It was possible to catch situations when someone deviated from the course and began to do something wrong.
- It was possible to catch situations when someone started doing something wrong.
- There were no situations when two people agreed on something, and someone else suffered from it.
- The managers could monitor the teamwork coordination.
- The managers could track the occurrence of conflicts, resentments and the occurrence of other negativity.
2. Tag those to whom the appeal goes
Any message must have an addressee. One or more.
When referring to someone, you should tag it.
When addressing multiple people, tag everyone, not everyone in the channel.
Why is this rule needed?
This rule is needed to:
- Not all chat participants were distracted by messages in group chats / threads, but only those who were tagged.
- The probability that the addressee would pop up a notification was maximum. For example, in Slack, notifications are sometimes lost.
3. React to messages
Any message sent by someone (not automatically) should not be ignored by the addressees of this message. The addressee, when receiving a message, must give a response. If there are several addressees, everyone should react.
In order not to write the phrases “ok”, “understood”, etc., Slack has a convenient feature - reactions. Our team members usually put the reaction: eyes :. The leader uses the reaction: eye :.
Why is this rule needed?
This rule is necessary for the sender to know that his message was “not lost”.
4. Use threads
Slack has such a feature as threads - the ability to create a "conversation thread" and conduct a conversation in it, and not in the main message flow.
This feature is well suited for discussing a single issue.
Why is this rule needed?
This rule is necessary in order not to make a mess in the main flow of messages, thereby increasing the structure of information and ease of navigation through it.
5. Log conversations that took place outside Slack
If some dialogue took place, say, on the call, then you need to throw in a protocol based on the results of the call - a set of theses that reflect the results of the conversation.
Why is this rule needed?
This rule is needed to:
- Make sure once again that the dialogue participants understood each other correctly
- We did not forget what we agreed on
- Were aware of what was happening who did not accept in the dialogue, but were interested in the topic of the dialogue.
- It was possible to refer to the results of the conversation
- ... and the same arguments from the first paragraph about common communication channels
Protocols must have addressees and receive responses!
Not everyone should be put as addressees, but those whom the topic of this dialogue concerns.
6. Initiate a call / meeting if the problem is not resolved in 15 minutes of active correspondence
Everything is simple here: if you can see that you have to write a lot of text, if a mess begins in the chat, you need to initiate a call and discuss everything with a voice.
And as a result of the call - send the protocol to everyone.
7. Conduct daily meetings in writing
A daily meeting is a group meeting in which each team member must answer several burning questions and discuss current issues / problems in order to synchronize the team. An example of a set of questions for daily meetings:
- What did you do yesterday?
- What will I do today?
- What problems do I have on my way?
We hold daily meetings from 11:30 am to 11:35 am in a dedicated group chat. The manager writes last - at 11:36. Anyone who unsubscribed after it is considered late. Educational work should be carried out with latecomers. Everyone should under the message of everyone affix the reaction: eyes :. This reaction is confirmation that everyone has read each daily message.
Our daily message template:
- What I've done?
1. API method / hello
2. API method / howareyou - What will i do?
1. API method / bye - Questions:
1. Alice, how long do you think your task will take you? - Problems:
1. Deploy fails. Help!
When discussing questions / problems, do not forget about rule number 6 - if the question / problem is not solved in 15, we put it on the count.
For the most part, our daily takes 15 minutes of everyone's time, taking into account the time to prepare for the rally.
Why is this rule needed?
This rule is needed to efficiently spend the team's working time. And patience.
No matter how rosy our world of Scrum is trying to make, in practice, on a daily basis, during a speech of one team member, not the entire remaining team listens to him, but 1-2 people. The rest are just waiting their turn. Typically, for teams of 10 people, such a daily lasts from half an hour to an hour, which means that most of the team just sits and cakes for most of that hour. Translating into text format makes the daily fast, concise and, among other things, fixed.
8. Bonus: In inhouse teams, discuss in text format everything related to products and the process of their creation
My personal experience is that life gets better when you discuss in writing:
- demands
- design
- realization
- work processes
- suggestions and problems
In practice, this is not always 100% possible.
Then, when something from the list above is discussed live, the results of the discussion should be recorded.
Why is this needed?
In order to solve the following problems in inhouse teams:
- Always: managers think they have a finger on the pulse, but in reality they practically do not see how the team is doing. Everything that can be caught when communicating in group chats is practically inaccessible in live format
- Often: decisions are made in the smoking room, which are then not broadcast to all interested parties
- Sometimes: discussion of work issues is accompanied by conversations of "nothing" in large numbers
How to set up a messenger?
In order for the channels to be conveniently ordered, we use a prefix system.
Since our team is engaged in different projects, we come up with a prefix for each project and use it in channel names.
For example, we have 2 projects - GoldFixing and Aurrency. For these projects we use the following prefixes: gf for GoldFixing and aurm for Aurrency. Then all channels associated with GoldFixing will start with the gf_ prefix and look like gf_somechannel. Likewise with Aurrency - channels will look like aurm_somechannel.
At the same time, there can also be many channels within the project. To organize them, we came up with a categorization of channels by their purpose. And for each category, they got their own prefix.
Channels can be divided into 4 categories:
1. Grocery
These are channels that are dedicated to the products that are created within the project.
Prefix: prdct_
The channels in this category discuss all those issues that in one way or another relate to this or that product.
Thus, if within the framework of the GoldFixing project, two products are created - a platform and a back office, then we create the following channels for them:
- gf_prdct_platform
- gf_prdct_backoffice
2. Information
Channels in this category are not intended for communication, but for the dissemination of information.
Prefix: info_
All kinds of notifications and messages for organizational purposes come to the channels of this category. For example, notifications from the task manager come exactly here.
Thus, if we use JIRA in the GoldFixing project, then we will have the gf_info_jira channel.
3. Team
These are channels dedicated to teams based on their professions.
Prefix: team_
The channels in this category discuss issues that are tied to a particular professional discipline (frontend / backend / etc) and not related to other disciplines.
For example, if there are several frontend developers in the GoldFixing project, then we will have the gf_team_frontend channel.
If the same people are involved in several projects, then you can omit the project prefix and simply name the channel - team_frontend.
4. Temporary
These are the channels in which you want to discuss something that you do not want to load non-related people with.
Prefix: tmp_
For example, if in the GoldFixing project it is necessary to discuss the purchase of cups with the project logo, then we create a channel gf_tmp_brand-cups.
If you need to discuss something that is not tied to a specific project, then we omit the project prefix.
Basic setup of information channels
Despite the fact that this setup was made for the IT team, I think that something can be borrowed by non-IT teams.
- gf_info_general - for everything related to the organizational part: declarations, fixing agreements and processes. Usually addressed to everyone and requires a response from everyone.
- gf_info_daily - here everyone unsubscribes their daily messages
- gf_info_changelog — , //wireframes/api , - - , Change Report , , ,
- gf_info_jira — JIRA
- gf_info_confluence — Confluence
- gf_info_deploy — . :
— Instance — Repository —
— Branch —
— Pipeline — gitlab
— Job — gitlab
— Triggered by — Slack ,
— Commit — - gf_info_sentry — Sentry
- team_backend — backend
- team_dlt — DLT
- team_frontend — frontend
- team_qa — QA
Advanced JIRA
If you pour notifications about everything that happens in JIRA into one channel, the channel will turn into a mess of messages.
To do this, we fine-tuned notifications and made not one, but several channels for JIRA:
- gf_info_jira_comments - for comment notifications in JIRA
- gf_info_jira_qa - for notifications for QA about the appearance of tasks ready for testing. This channel has only QA and manager
- gf_info_jira_qa_verdict - for notifications about the transfer of tickets from the “TEST” status to “DONE” or “REWORK”
Advanced setting up notifications from Sentry
We have several project instances (stands) on each project:
- Dev stand - stand for developers
- Test stand - stand for testers
- Release stand - a stand for running release candidates
- Production stand - production stand
For each of them, we created a separate sentry channel.
And so that the frontend developers do not twitch when an error occurs on the backend, and vice versa, they also split these channels into frontend / backend groups.
It turns out:
- gf_info_sentry_back_dev
- gf_info_sentry_back_test
- gf_info_sentry_back_release
- gf_info_sentry_back_prod
- gf_info_sentry_front_dev
- gf_info_sentry_front_test
- gf_info_sentry_front_release
- gf_info_sentry_front_prod
Thus, the fronts are not twitching due to errors in the backend, and vice versa.
For different stands, different urgency of the developers' response is acceptable.
Due to the fact that the production instance of the project is located on one cluster, and all other instances on another, we are thinking about how to group channels by clusters and get:
- gf_info_sentry_back_dev-cluster
- gf_info_sentry_back_prod-cluster
- gf_info_sentry_front_dev-cluster
- gf_info_sentry_front_prod-cluster
Example of channel organization
Questions to the audience
- What communication rules would you add to the ones I've listed?
- What other useful things can you configure / use in the messenger at the level of the whole team?