How do I deal with a counterproductive scrum team?

Question

Backstory:
I have been working as part of this team for the past three years and in this time we have had three different Scrum Master who have all run things differently.

Because of this change in Scrum Masters and their way of running the show, it has left my team numb to the idea of Scrum because the principles haven't been enforced consistently and one of the Scrum Masters was a person who do not believe in agile development and just kept events and artifacts as a novice to comply with company decisions.

Now my team members are annoyed and bored when we do Scrum events and one person in particular is very verbal about this.

Present:
Two months ago the company appointed me Scrum Master of my team because of my dedication to working agile and its principles.

I'm suffering greatly under the atmospheric pressure of my team members unwillingness to do Scrum.

As mentioned they are annoyed about the entire process which makes it very difficult for me because they are not engaging in the necessary conversations needed to make Planning, Retrospective, and Daily Scrum effective.

To them, Planning is just a waste of time, because we just move overflow into the new Sprint and don't complete the work anyways, so why bother.

During Retrospective I can just feel that they want to say "Stop doing Scrum". One person does, but the others are silent and I have to deal with this every time.

Daily Scrum is again just a waste of time for them because none of them bothers to talk and plan the day. They just state "I worked on task X yesterday and will work on that again today." And most of the time they just joke around until I get more stern.

I have been very large when it comes to how they spent their time during these events. But I'm dying on the inside because I have a passion for this and they don't care anymore.

Today the person who's always against me told me to stop saying "They said this is what they committed to for this Sprint" because, in his words, "We never complete a Sprint. We just move in tasks and take in new ones in the next Sprint to fill up a quota. We do KanBan in reality. So stop saying that."

I understand why he says this, but he doesn't seem to realize that this is how it is because him and everybody else on the team don't care. They just do work instead of dealing with impediments. They complain about the impediments, but don't do anything about them. And when I try to help they just shrug it off.

They used to give a damn, but over the past two years their willingness has declined to more or less rock bottom.

How can I make them see that joking around and wasting time during these meetings costs the company a lot of money?

Answer 1

You may have heard a lot of statistics about failed software projects and came to the conclusion that the failure is not of a technical nature. Technological problems can be solved via hundreds of technical solutions, but solving problems in your workplace atmosphere by using Scrum is not going to work.

My suggestion here is to completely stop looking at this as a technical issue. It's not about Scrum, it's not about daily standups, sprints, retrospectives or anything else like that. You need to get in touch with your team and find an effective way of working that satisfies them as well as you and your superiors.

If they think dailies are a bad idea, you should not tell them to do dailies and try to punch your reasoning into them. Think for yourself what it is that dailies offer to you. Check with your team whether they value those advantages as well. Find out why they do not share your understanding - as in understanding their point of view, not as in convincing them of anything. Then check whether dailies actually help your team, or if you can achieve more with some other mechanism. The funny thing about Scrum masters is that they are servants to their team - you may well serve them best by abolishing Scrum altogether.

In summary, stop focusing on Scrum and instead get back to the basics of agility. You may want to start right at the beginning with the agile manifesto: Value individuals and interactions over processes and tools.

Answer 2

In my experience, teams who are disillusioned need to start by having effective retrospectives. That's why in my opinion retrospectives are the only mandatory part of an agile process. Everything else is subject to change through the retrospectives.

In effective retrospectives, you don't just complain about your issues, you choose at least one of those issues and identify possible solutions to it, then try that solution over the next iteration. At the next retrospective, you talk about how that solution worked or didn't work, and make further adjustments if necessary, or pick another issue to work on.

When team members see they have the power to effect actual change in their process, they will become more willing to engage.

The retrospective process is why if you visit all the teams at a company that does agile well, they all do it somewhat differently. We have some teams that do Kanban, some that do XP, some that only do standups Monday Wednesday Friday.

If your team doesn't like how you deal with hangovers, brainstorm some different approaches. I have won over very reluctant developers just by consistently listening in retrospectives and trying solutions.

Answer 3

Ok so let's start rough - big part of the problem is with you - You hear, but you don't listen. Your team is telling you clearly what the problems are. You need to address them instead of blaming your team.

Planning

To them, Planning is just a waste of time, because we just move overflow into the new Sprint and don't complete the work anyways, so why bother.

Exactly. If you consistently fail to allocate correct amount of time to tasks, and they are consistently underestimated, it has very negative effects:

