Menu

Is your team wasting too much time on meetings?

Stop me if you heard this one before: “agile has too many meetings“. This is the most common complaint for teams adopting scrum or other similar agile methods. Developers feel that they are wasting their time instead of “doing stuff”. Is this a legitimate concern?

Let’s do some quick math, on the worst-case possible scenario. We are going to assume one-week-long sprints. Which turns into roughly 40 hours of work a week (this may change depending your country or company. Let’s just go with this).

Our sprint is going to have a planning session, spanning two hours, on monday. We will also hold a sprint review session, and a retrospective, each one hour long, on friday. On top of that, we will have 15-minutes-long stand-ups each morning on every day but monday (since we didn’t schedule any work for the sprint yet). That means a total of, roughly, 5 hours. Making up to a 12,5% of our total week schedule.

Surely, that doesn’t account for so much of a distraction that hinders the regular elaboration of their roadmap. Are these times being respected? Agile meetings can fall into the trap of following anti-patterns, making more damage than good to the team workflow. Planning and retrospective can get people passionate in a very negative way, dragging endlessly points at issue without reaching purpose. Make sure to respect the timeboxes, and work towards reducing those friction points. Common predicaments include “fitting” user stories up to their “size”, reaching concessions, or committing to work over the actual capacity of the team.

Another question to answer would be this: is your team is having additional conferences? Knowledge transfers make sure that business wisdom doesn’t get too much centralized, but they can get in the way of work done. The same happens with stakeholders meetings: if you must, take a single member of your team so they can provide feedback and knowledge, but try to keep their interaction with the team to the review demo session.

As a final thought, consider what interactions with your team members are disruptive, and which are collaborative. Developers usually step into “the zone” sometime during the day, a state of mind where they are deeply focused and extremely creative: forcing them to get out of this condition will drastically drop their productivity, and increase the feeling that they are “constantly interrupted”.