What do you do when a developer says “Agile has too many meetings”

Have you ever heard a developer say, “Agile has too many meetings!”

In my years as an agile developer, development manager and agile coach, this is the top complaint I hear from developers when their team “goes agile.” This complaint demonstrates a lack of engagement or lack of support for the team’s agile transformation. What techniques do we normally use to address this and why don’t they work?

(footnote on “agile meetings”)¹

Failed technique #1: Logic

I’ve added up the amount of time we spend in meetings and it is exactly 3 hours and 45 minutes per week. I feel this is an acceptable amount of time for us to collaborate.

Who has said this in response to the complaint about too many meetings? Did it work? Of course not.

What is interesting is why it doesn’t work. Turns out the complaint about too many meetings is not really about the facts of the situation, it is about the feeling. Rather than debate the facts, acknowledge the feeling. Assume they’re saying: “I feel like agile has too many meetings.”

Now that we aren’t debating facts, we’re acknowledging that they’re feeling frustrated and we can start to dig in as to why.

Failed technique #2: Obligation

Well, we’ve gone agile and this is just part of it. You’ll need to come to the meetings to be a team player.

Does this one work? Maybe for a little while. But how good are you at doing something that you don’t find valuable just because you feel obligated to? I know I can do it for a while, but eventually (when people stop paying attention) I’ll slip back into my old patterns of behavior.

What then can we do to help address the concerns of the developers and get them engaged?

Find the root of the problem

Here’s one thing I’ve learned over years of hearing this complaint: It’s not about the meetings. It really isn’t.

Now, if your team is having a 3 hour daily standup each day, it is about the meetings. But assuming you follow relatively normal scrum processes, the meetings are not the problem. It is what is happening between the meetings.

When your developers say, “agile has too many meetings,” what they are really trying to say is, “I don’t have enough focused time to do my work.” The regularly scheduled meetings are just the most visible example of things that are preventing them from having time for focused work.

Fixing the root cause

You might say at this point, “I’ve looked at their calendars, and they’re mostly empty. They’ve got so much time outside of the meetings!” Most managers, POs and scrum masters look at a developer’s calendar with jealousy because of the large swaths of unscheduled time. That must be plenty of time for focus, right?

Not exactly. Focused time isn’t simply the absence of meetings. It is the absence of interruption. Actually…it is even more than that. Speaking as a former developer, focused time arises from the guarantee of no interruption. That is the condition under which truly focused work can occur.

It takes time and effort to get into this state. Some say at least 20 minutes to achieve a state of “flow” where you are exceptionally productive and able to tackle the most complicated problems.

And with our modern office environments optimized for collaboration and real-time availability, it is getting harder and harder to achieve focus and flow. If a developer is interrupted with an email or a slack message or simply someone tapping them on the shoulder, they break focus and break flow. And because of the effort it takes to get back into that state, it isn’t even worth it to try if you’re 99% sure you’ll be interrupted along the way.

Part of why developers were happy prior to coming onto agile teams is that they were largely left alone to work independently on their code. Most non-developers assume developers are reluctant to be part of an agile team because they don’t want to work with others or aren’t “people people.” Some of it might be that, but I believe there is a different root cause.

Before scrum, they spent most of their day in a state of focused flow.
Now they spend most of their day fighting for a single uninterrupted hour of focused flow.

That’s a recipe for frustration, lack of engagement and in all honesty, lower productivity.

If you’d like your developers to be more engaged, have higher productivity (and reduce complaints about the number of the meetings), protect their focus. To do that…

Help them get into “Airplane Mode”

When you switch your phone to “airplane mode,” what you’re really doing is eliminating interruptions from the outside world. You’re cutting yourself off from outside distractions and this can create a very productive state. I know I’ve looked forward to a four hour flight because I knew I’d have the time to work on my work without worrying about what someone else needed from me.

How do we help get your developers into “airplane mode?” First, a few questions:

• Does your team have a working agreement?
• How does someone on your team indicate they are focused and don’t want interruption?
• Do you have times every week when no meetings are allowed?
• Do you have “quiet hours” where the entire team works with no communication or interruption?
• Are your meetings clustered together to minimize interruptions through the day?

If your developers are complaining about the meetings, make sure you’ve got solid answers for all the above questions. Because a developer without sufficient focus and flow will always be a frustrated developer. And a frustrated developer isn’t an engaged developer and will be less likely to support the rest of the agile transformation.

The more time your developers can spend in “airplane mode” with email and chat offline and in-person interruptions not allowed, the happier and more productive they will be. Clearly there must be a balance between collaboration and individual work and they can’t spend all week in “airplane mode”, but I do encourage you to increase the amount of time they spend there.

I believe you’ll like your results.