Standups are Not Poisonous

Standups can however very easily become very uncomfortable in a dysfunctional environment. (As the original article unwittingly demonstrated.)<p>Consider the standup to be the canary in the coalmine. Most of the time people can ignore the dysfunction, work around it and pretend it isn't happening by just getting on with the job as much as possible.<p>But the standup will then become increasingly uncomfortable. <i>Every single day.</i><p>In a healthy organisation, you can have perfectly pleasant standups, even without Scrum or Agile. I mean, what does a healthy team have to fear from standing around for a few minutes bringing each other up to speed?<p>It's a process that is very close to what often happens quite naturally around the time everyone on the team has arrived at the office (or online).<p>A standup can only become poisonous if the poison is injected from elsewhere. In Gareth's case abusing it for management status reports. In other cases it might be tension between team members, not having a clear goal, whatever.<p>The point is, you cannot have pleasant standup if there is that kind of stuff going on. Which is all the more reason to have a standup, unless it's your policy to ignore problems rather than dealing with them.<p>Standups aren't just <i>not</i> poisonous either: they are a very good poison detector.

I used to hate standups when I was at Yahoo. Maybe it's more a sign of how broken Yahoo is than how broken standups are, but the daily process was roughly:<p>0. 9am, catch up on email, then coast for a while knowing you'll have to stop work at 10am.<p>1. Find out which meeting room the 10am standup is in<p>2. Figure out where in the building that room is<p>3. Travel to the rough part of the building, hunt around for the room.<p>4. Wait for everyone else to do the same.<p>It's now 10.20am<p>5. Stand (OMG the standing!) around for 30 minutes listening to a boring load of status updates from 20 people that have absolutely nothing to do with you.<p>6. Give your status update (Yesterday I did some work. Today I'll do some more work. What's blocking me is this f'king meeting.)<p>It's now 10.50am<p>7. Travel back to the part of the building your desk is in today (if you can find it) and grab a coffee on the way.<p>That's an hour gone, and it's only another hour to lunch, so no point getting into anything too major. Knock off some smaller to-do items. Lunchtime!<p>An alien race observing us would conclude that teams were a device used to prevent work getting done.

"Remember, they are not status meetings."<p>Additionally, I think it is important to remember that standup is not a "justify my existence on the team" meeting. Having nothing to report is fine.

Honestly, I can't understand all of the vitriol around "agile" methods that arises here occasionally. If you're doing something that works for your team, do it, if it doesn't work, do something else. Isn't that the whole idea behind "agile" stuff? Do people get stuck in situations where they have to do X because "we're doing agile, and agile says we must do X"? If so, can't the offenders be gently pointed to <a href="http://agilemanifesto.org" rel="nofollow">http://agilemanifesto.org</a> ?

IMO the usefulness of standup meetings depends entirely on the project and the team. It's impossible to categorically say they're good or bad.<p>For a while I worked on a team with a small codebase, which we all knew pretty well, and it was very likely that if somebody made a change today, I'd be working in the same area of code in the next day or two.<p>In that situation I thought standups were really helpful.<p>My current team/project is a bit larger and it's maintenance on a much, much larger code base. The project is large enough that nobody really knows the whole thing very well, and everybody works on a different section and there's not much overlap. If I were to switch places with somebody I'd have a lot more to learn than just what they've worked on recently.<p>On this project we're still required to do standups, but they're useless. The information wouldn't be very useful to me even if people kept to one or two sentences of what they were doing. Of course, few people do that, and they usually go into obscure details that maybe two people in the whole group really understand. And that's when I tune out...

At my current job at turntable.fm, we only have standups twice a week (Tuesday and Thursday), and I honestly was surprised at how effective that is. I've always operated under the assumption that a standup needs to happen daily to be valuable, but trying them 2x weekly has changed my mind.<p>I think the real problem is when a standup is the only way that a team actually communicates status. At turntable we rely heavily on chat, which also contains messages indicating when new things are being pushed, and we also make it a point to have a lot of face-to-face communication. Our twice-weekly standups are a good way to fill in the gaps, if there are any, but they are by no means the only way that people find out what's going on.

I have tried to get this point across at every place I have worked. Management covets micromanagement, so stands turn into status meetings.

