A Guide for the Perfect Daily Standup | Hacker News Reader

A Guide for the Perfect Daily Standup

blog.standupti.me

35 pointspolysaturate54 comments

While I agree standups can have a use, I find they get pretty useless at my current place of employment. We have a small dev team where every single person is working on completely different portions of the software and there is little collaboration/overlap. The stand-up is pretty much just people telling what they are working on, so I'm not sure it's an effective tool.

I've never seen a standup be useful.

Last year we built a team that was in constant communication threat the day, via slack and bug reports/statuses. We had ad-hoc conversations regularly. We all knew what was going on and what was being worked on.

And yet we were forced to have a standup every morning where we tried to summarize what we were working on for non-technical "managers" who always would have the wrong impression- either something that was hard was trivial and why weren't woe working faster on it, or someone would rattle off a bunch of trivial things and they would think they were working heard.

Technically competent management would be in the slack and watching the issues and not need a standup at all. A jira report is all you really need.

Just make a bug status that is "blocked" if your system doesn't already have one.

Then of course In all the companies I've worked at in the last 10 years that had standup, invariably there was some sort of management type (you can tell them because their job is having meetings, not getting things done) who wouldn't mind droning on for 20 minutes while standing. They don't care that they are standing.

I think the standup has become some sort of cargo cult relic from the days before slack and is maintained because it lets managers who don't understand technology feel like they are making their reports report every day.

Now a sprint meeting, once a week or once every 2 weeks... that's more useful.

The one use I've seen there is helping people notice cross-cutting concerns that might need to be pulled out --- to do that though, you need to setup the standup in a pretty particular way, beyond just "here's what I plan to do today"

At the very least it's an opportunity for people to interact. I'd say our daily standups produce useful communication and at least once a week solve a cross-team issue.

On my team, we've had an evolution from daily in-person standup, to daily short google hangout, to daily status dump into a dedicated slack channel. While there's something to be said for face-time, I think this is working for us pretty well.

"You Should be Standing Up." I use a standing desk so during our standup, while everyone else stands up, I sit down. The part about standing forcing people to be efficient and succinct doesn't really apply when you're already standing for 8 hours a day.

I find that the daily standup is frequently a waste of time though often (maybe 1-2 times a week) issues I hadn't known about are brought to the fore. On a small team, I figure that if someone really needs something, they will reach out to the appropriate people to get it. This reduces communication overhead unless the whole team is required to make a decision.

I can see value in doing a standup somewhere between 1-3 times a week, but 5 times a week, unless everyone needs to work closely together on time sensitive issues seems excessive. The idea of everyone doing paperwork every day to be prepared for a low value meeting kind of gives me a headache. It seems like the opposite of lithe and agile.

You seem to be selfishly focusing only on the benefit to you. You are (or should be) part of a team. Even with your low 1-2 times a week, with 5 person team that is 5-10/wk. In otherwords every single day.

