The Unexpectedly-High Cost of Modern ‘Stand Up’ Meetings

Myth: Software Developers Dislike Meetings

Everybody likes a good meeting. Well, as long as they don’t have pressures to build/create something in a too-short time, which is rarely for software developers. Development pressures aside, interacting with our colleagues can provide enjoyment and stimulation - even for developers.

Why then the myth that developers dislike meetings?

For most managers, meetings fill their day. If they have a half hour free of meetings, they might consider filling it with another meeting. For those managers meetings are their ‘output’ - their product for their company. Being busy means having a day full of meetings.

In contrast, a software developer’s expected output is distinctly not meetings. Their output is a working, robust, bug-free, state-of-the-art “machine”. As any developer or technical manager knows, building such a machine presents challenges and takes time - takes in particular extended periods of focus.

A Bad Wind Blows

Something unfortunate has happened across the software-development industry. Agile’s standup meeting has been destructively usurped by ‘reportees’ worldwide. I use the word ‘reportees’ to include managers and non-managers who convene these mutated standup meetings - who are “reported to”. Reportees have ingratiated themselves into the development process via mostly-useless, time-wasting meetings - far from Agile’s original intent for the standup: to facilitate developers to quickly coordinate and align their efforts.

Reportees have aggressively promoted these so-called ‘standups’ for at least three reasons: 

1. lack of understanding of the creative process of the software developer,
2. lack of realization of the true cost in time and energy of such meetings,
3. an opportunity for non-developers to feel part of the mysterious development process.

The original, simple and powerful idea of the ‘standup’ meeting was a brief gathering of developers - in sports terminology, a huddle or scrum. Now the standup has been perverted into a status-reporting meeting which interrupts the morning development flow - when brains are freshest and most fertile, or, worse, encourages developers to do nothing important at all before the standup. 

Disadvantages of the Current Mutation of the Original Standup Meeting

The ‘new’, mutated standup meeting

• accomplishes little,
• drains developer time and energy,
• can damage morale. 

Standing around giving too-simplified, shallow reports to a non-developer ‘reportee’ means nothing. At its worst, the new standup can descend into a posturing, inappropriately-detailed, exclusive discussion between two developers - a discussion better suited to outside the standup. At best this new, mutated, status-reporting standup gives nothing to a project and more often hurts a project and the developers in many ways

Specific Cons of the Mutated Standup

Before suggesting alternatives, I’ll outline specific negative effects the new so-called ‘standups can have on the development team and a project. 

Raw, Obvious Time Waste

The clearest negative effect is the raw waste of developer time. if a 20-meeting has five developers and we assume just five minutes of non-productive time before and after the meeting, that’s 10% of every day, nearly 13 man-hours per week wasted and about 55 hours wasted per month.

Less-Obvious Time Waste

Meetings can start late, key players can arrive late or not at all and meetings can run overtime due to discussions not relevant to all participants. These things, and others, can cost additional time. Moreover the mere fact of needing to remember an impending meeting can lower whatever productivity might attempt to blossom before the meeting. See the Paul Graham’s powerful essay in the next section to understand more clearly how even a single meeting can be a disaster for a developer, in terms of productivity.

Breaking up a Valuable Block of Development Time

The insightful, landmark article Maker's Schedule, Manager's Schedule by Paul Graham, co-founder of Y Combinator, does an excellent job of demonstrating how a meeting impacts a manager’s schedule hardly at all but is disastrous for a developer.

Effective software development requires large uninterrupted blocks of time. That’s why some developers resort to doing their work at night. But night work, combined with a day at the office, can lead to immediate productivity problems and gradual health problems.

It’s difficult to make clearer the impact of a meeting on a developer’s productivity than Paul Graham does in his insightful article, Maker's Schedule, Manager's Schedule.  It’s well worth reading the original but here’s an edited, abbreviated version:

Delaying the Commencement of the Day’s Work

As Mr Graham mentions, having a meeting scheduled can make a developer hesitate to start something ambitious. Having a report-to-someone type standup meeting daily at 9:30am will all but ensure little serious work gets done before that. There’s just not enough time to get everything ready and build intellectual momentum.

The Death of Formalized Liaison Between Developers

The mutated Standup, usurped by ‘reportees’ has stolen a powerful moment from the development team: a quick liaison, speaking in their own efficient, esoteric language. It’s hard to overstate that damage done by this omission.

A Synchronous, Interrupting Meeting - For No Reason.

There’s no real justification for spoon feeding dumbed-down project status to a ‘reportee’ in person in public. ‘Asynchronous’ text: email, slack, sms... serves the same purpose. Forcing the development team to report synchronously, meaning at a given time and place, has no advantage to the project and disrupts the ideal, most-productive development flow. Plus...

Dust in the Wind

In my own experience, myself and others retain little from the mutated Standup. The long minutes of words float away, gone forever. No record, no reference. Text reporting, on the other hand can be saved for analysis and made public for integration, coordination and future planning purposes.

Solution

I’ll say less about the solution than about the problem because the company culture will and should ultimately drive the exact solution. That said, the gist of a solution is threefold:

1. return the Standup to it’s original, highly-useful form (developers only - see above)
2. ask each developer to report her status periodically via text
3. optionally have a weekly status meeting

Returning the Standup to Its Original Form

Returning to the original peer-to-peer format of the Agile Standup meeting means the manager (or other “reportee”) who previously convened the meetings may feel left out regarding gathering project status. The following two-fold reporting and meeting plan may help.

Ask Each Developer to Report Her Status Periodically via Text

Each developer can provide status regularly, perhaps daily, via text (email, slack, sms...) at a time which suits the developer. These reports can become part of the project canon. Over time, they represent a large body of valuable information. As permanent records, interested parties can analyze them later to help plan and estimate future projects.

Optionally Have a Weekly Status Meeting

For the benefit of managers and other reportees, a weekly status meeting makes more sense than a daily meeting from the points of view of time conservation and developer autonomy. Weekly may be the ideal frequency for project steering, accountability, cross-company issue raising, team bonding and morale.

In a weekly status meeting scenario, reportees can more-easily grasp the magnitude of the work done than in a daily meeting where progress can be lost in details. Financial instrument traders are aware of an interesting phenomenon: looking at portfolio performance too frequently can give an ongoing negative impression. The same goes for reporting software development status too frequently: the project will seem to be doing badly. Weekly developer reporting can more-easily translate to easily-understandable fragments than in more-frequent meetings.

Note that even in a weekly status-meeting scenario, perhaps especially in a weekly scenario, developers should feel free and even encouraged to escalate issues at any time.

Conclusion

The mutated, reporting-style Standup has dug in its heels across the industry, leaving managers and executives wondering why software development is slow. It will take open minds, courage, decisiveness and an almost altruistic desire for project success for managers at the coal face to drop their counter-productive, thoughtless, daily-meeting habit and replace it with the original standup idea alongside a more-efficient and superior status-gathering system.