Every daily standup I have been a part of or organized has turned into a status meeting. The biggest "tell" of a status meeting masquerading as a standup? When people address the boss, not each other.

I personally hate standups. They are the 21st century version of Chinese Communist style Daily Morning Exercises. <a href="http://www.youtube.com/watch?v=o_2C3bvh6ms" rel="nofollow">http://www.youtube.com/watch?v=o_2C3bvh6ms</a><p>Usually they either are void of real information (as they are supposed to be quick) and nothing is discussed in depth, or if things do end up discussed they end up taking too long.<p>Unfortunately they have propagated in most work places/engineering cultures.<p>Information should flow naturally between engineers. If you have a jelling team, people should communicate with each other naturally, without having to be forced to stand up and listen to status reports (that's exactly what standups are).<p>I prefer once or twice a week engineering 30mins sync ups. Short meeting, that get to the point on whats going on, and you have some time to discuss things in depth if needed. For any small things, the expectations would be that engineers should communicate with each other directly.<p>Instead of having 5 interruptions a week, you have one or two (slightly larger ones). At the end of the day accountability should be on the delivery of projects (end results), and not efforts (which standups are more about showing efforts, rather than results).<p>From personal experience, experienced engineers tend to highly dislike them, and the over-reliance on standups is an indication of a weak engineering culture.

