Ask Slashdot: Are Daily Stand-Up Meetings More Productive?

__roo writes "The Wall Street Journal reports that an increasing number of companies are replacing traditional meetings with daily stand-ups. The article points out that stand-up meetings date back to at least World War I, and that in some place, late employees 'sometimes must sing a song like "I'm a Little Teapot," do a lap around the office building or pay a small fine.' Do Slashdot readers feel that stand-up meetings are useful? Do they make a difference? Are they a gimmick?"

Comments

Curious

[Ethanol-fueled]

It's curious that they mention the military first doing stand-up meetings - when i was in the military, you stood up only when you were about to fall asleep, but that's all that needs to be said about that.

In the civilian world, if you have meetings every day, it's because your boss or some other important idiot is a bottleneck in the process and they need daily reinforcement of common sense, at the expense of department productivity.

Re:Curious

[snowgirl]

In the civilian world, if you have meetings every day, it's because your boss or some other important idiot is a bottleneck in the process and they need daily reinforcement of common sense, at the expense of department productivity.

Alternatively, it's a great way for a manager to enforce office hours on their should-be-flexible-schedule programmers if they set it early in the morning, but then that just bottles down again to "a manager who insists on micromanaging everything, and being a bottleneck".

Re:Curious

[kiwimate]

In the civilian world, if you have meetings every day, it's because your boss or some other important idiot is a bottleneck in the process and they need daily reinforcement of common sense, at the expense of department productivity.

From the article:

The current wave of stand-up meeting is being fueled by the growing use of "Agile," an approach to software development, crystallized in a manifesto published by 17 software professionals in 2001.

Which is true.

Don't be so quick to blame management. I know it's a reflex here on /., but the current craze for stand-up meetings, scrum, agile, etc., are being driven by tech staff.

Re:Curious

[jellomizer]

You don't get the point of the standup meeting. Why is it standup, it is to keep the meeting short, and to the point. Where otherwise it will be an hour long sit down meeting once a week.

The daily meeting has other advantages.
1. It puts everyone in the same room at the same time and they know what is going on daily. This can stop duplication of effort as sometimes you get multiple requirements across many people but the work is actually nearly the same.

2. It helps focus on what your tasks are for the day. Let's face it, there are days that you slack off on not because you don't have enough work but because your daily goal wasn't there. A quick meeting where you need to state your goal keeps you honest and helps you know your goal is for the day.

3. It is informal and no notes, nothing gets fixed in stone, allows for more of an honest assessment.

4. Team lead is informed on what is going on, and when pressed by management he has the answer.

5. Simple problems can get solved easier. After the meeting people's schedules can disconnect and it could take days to answer a simple question.

6. It keeps your team together.

Re:Curious

[Anonymous Coward]

Seriously, what does this have to do with anything?

I've read and reread it several times and it makes absolutely no sense. How are being a scrum master and knowing Dijkstra's algorithm connected in any way?

Re:Curious

[TheLink]

but the current craze for stand-up meetings, scrum, agile, etc., are being driven by tech staff.

That's daft and primitive though. The real tech way of having more productive meetings is: require most meetings to be done via text instant-messaging (IM):
That way:
1) you automatically get minutes of the meeting (the bosses could require the transcripts to be posted somewhere).
2) you can be in multiple meetings at the same time, potentially even chairing one meeting while attending a few others. Heck the bosses could attend them all, not to chime in like an idiot, but in case his/her official approval/opinion for something is required (reduce latency!).
3) you can do work and other stuff (slashdot, youtube)[1] while attending the meetings.
4) You can set "AFK", go to the toilet, come back, and scroll up to see what happened while you went AFK, without requiring everyone to recap or wait for you.

Now of course programmers generally are better off with an uninterrupted stretch for heavy-duty coding. So what bosses could do is require most/all meetings to be within a certain time range of the day. With IM meetings, it is not a showstopper if you have a few meetings scheduled for the same time.

This way bosses can squeeze even more out of employees ;).

Of course this requires employees who can actually read and type at reasonable speeds, and multitask.

With normal physical presence meetings (stand-up or not), you could have 5 people mostly idle, with the only the chairperson reasonably busy, for the entire meeting time. Not very efficient.

IM meetings could take a bit longer - many people don't type as fast as they can speak and do a normal presentation, but I don't think that's a show-stopper.