• Developers feel like they are constantly under pressure.
• "I can't get anything done in time".
• Since the process does not work, they rightfully see it as a waste of time.

Solution: Fix your estimations using combination of:

• Story Points (as a combination of Time and Risk).
• Do not allow tasks into a sprint that are > 55 SP
• Comparative Estimations
• Evidence Based Scheduling

As a base for this, you absolutely need to track time it actually took to finish previous tasks, this includes testing, writing documentation, writing tests, end user training, integration efforts, deployment. etc.

Once you have a total time for a given task, you can base expected time on those previous tasks.

Ask every member if the task given to them feels more complicated or easier than the selection of previous tasks, adjust number of allocated tasks based on that.

If you haven't used SP before, my advice is to start with 1h of real honest to god work = 5SP as a guideline. Keep in mind that in usual development environment, you'll get maybe 6 of those per day, so 30SP / day max. Never ever allow for a task that takes more than 2 days to get on the board. Ideally, in my experience, you should have 2 tasks per day.

If you don't do Planning correctly, rest of your Scrum activities will look like a waste of time (including Planning).

Retrospective

During Retrospective I can just feel that they want to say "Stop doing Scrum". One person does, but the others are silent and I have to deal with this every time.

Reminds me of Daily beatings will continue until morale improves! and two of the past jobs. If you don't remove impediments, then they are correct that this is a waste of time.

Again, listen to what people are actually saying. If the complaints raised during the retrospective are not addressed, why bother doing them at all?

So:

• Consider Six Thinking Hats techniques to improve the communication.
• Reduce the time spent on Retrospective, 30 mins maximum.
• Ensure that complaints raised during the Retrospective are addressed before the next one.

Daily SCRUMs

Daily Scrum is again just a waste of time for them because none of them bothers to talk and plan the day. They just state "I worked on task X yesterday and will work on that again today." And most of the time they just joke around until I get more stern.

Sounds like you have two problems here: SCRUM meetings are too long, and your planning and task creation sucks.

Both can make sound like a scrum meeting is a waste of time.

For the SCRUM length:

• Try 15 mins maximum.
• Try everyone standing up.
• Fixed formula:
  • What have you been doing yesterday.
  • What are you planning today.
  • What your team members (not you!) should know about the task, how it'll affect them.
• Don't bother with impediments if you're not going to address them.

This is a second evidence that your planning impairs your situation - if you have nothing specific to report, that means usually the task is too big and all you could say was: I was working on it.

• Break tasks down into the bullet points.
• Ensure tasks are small enough to take less than a day. Ideally, IMO, task should last ~3h and be equivalent of around 13 SP, so you can do 2 per day in most conditions.

Dealing with the team

Today the person who's always against me told me to stop saying "They said this is what they committed to for this Sprint" because, in his words, "We never complete a Sprint. We just move in tasks and take in new ones in the next Sprint to fill up a quota. We do KanBan in reality. So stop saying that."

He's right. You are wrong. You are doing bastardized SCRUM and/or variation on Kanban. Not their fault at all.

I understand why he says this, but he doesn't seem to realize that this is how it is because him and everybody else on the team don't care.

I don't think you understand at all. They might be caring less than they used to before, however blaming them not only will not improve anything, it might just make a situation worse. If it was rock bottom, they might actually start digging.

They just do work instead of dealing with impediments.

And here I thought doing work is what their job was all about. I wonder who was supposed to be dealing with impediments.... oh right. A Scrum Master. It's your job. They tell you what's wrong. You fix it. Not the other way around.

This is probably why you have so much problems in the Retrospective.

How can I make them see that joking around and circle jerking during these meetings costs the company a lot of money?

Stop the useless meetings and they'll instead joke around watercooler. Also see the paragraph about beatings improving morale. If they are using humor as a defense mechanism, you have some serious problems sir!

