Daily Scrum Meeting - can "other" people attend?

What does the Scrum Guide say about the Daily Scrum and who needs to be there? Is the Scrum Master aware of these rules and of the need to enforce them?

In your situation, why does the Product Owner feel a need to attend the Daily Scrum at all? 

Scrum Guide: The Scrum Master enforces the rule that only Development Team members participate in the Daily Scrum.

Some people will focus on the word "participate" and have the mindset that so long as only the Dev team members are talking, other people related to the product can attend so long as they do not interrupt or pose questions to the dev team. On one hand that is an okay mindset but what they don't account for is that when external people attend the meeting, it hinders transparency. Consider a dev team member has a roadblock that is directly caused by their manager and the manager is in attendance; do you think the dev team member will call out that road block? I would bet that they wouldn't out of fear of what the manager will do. 

I would encourage the Scrum Master to remove the impediments hindering transparency, inspection, and adaptation from the scrum team; even and especially when that impediment is a manager of the dev team. 

You're making an assumption that developers are not open when managers are around.

If this is true, then that's the real problem that you should solve i.m.o.

I actually appreciate a po frequently attending (not participating) the daily scrum. It shows involvement and might make the job being done feel more important/worthwile for the team members.

The same holds for managers once in a while.

What I would mind is an army of managers in case of emergency since that will typically prove your assumption to be correct and indeed hinder transparancy.

Norbert, respectfully I will say that my assumption about managers hindering transparency is not an isolated issue. This has been the case with both companies I have worked on Scrum Teams with. This is also frequently discussed in scrum meetups and the vast majority of Scrum Masters that attend say that managers even attending a daily scrum, does in fact hinder transparency; mainly when a roadblock is due to a manager. Secondly, I would be curious why managers feel their attendance is beneficial for the dev team. If the meeting is truly designed to be solely and specifically for the Development Team, other attendants need to ask themselves "is my attendance benefiting the team or am I attending for my own benefit?"

If you are able to say that managers absolutely do not pose a hindrance and that your developers are able to be completely open in their presence, my hat is off to you and the company for having such an awesome mentality. That is not the norm, unfortunately, because many managers do not take criticism from their subordinates very well. 

Personally, I like having the PO attend the Daily Scrum, because as you said, it shows the extra level of involvement and support. 

Our PO want to know about our progress torwards goal and status of other stories in jira. He listens to our problems and sometimes he is helping to solve them right away. His intentions are good and Dev Team likes him. He is very good PO. But we (DevTeam) want to know if Daily Sprint is a time and place for our PO to "get the status".

The goal of the daily scrum is to inspect, adapt and make a plan for the day.

If the po's presence is helpful in reaching this goal, i see no reason why it would be the wrong place.

@curtis, I agree with your arguments, but I do think that the goal should be to change the managers behaviour in your example.

I guess it's not the norm, but that doesn't mean we shouldn't aim for it to become the norm one step at a time.

Our PO want to know about our progress torwards goal and status of other stories in jira.

There are 23 hours and 45 minutes of potential opportunity for a Product Owner to collaborate with the Development Team. A Scrum Team, which includes the Product Owner, should be able to self-organize their working hours and make the appropriate arrangements for collaboration to happen.

The Daily Scrum is a 15 minute opportunity out of a busy day for the Development Team to stand aside, to focus, and to inspect their progress towards the Sprint Goal.

"is my attendance benefiting the team or am I attending for my own benefit?"

Didn't mention in my previous post, this is the most important no matter what.

Ian, would you rather have a po asking questions during the day when you observe that this distracts the team more than observing/answering questions during the daily scrum?

Are you sure those are the only options the Scrum Team has? Shouldn’t Scrum Team members inspect and adapt their process so a rather better collaborative way-of-working can be achieved, and in what ways might the Scrum Master help?

Are you sure those are the only options the Scrum Team has?

I'm sure that's not the case, I'm very open to better practical suggestions. I mentioned this one because it's probably what happens if we don't find a better alternative.

Shouldn’t Scrum Team members inspect and adapt their process so a rather better collaborative way-of-working can be achieved, and in what ways might the Scrum Master help?

Yes and I think we are doing this in this topic to figure out proper ways to deal with this pretty general question. Your point seems to be that there are more suitable moments to provide certain information than in the daily scrum and I'm curious if this requires more meetings, 1 on 1 talks or other ways to facilitate this.