FWIW, are stand-up meetings really more productive and effective than other sort of physical meetings? Or are they merely shorter, leaving more time to get the work done... You can actually have productive meetings - you must have a good reason for meetings, agenda, etc etc (plenty of stuff written on that already).

[1] This gets harder once there are too many meetings in parallel that require your concentration, but hey you want productive right?

Re:Curious

[BasilBrush]

I guess the egoless programmer part of Agile methodologies wasn't for you then.

Re:Curious

[squiggleslash]

You think that's bad? I had to go to the doctor the other day, and he was all "Well, let's cure that cancer of yours" (or whatever it was) and I was like "Hold on a moment, do you know Bresenham's line algorithm?

Would you believe he didn't? I had to NOT merely describe the algorithm, AND explain how to use sign changes and axies swaps to ensure any line could be drawn, but even what a damned BITMAP was. I walked right out, I wasn't going to trust HIM to heal my brain tumor.

Also the so-called plumber didn't know what a singleton was. I'm getting impatient now, I've rigged up a siphon to suck water out of the laundy room into the yard, but I haven't found a single pumber yet who knows a damned thing about programming.

Re:Curious

[DJRumpy]

I think a better way to go would be to stop inviting everyone from the top down to meetings that could be better served via email, or even IM. I find a don't pay attention to meetings that have little to no affect on my daily work yet they continue to invite me regardless, 'just in case' or because it's a major announcement for some VP who is changing departments, or some tweak to benefits, etc. I also get invited to technical meetings for various topics on projects I am only peripherally working on yet I'm on the invite list for every meeting regardless. They would be better served inviting key folks and let the disperse the info as needed rather than inviting people who's time is better spent getting work done.

As to the 'gimmick', yes it might wake people up, but it will also make them irritable, rebellious, and take them out of the proper productive frame of mind that often generates good ideas.

Re:Curious

[Daniel Dvorkin]

"Company! Yesterday, I did a lot of pushups! Then I low-crawled! Then I cleaned my weapon and did some more pushups! Today, I'm going to walk a lot! My impediments are the group of people across the wire trying to kill me! Hoooahh!!"

Not everyone's 11B, you know.

When I was a medic, we had a simple, informal process for shift change and report. "Here's what happened on the night shift, here's what's going on with the patients we have in here right now, hope you have an easy day." Once a year or so, the DoD would go through some management-techniques craze sold to the brass by some Senator's brother-in-law, and the word would come down from on high to use whatever the latest buzzword methodology was. We'd play along for a little while, and then when they weren't looking over our shoulders any more, we'd laugh and forget about it and go back to doing what actually worked.

Nothing I've seen in my years in industry and academia since getting out have convinced me that there is any value at all in any kind of meeting ritual. The more "process" you try to ladle onto the job of communicating with your co-workers, the less actual communication takes place. This is true regardless of whether you're trying to take and hold ground, save lives, or just get the damned code out the door.

Re:Curious

[Anonymous Coward]

Well I did a computer engineering degree and I don't know Dijkstra's algorithm inside out. Of course, we spent our time actually learning and solving problems, not memorizing algorithms.

Re:Curious

[Antidamage]

This is what I came to say. We had standup meetings every day and it devolved into one particularly megalomaniacal aspie micro-manager telling staff how to stand in the most abusive tone possible. I quit shortly after that started.

Re:Curious

[Anonymous Coward]

You do realise that scrum teams are cross-functional, right? As in, your backend developers, UI developers, DBAs and testers are all part of the Scrum team, and any one of them can be the ScrumMaster? And the entire role of the ScrumMaster is to facilitate the team with the Scrum/Agile process, and to help clear any road blocks in place?

That, and the fact that your snobbish arbitrary litmus test is complete bullshit, and would only ever be performed by a basement coder desperate to prove his worth with meaningless, idiotic technical buzzwords. It's the kind of test a startup company asks in a job interview, in order to really ensure that no developer worth his salt would want to work there.

Re:Curious

[Anonymous Coward]

Nonsense. If you were spending a lot of time on an algorithm that can be learned in 10 minutes on wikipedia then your education was progressing at an interminably slow rate.

Re:Curious

[Anonymous Coward]

Sorry, but no.

