Are standup meetings designed for remote teams?

Raquel Pau
4 min readMay 11, 2020

Currently, we are living in a VUCA environment, and in practical terms, it means that we can not foresee what is going to happen at mid-long term, and in some cases, even at short term. We are getting more and more connected, and thus, people and also businesses are more fragile about what is happening in the other part of the world. COVID-19, and the corresponding future financial crisis would be a very clear example.

In terms of software engineering, this is why agile methodologies have become so relevant. According their manifesto, “teams should respond to changes over following a plan”. In other words, they do not promote working during long periods following the waterfall approach (analysis, design, code, test, validation) without the user feedback. Customer requirements might have changed and this is completely acceptable. Instead, they perform small iterations, to deliver incremental value, usually called sprints.

Teams should respond to changes over following a plan

One of the most adopted agile methodology is SCRUM, and one of the main meetings is the Daily SCRUM or usually referred as standup meeting. The purpose of this meeting is being completely transparent about our daily progress and our blockers to achieve the sprint goal. For that reason, team members usually answer these three questions:

  • What did you do yesterday?
  • What will you do today?
  • Anything blocking your progress?

After interviewing more than 30 engineers, I detected that teams usually try to answer if they are on track for their sprint goal.

According the interviews, the main question to answer in a standup meeting seems to be if the team is on track to achieve the sprint goal.

In those interviews, I detected the following strategies for standups:

  • Answer those 3 questions by referencing (JIRA) tickets, pull requests or specific announcements related to the product or the company. The status of the tickets are usually updated in-live.
  • Skip those questions and check the status of the pending tickets for that sprint, and update their status.
  • Avoid the standup meeting and use 1 week sprints. Teams are mature enough to update tickets and report blockers (in tickets or Slack) when they occur. Engineering tools are connected and configured to give transparency of the progress. Then, people do not need to sync every single day. Here the source (in Spanish).

During the same interview, I also asked two questions:

  • If blockers are important, why do you wait for the standup meeting?
  • Are you using standup meetings for reporting?

Lots of different answers, but they were all related with the company culture, or if you allow me to be more concrete, with the team maturity. Teams usually argue that:

  • There are some (junior) personalities that prefer spending time removing the blockers by themselves during long periods. You need to force them to stop.
  • Some people procrastinate if the meeting is not there
  • Some team roles (e.g product owners/managers) need this kind of reporting.

In other words, they are running standup meeting because there is a lack of transparency, and thus, trust.

In my opinion, the lack of transparency is less propense in (fully) remote teams because, otherwise, you can not collaborate with other folks that work at different time zones.

Good communication skills are a hard requirement in remote teams because everybody need to work asynchronously. Therefore, remote teams need to use engineering and documentation tools (JIRA, GitHub, Google Docs, Slack..) in a more intensive and diligent way. Most of them allow to report status updates and notify your partner about a blocker.

An interesting piece of the Agile manifesto is “Individuals and interactions over processes and tools”, which seems invalid for remote teams, right? Indeed, some tools generate interactions when we mention our members with @... So, I wonder if maybe, what is lacking is:

  1. Add some automation to enforce people to update the work progress in the existing tools (e.g JIRA).

2. A proper interface in those tools to understand the progress from one day to another, and/or a list of metrics to estimate if the team is on track or not.

One shared comment I have found along all the interviews is the social aspect, which is also a common concern since we have started with COVID-19. I’d say:

Meet with your teammates regularly and talk about your interests rather than something that is already reported in a tool!

Now, with COVID-19, most of us have been working remotely. Then, it is may be time to think about our own unnecessary meetings.

--

--

Raquel Pau

Helping teams with their software delivery pipeline | MBA