The manager looks across the room at the team members. It’s 8:45 and everyone should be in attendance. Where’s Rob? Surely he’s not still at his desk?

“Okay let’s start on the left and go around the room,” the manager says, as she always does.

“Yesterday I worked on 2045. I’ll continue on that today. I have no blockers.”
“Yesterday I worked on 3122. I’ll maybe finish that tomorrow. No blockers” “Yesterday I finished 2066, then started 2173. No blockers”
“Yesterday I worked on 2754. Still on it. No blockers.”
“Yesterday was 2355. Still on it. No blockers.”
“I just started 2039. No blockers”

“Great,” says the manager, “we’re done in 7 minutes. Let’s go back to work.”

Just after the team disperses, Rob walks in from the next room. “Sorry I’m late,” he says, “but I was caught up in a code merge for 2960. I can report that it’s done now and I’m ready to pick up 2175.”

“Okay. Thanks, Rob.”

The manager returns to her office on the next floor with the status update in hand, glad to see the team collaborating so efficiently.

Seven team members were distracted from their work, participated in 20 seconds of a 7-minute meeting, and left no better informed.

It will take each of them about 15 minutes to get back up to speed with the work that they were doing prior to the meeting.

Origin of Idea

When I first met the morning stand-up meeting it was in XP.

Each morning we would celebrate what had been finished, then we would decide who we would pair-program with and on what story and for what reasons.

We were planning our day collaboratively.

If it took 15 minutes, that was fine. If it took 5 that was okay too.

If there was something important happening with the project, a looming deadline, an event involving the team, we would get the announcement together.

We could take a half-hour if necessary, but usually kept it pretty short.

Later I met the same meeting (called “daily scrum”) in a scrum context. The scrum team also used it to plan the day and share information.

Diffusion of Innovation

As Agile methods moved into larger, older businesses the messages and intentions of XP and scrum became a little muddled.

Each of the agile terms was (naturally) mapped onto concepts that the organization already understood. They became a kind of euphemism.

Ideas that didn’t map to existing practices tended to be dropped.

Instead of pair-programming (or group-programming) the organization remained focused on having individual assignments to keep all the people well-utilized and to maintain the ability to individually assess and rank the employees on their skills ( for professional development purposes).

As a result, the standup or daily scrum was converted/mapped.

Rather than a plan for the day, it became a status report. “Collaboration” became a euphemism for holding a meeting. To have a discussion is “collaboration” now.

If team members report having trouble (“blockers”) then a discussion could break out as to how to un-block the work and teammates could help them. The meeting is a chance for collaboration to break out, even if it usually doesn’t.

Simultaneously, online Agile Lifecycle Management (ALM) tools became popular. The most popular of these began life as trouble ticket systems, adapted by mapping a backlog item or user story onto a problem report with a unique ID.

As a result, workers use the unique “story” ID as shorthand, to get their part of the status report done quickly. They were assigned ticket numbers, worked on the numbered ticket, reported status of the ticket, and that became the language of the translated agile world.

This has a hidden cost: In most teams, nobody knows what their peers are really working on because they only know their own ticket numbers, and only for the ticket or tickets they are currently working on.

This mapping onto existing practice changed the entire context of the morning meeting from a crucial day-planning session to the version that appears above – which seems to be the de jure standard daily meeting now.

It’s Obviously Crucially Important

Any agile coach will tell you how important it is to have a daily meeting to collaborate with your peers and raise issues and questions.

The daily standup or daily status meeting needs to be held because it creates so much value for the team and its sponsors.

This meeting may be the only time during a day that peers check in with each other, and the only opportunity to ask for, or offer, help to each other.

It seems a shame to lose this valuable opportunity.

Whenever it is suggested that the meeting could be skipped or canceled, the reaction is usually quite visceral and energetic. We can’t skip the meeting. It is an important part of our agile process. It is the primary mechanism by which we collaborate on a daily basis.

We know how important Individuals and Interactions are to an agile way of working. If we discard the meeting, when will people interact? What will jump-start the day’s interactions and collaborations?

How will we know what anyone is doing or needs help on?

Collaboration is crucial, and so the meeting is crucial as well.