Dijkstra's algorithm is an important notion in computer science, but it's not used on a day-to-day basis in day-to-day programming tasks in the software industry. Using that as a dick-measuring stick is inaccurate because it emphasizes stuff-college-students-were-told-was-important versus real-world-software-development knowledge. If you asked me who I'd rather have as a "Scrum Leader," I'd choose someone with solid, real world software development leadership any day over someone who could recite Dijkstr's algorithm off the top of their head.

I think that the fact that you used a phrase like "scrum master" says a lot about the type of software developer you are.

Re:Curious

[aristotle-dude]

Dijkstra's algorithm is a good litmus test of somebody's programming and software development knowledge and experience.

BZZZT. Wrong. It is a litmus test to see how recent of a graduate you are of a computer science course and whether your training focused on memorizing search algorithms or honing your problems solving skills.

Anyone with any formal computer science, computer engineering, or software engineering education will know it inside out. Even many people who studied mathematics or physics will be familiar with it. It's a relatively simple algorithm that's easy to explain quickly, but it also touches on a variety of important concepts, and is quite applicable in the so-called "Real World".

Sorry, but computer science does not alway prepare you to be a proficient software developer as the course material can vary considerably from institution to institution.

Many software development professionals see it as a not-so-secret secret handshake, so to speak. If you know what you're doing, you'll find explaining it trivial. If you don't know what you're doing, you won't be able to. It's a fast way to separate those who can do from those who just talk the talk.

Sorry but you don't seem to have a clue about how modern software development functions and how it differs from pure computer science.

To be a scrum master, you should have at least this minimum level of knowledge of the field. That's where the connection comes in. Seeing if somebody knows Dijkstra's algorithm is one of the most basic and effective ways of seeing if somebody is qualified to be involved with software development.

Sorry but you do not understand what the function of the scrum master is. The main function of the scrum master is management of the team's velocity in an iteration. The contents of an iteration is determined by a combination of end user priority, estimation points on the stories which were candidates for consideration and the estimated potential velocity/throughput of the team involved. In essence, a scrum master is an imbedded team lead/manager/product architect.

Knowledge of how to implement a search algorithm is pretty much useless in most real world applications in businesses especially when most people would just leverage what is already present in a framework like .NET's linq or use the power of a RDMS to sift through data. There is often no need to "reinvent" the wheel and even if there was such a need, chances are, someone on the team would have already written a generic common library function for the most efficient search algorithm if you happen to be using a framework poor language such as C/C++.

Re:Curious

[moderatorrater]

Mod parent up. I've been in software development for 5 years now and Dijkstra's algorithm has never come up even once. I learned it in college, I know it, but claiming it's any sort of litmus test or secret handshake is just wrong.

Re:Curious

[Surt]

It's fundamentally impossible for any process to defeat a bad employee with the authority to subvert it. This is why hiring is the single most important meta-function that occurs in any organization, and if you don't put a LOT of energy into it you are screwed.

Re:Curious

[konohitowa]

Knowledge of how to implement a search algorithm is pretty much useless in most real world applications in businesses especially when most people would just leverage what is already present in a framework...

This is exactly the point I wanted to make. I've been doing professional software dev for over 20 years and if an interviewer asked me to explain an algorithm off of the top of my head I would immediately know that this is not someone I would ever want to work for – primarily because it tells me they're clueless and quite likely in way the hell over their head. Frequently, software development isn't about what you know... it's about what you don't know and how quickly you can learn it. Yes, there are some core things that help along the way, but being able to regurgitate a bunch of facts only tells me that you'd do well on the MCSE exam. How well you could deal with unknowns (i.e., whether you can do problem solving or not) is unrelated to amount of trivia you can spout.

As to standing meetings... been there, done that; circa 1998 or so (IIRC). Yet another attempt to avoid the correct solution to "the meeting problem". The correct solution is to stop having regularly scheduled meetings. You can easily schedule meetings as the need arises. I would also be for voting by the invitees as to whether the meeting is necessary or not.

Re:Curious

[houghi]

I think a better way to go would be to stop inviting everyone from the top down to meetings that could be better served via email, or even IM.

The reason we did a weekly standup meeting of 15 minutes was because people did not read those email, web announcements or what not.
Sure, you could force them to reply to mails or fire them if they didn't know or whatever. Sometimes however mails arrive at moments people are doing other things. I leave it out if they are important or not.

So a good solution was to TELL them in person what was important to us and listen what was important to them.

