Scrum Team Collapse - how do I stop it?

As a Scrum Master you have the ability to host meetings outside of the prescribed ones so this is the route I would suggest.

I would recommend constructing an agenda outlining your concerns and inviting key people to attend. If the developers share your view then have them attend the meeting to support your claims.

The whole Development Team shouldn't have to come as you don't want to disrupt the equilibrium of the Sprint.
I would recommend analyzing the burn down charts from the recent Daily Scrums. If you find that the work completed deviates significantly from previous Sprints then that may be enough to convince stakeholders that something is broken.

Make sure to time box the event so that it won't be longer than necessary. Hope this helps.

I agree that having a meeting with the key stakeholders is a good option,

Perhaps it would be helpful to begin by meeting with the manager to see what has changed in regard to the support that seems to have diminished; there may be some important findings there. That meeting may result in a partner to help you discuss the impact that the BA is having on the Scrum Team: "The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team."

What has been the response if the Development Team members refer the outside distractions to you? How might the Product Owner, as a business representative, be of assistance? Has there been a Sprint Retrospective in which these concerns were raised?

Lastly, I would involve the Development Team as little as possible since they need to Focus on the Sprint in progress. At some point, it may be helpful for them the collective express their concerns about the affects to the BA and others in one session.

This is where things get a little sticky. I am not only the scrum master, but I do the job of the product owner, and BA as well. I have tried to involve person who "should be" the product owner, but he has not shown up for any meetings. So I generally take care of prioritizing based on communication with the business, release impacts and federal regulations impacts.

I did talk with my manager this morning and he seemed unconcerned and the development team does not include me in meetings or email exchanges that impact them outside (or inside) the current sprint. I have tried to communicate to them that it is okay to say "no" and direct people to me, but it doesn't happen. They get pulled into meetings all over the place that I am not aware of.

I'm not sure I have many options. The "funny" thing about the BA outside of our scrum team is that she is setting up 3 scrum teams within our organization, so she "should" understand what the impact her actions are having.

I do like this idea. I think it will help me to get my thoughts in order while I'm developing the agenda as well.

At this point, I don't have the metrics to support what I see coming.

Melissa,

Your first paragraph paints quite a cheerful picture of Scrum at work. Unfortunately, as you dig a little deeper and peel away the layers, some significantly poor Scrum practices are identified.

I had a BA message me and inform me that she has taken the role of BA for our team for this release, for one specific dashboard.

Scrum can work with outside parties that are not Scrum, like 3rd party vendors and traditional waterfall teams. What is disturbing about this statement though is that a decision was made on the makeup of your team, based on outside priorities. Why is this B/A basically poaching your team? What authority does this B/A have to do this, and why is it being supported by the organization? It is a dysfunctional approach, not representative at all of Scrum, and as a Scrum Master I would ensure that everyone is aware of that.

My manager is not aggressively supporting our efforts to be Agile with Scrum like he was in the beginning.

That is definitely an issue, and I would agree with Alan in determining what has changed with your manager. It seems like normal business pressures are prompting individuals to revert to behavior that is comfortable for them, but definitely not Scrum.

I see our whole Scrum framework falling apart and our agile team failing with this upcoming release... How do I stop this complete disaster from happening?

Take a deep breath. There is a common saying in Scrum: "Failure isn't an option. It is mandatory." Failure often creates the right conditions for change. As a Scrum Master, you need to not only look at the small picture (with the team - sprint), but also take the long view of things (organizational culture change, transformation to Agile/Scrum). Begin documenting the dysfunction that you see, and how current practices are damaging Scrum. Be prepared to discuss these observations at any time, and as often as possible, including when the you-know-what hits the fan.

This isn't a case of "I told you so", but it can be an opportunity to make very visible the harmful practices that are holding your organization back from true agility.

I am not only the scrum master, but I do the job of the product owner, and BA as well.

