Like in any other human organization, communication is key to the success of a collectivity. Great teams communicate very well. By communication, we mean the act of sharing opinions or feedback to one single person or the whole group. In the following post, we are going to review the more common meetings were the attendants communicate with each other in a software development environment.
In Agile methodology, this kind of meeting is normally in the morning. All the team has to be there to review the virtual board from right to left. The oldest tickets are the topics that have to be addressed before.
Remember, finish things rather than starting new things. There is a flow facilitator role that reads the board and goes through each ticket where the person assigned shares some learnings about his task and communicates if there’s a blocker that stops him from advancing.
Those meetings should be quick, 10 minutes and after reviewing all the tickets, you can give space for some other topics that don’t belong to tickets (new member joining the team, some meeting where people can attend optionally …)
In these meetings, all the team joins to talk about general topics that are not linked with day-to-day such news from the business, news from other areas that can affect the team. It’s also a space to share with other members of the team what you have been working during the week and give context to others if the team works in different projects at the same time.
It’s a good moment also to review your metrics as a team or to review the board to see any improvements that can be done, like reducing the work in progress or also to do some training that can be interesting to the others.
These events are to review something that has finished as a project, see which things can be improved, what things were great, and which things were not as good. Those meetings are not to blame anyone, they are always constructive looking for new ways of working that can level up the team.
It’s possible to do a retrospective when there’s a bug in production also or when there’s a rollback, but I don’t recommend them becuase it seems that you are pointing someone that has released something that it didn’t have enough quality or it was not completely tested.
In these events, two developers can be developing at the same time and interacting with each other. Is good to mix a person with more experience with another that has less experience, this way the less experienced can learn some tricks from the senior, or the way that the senior approaches problems. In the past, before COVID-19 one person had the keyboard and the other one was next sitting. Now working remotely we can have more than 2 people interacting in the same source code and learning.
One trick if you are using IntelliJ IDE is to use the presentation mode for the others to see better your screen, also you can show to the others which shortcut in your keyboard you are using.
Code review feedback
Here we are not talking of a meeting, but it’s a very important form of communication inside a development team. This communication is asynchronous because the person that reviews the code, writes a comment in the code that some mate has developed and the person that has his code reviewed can respond in another moment.
This feedback starts when the developer does a pull request and adds as reviewers some mates of the team or all the team, depends on the rules that you agreed between the team. The feedback has to be always constructive having in mind that the person who worked with that code did the best way that he knew at that moment.
These meetings are used to communicate some news that can impact the team in the short term that has to be communicated to the team as soon as possible. Some person is leaving the team can be communicated in this kind of meetings, another example can be that team is moving to another functional area or some business update of the company.
In these events, there’s a trainer that explains to the others some topic and the others learn about it. When you explain something to others you force yourself to understand it and you benefit from it also. The audience of these meetings can be small or large. With the remote conditions, we don’t have space limitations anymore.
One to ones
In this kind of meetings, people talk openly about any topic that can be interesting to share. If you speak with someone like your direct manager you can ask for feedback to be able to improve as a professional, this person is normally there to help you in your development as a professional.
Sometimes we can feel afraid that this person will use this information against us but it’s the opposite. Tell this person what you feel more comfortable doing, and what are the points that you feel you have room for improvement.
These conversations are normally with your line manager that communicates to you how has been the year and which are the things that you can improve and which are the things that you have done a good job. It has to be a bidirectional conversation where the two parts share their view in the situation.
Meetings with stakeholders
In these meetings, there are 2 possible roles. You ask for something for another team or another team is asking your team to do something. The one who receives the request must listen to the requestor to understand what are their needs. You have to be assertive and in this situation, if you have other priorities or you don’t see it as a good decision, you have to challenge the other part with your view on the topic. If both parts are on the same page you can agree on the task to do and add it to your backlog.
Project status meetings
This kind of meeting (in my opinion) can be omitted and instead of that ask for weekly mail with the status of the project. Writing things down in an email help to recap all the details of the status of the project (KPI’s, tasks, next steps) and can be shared with all the stakeholders.
We have seen in this post different communication events where people interact with exchanging ideas, concepts, thoughts regarding different aspects and situations during the work in an agile software development team. Are you missing any important meetings on this list? Which is your favorite meeting? and the ones that should be skipped?