Current Episode

Episode 1:

How do I energize a demotivated Scrum team?

Angela recently joined an existing team as their new ScrumMaster. Unfortunately the team is a bit shell-shocked from their old ScrumMaster’s command-and-control ways. I’ll offer up several approaches to help her team get energized about Scrum again.

Like the podcast? I’d love it if you’d take 60 seconds to rate it in iTunes.

Mentioned in the show:

Agile Retrospectives:

Build Your Own Scrum:

Do you have a question for the show? Want the show notes or transcript?

Leave a Reply

Adam: Welcome to Agile Answers. I’m Adam Weisbart, your Certified Scrum Trainer and agile coach. Every week, I get your questions about Scrum and agility and I answer them here on Agile Answers.

Ever worked with a Scrum team that’s just totally demotivated? They don’t seem to care much about the Scrum framework or the daily Scrum or the sprint retrospective. They don’t seem to get much out of it. They kind of checked out. Well, today’s question comes from Angela Lewis who’s dealing with a Scrum team that’s in much of that situation. Let’s listen to her question and see if there’s any way we can help her out.

Angela: Hello, Adam. I had a team which was not trained on Scrum before I took over. The previous Scrum masters were seeking status updates during their stand ups, and in retrospective, they were looking at why such and such were not delivered.

When I took over the team, they were dispirited about Scrum and have bad habits. Despite my effort to train them on the values the team can gain from each of the ceremonies, they’re slow and reluctant to go with the Scrum framework. My question is how do you energize the dispirited team that you just took over, and how do you break their bad habits?

Adam: Oh, Angela, I feel your pain. I’ve been in the situation. First off, thanks for your question, and thanks for caring so much about your team that you submitted it. I know this can be really challenging. You want your team to do well. You want them to be excited. You know the value they can get out of Scrum. They just don’t seem interested.

Let’s take a look at maybe why that is, and I don’t think it has to do with you. I think it probably has to do with their previous Scrum master. Now you say the Scrum master was seeking status reports in the daily Scrum and that during the retrospective, they were asking people why this wasn’t delivered. Now those are both behaviors I would expect from somebody who was using Scrum as a weapon, somebody who, knowingly or unknowingly, is trying to keep up their command and control ways of being maybe a project manager and taking that into their role as a Scrum master. Now, I must admit, when I was a brand-new Scrum master, I did some of these things to. It’s really quite easy to fall into old patterns.

So the trick here is how do you break out of those old patterns? How do you help your team break out of those old patterns? Now the first thing I would do is actually not worry too much about the Scrum framework. You can talk to them about the daily Scrum, this meeting and that meeting, what they’re going to hear is wah-wah-wah-wah-wah-wah-wah-wah-wah, right? It’s going to be like Charlie Brown with the teacher. They probably don’t want someone to explain all of this to them again, because frankly, they’re fed up with it. They were beat up by it, and they want no part with it. It’s understandable. You picture yourself in that situation, and I bet you’d feel quite similar.

So what I would do is think different. I would be different than the last Scrum master. And the way I would do that is by focusing on the team. Don’t focus on the Scrum framework. Focus on the team, that whole individuals and interactions over processes and tools. Maybe it’s easier to say just people over process. Scrum is a great process, but what’s more important here, I think, is the team that’s using that process to get work done.

So the way that I would initially start this out is by having a retrospective. Now I know you said their retrospectives didn’t go particularly well because before, the Scrum master was asking, “Hey, why wasn’t this delivered?” during the retrospective. I wouldn’t have a Scrum retrospective, actually. I would just have a retrospective about the last year of working together as a team. During that retrospective, I would want to get a better idea of the impediments that they ran into working together as a team. Every team I’ve ever worked with, no matter how agile or not, can always identify things that are challenging to them, stuff that is a total de-motivator to them. The way you outlined in your question is a team that is totally demotivated. The way to help them get motivated is for them to see that you’re on their side.

Run a timeline retrospective. A timeline retrospective helps a team, when facilitated well, surface all the things or the major things they’ve dealt with over the last year, things that have both been great and things that have not been so great. Stuff about their process and working together, and stuff about the organization in general. You can find a great timeline retrospective in the book Agile Retrospectives: Making Good Teams Great by Esther Derby and Diana Larsen, I’ll put links to it in the show notes, and I would run that with my team. The cool thing here is your team is going to create a backlog of all the things that they find demotivating.

So your question is how do I motivate my team? Well, ask them, through this retrospective, what are things that are demotivating you? And then, over the next rest of your life with them as a Scrum master, help them remove those impediments. You’re going to create an organizational backlog. This would different than the team’s sprint backlog or product backlog. It will be a backlog that you use as Scrum master to help your team move through their troubles. So you’ll get the team to prioritize this thing, and you, as a dutiful Scrum master, will help them remove these impediments.

Depending on their size, it might take a while, but over time, your team will see that you’re actually on their side. You’re not there to command and control them, you’re there as a servant-leader to help them improve through whatever means they tell you they need help. So you don’t have to worry so much about the Scrum framework, initially. You just need to build some trust with your team by removing impediments for them, and that’s the best way I found to help my team improve and to help them see that I’m on, well, frankly, the same team as them.