The preferred mode of ongoing collaboration would involve informal face-to-face conversation between team members rather than arranged meetings. There should be a clear whole-team focus on work-in-progress (WIP). One-on-one talks are an option, but if they are the usual means of collaboration this can sometimes indicate that WIP has not been sufficiently limited by the team. A Scrum Master ought to be able to assess that situation and coach accordingly.

Scrum events, such as the Daily Scrum, provide more formal opportunities for information sharing and to inspect and adapt progress. The required participants in each event reflect the need to establish the appropriate focus.

So You think that we should figure out something to let PO to "get status". And leave Daily Sprint only for Devs, right?

Correct. Bear in mind that the PO is a Scrum Team member, and the state of progress within the team ought to be quite transparent. If problems arise that the PO can help with, see how this information can be radiated so the PO immediately sees it, or is automatically notified.

Thank You for your help.

Do you think this is the preffered way? Scrum Guide is tellin' us to do that?

Scrum is a framework and the Guide does not prescribe implementation choices. However, the Guide does assert that “Significant aspects of the process must be visible to those responsible for the outcome” and that “The Scrum Team and its stakeholders agree to be open about all the work and the challenges with performing the work”.

Radiating essential information is therefore preferred, largely because it reduces the delay in waiting for meetings and the need to then explain matters. There is often waste associated with having filtered and untimely information.

Thanks. What should we do You think? Need some advice please.

A Scrum Master should be pre-disposed to “take it to the team”. It is up to them to inspect and adapt their process, since in an agile way-of-working they are best qualified to do it.

In this case, the Scrum Team ought to consider the matters of collaboration, trust, and transparency no later than the next Sprint Retrospective. The rules of Scrum, including the correct way to conduct events, may need to be clarified by the Scrum Master. At a technical level it may be possible to configure Jira in a way that gives better access, transparency, or notification to the Product Owner. Burn down charts at task and story levels might be derived automatically for example, and the PO might receive email notifications when work is in an impeded state.

@ Norbert, sorry my delay in reply. I would love to have the managers change their mindsets as I fully agree with you on the goal. However, that is easier said than done in this case and ultimately, it boils down to the managers on an individual basis. You may have 1 that will be totally fine with the request of change, but you may have 2 others that take offense. That is when it would be the time to remove them from the daily scrum if and when they do not adhere to the "rules" so to speak of the daily scrum. 

As far as the PO wanting to get a status update, I think that can change depending on the PO. What I mean is some PO's may want a very detailed status, as in a task status; meaning they want to know how many tasks the dev team completed to reach a completion of a backlog item. Other PO's simply want a status update of "Everything is going well, no visible setbacks ahead at this point and we are on track to meet the sprint goal." So depending on the PO's preference, will depend on the best method of meeting the request of a status update. If they are the former, then by all means sit in the Daily Scrum but listen and don't interrupt or participate unless requested by the Dev Team. If they are the latter and just want a steeple view status update, wouldn't an email from the Scrum Master to the PO suffice? 

So depending on the PO's preference, will depend on the best method of meeting the request of a status update.

In my opinion, anything resembling a "status update" in Scrum is indicative of either a lack of transparency, or a lack of trust, or quite often both.   As a Scrum Master, you can raise the right observations and pose the right questions to highlight this dysfunction.

wouldn't an email from the Scrum Master to the PO suffice?

By no means should a Scrum Master ever insert themselves into a role/responsibility where they are tasked with providing an update on team progress.   This is a serious "bad smell" in Scrum.  

As an SM, don't insert yourself as a liaison between the PO and the Development Team.   Ask the PO why they are skeptical of the Development Team meeting their forecast?   Ask the PO and Development Team if progress of sprint items is visible and up-to-date?   If not, ask why, and ask what can be done to remedy it so that visibility and transparency are supported.

@Timothy, my response was directly related to the question posed for getting a status update to the PO; not what I believe should be the norm within Scrum. I agree that a status update is indicative of other problems like transparency among others. Again, my suggestion was directly related to the question posed, not to be taken and used in the general world of Scrum.

By no means should a Scrum Master ever insert themselves into a role/responsibility where they are tasked with providing an update on team progress.   This is a serious "bad smell" in Scrum.  