This did not mean that we would read each and every email we had send. What we did was pick 3 points that needed focus. This could be deadlines, major changes in procedures, drink after work, new projects, stats and numbers, announcements, ...

We held them in the kitchen, because that was where the coffee machine was. After a while you get pretty good at it and it can be done easily in 15 minutes.

Obviously it all depends on the size of group, the information you want to bring across and the way you bring it.
If you want several thousand people standing in line and yell at them how horrible they do their job, that might be a bit wrong.

I would say max 10 people in total. More needs to be split. It will not me magical. It will however cooperation and understanding.

Oh and no handouts, unless you can eat them. Just a short minute online for upper management. (Your staff is not going to read it. Otherwise you would not need those weekly meetings.)

We called them "Power Meettings". The time you do it depends on the goal of your meeting. Do you want to inform how you did? End of the week. What you want to do? Begin of the week. And no, no 9:00 meetings.

Re:Curious

[Uber Banker]

I think this depends much on the dysfunction of the organisation as a whole.

Regular daily stand-ups are great for dysfunctional organisations, not exclusively but particularly, as much signal can be added to noise. "Dave has X issue yesterday, this is how he fixed it." "We're expecting high volumes over the coming week." "There's a new UAT manager in Y." Absolutely fantastic for these things, but very short and sweet. It ensures everyone hears the osmosis at a high level, and allows the team coordinator to share their daily dashboard highlight view, all to enrich each of their views.

Not in a meeting room, not sitting down, just standing up for 5 minutes face-to-face. That level of information sharing, especially in dysfunctional organisations where an individual's inbox may receive 900+ emails per day, which I have seen and been horrified at, is essential.

Absolutely not saying they're only useful for dysfunctional organisations, but are a necessary daily for dysfunctional organisations.

How to do them well? Empower all; do not dictate; keep to 'team' size which should be 5-10 people, any teams larger than this probably have difficult structural issues, a team larger than 10 cannot empower a stand-up as it will unless with great skill degenerate to a grand town meeting.

sure they're helpful

[raind]

You go outside with your boss and have a smoke and tell him what's really going on..

I'm sorry, what?

[grasshoppa]

I'm late to a meeting, for whatever reason, and you are asking me to do what now? No. I don't think so.

