Recently I was working with a team of two other developers, remote from each other. I noticed that in the morning they would have a Skype conversation before their stand-up, where they would discuss their issues, the status of the iteration, and divvy up the work. Then they would hang up, and immediately call their customer to have the stand-up, where they would answer the holy three questions of a stand-up. After we did this I told the developer that it was funny that they had a stand-up before their stand-up, and after a little back and forth over what I meant I told him, “Stand-ups aren’t for reporting status to the customer.” He replied, flabbergasted, “They’re not?”

I have a little spiel I give in this situation, where I explain what stand-ups are supposed to be, but upon reflection I realized that what they are “supposed” to be is irrelevant.

What Was the Stand-up?

When I refer to the stand-up, I’m really referring to the Daily Scrum as described on the WikiWikiWeb, because that’s how I learned it, and I believe it’s the canonical stand-up that best reflects its original goals. The meeting is described as follows:

Each work day the ScrumTeam gathers in the same place at the same time. The ScrumMaster asks each person three questions, in turn:

• "What have you done since the last Scrum meeting?"
• "What do you plan to do before the next Scrum meeting?"
• "What impediments are in your way?"

The author makes some references to farm animals, and follows that up with:

The DailyScrum is not a status meeting, but a meeting that will foster the communication between all participants.

When I see stand-ups that aren’t meeting this description, I give a little spiel that borrows heavily from Jason Yip's blog on stand-up anti-patterns.

Team members are facing and talking to the manager or meeting facilitator instead of to the team. This indicates that the daily Standup is for the manager/facilitator when it is actually supposed to be for the team.

My spiel ends with me pointing out that on every team I’ve ever been on, if there’s a customer (or scrum-master or project manager) present, the meeting always turns into a status report.

Logical Fallacies

It has occurred to me that I am engaging in a classic “No True Scotsman” logical fallacy. No real stand-up would be a status report to the customer, therefore any stand-up that becomes one is a broken stand-up, and if teams would fix the stand-up they’d see the value in it.

What a crock.

If every single stand-up becomes a status report to the customer, then stand-ups are status reports to the customer regardless of their original intent. Instead of trying to make the stand-up into this wonderful ideal I read about in a book, I should really be asking myself if daily status reports to the customer are worthwhile.

Daily Status

Asking myself this question made things really interesting. On many teams I’ve been on, it’s very difficult to get the product owner to show up for the meeting. This causes tension, because the team has adjusted the meeting to give a status report to the customer, but the customer still hears a bunch of developer mumbo jumbo. It’s a status report, but a confusing one for the customer who doesn’t find value in it, so they don’t show up. Meanwhile, the development team frequently gets pretty grumpy about giving updates to a boss who isn’t there. So is it settled? Should we cancel stand-ups?

Solve the Actual Problem

The stand-up meeting was created to solve a particular problem—developers don’t always talk to each other. This quick conversation forced the team to get aligned every day, frequently preventing developers from going down rabbit holes or getting stuck on bugs. If you have a team of natural introverts, or developers who are co-located, then the traditional stand-up might be for you. On the other hand, if your team is working in the same war-room or communicates frequently through other means, it’s probably not necessary to have everybody discuss explicitly what they are doing.

But what about the customer? Despite the desire for an On-Site Customer, most teams do not have their customer available all the time, even if she is physically on-site. These status updates are frequently the only time of day for a customer to figure out what is going on with the team they are supposed to be directing. In that scenario the stand-up is doing its best to keep the customer engaged, and make them ready for questions. What needs to happen is to re-focus the meeting on what the customer actually needs to know. Fortunately, it’s not that different from the normal stand-up questions, they just need to be re-focused to put the customer in the center of the meeting.

A story-focused stand-up can be very helpful in this regard. If you finished a story yesterday, highlight it and ask the customer if they want to see it. If you’re stuck, let the customer know that story is delayed and perhaps the iteration will not be completed as planned. Sure, ask for help from your fellow developers if this is your best chance, but this isn’t a technical meeting. Get status, get help, get back to work. Schedule more time with the customer now, if you need it.

On other teams, the customer really is around as much as the development team. Those teams hopefully have plenty of communication, big visible charts, and usable software demonstrating status that doesn’t really need to be reported on. If a team has that kind of communication, then they don’t really need a stand-up.

In either case it’s probably time to accept the stand-up for what it is, rather than trying to reach some ideal written down in a book somewhere.