Opinion

  Download PDF version of this article PDF

Stand and Deliver: Why I Hate Stand-Up Meetings
Phillip A. Laplante, Penn State University

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.” [1]

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.” [2]

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. [3]

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.” [4]

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.

WHY STAND?

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. [5]

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.

WHY SHORT MEETINGS?

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.

FLAWED PERSONALITIES

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.

SENSITIVITY ISSUES

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.

PRACTICAL MATTERS

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.

ALTERNATIVES TO THE STAND-UP MEETING

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.

A CONTRADICTION

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.”

REFERENCES

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.

acmqueue

Originally published in Queue vol. 1, no. 7
Comment on this article in the ACM Digital Library





More related articles:

Nicole Forsgren, Eirini Kalliamvakou, Abi Noda, Michaela Greiler, Brian Houck, Margaret-Anne Storey - DevEx in Action
DevEx (developer experience) is garnering increased attention at many software organizations as leaders seek to optimize software delivery amid the backdrop of fiscal tightening and transformational technologies such as AI. Intuitively, there is acceptance among technical leaders that good developer experience enables more effective software delivery and developer happiness. Yet, at many organizations, proposed initiatives and investments to improve DevEx struggle to get buy-in as business stakeholders question the value proposition of improvements.


João Varajão, António Trigo, Miguel Almeida - Low-code Development Productivity
This article aims to provide new insights on the subject by presenting the results of laboratory experiments carried out with code-based, low-code, and extreme low-code technologies to study differences in productivity. Low-code technologies have clearly shown higher levels of productivity, providing strong arguments for low-code to dominate the software development mainstream in the short/medium term. The article reports the procedure and protocols, results, limitations, and opportunities for future research.


Ivar Jacobson, Alistair Cockburn - Use Cases are Essential
While the software industry is a fast-paced and exciting world in which new tools, technologies, and techniques are constantly being developed to serve business and society, it is also forgetful. In its haste for fast-forward motion, it is subject to the whims of fashion and can forget or ignore proven solutions to some of the eternal problems that it faces. Use cases, first introduced in 1986 and popularized later, are one of those proven solutions.


Jorge A. Navas, Ashish Gehani - OCCAM-v2: Combining Static and Dynamic Analysis for Effective and Efficient Whole-program Specialization
OCCAM-v2 leverages scalable pointer analysis, value analysis, and dynamic analysis to create an effective and efficient tool for specializing LLVM bitcode. The extent of the code-size reduction achieved depends on the specific deployment configuration. Each application that is to be specialized is accompanied by a manifest that specifies concrete arguments that are known a priori, as well as a count of residual arguments that will be provided at runtime. The best case for partial evaluation occurs when the arguments are completely concretely specified. OCCAM-v2 uses a pointer analysis to devirtualize calls, allowing it to eliminate the entire body of functions that are not reachable by any direct calls.





© ACM, Inc. All Rights Reserved.