"Selfish" is the wrong word, and to me assumes a certain troubling kind of bad faith. People respond to incentives. If the performance of a team is not the primary evaluative factor for a developer (and it often isn't), then it makes no sense for somebody to focus on anything else. A developer must be incentivized to view those five to ten times a week as a plus to the point of not finding it worth complaining about.

I injured my back in a fall a long time ago, 2 discs are bad. I literally can't stand for more than a few minutes without taking ibuprofen the rest of the day. It's time for standups to end and go back to the old fashioned sit around the table meetings.

Standing Up is a crutch to keep meeting short.

If you can keep the meeting short and effective with everybody sitting why you make people stand up ? It is not agile to apply practices out of principle, you apply them with a result in mind, and if the result can be achieved in a more efficient manner you just do it that way.

For example, my team has never suffered from anchoring. We stopped playing with the voting cards once it became clear the result we got with or without them were the same, just faster without the cards. We continued to stand up because that meant people going away from distractions but not requiring a trip to a meeting room.

This, I think, is what people so often miss when they are talking about agile.

It's not a magic set of hard-and-fast rules that should be applied to every situation regardless of how they fit. If you feel you can do without some parts of the canonical process, then drop them. If you feel you'd benefit from some different approaches, you can add them.

Standups are no different, and if your team doesn't need them, or has an alternative that works better for you, then go for it!

This is, however, used as a dodge by Agile proponents (okay, more specifically Scrum proponents, but the other "Agile" options have mostly receded) to avoid answering to the significant criticisms of the methodologies involved. "Oh, you changed it because we said it was flexible and could be changed? Now you're doing it wrong, the methodology(tm) is fine."

I've never seen it work. The people whose only purpose in the organization is to create meetings and waste other people's time always seem to be able to stand and drone on about irrelevancies for 45 minutes without breaking a sweat.

I've taken the policy that I a reserve the right to sit down at any time. If I'm sitting, you're bullshitting.

That sucks, but I don't think your misfortune in this case has any relation to whether or not standups are useful. There's a good argument that moving out of context for five minutes helps to focus and keep the meeting short.

The practice is discriminatory against anyone who is disabled or has suffered an injury and can't stand in one spot for even a few minutes. Moving to a conference room is moving out of context.

I'm sorry, that's nonsense – in the same way it would be to claim that any meeting where people usually sit down is discriminatory because some people have medical conditions that make that difficult.

Any company with even a shred of positive culture will work around an individual's medical needs. You can all sit down, or some of you can sit. I sit on my desk for most morning stand-ups.

In that case it does not ruin the standup to allow you to remain sitting, or have everyone sitting. Actual standing up was one point they recommended out of multiple and is not necessary for the practice to be useful.

I don't see any reason that a standup is superior to sending an update email in the morning and many reasons why it's inferior. Mainly, it's a tool for managers to feel important. That's it. There's no need to optimize that except to make it go away, for which there is a great need in this industry. If it was a tool for managers to get updates, they'd use email, chat or something saner. Standups put developers under pressure unnecessarily and offer nothing to the development process in return. It's sad that they even exist and they're a perfect example of managers who don't know how to manage and can't figure out a proper way to stay updated. They make developers angry and less productive because now the developers are stressing over what they're going to say in the standup rather than developing. Yet another terrible idea from the agile camp that seems to have no shortage of such terrible ideas.

EDIT: Note that all the information available in standups is also available on a board or ticketing system for a manager's perusal anytime. That to me proves the uselessness of the standup and its only purpose being to make managers feel in control.

This doesn't reflect my experience at all. I'm not at all a fan of Agile as a practice, but I am a fan of well-run standups. Update emails can tell a manager what they want to know, but incentives virtually never align to get the rest of your team to read them and be up to speed on what everybody else is doing. And that's why standups work: you get a little face-time with your entire team, away from the desk, and it's a chance to have everybody's undivided attention for a minute or so and to get them rummaging around the attics of their brains for things that might be relevant to you.

You say what you did and what you're planning on doing. If you are worried about the optics or politics of saying what you did, I would reflect on whether or not that's an issue, either with the team, its management, or you personally, separate from the process of a standup meeting itself.

It should be obvious, on an hour by hour basis, what is bing down, what is on deck and what is a blocker due to where issues are in the workflow. This is much more detailed and it's already being updated.

You don't need to interrupt your developers and take out 2 hours of productivity with a daily meeting.

I've never seen that undivided attention used for anything worth a damn- even the manager ends up giving filler.

It's like 24/7 news channels. There simply isn't enough content to fill a 15 minute (half hour) meeting every day. But they feel like they need to.

I've pretty much given up on the old Scrum-style standup. It's just another form of torture that to put devs through. I agree with the ceremony itself, but for development teams, or even worse operation teams, trying to catalog and remember all the things you did yesterday, or Friday, is painful.

Since we've moved over to Kanban, I've found it's much more useful to walk the board. We start on the right and move to the left. The discussion is much richer and I've found people no longer struggle to remember what they did yesterday.

What the author suggests at the end, having everything written down in advance, is just another chore designed correct 'bad' behaviour (people not sure what to say, lots of 'umm, errs'). Perhaps we should be asking ourselves if it's the format rather than the people.

Here is a blog post describing something similar to the one we're using now: http://brodzinski.com/2011/12/effective-standups.html

Having a daily short, informal, morning meeting certainly helps us. You don't need to be standing up to have "standup". Dogma for dogma's sake is the king of anti-patterns.

For what it's worth, I have noticed that actual stand ups are shorter. When people settle in and sit they tend to start rambling. It is hard to convince people to actually stand though without being dictatorial. Here's a study of undergrads (so take it with a grain of salt) that shows that they are in fact shorter:

http://nymag.com/scienceofus/2014/05/work-smarter-for-shorte...

I think that's true. When I had a local team we stood, and the meetings seemed shorter. With global or national teams, that's a bit harder.

I have found for phone/web "standup" meetings, that the person running the show needs to set the pace and keep it moving along. Nice and short, keeps the team informed and gets help were its needed.

On the other hand, I've had leads who just let people ramble non stop, and doing that for weeks was just wasteful and demoralizing.

Standing up is not dogma. Every description I've ever read of standups explains why you should actually stand. Read the article.

To be fair, they mention(with no sources) physiological benefits to standing up.

You can't use methodology to change what is largely a people-problem. Your projects are failing not because you didn't have daily status meetings correctly, they're failing because your organization has a culture of lying to itself about work. Thinking you can fix that by fixing daily status meetings is a symptom of that culture.

A daily status meeting is about seeing what is going on, comparing that to what needs to happen, and changing course if necessary. You don't need a checklist of how to do that. If you can't figure out how to communicate with people you see every day on those points, then I don't know if you're clever enough to figure out how to write code in the first place. You're fired. Pack up your things and get out.

I've seen way too many organizations use "we're standing up" to mean "therefore, we're having a productive meeting". I've seen places do 50-person standup meetings. Yes, they would go two hours. I've seen other places get the number of people right but do full-status-report standup meetings. Yes, they would also go two hours. That's a quarter of your work day, probably half of your productive work day, just wasted on an emotionally draining process.

Last time I had daily status meetings that worked, I had my entire team in one room, we had a large whiteboard with every task we were working on between us, and when everyone got in, had their coffee, got through their emails, I would turn around in my chair, ask if everyone was ready, and we'd just go through the list. We would scratch things off when they'd get finished, so we always knew who was getting what done anyway, and everyone had their names next to what they were working on, so we knew what they were working on already. It was mostly just a chance for someone to ask for help on something. It took about 15 minutes. If new tasks didn't fit on the board, they didn't fit in the team's workload.

I think there is something to be said for not placing the focus on individual contributors but on the tasks as a whole, on the team as a whole. My meetings didn't pit people against each other, "oh, Jim got 3 things done yesterday and has never been blocked on 1 thing for over a week, but Dave has made zero progress on his task since two days ago. Shame, Dave, shame. Let us not question whether the task was specified correctly or appropriately broken down."

I know there is a large sentiment at HN that the Daily Standup is dead, or an anti-pattern. However, the truth is Agile and Scrum are still huge. Plus, most do not have a say in the methodologies they use at their job. Why not try and make the most out of it!

Standup was never part of Agile:

http://www.agilemanifesto.org/principles.html

The standup is obviously one method of applying "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation."

Agile also strongly discourages remote work, under the same principle.

"Agile" means Scrum at my workplace. I wish it meant Agile still.

well the idea is that you're going to talk to your colleagues anyway for updates, the only person who really needs the daily standup is a manager who doesn't interact with the work all day.

it's like being treated like a child at times as if we aren't trusted with our own time. other departments don't have a daily standup, why is that?

That's a false idea, I think. I don't interact with all of the other people on my project team every day, but there are still dependencies and useful bits of knowledge that can be exchanged in outline at the beginning of the day. The standup is for all team members, managers and developers included.

Frankly, I think other departments would really benefit from daily standups. The reason they don't is likely because they're not a workflow where there are multiple small, distinct deliverables – which benefits the most from this approach.

If your team is too big to interact with through the course of your work, then your team is also too big for standups.

My team is currently three developers plus a product owner. Two of us might pair up on something for a day, while the third works on something else. We might not interact much during the day, but it's still useful to compare notes in the morning and understand if there have been any developments, changes in priority, or anything that could require discussion. I don't think that's unreasonable.

What if your work consists largely of research and experimentation? No tasks or stories, mostly many long spikes.

What if research and experimentation happens over a period of time and only later there is a period of focused prototype development?

Have you experimented with alternatives to daily standups? Standups three times a week? Changing the routine based on the stage of the work (research vs. development for example)?

What if standups are misused for micromanagement?

If there are so many ways standups can go wrong maybe its not a good generic tool after all?

Sure, I've been there, trying to do R&D under an imposed scrum regime. But, it's dangerous to challenge the current management religion unless you are in a position of power.

The solution is the time-honored practice of keeping two sets of books. Even if your true stand-up report would be:

  Yesterday: thinking.
  Today: thinking more.
  Blockers: meetings like this.

You would be well-advised not to say so. Instead, you need to identify or invent some small subsidiary tasks that can be used for stand-up reporting, e.g.:

  Yesterday: designed alternate schema for one of the database tables.
  Today: timing tests with new schema.
  Blockers: none.

In this way, you can carry out your research, which may involve a meandering path, fuzzy ideas that are hard to express verbally, backtracking, and work in units of multiple days, in private. While doing so, you have a parallel public task list that follows the scrum agenda and can be used to keep people off your back while you work on the actual problems that need to be solved.

If there are so many ways standups can go wrong maybe its not a good generic tool after all?

I don't think that's a useful conclusion to draw. Standups go wrong if they are too long, and that's about the only way they can fail.

What if your work consists largely of research and experimentation? No tasks or stories, mostly many long spikes.

"I researched this area yesterday. It seems like a good approach. I noticed we need to think about how it will scale, but I'm going to look into that further today."

Or even consider that standups are indeed not for your organisation. That's fine.

Have you experimented with alternatives to daily standups?

This is something I would encourage every team to do if they don't feel standups are useful. Try a status email at the end of the day instead, or a weekly status meeting. I definitely think that a standup had value, but I imagine it depends on the environment.

What if standups are misused for micromanagement?

Then fix it. If you are in a situation where you are being micromanaged, then it's not the fault of a standup – it's the fault of a micromanager, and eliminating a standup isn't going to fix that.

>> What if standups are misused for micromanagement?

> Then fix it.

That's easier said than done. It assumes that the micromanager has enough self-awareness and listening skills. If he had, maybe he wouldn't be a micromanager. I tried to fix it but eventually it was one of the biggest reason I left the company.

>> If there are so many ways standups can go wrong maybe its not a good generic tool after all?

> I don't think that's a useful conclusion to draw. Standups go wrong if they are too long, and that's about the only way they can fail.

Micromanagement is another way we already mentioned. Fabulating stories about work done as a means of avoidance is another (as your sibling suggests). I'd say there are even more ways they can fail in general. In specific cases they might still be indispensable.

edit: formatting

Is it just me or does everyone in the picture look younger than 30?

The one guy in the long-sleeve button-up shirt might be in his 30s or 40s.

Async standups may be a good alternative, you can do them over email or on Slack/Hipchat/Flowdock.

Different rules apply in async standups than in meeting-like standups. There's more focus on what your daily status can bring to other people.

I wrote about some tips here: http://andrzejonsoftware.blogspot.com/2014/05/async-standups...

I'm still confused why this isn't just handled via email. Send an email at the end of the day and be done with it.

It depends the project you work on. Typical scrum project is one that contains lots of smaller tasks - the standup is an opportunity for quick interactions, ad-hoc replanning (like don't do Y this morning, I'm not done with X. Should do Z today, not sure where to start, anyone can give me a hand ? Anybody remember what M is ?)

Of course, you can and should do that anytime you are in need, but the standup meeting is a small time allocated where you have the attention of to the whole team.

It can be done in an email - but generally people are not as succinct or too succinct and dialog does not really happen. If dialog does happen in your team, and you spend less time writing email than joining the meeting then why would you not do it via email ?

I guess because sometimes people don't read email properly. If people actually meet up, you can be mostly sure that everyone has heard and processed everyone else's status updates, especially if the meeting is quick enough that people don't get too bored.

Email is asynchronous. Impediments can't be addressed with the same immediacy.

Yeah, but do you want to have 10 people go through their 5 minute thing every day? Its basically a whole hour that could have been better used.

Reading the same thing in email form and replying would maybe take 15min.

Yeah, but do you want to have 10 people go through their 5 minute thing every day? Its basically a whole hour that could have been better used.

Every company is different, but in my opinion that's just a meeting rather than the canonical standup. I wouldn't expect a 10-person standup to take more than 15 minutes.

90 seconds per person?

I've never seen any meeting go that fast.

Then your "standup" meetings are being run by an incompetent person; I've had that happen on several teams, as well, and it resulted in some miserable months; but, when it works well it works well. It is completely up to the person leading the meeting to set the tone and keep the pace - they should be interrupting people who take too long and moving it along.

Properly run, people should just be reporting on status and impediments, not details.

Remember, most people don't have anything to report: "I'm working on my stuff, no issues, that is all."... that's like 10 seconds tops.

or, "I'm done, moving on to my next task". What's the next task? That's already been assigned at the start of the sprint, don't need to go over it here. If someone wants to know, they can look at the task tracker - if someone needs to change priority "need X done so I can work on Y", they can make a quick comment, or email after the meeting.

even if it is "I'm done with my last thing, i need something new" -- you don't need to get that new thing in the meeting, the boss man knows you need something, they'll assign you something after the meeting.

... that leaves room for people with issues. And they still shouldn't take long. "I'm stuck! I need help with Z!" that gives time for a few people to say "I can help with that" and someone to be picked.

Anything more should be a meeting of its own with just the effected people (not the entire team). Detailed status should be in nice clear comments in your task tracker.

When done well--and I'm pretty down on Agile in general, though I find standups valuable--ninety seconds should be at the high end, on average. I mean, sometimes people have a problem that needs some crosstalk, and they might go a little longer, but that should be rare and the person running the meeting should aggressively push that stuff to after the meeting whenever possible.

IMO, at least, if your team takes more than 15 minutes going through 60-90 second blurbs of their day, your team either needs to get better at succinctly summarizing their stuff (and aggressively pushing side conversations to follow-ups after the meeting) or your team's too big.

Excellent point.

Also when problems are raised; you will get tons of responses to email; taking the time of many people.

As opposed to being assigned one expert to help, taking the time of only one additional person (ideally).

The perfect daily standup is an email.

Reply on news.ycombinator.com