On Daily Standup Meetings

Agile development methodologies such as Scrum, Kanban and XP have taken the software development industry by storm. By now, most companies have drunk the kool-aid – first the decision-makers, then the developers – and follow it with a manner of religious zeal.

It seems like this exciting new “agile” way of working has made traditional hierarchical management and reporting lines obsolete. Agile has by now entrenched itself deeply within the fabric of software companies, and it seems like we’ve forgotten the old ways.

We are now faced with the conflict of fixed-backlog sprints and shifting requirements, burndown charts that never converge, armies of full-time scrum masters babysitting developers to death, and the progression (or regression) of the Daily Scrum into… the Daily Standup Meeting.

While I understand this article may be controversial and may touch a nerve in a large number of people, I find it much more important to work efficiently and to challenge harmful norms than to mindlessly conform to them. My hope is that at least some people might read this article with an open mind, break out of their stupor, and start questioning these established practices. In order to improve, it is necessary to first acknowledge problems, and then take active steps towards addressing them.

What is the Daily Standup Meeting?

Image credit: taken from here

The Daily Standup Meeting is a “ritual” (quoting Jason Yip’s comprehensive article on the topic) in which the development team (and possibly other stakeholders) gathers to report on the progress of each individual member. They must in turn answer three questions:

  • What did you do yesterday?
  • What are you going to do today?
  • Are there any obstacles hindering your progress?

Let’s take a look at the meaning of each word, aside from “Meeting” which is obvious enough. As a “Daily” meeting, this happens routinely every day at a specific time. All those involved must stop what they are doing and participate, whether it is productive or not.

What I have just described is nothing new: I have participated in Daily Scrum meetings of this nature for years, and I’m pretty sure this goes back much father than my personal experience can account for.

A more recent twist, though, is the Daily “Standup” Meeting. The idea is to force people to stand up in order to keep meetings short, by having the physical discomfort as a disincentive to letting the meetings drag on unnecessarily.

Standing Up

This factor, on its own, speaks volumes. Rather than solving the problem of pointless meetings that are a complete waste of time, we choose to make people feel uncomfortable in the hope that the meetings will be kept short.

The first problem with this is how ridiculous and humiliating it is. Not even in church are you obliged to stand up, and perhaps at school there may have been instances where some posture was enforced in punishment (a practice that is probably considered barbaric by today’s standards).

But no. We are fully grown adults, who have been working for several years in the industry, and there is a perfectly comfortable sofa behind us, but we cannot use it, under pain of menacing glares from everybody in the room.

This also has no regard for any physical issues that the participants may be undergoing that may make this practice more uncomfortable than for the average human being. Such people should not have to disclose their personal problems to the team in order to waive the enforcement of a certain posture on the job, something that nobody has the right to enforce in the first place.

The second problem is that, well, it doesn’t work. Standing up or not, the tendency to ramble on is a lot more powerful than the discomfort (which most people can just as well get used to). Which brings us to the next section.

Excessively Long Standups

Do you remember what we’re supposed to do in standups? Basically, answer the following three questions, and then get on with our work:

  • What did you do yesterday?
  • What are you going to do today?
  • Are there any obstacles hindering your progress?

It is much harder than you would think, to stick to the plan. Despite having been brainwashed into enthusiastic and excited participation in this drudgery, people’s overexcitement tends to take over. There are many different scenarios which result in deviation from this template, and in turn cause Daily Standup Meetings to drag on. These are just a few of the most common I’ve encountered:

  • People want to justify their job and show that they are doing something, so they read out a whole list of every little detail they worked on since the last Daily Standup Meeting.
  • Stakeholders ask a lot of questions to the development team. They have a right to be answered, but the Daily Standup Meeting is not the right place.
  • Developers going off on a tangent and having a technical (or other) discussion between two or three people, but keeping everyone in the room.
  • Lots of people in the room, so it takes a while to go through what everyone has to report. This is mainly a problem when developer teams are large, but it can also be a result of participation of a lot of stakeholders who join the Standup. With 20 people in the room, it’s hard to keep meetings efficient.

Broadcasting Information

The format of the Daily Standup Meeting is such that the development team and any other stakeholders are present (whether physically or otherwise). It allows everybody in the room to be kept up to date with progress (in theory) and to be able to help remove any obstacles (again, in theory).

Personally, I believe that this is one of those cases where too much transparency is a bad thing. The main reason for this is that there is no reason why each person should need to broadcast their progress to so many people in the room. Typically, you work with one or two direct colleagues, and report to your manager. There is no need to keep a whole crowd in the loop.

