Should a Team Lead be the Scrum Master?

My first contact with Scrum happened in 2012. Back then, we worked according to a waterfall model. The jobs were well defined: business analyst, software engineer, quality assurance engineer, project manager, delivery manager, and many other titles. However, our results constantly frustrated the new COO; he couldn’t see an outcome justifying the total costs, and he yearned for a change. That was the moment a massive transformation happened.

The COO pressured the CEO to change the IT Department drastically. They came up with a radical approach: implement Scrum and cut the team size by half. At first, I was shocked. I couldn’t understand how we would function better with half of our people. Still, after some six months, one thing became clear:

Few people focused on the outcome can outperform many people following rigid processes.

The transformation wasn’t smooth. We hit the wall several times. One of the challenges we faced was who should take on each role? Some things were obvious, e.g., a Business Analyst becoming a Product Owner, but we struggled with the Scrum Master role. We didn't know for sure who should lead the Scrum Team. We tried different approaches until we could succeed.

In this post I will share what I learned from Scrum Masters being the Team Lead, a team member, or a neutral person. Hopefully, it will help you understand the pros and cons of each scenario.

What’s a Scrum Master?

Companies frequently misinterpret what this role means. If you’d ask ten different people, you would probably get ten different answers to this question. Before we look at what the role is about, let’s understand what a Scrum Master isn’t:

• Scrum Team Secretary: Responsible for scheduling all meetings and rituals required by the team.
• Therapist: The one who’s always there to listen to team members and offer therapy sessions for their problems.
• Delivery Manager: Accountable for maximizing the teams’ output and agreeing on release dates.
• Boss: Hosts one-on-one with team members to micromanage what they are doing and how to squeeze them more.

Once you understand what a Scrum Master isn’t, you can better understand the role from the Scrum Guide. In bold, you can read the most relevant aspects:

The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide. They do this by helping everyone understand Scrum theory and practice, both within the Scrum Team and the organization.

The Scrum Master is accountable for the Scrum Team’s effectiveness. They do this by enabling the Scrum Team to improve its practices, within the Scrum framework.

Scrum Masters are true leaders who serve the Scrum Team and the larger organization.

Team Lead as a Scrum Master

Coming back to my first experience with Scrum, our team lead was our first choice for the Scrum Master position. He felt accountable for our success as a team with Scrum. The experience had two sides, positive and negative. Let me walk you through what I’ve learned.

Pros

The Team Lead had more authority over the organization than any other team member, and that helped us significantly during the early stages of our implementation. Here are some key points:

• Access: Our Team Lead attended several meetings with executives to which no other team member had access. This let him advocate for different ways of working and collaborating. He took every opportunity to educate high-level stakeholders on how to benefit from Scrum.
• Authority: Given that he was an experienced developer promoted to Team Lead, the organization respected his perspective and followed him. Executives trusted him regardless of Scrum, so they would listen to him instead of rejecting his points.
• Fast team adoption: Team members wouldn’t like to piss off their boss. We faced little to no resistance with Scrum adoption inside the team. Everyone agreed to give it a try and attended to all events with an open mind. I attribute that to the direct manager pushing for this, and nobody wanted to go against him.

Cons

The Scrum Master came as an additional responsibility to our Team Lead, which worked sometimes and caused conflict on several occasions. Here are some examples:

• Availability: We had to shift our Scrum events due to agenda conflicts constantly. This was annoying and demotivating.
• Conflict of interest: The Team Lead couldn’t take a neutral position in many situations. For example, a developer took longer than expected to finish a task. The Team Lead would interrupt the daily and push for an explanation instead of bringing up the situation and letting the team find a solution.
• Secret agenda: At some point in time, our dailies got tiring as our Team Lead frequently brought up unexpected topics, announcements, or something else. In short, instead of 15 minutes, it tended to take 25 to 30 minutes a day. That demotivated the team, and nobody would say anything for fear of conflict with the boss.
• Squeeze the lemon: Now and then, the Team Lead would take a manager position and ask someone in the team to do something for him. Regardless of the Sprint Goal and our progress, the Team Lead would forget everything about Scrum and interrupt the team.

The most dangerous part of a Team Lead wearing the Scrum Master’s hat is the people management responsibilities. It’s hard to take a neutral position and the team won’t grow into a stronger team if they fear conflict.

Team Member as a Scrum Master

After three months, our Team Lead realized he was damaging the team as a Scrum Master and asked to step down. It was a noble action from him as he perceived it himself. We didn’t have a solution, but he asked us to figure out how we would like to proceed. Our choice was for a team member to take the Scrum Master role.

The QA Engineer took a stand and decided to wear the Scrum Master’s hat. This setup ran for another three months, and here is what I learned:

Pros

The team benefited the most with a team member acting as a Scrum Master. Some benefits were:

• Cadence: Our events came to a natural frequency. Every event happened at the same time and place. It reduced friction, and we learned to timebox our exchanges.
• Conflict: The Scrum Master could name conflicts with the team and encourage the team to solve them while being part of the team. I felt we grew as a team as we could pinpoint what wasn’t working well.
• Balance: As a team member, the Scrum Master kept us free of  interruptions. The Product Owner couldn’t put additional topics into the Sprint, and stakeholders were redirected to the Product Owner whenever they wanted something extra.

Cons

Similar to our previous scenario, the responsibilities of a Scrum Master came on top of our QA’s current responsibilities. That didn’t make it easier for him to thrive with the additional role. We struggled with the following:

• Mechanical Retrospectives: Almost all retrospectives had the same format; we answered mechanically the same questions. Also, we didn’t follow the agreed actions during the Sprint, and slowly, the retrospective lost its value, and we started skipping it.
• Absent Scrum Master: When we needed the Scrum Master the most, he was absent because he had to wear his QA hat. For example, our refinements became chaotic and stressful, the Product Owner wanted to talk about problems to solve, and developers wanted sharp requirements to implement. The discussion often fell into a tech spiral, and we couldn’t proceed. The Scrum Master was absent because he was part of the discussion as well.
• Low involvement with top management: Our QA had no interaction with executives and C-level, and they would reject his meetings invitations. Slowly our Scrum adoption deteriorated because influential stakeholders fell back to previous command and control behavior.

The responsibilities switch was considerable, and our QA could only be semi-successful in these roles. After three months, he wanted to focus on either QA or Scrum Master. Which brings me to the last variation we experimented with.

Neutral Person as a Scrum Master

We were skeptical about our progress. As a team, we felt more robust, but the pressure from our stakeholders was unbearable. We needed help. Many stakeholders pushed for predictability and wanted to interrupt our Sprints all the time. They ignored the fact that we worked with Scrum and started being aggressive, “I don’t care how you work. I want this done by tomorrow!”

The company decided to bring an external consultant to act as a dedicated Scrum Master. We were raw to Scrum, it was only nine months since we had our first Sprint, and we hoped an experienced Scrum Master was all we needed.

Pros

We quickly observed several advantages of having an experienced person as a Scrum Master, and our progress accelerated. Here are some of the fundamental changes:

• Taylor-made retrospective: From mechanical to engaging exchanges, that’s what happened with our retros. Our Scrum Master knew how to bring the proper format to uncover our bottlenecks, Sprint after Sprint; I felt we became a stronger team.
• More questions and fewer answers: I don’t recall our Scrum Master giving us answers to any of our problems, but I do remember many questions. I felt he always met us a step ahead and helped us advance step by step. It’s like he knew which question we needed to answer.
• Transparency: He knew how to deal with our pushy stakeholders. He would invite them for a coffee, share observations, and help them understand the effects on our team. And then, he would say how a sustainable collaboration could be beneficial.
• Right words: He was direct and knew how to deal with demanding stakeholders. I remember when he got a stakeholder to the corner of our room and told him, “If you push them to deliver more without getting them committed, you will get nothing but resistance. But if you bring them purpose and ask for help to reach goals, you will benefit from commitment. You can pick your choice.” It was a game-changer for us.

Cons

At the beginning of our relationship with our new Scrum Master, I couldn’t see any negative aspects. Yet, as we grew as a team, I noticed our collaboration changed. Here are some characteristics:

• Silent: The Scrum Master was silent and barely exchanged with us. He seemed like an outsider to our team. He remained quiet on his chair, and I felt distant from him. Although he was there for us, I didn’t feel he was with us during our Sprints.
• Only questions annoyed the team: Given our progress, we’d rarely face a problem as a team and ask the Scrum Master for help. But when we longed for directions, he would only ask questions and we would feel he didn’t meet us where we needed him.
• Uncertain outcome: As we became self-managing, we had less and less involvement with the Scrum Master. We started doubting the value of his work with us because mostly, he had interactions only during our Scrum events.

My Perspective

Since this experience, I’ve been in dozens of Scrum teams, shaping my perspective according to each scenario. The best choice greatly depends on your scenario. My approach is the following:

• Unexperienced team and organization: A dedicated and skilled Scrum Master is vital to success. Preferably this person is outside the team and has no executive  power over any team member.
• Experienced team and organization: A team member can play the Scrum Master role in a scenario where the team runs autonomously. It’s sustainable to have a rotative Scrum Master responsibility for the team members.

Answering my initial question, should a Team Lead be the Scrum Master? I would be against it because it will limit team members from starting sustainable conflicts and evolving as a team. Also, the Scrum Master would function best without any work activity inside the team; this would empower him to act as an observer and help the team progress step by step.

“Scrum is like your mother-in-law, it points out ALL your faults.”  - Ken Schwaber