This is the second part of the story about the role of meetings in agile approaches. In the previous part, we mainly talked with management about value delivery and its prevalence over utilization. We discussed the importance of self-assessment by regularly asking the question, “Is the thing we are currently doing the most important and necessary thing we can do right now?” Now it’s time to switch sides and look at the world through the eyes of those who write code.
Let’s try to understand why developers dislike meetings and reflect on what can be done about it. When starting to work with new development teams, I constantly hear about the same problems:
- The client doesn’t know what they want (they want something strange);
- The requirements are poorly described (they do not take into account the specifics of implementation);
- Give me a clear task and don’t hinder my work;
- The business takes a long time to respond to the questions to clarify the request;
- There are too many tasks, and priorities are unclear.
I believe that most managers, team leads, scrum masters, and agile coaches are familiar with this set of problems and could go on with this list. In most cases, the people who talk about these problems are not lacking in communication and meetings. They participate in numerous meetings that annoy, tire, and distract them, but don’t solve the problems.
When developers say that meetings seem useless to them, it’s likely that they truly feel that way. When you receive such feedback from developers, it’s highly probable that current meetings are useless for them. Then, it becomes essential to solve the crucial task of understanding the processes and people and identifying the root of the problem.
Based on my experience, in most cases, the problem of useless meetings for developers can be solved simply by ceasing to discuss unimportant matters in these meetings and starting to discuss important things. I had a paradoxical example when a scrum master tried various game formats and activities to liven up the team’s retrospective, but the team still considered the retro to be useless waste of time. I advised them to stop tormenting people by imposing communication formats on them, allowing them to express their problems and potential solutions themselves and then simply guiding the discussion. No stickers, boards, or dot voting. At the beginning, we were close to failure. The first conversation turned out to be so aggressive that a lot of effort was required to prevent an argument. But the first step was taken, people got rid of the pressure of formats, and they started talking about the problems.
Very often, the reason developers don’t see the benefit of meetings lies in mistakes made in organizing and conducting them. Typical mistakes leading to a negative reaction to meetings include:
- Absence or non-compliance with rules;
- “Hijacking” meetings for irrelevant purposes;
- Lack of clear outcomes;
- Insufficient or “extra” people attending meetings;
- Lack of preparation.
This list can also be extended. Most of the problems are obvious and can be easily addressed. Once developers see the value of regular discussions in meetings, the negativity disappears.
However, sometimes there is another scenario. I have encountered situations where leaders put a lot of effort into preparing and conducting meetings, doing everything seemingly right, but still not achieving results. People don’t engage in discussions, don’t want to make decisions, and actively sabotage the meetings. Why does this happen? In my opinion, it occurs when people are “assigned” to be a team but were not taught how to be a team.
Very often, due to the lack of experience, leaders try to conduct team events with groups of people who are not actually teams. I am convinced that individuals pulled out of a matrix structure do not automatically become self-organized teams just because someone issued an order to change the organizational structure. People need to be trained. And at the very beginning, they should be given only as much self-organization as they can handle.
Expecting people that stay at a low level of awareness to show empathy for users, company goals, and the product as a whole is really naïve.
To expect an instant transition from give-me-a- clear-task-approach to full ownership of their workflow is just as naive.