Again this is directly related to this specific situation. Clearly, the PO is either left out of other forms of communication, there is no virtual tool like JIRA being utilized, and/or the PO is not paying close enough attention with this team. THAT is a bad smell in scrum. My suggestion for an email was a way to serve the dev team; not just insert the SM as a liaison as you took it. Again, this was related to a very specific situation; one that doesn't follow the scrum framework fully anyway. What do you in a situation where leadership within the company does not adhere to the scrum framework? If you say the SM should never take on a task to provide updates or other forms of communication, would you rather have a director or other department manager bothering your dev team members directly? If that is not an impediment, I don't know what is. 

With all due respect and no offense to anyone, this is how I relate this situation with the reasoning behind my answers. Someone asks "How do I make buttermilk biscuits if I don't have buttermilk and can't get to the store to buy it?" People respond, "You need buttermilk to make buttermilk biscuits" and another says "If you don't have buttermilk, are you sure buttermilk biscuits are the best biscuits for you to make?" How is that helping to find a solution? So rather than telling the poster something that may not be helpful; I would reply with the following. "If you have milk and vinegar or lemon juice; combine 1 tablespoon of either vinegar or lemon juice to 1 cup of milk and let stand for 10-15 minutes and use this as a substitute." Is it true buttermilk? Nope. Does it work as a good enough substitute in a pinch? Absolutely. 

Ian, I agree that the process should be as transparant for the whole team as possible and we should strive for perfection on that matter. I also agree with Timothy that 'Requests for status' are alarming and often reflect a lack of transparancy.

I think it's important to note that the goal of the daily scrum is not to update status, but to inspect and adapt the sprint progress as development team and I think everybody agrees on that here.

In practice though, there will always be some degree of opacity. If the PO gets some useful information out of the daily scrum and is not hindering the goal itself, the only risk I see is that the 'urgency' for improving transparancy could decrease a little. In a near perfect scrum team this might be something to address, in 99% of teams I would pick other battles first and I would want to be damn sure the whole team perceives full commitment/involvement from the PO before denying him/her to attend the daily scrum (yes, that should be the case).

As for the 'SM should never provide a status report', as Ian said, the preferred direction should always be to take matters to the team.

However, when the team is at risk and/or impeded, the scrum master should resolve this asap. If this requires a status update from your end to buy yourself and the team some space to make improvements, this might be worthwhile. But please make sure the root cause will be resolved to prevent these impediments to occur again.

Let's imagine you allow the Daily Scrum to remain as is most commonly applied, where 'anyone' participates and delivers a status update.

Then you schedule a new 15 meeting later in the day with the following rules: Happens everyday at the same time, Only Dev Team may participate, The Dev Team must inspect its progress towards the Sprint Goal, The Dev Team must conduct the meeting

I bet there would be no complaints about the rules of the new meeting. 

-

In my experience, there have never been complaints about the new meeting's rules.  Eventually I switch the meeting names around and encourage important information shared in the status meeting to be shared more frequently throughout the day.

As for the 'SM should never provide a status report', as Ian said, the preferred direction should always be to take matters to the team.

However, when the team is at risk and/or impeded, the scrum master should resolve this asap. If this requires a status update from your end to buy yourself and the team some space to make improvements, this might be worthwhile. But please make sure the root cause will be resolved to prevent these impediments to occur again.

@ Norbert, exactly my friend. That is exactly my point. Scrum Masters must remove impediments to the team so if it means a status update from time to time and then broach that topic for improvement during the Retro; why would anyone be against that? It boils down to the 3 pillars in scrum, Transparency, Inspection, and Adaptation. In the case of a status update: obviously there is an issue of transparency. This could be for any number of reasons, lack of resources, unable to be involved in meetings; you could literally find hundreds of reasons for the lack of transparency. So you inspect to try to find the problem and look for ways to resolve this problem. You adapt to implement a short term and long term resolution. The short term, send a status update if necessary; the long term, resolve the issue of transparency so this problem is completely resolved and not an ongoing issue.

Scrum Masters must remove impediments to the team so if it means a status update from time to time and then broach that topic for improvement during the Retro; why would anyone be against that? 

I would maintain that in this scenario, a Scrum Master choosing to send a status update is a very short-sighted and poor solution.   Yes, I am against it, and for the following reasons:

