Should Managers Share an Update in the Standup?

I've been a part of several agile teams in my career that did a daily standup as part of their process. I've come to view standups as a must-have for software development teams. The payoff is large for the minimal time commitment.

The idea is that the team gathers together every day for a brief meeting (typically 15 minutes or less) just to update each other quickly on what they worked on the prior day, what they plan to work on today, and if they’re hitting any roadblocks that the team may be able to help out with.

In some teams, I've noticed what seems like a strange phenomenon to me, which is where managers that attend the standup don't share an update with the team, but merely attend to hear the updates of everyone else. This has always bothered me a bit, as I view the Agile philosophy as an egalitarian approach to making software, where everyone on the team is an equal.

I can distinctly remember on one team, where one of the developers had recently been promoted to management, and almost immediately stopped sharing an update like every other member of the team in the daily standup. As we had worked together for some time, I good-naturedly asked him to share an update, which was greeted by nervous laughter from the rest of the team, as if this was an odd request. He obliged and shared an update, which turned out to be packed with helpful information for the team. But after doing this a few times, and each time feeling like I was violating a cultural taboo somehow, I relented to the idea that he was now in a different class from the rest of the team that did not need to share an update.

I saw this pattern repeat a few times, where managers who attended the standup would listen to everyone else, but rarely speak about their own work. I may find this strange, but what do the experts have to say?

Scrum—the most popular agile methodology—has its version of the standup called the “daily scrum.” According to the official Scrum guide:

…only Development Team members participate in the Daily Scrum.

According to the Scrum Alliance:

Though interested parties are welcome to come and listen to the Daily Scrum, only the Scrum team members, including the Scrum Master and product owner, speak during this meeting.

In my experience with Scrum, the Product Owner has always been someone in management. The quote above indicates that the Product Owner speaks during the meeting, but it’s not clear if this means answering the three questions development team members answer:

1. What did I do yesterday that helped the Development Team meet the Sprint Goal?
2. What will I do today to help the Development Team meet the Sprint Goal?
3. Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?

In James Shore’s highly-rated book, The Art of Agile Development, he has a fictional transcript of a well-run standup:

A programmer:

Yesterday, Bob and I refactored the database pooling logic. Check it out—we made some nice simplifications to the way you connect to the database. I'm open today and I'd enjoy doing something GUI-related.

The product manager:

As you know, I've been away at the trade show for the last week, getting some great feedback on the user interface and where we're going with the product. We need to make a few changes to the release plan; I'll be working with the other customers today to work out the details. I can give a lunch-and-learn in a day or two if you want to know more. [Several team members express enthusiasm.]

A domain expert:

After you guys [nodding to the programmers] asked us about that financial rule yesterday, I talked it over with Chris and there was more to it than we originally thought. I have some updates to our customer tests that I'd like to go over with somebody.

A programmer responds:

I've been working in that area; I can pair with you any time today.

In this hypothetical standup, not just programmers but the “product manager” and a “domain expert” are both chiming in with relevant updates for the team.

Scrum expert and author, Mike Cohn, has this to say in the comments of a blog post on daily scrums:

I have no idea why the Scrum Master and Product Owner would not give updates. That sets up a complete us-and-them division between the team: "You have to share what you did, but I don't." A Scrum Master and Product Owner could easily within a minute (total) update the team in a way that kept things brief but didn't create that division.

In another comment on the same post, Mike continues:

I view the Scrum Master as a committed participant. I coach Scrum Masters to give (brief) updates on what they did. For example, if a Scrum Master never reports on removing impediments he's told about, other team members may never mention them. They'll think, "Why mention my impediment? I've never heard our Scrum Master say he's resolved anyone else's?"

Finally, here’s a comment from Gunther Verheyen, author of Scrum - A Pocket Guide:

I tell that Scrum Master and Product Owner are allowed to join the meeting. This seems to have a positive effect on the team; it shows they are connected and committed as Scrum Team members. But if they join, behave as every other Scrum Team member. So, don't start leading the meeting. I ask them to answer the 3 questions from their perspective. It keeps the others informed, and it helps to keep the Product Owner to be accurately informed which is quite helpful for his/her stakeholder management.

Let’s consider the chickens and pigs analogy that Scrum practitioners are fond of. If a person is so invested in the success of a project that they are attending the standup every day, then in my mind, that makes them a “pig” and their input is needed just like every other member of the team.

If you're a committed member of the team, then you have important work to do to make the project successful. Tell the team what you're doing! In my mind, the standup is partially about keeping the team members accountable to one another, so that everyone is clear about the team's goals and that each person is contributing on a daily basis to make those goals a reality. If you're the Scrum Master, for example, tell the team what impediments you removed the day before and which ones you're removing today. If you're the Product Owner, tell the team about requirements that you're gathering or priorities that you've shifted. Tell the team about demos that you've given or discussions you've had with stakeholders that are relevant to the team. How are you helping the team meet its goals? What impediments are you facing?

When a manager attends the standup every day but doesn't feel the need to communicate what they've been working on that's relevant to the team, it indicates to me that the person thinks the standup is an old-fashioned "status meeting" where underlings account for what they've been doing while management listens and judges. I would argue that the best place to see the status of work the team is doing would be to look at the backlog in whatever tool the team is using to organize work (Pivotal Tracker, for example). There’s no need to be in a certain place at a certain time each day to find out the status of work. Pull that status any time you like.

What do you think?