One of the most familiar and regular rituals in an agile process is the daily standup. This is the opportunity for everyone on the team to say what they’ve been working on, what they plan to work on next, and what problems they may be having.
Sometimes the question comes up about who should be invited to attend standups. Some teams feel uncomfortable when people unfamiliar with their process attend. For example, I recently came across this comment from a concerned scrum team member discussing his team’s feelings about visitors at standup:
“When someone from outside the team wanted to join in, especially any Manager/Sr. Manager, the team wasn’t really happy.”
One thing that impressed me about the comment was that it was about how the team feels, rather than trying to determine the “right” or “wrong” way to manage standups. This is always the bottom line when it comes to a question like this. And the place to get those concerns voiced is, of course, during a retrospective.
Most of the teams I’ve been scrum master for have appreciated any outside interest in what they were doing. It’s validating, it exposes the team to the broader organization, and it supports their career development within the company. As long as the observers are polite guests and don’t try to interfere, it usually adds a lot of value. (And as scrum master, it’s important not to be shy about enforcing the rules of the standup in a gentle but firm way.)
I’ve even gone so far as to campaign for people from all parts of the organization to come and observe our Scrum process in action. Afterward, I often solicit feedback from attendees. It’s a great way to find out what they noticed from an outsider’s perspective, and gather learnings for future improvements.
The standup is for team members, but by tradition a standup meeting is intended to be open to anyone who wants to attend. Only team members should participate, with everyone else observing and holding any comments or questions until the entire team has had a chance. This is part of the transparency of scrum, and if it makes anyone feel uncomfortable, that is a signal to look for other deeper issues.
I’m curious how you approach this issue in your own scrum teams. Let me know. And if you want to read more about issues like this, feel free to sign up below and get new lessons and insights about agile that works for free as soon as they’re released.