Both articles lack context, which we're all just filling in with our personal experiences with standup meetings, hence the pointless "debate" in the comments here.<p>I've noticed that developers can be divided into two groups based on whether they prefer to work with others or by themselves.<p>Those that prefer to work by themselves take chunks of work that can be done without input (formal or informal) from their fellow developers, (who they may refer to as "teammates" despite the fact that they don't work as a team in any real sense.) For this group, having a daily standup is a waste of time, because there is no work to coordinate.<p>Those that prefer to work with others take chunks of work that can't be considered complete until their fellow developers have also completed their portions. They seek continual input from their teammates in order to keep everyone on the same page. For this group the daily standup is just a more formal version of what they already do informally.

Offtopic - Hate these "github.com" posts that are actually from some blog hosted by some random dude on Github. Makes the domain bit meaningless. Wasn't there some fix for this to show more of the domain in certain cases?

I'm on my fourth team now since 2005 where I have helped successfully employ scrum, and stand ups are a great part of it. A couple of the biggest mistakes I see being made are:<p>1) not correctly identifying "chickens" and "pigs"[1]. Pigs get to talk in a standup, chickens do not. In fact any interaction with the pigs and chickens should go entirely through the scrum master (and not during the standup). If chickens want to come to the standup it is to observe only.<p>2) conversations. The standup is not the time for conversation. The best method I've employed is to have each person specifically answer three questions: what did you do since the last standup? What are you going to do between now and the next one? Are you impeded in any way? The last one is where conversations often start. Scrum master needs to stop those, identify the people who need to talk <i>after</i> the stand up, and move things along.<p>When you follow those as hard fast rules, standups shouldn't take more than N*3 minutes where N is the number of pigs.<p>[1] <a href="http://en.m.wikipedia.org/wiki/The_Chicken_and_the_Pig" rel="nofollow">http://en.m.wikipedia.org/wiki/The_Chicken_and_the_Pig</a>

Standups would make more sense if the team did not communicate during the day. The reason I think they are pointless is that when a blocking issue arises, you drop what you're doing and walk straight over to the person who can help you. I've never seen or heard of someone waiting until the following day's standup to bring up the issue (which is supposedly what the standup is for, right?).

Standups work really well when there are dependencies between different functional groups.<p>Consider a team working on a live browser/Facebook-based free to play game (social game as a service). There are many releases a week.<p>- Engineering typically requires art assets to begin/complete work. Ie. building models, unit models, 2D unit images, item images, etc.<p>- Releases don't end when they are pushed up to prod -- most releases have some kind of "go to market" plan that must be executed. For example, if a new Dragon Armor is released, we need to message all players to inform them of the new functionality and educate them on how it works, there would typically be a simultaneous tournament or contest that awards the new Armor as a prize, and possibly some other sale or promotion on a related item.<p>- It's a time for product to provide updates on where different specs are and on key game metrics.<p>- Customer Support/Community Management also provide updates on any emerging issues in the game, which improves everyone's situational awareness.

Standups are like communism, great in theory, often horrible in practice.<p>Of all the standups I've participated in going back 5 years I'd say only one was any good. It was every other day, it was forcibly limited to 15 minutes or less, it was always on time, it was never allowed to go off on a tangent, it only had about 3 or 4 people in it, and it was actively pushed away from being a status meeting. This contrasts with every other standup I've been a part of which almost always cut into productivity, and worse. For a while there was a daily standup with 12+ members that often went for 45 minutes and sometimes went for an hour and a half.<p>The problem with a formalized methodology like standups (or agile in general) is that if you don't have very well defined and explicit reasons and goals and you don't make that a part of the system then people will just drift into doing what seems to make sense to them, which is status reports and aimless meetings.

I think the summary of this could be, "Ineffective meetings are ineffective."<p>Meetings are one tool among many for team communication, it's just that very few people are able to run a meeting effectively. I used to believe that all meetings, in any form, were a waste of time. Right up until I worked for someone who actually knew how to run a meeting. It was amazing - in a 12-15 person meeting, everyone person contributed, tangents were quickly cut-off, and they rarely lasted more than 30mins. Sadly, she was promoted (i mean, good for her, bad for my group at the time) and without her guidance our group meetings quickly reverted back to a multi-hour mostly useless waste of time.<p>The lesson I learned is not to dismiss meetings outright. Spend some effort learning how to run them effectively, and it's still a useful communication tool.

We run stanups at my place. Everyone keeps their time to talk brief as possible and we have a rotating leader to keep people out of the weeds. It works out quite well, so I agree strongly with the article that stand ups are not a waste.

We don't do standups.<p>Trello does all the communicating.<p>1) It tells me whats done and what is not, through the checkboxes<p>2) On larger projects, the guys leave updates in the activity section every couple of hours or when they hit a milestone or a are stuck with a problem or are unsure of something. Think of these as like facebook style updates but for large projects.<p>These updates are delivered to me in real time. We can then discuss any problems etc at a suitable time at their convenience or I can pre-emptively direct them to someone who can help. Unless the problem is urgent in which case we discuss it then and there.<p>This way I know what's what and the guys have an open channel to me.

If your standups are bad, there are things other than the standup that are going wrong:<p>If it lasts too long, the person running it has lost control<p>If it ends up berating a coder twice a day, every day, regarding a multi-day implementation task, the person running the standup is an incompetent project manager<p>If, as others have given examples of, people zone out, or become unconfortable, the project has become toxic and the standups can't fix that<p>If standups adhere to dogma more than they solve problems, the person running them lacks critical thinking skills and knowledge of project management techniques

I'm inclined to agree that Standups can be quite good.<p>Every morning we have our meeting which maxes out at 15 minutes. The designated note-taker rotates daily and takes the list of current action items to be added to RedMine.<p>The biggest difficulty was fairly simple actually - removing digression from the mix and also removing things we've completed from the meeting.<p>There are no side conversations while stuff is being covered, and every day we sum up what we did in a company-wide email. Other subjects happen offline between relevant parties. This has been remarkably effective for us :)

A few times a day, I say to my colleagues "Want to grab some coffee?" and then we go to the coffee machine and get coffee. It is inevitable while doing that we talk about what we are doing, roadblocks, etc. and sometimes we have nothing to say and we talk about something else.<p>That works for our team of 4-5, but I understand that it can't scale. Of course, if management started calling it a stand-up meeting and took away the coffee, I'm fairly certain we'd get less out of it.<p>tl-dr; why is a stand-up meeting better than just grabbing a coffee with your colleagues?

I'm a developer and not really a fan of standups, I find them monotonous and dull and often "zone out" after I've said my bit, but I can see how they are useful to management.<p>The problem with standups at the company I work for is our team work on multiple projects so standups end up being just "I'm working on project X and it's going well, no blockers, cheers!" updates from everyone in the circle.<p>Standups are probably better for teams working on a single product as everyone has a stake in what's going on

IMO Standups are very useful for a team that works remotely. Placing them in the middle of the day ensures that nobody's going to have to bend his or her schedule unreasonably.<p>Would you rather get at least one extra IM or phone call(?) from each member of the team randomly throughout the day as you're quietly and productively working in your own zone?<p>I'm all for anything that tends to eliminate mental context switching during the day. Needless to say, not a fan of any office environment for coders.