• It does nothing to address the underlying issue around the lack of trust or transparency between the PO and the Development Team
• It creates a dependency on the Scrum Master.   There should never be a dependency on the Scrum Master outside of Scrum
• By "solving" the problem, the Scrum Master in this instance completely removes the need to address the underlying issue.   Why do the PO and the Development Team ever need to discuss trust issues or lack of transparency into sprint work, if the SM takes it upon himself (or herself) to be the solution?
• Nothing changes.   Agile (and Scrum) promote needed and fundamental organizational changes.   Propping up existing non-agile processes, even with the short-term caveat, does much more harm than good.

While it is indeed a Scrum Master's responsibility to help identify and remove impediments, it should not be the SM's responsibility to either prescribe or become the solution for such issues/impediments.   The conversation(s) regarding the underlying issues need to happen, and the Scrum Master needs to facilitate such open dialogue, in order to help all parties move forward in a more agile (and healthier) fashion.

@Timothy, all due respect, I don't think you're reading my entire comments. It is crystal clear that it is a temporary suggestion AT THE TEAM'S REQUEST and that a true solution would be found and implemented no later than the next retro. Every point you brought up in your last comment, I made very clear in my previous comments. My encouragement to you, realize that sometimes you have to think outside the box in order to serve your team. 

@ Curtis,

If this is a hypothetical situation, then we can continue to provide our opinions based on experience and knowledge (or not provide them).   However, if this is not a hypothetical situation, I would be interested in learning how your team and PO addressed the issue, what experiments were tried, and how your Scrum Team began to resolve their communication and trust issues.

Timothy, it's not hypothetical; the OP stated that they needed advice for this issue. I've had this happen with a team of mine in the past. The PO was remote and not involved as he should have been because he let other tasks take a priority. After the first sprint we discussed the issues in the retro, he pledged that he would do better and pay attention; he didn't follow through with the next sprint unfortunately. Rather than him bothering my team, I took care of the PO's requests for status updates etc at my team's request; this was only short term. one day when he was in the office and I was able to sit down one on one with the him to explain the importance of him being involved as a team member, not a project manager type role. We had JIRA that was being used but he wasn't paying attention to it of course. It took a while for him to fully come on board but he was not well versed in Scrum but thrown into the PO role because of his project management background and experience. In order to serve my team, I took on responsibilities outside of my normal scope of work and but it was also done alongside discussion and continuous improvement in addition to the Retros and it did get better each sprint. Remember, not every company that uses Scrum, lives within the framework. Too often they toe the line or straight up cross it with no second thought. In those cases, it's hard to utilize a solution that is found strictly within Scrum; it's like putting a square peg in a round hole. Sometimes it takes chipping away at the corners to make the square peg round because a true round peg is not available. 

@Curtis

Just for the record, I am neither averse nor unfamiliar with situations as you describe.   In fact, it is my extensive experience with these situations that lead me to my preferred approach.

I do agree with you that it is a primary responsibility of the Scrum Master to protect the team from interference, and I would classify status updates as a common "ask" that impacts Development Team capacity.   I used to approach such issues as you have suggested by addressing them myself, and thereby isolate the team so that they could continue focusing on the sprint.   My response has evolved over the years though, and I strive now to not protect the team (even temporarily) by inserting myself into the solution, but to engage such behavior/actions when they occur, with the intent to make visible such dysfunction.  

On some things, I defer discussion/action, especially if they are large organizational challenges, but something like this case where an individual (PO) is negatively impacting the Development Team (lack of transparency, trust, etc.), I have a productive dialogue with them to help them "come fully on board".

To re-use your analogy, I think your approach to protect your team and delay the needed conversation with your Product Owner wasn't chipping away at a square peg to help it fit into a round hole, it was accepting the square peg, and finding a square hole for it.

Timothy, See, we were on the same page after all; it just took a little bit for us to see each other's points. I am a helper at heart so if I see a need I jump at the chance to help. With the teams I have worked with though, I always offer the help but if the team decides against it; that's cool with me too. In my situation, it would have been dealt with much sooner but with this individual it really needed to be a face to face discussion and he was remote and only in the office a couple times a month. Otherwise, it would have been pretty much immediate; I don't like putting things off if they can be resolved.