Communication in agile software development – Do we really spend too much time in meetings?

‘Software developers spend a third of their time at work in meetings’ is one of the headlines on heise online, which refers to a study by a scheduling software provider. I also notice time and again in my teams that time spent in meetings is often perceived as excessive and burdensome. A phenomenon that seems to continue being exacerbated by remote work. But does that really mean we spend too much time in meetings? Today, I would like to share my thoughts with you concerning this matter.

Solution suggestions can be found quickly: times or even days without meetings need to be provided, and, to ensure that we stick to this concept, doing so must be a company-wide regulation.

Despite these attempts at a solution, the problem does not disappear – a true sign that we have not yet really understood the problem and are only fighting the symptoms.

First of all, it should be noted that, generally speaking, meetings are an expression of a legitimate need for communication. Getting rid of meetings altogether is therefore as effective as stopping the clock to save time or turning off the oil warning light in your car when it is constantly on.

To be clear, you should of course limit meetings to what is necessary and schedule, prepare and conduct them as efficiently as possible. There are, however, well-known and well-proven solutions for this in agile software development, as I will illustrate in the following. That being said, efficiency is not the first question we need to address because efficiency only ensures that we do things properly. If we want to be effective, however, we have to do the right things the right way, and there are a few things that need to be considered.

So, to approach this issue, we should first distinguish in which context the need for communication arises. Are we talking about coordination and discussions within or outside the team, for example, with other teams in the same unit, at the control level of these teams or with completely different units?

Internal communication in agile teams

In our agile teams, we rely on typical meeting formats such as dailies, refinements, planning meetings, reviews and retrospectives. The purpose of these meetings is to reliably discuss the right things in the right format at the right time.

If our team does not exceed the recommended size of eight to ten people, the only thing we have to pay attention to is scheduling, preparing and conducting the meetings efficiently.

The principles of the Agile Manifesto, such as personal responsibility, self-organisation, the pull principle and time boxing, are decisive in helping us do this. In addition, well-maintained sprint/product backlogs or Kanban boards are just as important as a transparent agenda that everyone agrees with. Yes, I think agile meetings should have an agenda, too, even if it sometimes seems trivial.

A few useful tools, such as Jira, Confluence, Webex, Teams, physical Kanban boards and so on, are also helpful – at least if they are used properly and wisely and work reliably.

If we then conduct valuable retrospectives on a regular basis, we can continuously improve ourselves.

Increases in efficiency can thus be achieved where applicable by shifting the appointed times to off-peak hours. Meetings can be lined up, for example, in the morning, immediately before or after noon or before the end of daily business hours. And in doing so, you should make sure there are enough breaks between meetings.

You should also consider holding the meetings associated with a sprint change on one single day instead of spreading them over several.

Conversely, careful consideration should be given to supposed increases in efficiency that are achieved by increasing the frequency of regular meetings (for example, biweekly instead of weekly). It is not just the duration of the meetings which is usually extended when doing so. In addition, the problem often arises that clarifying important issues is then postponed for too long, and thus effectively more time for clarification is needed once again.

This is why we now also use dailies instead of the fixed meetings we commonly used in the past and why we prefer agile sprints of two to four weeks instead of dividing traditional large projects into just a few partial deliveries.

It is generally advisable to shorten such regular meetings but make them more frequent. A meetings may of course be cancelled at short notice if there are no topics to discuss.

Communication at the control level

Agile teams rarely work completely independently of one another. They usually work in parallel with other agile teams on similar or complementary products. In such cases, effective cooperation must be coordinated at the control level. This is an essential part of any agile scaling endeavour.

The same agile principles and values applied in teams are of help to us in this regard. It is therefore certainly worth considering using the same agile formats (dailies, refinements, planning meetings, reviews, retrospectives), too – just to a different degree, and possibly with different frequency. After all, these formats have proven themselves and ensure that we reliably discuss the right things at the right time in the right format.

Here, too, well-maintained backlogs, agile boards (for example, at the epic level for a longer period of time) and useful tools can help us prepare and conduct the necessary meetings efficiently.

However, it is also important at the control level to take care that responsibilities, accountabilities and roles are clear. Things such as the RACI matrix can help us in this regard.

Cross-team communication

Things become significantly more difficult when it comes to cross-team communication, as the need here depends heavily on how the teams and their products are organised.

One of the things to question is whether interdisciplinary tasks are organised by loosely pairing teams or whether there is a dedicated interdisciplinary team whose intended primary task is to perform governance functions.

Loosely pairing teams usually reduces complexity and therefore also reduces the need for communication. It can be helpful here to do things such as let the software developers decide themselves – within the framework of a Community of Practice (CoP) – which components should be developed using existing assets and how it should be done.

Having a division within a team that is more oriented towards technical components that do not have independent product characteristics can also be problematic – especially when the entire product development process is heavily dependent on the interaction of all the teams involved. On top of that, such a division is usually conducive of specialisation and thus the unwanted bottlenecking of resources.

It becomes particularly critical when strong team dependencies exist outside the direct sphere of influence of those at the control level or when those at the control level have to coordinate too many teams at the same time.

Since such structural problems can rarely be solved by the teams themselves, those at the management level sometimes react with measures that concern focus times, consultation hours or the like.

However, it is more helpful if you look for solutions together with those at the control level and first answer a few critical questions yourself:

• With whom do I have the most frequent need for communication?
• Are the most important skills present in the team, and are the most important people part of it, both at least temporarily?
• Are the responsibilities properly distributed, or do we depend on externals for our agile processes?
• Does anyone frequently bring up topics from other teams, discuss them in a team meeting and then carry over the results or, even worse, questions, to another round of discussion?
• How can we minimise dependencies on other teams?

If this is not done, it is important to increase the teams’ level of personal responsibility. Every divisional or interdisciplinary unit with decision-making or directive authority but no responsibility for results increases the need for communication and thus unnecessarily complicates teamwork.

It is equally important to keep the communication channels as short as possible. Not all cross-team communication has to pass through the control level; this is what distinguishes the control level from the traditional hierarchy. You can also, for example, temporarily allow the necessary people to join your team, or at least invite them to your agile team meetings.

Only then, should you try to increase the efficiency of your additionally necessary meetings, taking into account the agile principles and tools mentioned above. These kinds of meetings should generally be voluntary and self-organised. Regular feedback meetings, ROTI scores (return on time invested) and retrospectives, if applicable, ensure that such meetings are useful.

The influence of remote work

The question that remains to be answered is whether the trend towards working remotely is exacerbating the problem.

In order to strengthen social cohesion in the remote teams, many teams rely on additional meetings, such as informal coffee breaks or one-on-one conversations.

But are these really additional meetings? After all, we also make our own arrangements to meet for coffee or lunch in the office, or we discuss official and non-official matters with each other on the way to the canteen – but communication is admittedly easier and more flexible in these situations.

Ultimately, this is probably also a question of personal perception. I myself appreciate these kinds of informal meetings, but I still make my decisions on a case-by-case basis.

Conclusion

Effectiveness is worth more than efficiency. Only when we are properly positioned can we minimise dependencies among different teams and the associated need for communication.

Because – what was it that Einstein once said?

‘Identifying the problem is more important than identifying the solution because accurately presenting the problem leads to the solution.’

You will find more exciting topics from the adesso world in our latest blog posts.