Stand-up meetings are an important component of the “whole team,” which is one of the fundamental practices of extreme programming (XP).
According to the Extreme Programming Web site, the stand-up meeting is one part of the rules and practices of extreme programming: “Communication among the entire team is the purpose of the stand-up meeting. They should take place every morning in order to communicate problems, solutions, and promote team focus. The idea is that everyone stands up in a circle in order to avoid long discussions. It is more efficient to have one short meeting that everyone is required to attend than many meetings with a few developers each.” 
The stand-up meeting is consistent with XP’s philosophy that software development should be fun and that any distractions—such as too many or overly long meetings—drain energy from the team. The stand-up meeting is designed to maintain communication without the need for typically onerous meetings and ultimately to save time. According to the XP Web site, “The daily stand-up meeting is not another meeting to waste people’s time. It will replace many other meetings giving a net savings several times its own length.” 
Apparently, the stand-up meeting has been well received by some. Here, for example, is a statement from Jonathan Rasmusson:
Just putting everyone in a room and quickly sharing knowledge at a high level efficiently enables mass communication between team members and stakeholders. Team members ranked stand-ups very high among factors they considered essential to the project’s success. They became “town hall meetings” that everyone wanted to attend for updates. … Everyone from the developer to project manager knew the project’s state at any given time. 
Laurie Williams, a leading proponent of Extreme Programming, concurs. “Through the daily stand-up meetings, team members learn what others are working on and struggling with and how they can help each other so that the whole team succeeds.” 
While I might begin my criticism of stand-up meetings by questioning the claim on the XP Web site of “net [time] savings several times its own length,” I am more concerned with the organizational implications. Despite glowing endorsements, I am not sure that stand-up meetings are for everyone. I contend that they work only in the best of circumstances, perhaps only in the abstract, because so many things work against their success.
I think there is something wrong with a meeting held standing up. Standing is inherently onerous. It is used for punishment in schools and in the military: “Stand in the corner,” “Stand at attention,” etc. Standing has an implicit element of authoritarianism and theory X control (which asserts that people will respond only to threats).
I endured regular stand-up meetings for three years. What made the meetings most painful was my boss (I’ll call him Wally). His main reason for the stand-up meeting was not to increase efficiency or embrace XP as much as it was to shorten human interaction beyond anything directly related to the work product. This is the same boss who never took me out to lunch because he believed it was a waste of time. I contend, however, that lunch meetings could have the same benefits that Rasmusson reports for the stand-up meeting. For Wally, however, the stand-up meeting (like the 7 a.m. Monday meeting and the 5 p.m. Friday meeting) was a loyalty test designed to reinforce the employer-employee relationship.
Consider the following excerpt from the twelve|71 Web site, which advocates the stand-up meeting for XP:
Every morning, the whole team takes part in a “stand-up” meeting. The reason for standing up is that if no one gets too comfortable, the meeting will by necessity be short. This meeting brings the whole team together at least once a day and allows problems to be aired and progress to be visible.
The meeting is not for resolving problems, or long discussions, it’s for discussions and raising problems.
It’s amazing how many pointless meetings during the day can be dispensed with by simply standing up together for 10 minutes each day. 
Doesn’t this sound like Wally as I described him? Isn’t this description of the stand-up meeting somewhat at odds with that of Rasmusson and Williams? The point is, in the hands of an authoritarian manager or in a hierarchical, command-and-control environment, the stand-up meeting can become a weapon.
Restricting team interaction to 10- to 15-minute snippets is artificial and suggests disconnection and coldness. Why not five-minute meetings? Sixty-minute? How about as long as it takes—or even not at all on a given day? The 15-minute meeting conveys an explicit message: “Let’s keep it short and to the point.” But there is another, more subtle, message: “We can’t waste time socializing; just deliver the facts.”
Another boss of mine (let’s call him Bobby) used to tell his management team, “We need more communication.” Then he held more meetings. These meetings had no elements of good communication; they were simply diatribes.
Does this mean that long meetings are inherently bad? I think not; longer meetings provide opportunities to convey warmth, caring, and a sense of “whole team.” To paraphrase Einstein, meetings should be as short as necessary, but not shorter.
Consider the magnification of personality issues in a stand-up format. For example, a stand-up meeting in the presence of an authoritarian leader evokes cinematic images of Captain Bligh shouting “Mister Christian” in Mutiny on the Bounty, or gunnery sergeant Louis Gossett Jr. shouting questions at recruits in An Officer and Gentleman, or even Edward James Olmos prodding his students to Stand and Deliver. Surely you would not want to have a stand-up meeting with Wally or Bobby. Insufferable managers are everywhere, but imagine adding to the stress by having to stand at attention like some schoolchild.
Even if the manager is a good one, bad interpersonal dynamics can exist among team members. Discord is not unusual in any kind of meeting, but it is unduly torturous to suffer difficult personalities with the added difficulty of standing up every morning.
Even those, like myself, who become impatient and fidgety in any kind of meeting would find that the stand-up meeting is more uncomfortable and fraught with distractions than a sit-down one. Standing just seems to worsen everything that is already wrong with meetings.
Stand-up meetings probably aren’t suitable for physical reasons. For example, those with an inability to stand or those with speech, hearing, or language disabilities must find these meetings excruciating—if not humiliating—so isn’t this practice discriminatory?
Those who are shy and have difficulty speaking or being in public must really dread these encounters. It must be very difficult for someone who just doesn’t have the personality for a highly interactive meeting to be forced to endure one every day.
Now let’s talk about a few practical matters concerning the mechanics of the stand-up meeting. Who is the leader of this meeting? You might say that no one is the leader. Even so, there has to be some protocol. Should meeting attendees stand and deliver their spiels in order? Randomly? Boldest first?
Is there any accountability in these meetings? For example, who said what and when? How are disagreements resolved?
What if someone is absent? Since there is no record of the meetings, how does one keep up if they are out for an extended periods of time? Are members sanctioned if they miss too many meetings?
This all seems like a free-for-all.
I’m not advocating the return of the overly long, structured meeting with an agenda, action items, and minutes. Although you can argue that there are some benefits to these kinds of meetings, there is no refuting the fact that long meetings can be dull, tiresome, aggravating, and often simply a waste of time.
But aren’t there other mechanisms for frequent, short, informal meetings of pleasant and unstructured information exchange that would remain consistent with the principles of agile methodologies? Why do the meetings have to be held standing up? How about structuring the meetings exactly the same as the stand-up meeting, but sitting down? If sitting comfortably implies a longer meeting, an egg timer can be used to ensure that no meeting exceeds 15 minutes.
What about combining the informality of breakfast or lunch with a sit-down meeting? This is an efficient use of time that is more relaxing than standing at attention. As a manager, I held regular “staff” meetings in an informal place, such as a lounge, break room, or cafeteria (off-hours, when it was quiet).
I would also visit my staff daily for 15-minute sit-down meetings. I went to their offices to put them at ease—as well as to get a sense of what they were doing. This is consistent with management by sight (walking around). It also helped me understand their perspectives. We would start with pleasantries, then get to what was on my mind or their minds. Although this is not multicast communication, it offered some advantages—in particular, I could control bad interpersonal dynamics.
Occasionally, I would hold walking meetings with my direct reports. These meetings were 10- to 15-minute strolls outside the office complex. This combined some of the benefits of the stand-up meeting with the additional benefit of exercise for all.
For a methodology that emphasizes people over process, stand-up meetings seem contradictory: Don’t structure meetings because informal communication is the best; hold highly structured meetings that discourage informal communication.
I have described several objections to stand-up meetings, and although some of my alternatives can also be dismissed, my hope is that those who embrace XP—or consider embracing it—will understand that the stand-up meeting is not necessarily what it seems. I suspect that many team members consider this aspect of the approach the most onerous. Perhaps alternatives should be embraced as part of the XP culture. After all, one of the tenets of agile methodologies is to “embrace change.”
1. Extreme Programming: see http://www.extremeprogramming.org/rules/standupmeeting.html.
2. Extreme Programming: see http://www.extremeprogramming.org/rules/standupmeeting.html.
3. Rasmusson, Jonathan. Introducing XP into Greenfield projects: Lessons learned, IEEE Software (May-June 2003), 21–28.
4. Williams, Laurie. “The XP programmer: The four-minute programmer,” IEEE Software (May-June 2003), 16-20.
5. Twelve|71: see http://www.twelve71.com/xp/standup.jsp.
PHILLIP LAPLANTE, Ph.D., is associate professor of software engineering at the Penn State Great Valley School of Graduate Studies. His research interests include realtime and embedded systems, image processing, and software requirements engineering. He has written numerous papers, 17 books, and cofounded the journal, Real-Time Imaging. He edits the CRC Press Series on image processing and is on the editorial board of four journals. Laplante received his B.S. in computer science, M.Eng. in electrical engineering, and Ph.D. in computer science from Stevens Institute of Technology and an M.B.A. from the University of Colorado. He is a senior member of the IEEE, a member of ACM and the International Society for Optical Engineering (SPIE), and a registered professional engineer in Pennsylvania.
Originally published in Queue vol. 1, no. 7—
see this item in the ACM Digital Library
Andre Medeiros - Dynamics of Change: Why Reactivity Matters
Tame the dynamics of change by centralizing each concern in its own module.
Brendan Gregg - The Flame Graph
This visualization of software execution is a new necessity for performance profiling and debugging.
Ivar Jacobson, Ian Spence, Brian Kerr - Use-Case 2.0
The Hub of Software Development
Tyler McMullen - It Probably Works
Probabilistic algorithms are all around us--not only are they acceptable, but some programmers actually seek out chances to use them.
(newest first)Your post is misleading because it's out of context. This is the first time I've heard anyone speak of stand-up meetings outside of agile software development. The stand-up meeting that people (mostly, software developers) are raving about is an effective tool that eliminates waste in software development. There is no end to useless meetings in the field of Information Technology. Meetings where people seem to talk just to hear themselves talking. Stand-up meetings, in this type of environment are a way of focusing the team on results, sharing information and request assistance. I hated meetings until my company adopted agile software development methods.
You mentioned authoritarian leaders and command and control organizations. This is more evidence that your experience is out of context with those who attend stand-ups as part of a cross-functional, high-performance, self-organizing team. Sorry you've had such a bad experience. You can't blame the tool for that, though. You've got a people problem, moreso than anything else.
* I don't think anyone advocates the stand-up as the *only* communication within the group. Whatever communication would make work more effective should happen right away, as needed, when needed, among those involved, not be deferred until some regularly scheduled meeting (whatever the duration or posture). The key thing about the XP stand-up is that it's a meeting of *everyone*. There's some real communications value in having everyone present, no question; but there's real cost as well. The stand-up structure is intended, and should be managed, to optimize the all-here group value while minimizing the all-here group costs.
* The topic of the stand-up is not status, nor diatribe, but "accomplishments and impediments." Accomplishments, because once you've finished something, someone else may be ready to take the next step (and besides, you deserve some recognition for each accomplishment); impediments, because -- particularly in an XP team -- any team member might be able to remove the impediment.
On the other hand, you did finger the single most crucial, least talked about aspect of XP: it's 100% optimized around teams of the best. If your team has managers whose sour disposition is sabotaging all work, if you have workers who sand-bag and malinger, if you have not clear objectives or customer representatives & well, then, you're going to fail anyway; you can pick any process you like and blame the failure there, but that's not where it really resides.