TLDR;

Just keep only what is required by the Scrum Guide—no more, no less. Focus on Empiricism and the Scrum Values.

Introduction

Recently I joined a new team and was taking over work from another Scrum Master. This team was 16 people large, including the Product Owner and the Scrum Master. When I started, my main focus was to start the new teams with a new product focus and only really focus on helping the Product Owners build their backlog and the Product Goal.

What did I notice? Every team member hated Scrum, including the Product Owner.

• They hated the way they were working.
• They hated the Scrum Events.
• They hated updating their hours on tasks.
• ...

My focus rapidly shifted to the entire team instead of the Product Owner. The first priority was getting just enough Product Backlog Items ready to start sprinting with a Product Goal that is not yet complete and can be refined while we are learning. Then see how the team can enjoy working with Scrum ones again.

What are the red flags to look for?

Well, there are a lot of red flags that you can look for. You can figure these out by just doing 1 on 1 talks with the team members and by just observing their current way of working.

It is important while you are just in your observation stage that you are not judgemental about their opinions around Scrum. I do this mostly by just nodding and asking deeper questions.

Here are the red flags I noticed during my observation stage:

The amount of people is too much in the team

When I joined, there were 16 people on the team. The Scrum Guide describes that an effective team has 10 or fewer people.

Luckily for me, there was already decided that the team was going to split into 2 new teams. One of 7 people and one of 8 people. They both work on the same User Journey but have different products they focus on. Giving the team the size required for Scrum to be effective.

There is a lot of overhead on the Scrum Events

For the Scrum Events, there was a lot of overhead for the teams. An example is the Sprint Review. Before the Sprint Review, there were 2 dry-run meetings with the whole team. Each meeting lasted 1,5 hours. A waste of time for a lot of team members.

You get challenged a lot when asking about their way of working

When you propose an exercise like planning poker with the team. You get challenged a lot. For my situation, I proposed to do Planning Poker with the team. I immediately got the response that they didn't find it valuable and that it was a waste of time.

They want to finish the Scrum Events fast

Just when starting a Sprint Planning Event. The Product Owner said that it'll probably only take 30 minutes to finish the Sprint Planning for a 4-week sprint. I immediately jumped in and told them that we'll probably use the full 2 hours to align ourselves and create a goal to work towards.

How to get your team to love Scrum ones again?

Observe

So as you probably read, it starts just with observing the team.

• What is their current state of Scrum?
• How do they feel in the team?
• How do they feel about the Scrum Events?
• How do they feel about the collaboration in the team?

Keep Scrum lightweight

Secondly, make Scrum as lightweight as possible. You can do this by sticking to the Scrum Guide and cutting out all that is not required.

For this team, it meant that:

• You don't need to update your hours on every task. Heck, don't even put hours into the task. I don't care about a burndown chart.
• Update the Sprint Backlog just once a day before the standup.
• Yes, you can put a Product Backlog Item into Sprint Planning when it's not all the way defined. We'll refine it there and then learn more while sprinting.
• I don't need to see every Product Backlog Item with all of the subtasks during the Sprint Planning Event. I just need tasks for 2-3 days.
• The Sprint Review does not have to be a PowerPoint with 30 slides. A few slides with just an update about our past Sprint and the priorities are good enough. Focus more on the demo/workshop that you'll create around our Product Increments. See the 10 Sprint Review Experiments!
• During the standup, I only want to hear a plan for the day and where you are blocked to reach the Sprint Goal. Do you want to go into detail? Ask for the people you need and do it after the standup.
• This list will probably grow while we are just in our first sprint. But after the first few events, I saw the team's motivation grow. - They now feel that they can focus on their work and are not wasting time on 'stupid' events or overhead for the way of working.

Focus on Empiricism

I told the team, I don't care about Scrum; I only care about the Empirical process it puts in place. So I want them to be Transparent about their work and challenges. Update the Sprint Backlog at least daily before the Daily Scrum. I want them to Inspect regularly about their progress and Adapt where needed.

Focus on the Values

Encourage the team to be Courageous and Open with their work. That they Focus on what is important to reach our Committed goals and be Respectful to each other. It's an ongoing process that you'll need to remind them of daily.

Conclusion

Observe the team closely when joining. Let them first run their Sprints how they are used to.

But the biggest part for me is just throwing away everything that is not described in the Scrum Guide. This makes their Scrum super lightweight and helps them focus more on the work.

We can still add changes to our Scrum after we identify improvements in the Sprint Retrospective, like a burn-down chart or WIP limits on the Sprint Backlog.

Focus on the Empirical process Scrum puts in place and the values that come with it. It helps them cope with all of their current struggles with Scrum.