Rather than focusing on what each of us needs to do, we instead feel the urge to get involved in what the whole team is up to. A consequence of this is that it becomes necessary to involve everybody in the team in order to take the slightest technical decision, which is really the opposite of the empowerment that should be enabled by giving developers such autonomy.

In practice, keeping everyone on the team updated has no real benefit. They may know you’re working on something, but they would not understand the business or technical decisions, and as a result, they would not be able to take up the task you are working on, in your absence.

Another problem is the direct access to the development team from higher-up stakeholders. Part of a manager’s job is to manage expectations, both to his superiors and to his subordinates. And yet, higher-level stakeholders and members now suddenly have full access to the fine details of what the development team is working on.

A real problem here is when members of the development team are cornered into publicly answering uncomfortable questions, possibly by external stakeholders or maybe even by members of their own team. Such things should really go through a manager or scrum master rather than being laid out in a public shit show. It is not uncommon for such meetings to degrade into blame games.

Even in the absence of such situations, it is often uncomfortable for developers to speak (let alone report their progress) in front of a small crowd, even if it consists of their own direct colleagues. While the stereotype of anti-social developers may be questionable, in my experience I have observed that most developers feel intimidated when speaking in front of people, just as they feel uncomfortable when someone (even a direct colleague) sits next to them while they work. It is thus quite easy for developers to go on the defensive if challenged about their work during the Daily Standup Meeting.

And this, of course, is something that should be completely avoided. As any manager worth his salt would know, you should never, ever reprimand someone in front of other people. This is also a fundamental flaw of retrospective meetings, although that is beyond the scope of this article.

Finally, the routine of the Daily Standup Meeting makes it convenient for people to provide updates and feedback during the meeting itself, rather than spontaneously as needed. Communication should be spontaneous and immediate; that is what keeps things efficient.

A trend I have seen is for companies with poor communication to turn to agile ceremonies to try to resolve the problem. Little do they realise that they are making it worse by adding more ritual baggage and introducing more middlemen. There is no substitute for real and effective communication.

What Alternative is There?

Honestly, what was so terrible about the good old system of hierarchical reporting lines? Think about it:

  • You talk directly to your manager when you’ve finished your work and need to work on something new.
  • Your manager can ping you periodically for progress, but otherwise you can focus on your work.
  • If there are impediments, the manager can bring the right people on board.
  • If you need to talk to some direct colleagues (e.g. to integrate with their API), just do so. No need to have the whole team in a meeting for that.
  • Requirements and other outside interferences go through the manager first.
  • Feedback and criticism take place one-on-one with the manager.
  • Each manager reports to their manager. No need for crowds.

That just about solves all the problems I’ve described earlier: notice the contrast of involving only the people who are necessary, as opposed to everyone. The important factors to make this work are having a manager who is organised and has excellent people skills, and that everybody on the team is able to communicate efficiently and effectively.

Agile methodologies will remain a reality for many years to come. But are they really an improvement?

Update 11th September 2017: Here are some reactions to this article on social media (might require login):

6 thoughts on “On Daily Standup Meetings”

  1. BRILLIANT!! This is exactly what it’s all about and its slowing all progress on the job front. Well done for saying it as it is and business needs to wake up to the “emperor’s new clothes” this Agile BS really is all about!!! Get back to basics and normal reporting lines and accountabilities. THANKS for the well written article.

  2. It may become a problem with large team, like more than 20 ?
    But my team has been using this method and we worked fine until now, of course our team members in the meeting is only about 10 or so
    Maybe that is the problem, too big is a crowd

  3. My team has been using Scrum for the last 3 1/2 years. It has helped tremendously to get an amazing amount of work done. We are a small team of six. Our stake holders love scrum too. They do not participate in the daily meetings and ours are kept really short; update and end. They are less than 15 minutes per day.

  4. The 2 requirements for the old model to work which you mentioned (a manager who is organised and has excellent people skills, and that everybody on the team is able to communicate efficiently and effectively.) are really rare things to find in the same place. And unfortunately, without this, all the companies which are still using the old model are failing or will fail because they are not so flexible as you are mentioning and they are not able to adapt to change a very good example is Nokia.
    The large teams which you mention should never happen, scrum is recommending teams which are composed of 6 + 3, that is ideal is 6 people only including the Scrum Master. So if you have teams of 20 definitely you are not doing scrum and you are not agile you are only calling yourself like that and you blame the failing on it.

    1. If management is incompetent and the team is not capable of basic communication, whatever process you adopt will fail. Also, do not assume that there is a correlation between agility (reacting to change) and agile processes. I have seen very rigid ‘agile’ settings, and very flexible traditional management.

Leave a Reply

Your email address will not be published. Required fields are marked *