Get in on a joke - as in work with your team, not against it. (Who the fuuuuuuck cares about the company's money? Are you a shareholder now?)

To summarize

Your bad planning is making other parts of SCRUM fail, and everyone who participates miserable. They see that nothing changes, nothing is addressed, and their complaints not heard.

Improve your planning, and you'll improve the flow and morale.

Do your job removing impediments and your team will progress faster. Ask them what they feel you should do to help them.

Most importantly: Listen to your people. They already told you (and me) what's the problem.

Good Luck!

Answer 4

One of major agile principle is to go back, and correct whatever is wrong. That doesn't only include code refactoring and bug fixes, but also fixing the development process.

So, why don't you make a meeting with your team, and see how can you improve development process? If that means, no scrum or standup meetings, then be it.

Also you are breaking one of principles in agile manifesto: "Individuals and interactions over processes and tools".

On the other hand, if your team thinks that iterative development is bad, then maybe you are doing it wrong. It doesn't matter if you do not finish everything you planed for one iteration - you can always move things to next iteration. That is also why you mark things as "has to contain", "nice to have", etc. As long as you provide new functionality, you are doing it fine.

---

Just a small rant: in my previous and current company we did and still do standup meetings. From my experience, they are massive waste of time, since every time they turn into 30+ minutes status report meetings, and to me provide little to no information. People talk about their problems, which honestly I do not care.
In my previous company, they were smart, recognized this problem with standups, and stopped them soon after people started complaining.

---

If you like to see a really good video about scrum, see "Robert C. Martin - The Land that Scrum Forgot".

Answer 5

As I priority, I'd look at tasks which keep getting carried over. Not meeting targets is hugely demoralizing. Are you committing to too much? Are there fatlogs that should be broken down? Are there bottlenecks outside your control? Do you have a clear definition of "done"? Are the requirements clear? Are the hours per developer reasonable (i.e. takes into account admin, standups, planning, retrospectives, keyboard breaks, non-project work).

Next, ditch whatever isn't working. Process without value is just a time thief. Standups can consume vast amounts of time if it isn't focused and doesn't provide value to the team. The hours might be better spent elsewhere. Maybe also consider splitting the team up if it is too big.

Try to get a handle on what is demotivating the team. Have retrospectives and more importantly, act on the output. It is equally important to celebrate successes as well as looking at failures.

Finally, you may want to assess the approaches of scrum masters who have gone before who may have damaged the brand so to speak. I've worked under a toxic scrum master before where every problem that was raised got added to your workload whether you knew about it or not. End result: problems got ignored and everyone worked on their own little area with very little teamwork.

Answer 6

Getting your team to close your sprint effectively (like at least close 80% of stories) sprint over sprint is in my opinion the single most important thing you can do. If your team is consistently missing, then that's a clear indication that you need to adjust your estimates.

The team should be receptive to this, though it can be very hard to get developers to be more realistic about estimates - I worked on a team that didn't close a sprint for a year (consistently closing less than 50% of the sprint), always under estimated and in every planning/retrospective I was a lone voice telling them your estimates suck, you're being foolishly over-confident, stop making excuses for what prevented you from making the estimate and instead adjust the estimate to reflect reality (perhaps more diplomatically than that but that was the basic sentiment) - When you're in that position, I would fully agree with the curmudgeon on your team who says the process is a waste of time because you are in fact doing KonBon, regardless of what you call it. At a certain point, his opinion becomes validated by the circumstances. It's hard to overcome that inertia but if you can't do that then I don't think the team will ever be very successful.

At some point you have to reset things, you have to get the team to drastically over compensate on their estimates just to get the system in motion. Once a team begins closing stories consistently, they should realize that the Agile process is mainly common sense and failing to materialize it in some fashion is harmful to your productivity. But so long as the 'commitment' and 'sprint goals' aren't taken seriously, which happens when they aren't achieved consistently, then the whole thing is a sham and becomes a drain on the teams productivity.

Getting people to buy in on a significantly different sprint (in terms of estimates, planning, the commitment ect) is difficult, on that team I eventually accomplished that due to two factors. One was just collecting the data from JIRA and saying "there is no excuse for this, the numbers are way off, they're always off in one direction, we need to correct it, I don't want excuses in retro, I want the numbers to add up" - and the other was pressure from higher up in management which I eventually explained to them like... "The point of this process is to make our development timeline predictable. If we complete a constant amount of work every sprint that's fine, independent of that, our board needs to accurately reflect what we do get done. Management is more aware of our success relative to the commitment than it is to our actual output, for your own sake, make the projection line up with the output so it looks like you're getting your work done rather than spending half of every sprint doing nothing. The further removed people are from this time, the more they just see you failing, the excuses you make in retro aren't even something in their purview, they just see you failing."

Eventually our team got traction and things started going a lot smoother and low and behold, we even started to have higher output once the process actually started working. So tl;dr - do whatever is necessary to start closing sprints with a relatively high degree of success. If you're not doing that the curmudgeon on your team will continue to have his resistance to Scrum validated by the results and ultimately will be right that your process is in fact just a sham and waste of everyones time.

Answer 7

As a Scrum Master you coach and guide the team to become more productive. The Scrum framework is a powerful tool to get there, but the Scrum framework absolutely must not ever become the goal by itself - otherwise you're doing Cargo Cult.

It seems you've been doing Cargo Cult for 3 years now and people realized that's a horrible project management methodology. The good news is you've got smart people, they got it right. Unfortunately, some people in your company are calling it Scrum, but again you've got smart people, they even told you what the team's doing isn't called Scrum.

Planning is just a waste of time, because we just move overflow into the new Sprint and don't complete the work anyways, so why bother.

Exactly. Why bother? You need to find an answer, or rather you need to change the planning and the sprint itself so there is a point to planning. Either that, or stop wasting everybody's time with a pointless Sprint Planning. You may want to ask the company to send you on a Scrum Master training, because running a great Sprint Planning is not trivial.

During Retrospective [...] the others are silent and I have to deal with this every time.

If you're dealing with the same issue every Retrospective, an people don't even bother (anymore?) to speak up during the Retrospective, that's just a waste of time. Unless you or the team can somehow address the issues raised in the Retrospective, the meeting is just a demoralizing the team. Issues raised in the Retrospective must be addressed, and there should be progress by the next Retrospective.

Daily Scrum is again just a waste of time for them because none of them bothers to talk and plan the day. They just state "I worked on task X yesterday and will work on that again today."

Indeed, why bother wasting everybody's time if they just work on the same tasks multiple days? They are absolutely correct, that Daily Standup is indeed pointless. The Standup facilitates close collaboration on many tasks which can each be completed in half a day or less. If your tasks can't be broken down that way (due to broken Sprint Planning, or because your tasks actually don't fit well with Scrum), there's not much of a point to holding the 5-minute Daily Standup meeting (it is no longer than 5 minutes, right?).

"We never complete a Sprint. We just move in tasks and take in new ones in the next Sprint to fill up a quota. We do KanBan in reality. So stop saying that."

I understand why he says this, but he doesn't seem to realize that this is how it is because him and everybody else on the team don't care.

No, you absolutely do not understand why he says this. You got the root cause of the impediment - which you need to resolve - wrong. They don't care because the team's project management practices suck. Caring about doing Cargo Cult and doing Cargo Cult harder doesn't stop it from being Cargo Cult, one of the worst project management methodologies in existence (in your defense: also the most widely used).

---

What can you do about this?

1. Listen to their concerns. Again, you're blessed in that you've got smart people.

2. Help them resolve the impediments.

And that's it, really. You'll need to experiment with how to change Sprint Planning, Daily Scrum and Retrospectives to make them valuable to the team - even if you wanted to drop the Scrum label, you still have these 3 meetings with similar frequency and similar purpose in every other project management methodology out there. As for how you're going to experiment (frequency, content, who hosts the meeting, time, duration, etc), that's surprisingly easy: Ask the team. Don't force your ideas on them, if anything you should let them to force their ideas on you (assuming they can agree on some).

If you're afraid you'll lose control, set some boundaries beforehand, e.g:

• The labels of the meetings stay the same.
• The meetings still take place and frequency of the meetings cannot change by more than a factor of 2.
• You're currently experimenting, so any change only lasts for 2 sprints, after which you revert to the old pattern (best give the time in weeks to avoid ambiguity when they want to double the sprint duration).

Answer 8

I think everyone is quoting the same line from the Agile Manifesto. I will do the same: "Individuals and interactions over processes and tools."

If you as the SCRUM master want then to use SCRUM to do the job, you must approach them as one individual interacting with another. Start brainstorming how to make the process better. Maybe you can convince them to like SCRUM. Maybe they can convince you to use a different process. Let's find out!

It sounds like the team already recognizes that the current system is not doing the job. Can you encourage them to believe it can do the job? You mention a few examples. If you're overfilling the Sprint so that it always leaks over... stop. It's your SCRUM team. Help them stop over-committing. Push back on management to get some breathing room. Use SCRUM for what it's good for. Use it to present the data to management that they are pushing hard enough that they are losing the value from their process. If management wants SCRUM as a process, get them to help build the space and energy you need to fix it. As SCRUM master, your job is to solve problems so that the team can be productive.

Another useful approach can be to spawn a new process within the old. Keep running the SCRUM in the same useless way, but cordon off a small part of the schedule and say "in this part of our schedule, we're going to figure out how to use the tools properly." Don't overcommit there. Use your metrics. Focus on all your meetings there. Just the remaining part of your "SCRUM" project as a shield to keep management happy while you and your team "[uncover] better ways of developing software by doing it and helping others do it." Over time, you'll want to put more and more of your valued tasks in this bucket, and the old bucket will slowly die. Soon, you have a vibrant software development environment and no one is the wiser.

Or mix and match them. I worked on a program which was anti-scrum. The clients wanted to be able to add new tasks at any point during the process and have us act on them immediately. (This was actually a sane request: their work was highly volatile and they often needed rapid support... it's what we were paid for). Of course, we had to figure out how to deal with their "why isn't X done when you promised it in the sprint" issues. Our solution was actually to build a two step process. Long term tasks were put into SCRUM for proper prioritization. The short term tasks were put in a homebrewed process which focused on tight interaction between client and developer. It was understood that the clients were welcome to push on us using this short term process, but that they understood that doing so pushed on the Sprint's timeline, and they were forbidden from adding requests without simultaneously hearing and addressing the scheduling issues they caused. Result? It worked. Most tasks were put in the SCRUM process, like they should be, and the emergencies interacted seamlessly with them. The attitude was "If you want to be a customer, stand in line for a SCRUM story. If you want to be a partner, feel free to come down and work with us on the day-to-day level and make this product work!"

Answer 9

I say this because I truly know. You have a problem in upper management with overscheduling, unable to set priorities, and a willingness to add more items but not push the release dates back.

I used to say that there is no methodology that can function like this, but now that I've seen Kanban I say it can, but only because Kanban doesn't have to care. It continues to function when overcommitted. It's not going to bring results any faster but the backup in the queues is not allowed to be laid at any individual and so the management problem rests with management. The feedback reports show overload, which is correct.

Answer 10

Because of this change in Scrum Masters and their way of running the show

Oh well, this may be your problem. A Scrum master is not there to run a show, he is not a project leader. He is there to make sure all stakeholders are communicating and the operation is transparent.

I am wondering where the team is coming from. Could it be they were more or less autonomous before Scrum (including the inevitable Scrum master) was dropped upon them? Why was Scrum introduced in the first place? What was it supposed to solve?

Scrum is supposed to provide guidance and your team is making it clear they do not experience it as helpful in any way. They don't care for guidance, they consider it an inappropriate waste of time. Apparently at least one decision maker thinks they need to be guided anyway. Who? Why? Do they have a point?

Answer 11

This is a problem not limited to software.

In any work environment, there will be different people with different personalities and abilities. Even if Scrum was a perfect method, there would still be people against it due to their personalities and abilities.

Developers handle difficult tasks in a rational way. To be able to do this, each developer will have his way to handle such things which may show up as aversion to things like Scrum. If all the developers were trained from scratch in exactly the same way then it may be a lot easier to use one pattern, but otherwise adaption on the developer side or management side is needed.

In addition, independent thinkers(developers and other specialists) often do not like being told how to do things because that is their job and it is easy for clashes in opinion to happen. Scrum can seem like some pointless ritual to a logical thinker who would usually analyze and act accordingly to each issue at hand.

The below seems to suggest where the problem is but not what it is. There is definitely more than this. I can only assume(out of experience) that the developers tried but was prevented. I have seen it many times where developers want to fix something but something systematic(management, company policy, etc.) makes it near impossible so they give up. Do they really not care or do they not care only about doing something that they believe will not help(possibly out of experience).

I understand why he says this, but he doesn't seem to realize that this is how it is because him and everybody else on the team don't care. They just do work instead of dealing with impediments. They complain about the impediments, but don't do anything about them. And when I try to help they just shrug it off.

They used to give a damn, but over the past two years their willingness has declined to more or less rock bottom.

How can I make them see that joking around and circle jerking during these meetings costs the company a lot of money?

If something is being forced onto other people, it is up to the people forcing the method to convince them of the benefits. Although, I don't really believe in forcing people to do things, I suggest like in any situation, listen to everyone and develop a method that works for the current environment.

Answer 12

Scrum is not without its weaknesses. I can speak for myself of course, but I think developers hate it for good reason. It is my honest opinion that it must not be attempted.

To understand why, read what every scrum master should know about scrum. It is not written by me, yet everything there is representative of my experience, which I can only sum up as sheer terror.

In my case, I especially suffered under point 5. Basically, scrum treated me as a child and a loser. Now, I am a resourceful co-developer helping my colleagues … no wonder what I would prefer!

I have a new (non-scrum) boss now, that just walks around and talks to people, and I'm so so thankful for that! Part of why this works is that we also have a chat room (we use mattermost) for inter-developer communication. If anyone is having an agenda, we take it there. Meetings are only for ad-hoc developer discussions, not for imposing artificial daily deadlines on oneself.

Answer 13

You've gotten a lot of excellent answers. Here's a few more points that might be helpful:

Changing Methodology Is Hard

It's a huge challenge in a workspace, because you're working under the inertia of "this is how we do things", and against the pressure of deadlines and business needs.

You're quite correct to conclude that your team needs to spend more time on planning, not less; that planning is something your time currently is not great at, and needs to improve. The problem is, you don't get there simply by dictating new rules. New rules are a new burden before they become a big help. And if they don't provide great value immediately, you're going to get avoidance rather than cooperation.

I highly recommend Roy Osherove on this topic. He's got a brief summary of how to plan and effect change at your company, and he goes into the topic at much greater depth in this video.

Osherove's basic observation is that all the following challenges need to be met:

Personal Motivation: Why should someone care to behave a specific way?
Personal Ability: Can they literally do it?
Social Motivation: Is there peer pressure push for this behavior?
Social Ability: Do people around me support my behavior and help me out with it when I need help?
Structural Motivation: Are there rewards\punishments for good\bad behavior?
Structural Ability: Does the physical environment support this behavior?

You Need To Learn To Break Tasks Down

Your team feels that "I worked on task X yesterday and will work on that again today," and they seem to be right, in the sense that tasks keep being pushed back a week.

What's really helpful here is learning how to break tasks down into small components. What you're looking for is the answer to the question "OK, you're working on task X, but what specifically in task X are you working on today?"

Some answers might be:

• I'm learning this class of legacy code.
• I'm fixing a bug, whose symptoms are (SYMPTOMS).
  • If this is some ongoing bug that's taking a while: "Today what I'm going to try is... (PLAN)"
• I need to change this interface.
• I'm writing tests.
• I'm integrating untested code.

... and so on, and so forth. Being able to observe what you can actually get done in a day, or in a week, is one of Agile's great benefits. But that means you actually need to look at resolution of individual days, not some monolithic Task X that will Be Ready Whenever It's Ready.

Done vs. Delivered

One common problem (with Agile, and workplace planning in general) is that deadlines tend to come from management, not from the developers. That deadline might be divorced from the actual work to be done -- and particularly, it's likely to want things delivered as quickly as possible.

The problem is, "delivered ASAP" is a very chaotic process. It encourages cutting corners; coding "quick and dirty"; ignoring guidelines; not cleaning up after yourself. It encourages a mentality of "try it, see if it works. if yes, deliver. if no, try something else" -- and, phrased like that, you can see why nobody can predict how long anything will take.

Whereas if you are working methodically, if you're rigorous about planning and testing and so on, then you've set up a bunch of signposts and safety nets. It might take longer -- you're devoting a lot of time to things that aren't furthering immediate delivery, and, you might just not be very good at this kind of workflow yet -- but it will be much less volatile.

So one thing to ask yourself is: Is it the developers setting the sprint goals, according to the needs and necessities they actually see? Or is it management setting the deadlines, leaving developers to try and slot their commitments into a sprint-like schedule?

If developers aren't being afforded the time to plan things out, or work according to a reliable plan, then it's no wonder that they can't make helpful estimates. :)

Answer 14

This might be an unpopular opinion, but you might not be able to do anything about it.

I can imagine that over the years of team's existence and flux of leaders, people who were truly dissatisfied with the team, left. What you have are remains of people who might complain, but aren't interested in actually putting effort into improving the situation. They just want to spend their 8 hours of hacking code, not interrupted by anyone and just go home at end of the day. What you have here seems to be serious motivation problem. And it is not job of scrum master to solve that problem. It is problem of whoever is paying those people.

If this truly is the case, then only real option is getting rid of the current team and start over from scratch. Maybe leave one or two people who you think are best in the team and either fire or move the rest to different teams. You should at least discuss this possibility with your superiors.