Well, that is quite an issue around Scrum adoption right there. It is a widely-accepted Scrum practice that a Product Owner must be a separate individual from both the Scrum Master and the Development Team. Only in rare occasions (with mature teams) can the Scrum Master also be a part of the Development Team. What you are currently practicing is unfortunately not Scrum if you are personally trying to satisfy all three Scrum roles.

the development team does not include me in meetings or email exchanges that impact them outside (or inside) the current sprint. I have tried to communicate to them that it is okay to say "no" and direct people to me, but it doesn't happen. They get pulled into meetings all over the place that I am not aware of.

As a Scrum Master, one of your primary duties is to protect the Development Team from outside interference so that they can focus on Sprint work. The context-switching is a drain on the team's productivity, and affects their ability to meet their sprint forecast/goal. Anything that impedes your ability to protect the Development Team, including actions by the Development Team, need to be made as visible as possible.

The "funny" thing about the BA outside of our scrum team is that she is setting up 3 scrum teams within our organization

Just my opinion, but based on their behavior towards your team, I have strong suspicions that this B/A does not have a solid understanding of Scrum. Perhaps she's helping to set up three "teams" in the traditional project sense, and simply calling them Scrum teams?

Good luck to you. You are definitely not the first, nor the last, to be involved in a situation that is SINO (Scrum In Name Only).

Thank you for your detailed reply. It gives me a lot to think about.

I do think documenting the pain points is definitely going to be helpful and probably a glaring one is the lack of a product owner and the various roles that the scrum master should not be responsible for. However with our current structure, without me taking on those roles, we would get no where with work getting prioritized and getting done.

As far as the authority of this other BA, all I can say is that she sits in close proximity to senior management. She has scheduled a meeting in the middle of sprint planning tomorrow morning and invited all of the senior managers to go over her requirements but this will also pull developers out of the sprint planning meeting.

I don't have the authority to tell her no and since there are several senior level mangers, I am not sure that our team not showing up is an option.

I don't want to be a Srum in name only team, but we seem to be heading that way rather quickly!!!

She has scheduled a meeting in the middle of sprint planning tomorrow morning and invited all of the senior managers to go over her requirements but this will also pull developers out of the sprint planning meeting.

I don't have the authority to tell her no and since there are several senior level mangers, I am not sure that our team not showing up is an option.

It can be intimidating, and perhaps risky, to say no in this situation. To me, one option is to still make the effects of this situation/decision very visible to those participating. Unfortunately, if your organization is only halfheartedly practicing Scrum, and still holding on to processes that are comfortable (but highly inefficient), there isn't much you can do.

As your team's Scrum Master, one of your highest priorities is to protect the team. If you are not allowed to say "no", and your team members are not allowed to say"no", then you have a significant impediment that can only be remedied through a more "respectful" approach.

One of my favorite Agile quotes is from Alan Dayley of The Gartner Group:

“If your people are not allowed to say “No”, then all of their “Yes” answers mean “Maybe.”

Respect is one of the 5 Scrum values (along with Focus, Openness, Courage, and Commitment). It appears there is little respect within your organization for your team's time and the work they forecast to complete each sprint. It will take "courage" from you to make this visible to others.

Again, good luck to you in handling a difficult situation.

Hello Melissa,

One of the main foundation of scrum is to deliver only work that will provide the highest value to end users/customers.
However, if your organisation, by its actions, is doing everything not to let you deliver this work, then as a scrum master, you can face them in their act and enquire whether they want to see the outcome or not of the work your development team is working on.
If the organisation is not interested, then their shouldn't be any work in the first place. It sounds a bit harsh, however it is part of our mission to help the team focus on what the organisation really wants (or in reverse, reminding the organisation that if this is what they really want, they need to give space to the scrum team).
This is an extra argument to add to your case.

> How do I stop this complete disaster from happening? I don't
> have much time to fix it...and I was hit with all of this on Friday.

I'd look at it the other way round. What evidence is there that matters are under control? If you don't have satisfactory evidence, then you as a Scrum Master must make that fact open and transparent. You should then explain the options for achieving empirical control. Disaster avoidance is not the job of any one individual, but of teams and organizations.