My old group started "doing agile." We had daily scrums. They quickly turned into status meetings for the PMs to bubble up micro-progress reports.<p>This, on a team with four engineers and three QA types. We sat next to each other. We didn't need standups, we needed to be left alone to do work.<p>Finally, on one project the PM (who had appointed himself scrumlord) finally let us meet only twice a week, and had the common decency to call the meetings "status".<p>Call things what they are.

I appreciate the author taking the time to write the article, but my opinion is that the whole purpose of a daily standup is to open a line of communication between team members. Well, if you have this line of communication open 24 hours, emails, chat (xmpp, irc ..etc), phone, and so forth, why do I need to wait till tomorrow afternoon for the scheduled daily standup to talk about a blocker in my code?

Regarding the usefulness of standup-meetings I've written a blog post on how we do them at Blossom:<p><a href="https://www.blossom.io/blog/2012/09/17/3-tips-for-quick-effective-stand-up-meetings.html" rel="nofollow">https://www.blossom.io/blog/2012/09/17/3-tips-for-quick-effe...</a><p>If done well they can be a great facilitator. Just make sure it fits your culture.

At my company, we have a HipChat room for "Daily Updates" and an automatic reminder that notifies everyone to post what they did yesterday and what they plan on doing today. That's it.<p>Most people post by noon, and the manager has a written log. It's been working well so far.

This just seems to boil down to well-run meetings vs. poorly-run meetings. Standups are meant to be light-weight meetings where everyone gets back on the same page. If that's not happening, then someone isn't running the meeting correctly.

Standups, when well done on a healthy team, aren't poisonous. But I've found that they're rather pointless as well. If you have enough unforced communication in your team, you don't need the standup.

When I first started doing standups, mine were longer than necessary. But as I got more comfortable and the team's workflow jelled, I've gotten better at being concise.

One on Monday before I start and one on Friday before I leave. That is how I do it and it works.

I am wondering where you guys draw the line between a standup and a status reporting meeting ?

"Gareth Rees’ article titled, Standups are Poinonous hit HN" ... I stopped there.

Holy crap, he has 3 hours standups? They're called "STAND UPS" because you stand while giving them so that you're motivated to be quick! I actually try and follow the one-breath rule for what have I done, what am I doing, what are my blockers.

What's a standup? I didn't see it defined in either post.

For my show and tell, sniff sniff, I ...

I'm genuinely curious, how are standups <i>not</i> status meetings?<p>From the article:<p>- Make sure everyone is working on the right thing<p>- Help out other team members by taking work off their plate or helping them by sharing domain-specific knowledge<p>- Keeping everyone informed<p>How is that different from a status meeting? I've heard "standups are not status meetings" over and over from the agile community, but I don't get it. They sure seem to be quick status meetings that allow everyone to get a handle on the current <i>status</i> of the iteration?

Aside from standups becoming status meetings (which it a mechanism of superficial management used by terrible managers), one of my gripes with them is that they're often redundant -- everyone should know what everyone else is working on, and what everyone else finished, and any blocking issues, via your agile tool (e.g. Rally). Redundancy in information is a terrible, terrible thing, and it leads to a situation where neither becomes canonical because <i>that other thing</i>.

Who's doing standups with a 6 member team for 30 minutes? That's nuts.<p>We're a 6 member team and our standups are typically 5 minutes or less.<p>We stopped that "what you did yesterday, what you're going to accomplish today, do you have any roadblocks" rigor nonsense.<p>We just turnaround to see what's going on. In the beginning, I was pretty turned off by the rules we were using for standup, but once we stopped all that, they're pretty helpful, just so we know where we all stand.<p>My first job out of school, we had a developer that claimed that he couldn't get any work done around the office because he was constantly being interruped. Well, his boss let him work from home on this very important project with a hard deadline. Well, he wasn't checking in and he was being vague about where he stood. Lo-and-behold, 3 months later he has nothing to show for, and he's history.<p>As a previous poster put it, standup can be a canary in the coalmine.

Standups are a symptom of a failing software engineering disease called 'Agile', which is the real toxin to the system of all healthy developers.