If you have been reading this blog, you would be aware that I believe that thinking agile is more important  following agile dogma. Of the things that really get me riled up are mindless standups. There are better ways to kill a maker's time than to subject them to this. Yet day after day, people come together to mindlessly go through the 3 questions

  • What are they working on ?
  • What is next ?
  • What are their impediments ?

The original thinking behind having a standup was threefold. First frequent meetings to prevent recent information from falling through cracks. Secondly the contribution to team bonding. Lastly it being a standup, it is meant as a short,  informal and way to start the day together. So in effect they are meant to be short , sweet and informative. Those words hardly describe standups we have endured.

Let us go through a few reasons why standups do not work and what we could do about them.

Standups as proxy for status

This is the #1 reason why standups have proliferated the way they have. It is the need for the manager to keep in check with what is happening in the team. Getting everyone to provide a 2 minute summary on what they are doing and collating it is an easy way to keep in check . But Hey !!  if your team had a good culture of talking to each other and updating the tools and backlogs you wouldn't need to do this. There is nothing wrong with status updates, just don't call it a standup. A protip for status update : It is easier to collate it online.

Team size

The recommended scrum team size is between 5-7, yet I have seen standups with 25 people. Imagine the time it takes for 25 people to give updates. So what should have been a 10 minute affair is an hour long waste of time for an entire team. If you have 25 makers in a room  doing that every day, that is 250 man hours or 12% of your time.  And more importantly 25 people cannot be bothered enough to care about what the other 24 are doing. If you find yourself in this situation encourage micro standups in groups that work close together.

Fungible work

Standups work amazingly when the work is truly fungible i.e. anyone can do any piece of work and understand the shared context. If you ever find a standup where a backend, frontend and designers are giving updates on their own pieces of work and they have no shared context, run away while you can. In any large team, people work on different parts, components and projects but they still need to share a context. In such cases it is better to have cross functional standups by groups that work together and help out each other.

Remote teams

With remote teams it is genuinely hard to keep track of all the moving parts and it is tempting to have standups. An important part of standups is the feeling of starting together. There is no point having a standup at the end of someone’s day as he is leaving  and the start of others. That is a handoff and not a standup. For remote teams, the right path is to invest in tooling and a culture of written and asynchronous communication. More importantly set the bar for written communication really high in the hiring process.

Disruption of flow

Unless you have a really well managed standup at the start of your day, standups always tend to break peoples flow. As a maker I hate having to jump on to daily standup ( or any meeting for that matter ) when I am in my zone. Allow people to provide asynchronous standups. There are companies that ask their teams to record a 2 min standup video and upload it for others to view at their own time.

Lack of other avenues

Many a time standups end up being debugging sessions, deep dives, philosophical ponderings. There may not be space for such thought in other avenues. Standups are not meant for that as it might risk alienating parties. Teams should encourage free spirited discussions in other forums where they can be curated and managed well. Teams should facilitate the culture of micro meetings and interactions (in-person and online)

Having said that,  there are specific pre conditions where a daily standup is helpful. Firstly a small group ( <5 ) of people working on a coherent goal with some degree of fungibility. Secondly you need fast feedback and there are many unknowns on any given day  ( ex multiple A/B tests, MVP, rollout of a big feature etc ). Finally all decision makers are part of the group and can provide day to day decision making support. Using it minimally in bursts actually increase a sense of camaraderie and teamwork.

It is always useful to remember first statement of the agile manifesto says

Individuals and interactions over processes and tools