Therefore should devote whatever time is necessary to acquire its many benefits.

It’s Obviously Not Worth Much Time

It is crucial that the meeting not last more than 15 minutes, so that the team can “get back to work” and “not waste everyone’s time on it.”

Various agile forums are full of articles about how Scrum Masters (or the like) have managed to get the daily meeting down to less than 10 minutes! This is a huge win so that people are not distracted from real work for very long.

There are concerned people who have noticed that sometimes the meetings last more than 15 minutes because people are discussing problems and solutions in the meeting.

The obvious answer is to eliminate the discussions from the meeting so that it can be “over with” sooner.

Notice that Rob showing up late and reporting his status individually had no more or less value than having reported the same thing while standing in a circle with his peers present.

Therefore, the meeting (as performed) is a low-value interruption to work and must be reduced or eliminated.

Cognitive Dissonance

Cognitive Dissonance is a state of mental stress that comes from holding contradictory ideas as being true. I find that there is a lot of cognitive dissonance in believing that the meeting is both a crucial collaboration and also a wasteful interruption that needs to be as short as possible.

But this dissonance isn’t shared universally.

And, of course, there are people who feel that it is important because it’s part of the process and that it must be short because that’s also part of the process. They feel no stress at all.

One day, we were having a daily meeting among the developers on an internal software initiative at Industrial Logic. As the meeting concluded, Josh asked about any suggestions for improving the meeting itself.

One of the coaches on staff felt that we should limit the meeting to 15 minutes. We could all give our status and then get on with the work rather than carrying on with discussions. Several agreed.

Josh offered a counterpoint: if our meetings are producing value, doing things that we need to get done, he didn’t care if they ran on to 20 or 40 minutes. The important thing was that we were collaborating on getting valuable work done quickly.

I remember the silence that followed for some 20 seconds. I had nothing to add. I had just been enlightened.

If a meeting provides crucial value, there is no sense in cutting it short.

If it does not provide much value, then there is no sense in drawing it out.

If it provides no value, there is no reason to have it at all.

It’s up to us to wring as much value from the meeting as possible or eliminate it.

Short Status

To this day, my thought is that if we are going to have a status meeting, that meeting needs to be very short.

The meeting listed at the top of this blog is a status meeting. Each person is standing in a circle, hostages of a polite convention. They wait for their turn to state their numeric codes. After speaking their proforma line, they wait for the meeting to end.

That kind of meeting is not collaboration at all.

It’s not even, strictly speaking, communication.

And it’s focused entirely wrongly on individuals doing individual tickets. This is why the “three questions” in the Scrum Guide have been downgraded from directions to “suggestions” in recent years, and carefully refocused on the Sprint Goal (which isn’t a feature list, by the way).

I’m convinced that the status meeting is unnecessary and unhelpful in most circumstances but will leave it to a reader to consider whether following strict three-questions status meetings actually provide value for them.

But there may be more happening than status…

Collaboration

The important part of the meeting, if this part exists at all, is the part where we work through our progress and difficulties together. This part should continue and flow into work sessions, as long as needed.

The first question is whether we’re collaborating with our peers, or merely reporting status to an administrator. An administrator should be fine with a ticket number and a quick assessment, but if we are talking to our teammates we need to describe the work in a way that they understand.

Ticket numbers are a “tell.”

Next: are there too many things in progress? Could we work together more effectively? Is work piling up, and can we break the logjam rather than piling unfinished work on top of unfinished work? Are there jobs that are unlikely to be finished?

And what of continuous improvement? What new technique could we share that might save our team members a few minutes a day from here on?

Did we recognize a bit of waste or drag that we can remove from the process?

Have we identified areas where we need more knowledge or technique? Can we address these?

If the meeting can create progress, then it is important, and maybe 15 minutes isn’t nearly enough.

If the meeting is just an event that holds people hostage for ticket number reports, maybe 3 minutes is far too long.

It is all a matter of whether the meeting is real work or not. Is it getting things done, or interrupting real work?

What do you think?

Related Discussion:

We had an open discussion through our Industrial Logic TwitterSpace. Here is the recording of that conversation.