The next thing I would do is act differently in the daily Scrum. You said the daily scrum was a place where their old Scrum master would look for reports from each of them. And so if you want to stand out from that Scrum master , seen that you are different from that Scrum master, remind the team that you’re there to let them know when they veer off topic, when they start talking about solutions to their impediments. But other than that, you’re not going to do anything. In fact, I would probably turn my back to my Scrum team. Not to be rude, but to show them that their meeting is for them and you’re there just to listen and if they need help in resolving organizational impediment, you’ll write that down and jump on that if they raise those, or if they start veering off of the three questions of the daily Scrum, and start trying to figure out solutions, you’ll remind them that those solutions could be better discussed in a sidebar after the daily Scrum.

Doing this one simple action will help them see that you are on their side, because the three people that need to discuss that impediment, who are impassioned about it and will have a good conversation about it can stay and do that as a sidebar, and the other five people on the team can go do anything else in the world. If they go take a nap or get coffee or both, they will be happier, more effective teammates than just standing around in a meeting for half an hour about an impediment that they have no part in resolving. So just by doing that, by facilitating that, you will start showing them that you are on their side and not asking for status reports, and not asking them what stuff is not delivered, because heck, they already know why stuff’s not delivered, right? It’s just your job to help them remove those impediments when they come up.

So lastly, you said that they weren’t trained in Scrum. And while I think training people in Scrum is very important, in fact it’s my job, I travel around the country and world teaching Certified Scrum Master Courses and doing onsite coaching and training, I do think it’s important, but I think out of all the things you’ve asked, it’s the least important. I think what’s most important here are the people over the process. When you get to the process part, when they actually see that you are on their side, when you’re removing these impediments for them, then I think it’s a good time to start talking about the Scrum framework again.

For that, I would use Build Your Own Scrum, which is a workshop module that I’ve put together that has a bunch of games that you play with your team to get them on the same page about Scrum. And instead of boring them with PowerPoint slides and that sort of thing and lecturing, you play these games with them and it will help get everybody on the same page about Scrum. You can ask them really good conversations about the Scrum framework and how it might help them or what impediments they currently have to it helping them.

You can download that from my site, I’ll put it in the show notes. And it’s free. It comes with a 30-page facilitation guide to walk you through doing the workshop with your team. And if you have any questions , or anyone out there listening to this that downloads Build Your Own Scrum has any questions, you’re welcome to get in touch with me. I would love to help you out. There are hundreds of folks using Build Your Own Scrum all over the world to teach Scrum to their team without a boring lecture, and it would be awesome if you joined them.

So Angela, I hope you found that helpful, and I really appreciate you submitting the question. If anybody else out there has a question, you can submit it at has a little widget on the front page there where you can record your question. Hopefully, I’ll answer it on a future show.

If you’d like the show notes from this episode, you can visit, that’s You’ll get a transcript to the episode. You’ll get links to the book that I mentioned or to Build Your Own Scrum. I want to thank Podington Bear for the music for this episode. You’ll find out more about him at as well. Look forward to seeing you next week where my friend Luke Walter will be joining me to answer caller’s question.

Until then, stay agile. Never change.

Past Episodes

Episode 24:

What should we do instead of painful “Annual Planning”?

Episode 23:

Agile Virtual Summit Preview: Lyssa Adkins

Episode 22:

How do we make sure we have cross-functional teams and why does it matter?

Episode 21:

What agile practices can you recommend to our game development studio?

Episode 20:

How do we remove silos when doing government contract work using Scrum?

Episode 19:

How should we form new Scrum teams?

Episode 18:

How can we have good retrospectives (about our Scrum Master)?

Episode 17:

When’s the podcast coming back?

Episode 16:

How do we self-organize if our boss is on our team?

Episode 15:

How do we deal with constant interruptions to our Sprint?

Episode 14:

Can a User Story be too long? Ours seem insane!

Episode 13:

Can our Scrum Master and Product Owner be the same person?

Episode 12:

What 1 simple thing can I do to improve my coaching & scrum mastering?

Episode 11:

How do I get hired as a ScrumMaster if I’ve never been one before?

Episode 10:

Our team wants to be more agile. What agile process is best?

Episode 9:

How do we improve our giant, multi-team Sprint Review session (or Sprint Reviews in general)?

Episode 8:

What are some creative & effective ways to make Retrospectives more engaging?

Episode 7:

Will this hurt my Daily Scrum? And how do we deal with “non-dev” work?

Episode 6:

How do I escaped the dreaded ‘Scrummerfall’ trap?

Episode 5:

How do you help PMs and Managers not fall back into their waterfall ways?

Episode 4:

Our teams keep changing. How do I set guidelines that keep teams together?

Episode 3:

How do you make sure your team has time to make the improvements they identify in their Retros?

Episode 2:

When should the business stakeholders get help from the dev team to get items ready for work?

Mic Check! 1…2…3…