But by all means, try it. Not only will it undermine your authority ( which can't be all that strong to begin with, if you have to rely on silly shit like this ), but it will create some seriously awkward moments ( which I have trained myself to be immune from, for just such a situation ).

Re:stand up - sit down

[forkfail]

Then you're doing it wrong. The standup should be for status and blockers only - if you need another meeting, schedule it during the standup.

Their great if done right.

[Lifyre]

We run an end of the day 5 minute run down meeting. It is a great way for managers to catch patterns, problems, and just generally keep a finger on the pulse of how things are running. The key is the 5 minute time limit.

It makes it easy to pass information up and down the chain and maintain the focus.

-Lifyre

wow

[w_dragon]

That article reads like a list of every stupid idea a project manager has ever had. Here's an idea: keep the status meetings to once a week major changes in the project, keep individuals informed of changes that affect them as they happen, and let the workers do the work. When we're done, we'll update the feature/bug tracking system to indicate that we're done and move on. The tracking system will then notify the next person down the line (QA, build, PM, whoever) that something is ready for them, and if they have questions they can come talk to us directly, one on one. Go back to the agile manifesto, and screw off with all the buzzword-laden process crap.

Standups can be extremely useful.

[forkfail]

When used properly.

If they are kept short, if folks give status, indicate plans and lay out blockers, without drilling down during the meeting (you can always schedule another meeting after standup, but standup is not the time for deep discussions).

In general, when used correctly, agile is just the fitting of good work habits and practices to the reality. No matter what the approach, an individual should have reachable short term daily goals, weekly goals, sprint level goals, etc. Forming the process around good work habits can indeed massively increase productivity.

With that said, no management/team approach will in and of itself fix a broken team.

Re:Really?

[forkfail]

Seems to me that if folks have to use public shame as a whip, the team has more problems than simple standups will fix.

On the other hand, the pride of being able to come in every day and announce the accomplishments is a positive motivator.

Only works with respect

[Tony Isaac]

When I first brought daily 10-minute meetings to my programming team, they were skeptical. They hated meetings because they had been long and unproductive. But recently, after three years, I gave the team the option to reduce the number of meetings to, say, twice a week. Unanimously, they wanted to continue the daily meetings. Each of them said they got a lot out of them. They felt they knew what was going on, and many problems were caught before they grew.

The thing is, I respect my team members. I treat them like they are the professionals they are. In return, they give me everything they've got.

Daily meetings done right can be highly valuable. Done wrong, they can be torture.

I'd rather not stand

[Liquidrage]

I've run development projects for about 15 years now. I've always considered development a creative process. And as such I've always avoided too much structure in developers time. I'm not going to say to anyone, "Every day at 9:30 we're going to spend 15 minutes talking about yellow post-it notes". There will be meetings. But overall I treat developers as professionals, I'm not monitoring their time. I'd rather have 35 hours of productive time then 50 hours on the clock of which 10 is spent avoiding work and another 10 not giving their all. And I'd rather they stay until is needed without needing to be asked when the time comes because they appreciate the freedom they get normally. Basically, I measure productivity and not timesheets. I have no problem approving a timesheet that is "short" on hours as long as I feel the production was there. Some people like working late and come in late. Some early and leave early. Some like to skip out after 37 hours a week, but if they're productive why do I care?

I might be lucky and through many stops have it always work for me. But overall a process development is simple. Get me good requirements. Do a good design. Develop with good practices and patterns. Test it. Deploy. More than that is a solution looking for a problem IMO.

I've had several developers come in early and stay late and not do as much work as someone that always sneaks out a little early. What's the big deal unless their pay levels are off? The stand up's just seem childish and are a fad. I hope!

Not too often

[ToasterTester]

When people stick to the idea, previous days targets, any issues, todays targets, and move on. It fine, but when others start whining or manager wantabee start say "don't be so negative..." it turns to be a pain.

At another place I worked we had morning meeting (sit down) with all who were at work. Meeting was set a one hour max. Manger made any annoucements and floor open to issues and questions, very informal. Those ended up being good meetings very informative and some morning only 15 minutes long.

Re:No meetings are even better

[ohnocitizen]

Good communication is the key. Not email, or meetings, which are just mediums. Its all about the data being transferred. I've had meetings/status updates via email, bug tracking, chat, phone, in person, and in person stand ups. They all fail when the communication is poor, and succeed when it is clear and concise. With relation to the post itself, yes, I think it is a gimmick (especially "penalties" for not jumping through the right hoops). Invest in making sure the whole team understands how to communicate effectively. That will pay dividends that will help your company really grow.

Re:No magic bullet

[Daniel Dvorkin]

Wow, you've really synergized your paradigms for maximum best-of-breed stakeholder network impact, haven't you?

Re:So wait,

[Austerity Empowers]

Depends on what you're smoking.

Dilbert

[Frankie70]

http://www.dilbert.com/fast/2008-04-15/

What a prick

[SuperKendall]

I have a CS degree. If you had asked me how find the shortest path across a graph with positive edge values, I could have given you that algorithm. I even did an implementation in code.

But I didn't remember it being called "Dijkstra's", though I must have heard the term used. I've always had a rough time remembering names, and isn't the algorithm way more important than the name given it?

Furthermore why WOULD a scrum master necessarily be a CS name-dropper like yourself? I'll bet he could ask some question about SCRUM that would have you shitting your own pants.

I hope (for the sake of your team) you were fired and that your ego someday cools down to somewhere below supernova level. I can't imagine working with that level of prickery, I'll bet at that company you didn't even do anything involving graphs in code...

You strike me just like the Design Pattern guys that can recite chapter and verse every single pattern from Gamma-Helm but produce a mess of nonsense code in real life that is utterly un-maintainble because you have glued together every possible pattern (and probably a graph or two for a problem that required none!) into spaghetti code.

All of those things are great ways to learn lots of techniques for solving problems but the important thing isn't knowing any one algorithm, it's knowing how to put together software that WORKS. I don't even like Scrum exactly but I admire what them and the Agile guys are trying to accomplish in producing higher quality software faster, and you should have way more respect for the attempt than you do.

The Queen

[jaweekes]

The British Queen has daily meetings where she's the only one sitting. It's not for any formal reason but rather to make the meeting as short and to the point as possible. From what former PM's say, it works really well.

Precedent

[GerryHattrick]

Britain's highest-level meeting, the 'Privy Council', has for centuries been stand-up only. All HM Queen ever says there is "assent", and that certainly keeps it quick too.