What a Scrum Master actually does (and why it’s not “running meetings”)
A Scrum Master is there to help the team deliver better outcomes, more consistently, with less stress. That’s the job. Meetings are just the visible bit, like the tip of an iceberg, except less majestic and more likely to contain awkward silences.
A good Scrum Master helps the team improve how they work, sprint after sprint. They remove blockers, help the team collaborate, and keep attention on what matters. They also coach the Product Owner and the wider business so the team isn’t constantly interrupted, whiplashed by changing priorities, or dragged into “quick favours” that smash focus.
Here’s the part people miss. A Scrum Master is also a mirror. They point out habits that are slowing the team down. That can be uncomfortable. It’s hard to do that well when you’re also knee-deep in coding tasks, code reviews, production issues, and a backlog that breeds overnight like rabbits.
Is the Scrum Master role full-time
You said yes. I mostly agree. And I’ll add a practical rule of thumb.
- If you have one Scrum team doing steady delivery, the Scrum Master role is often close to full-time when you do it properly.
- If you have multiple teams, it can become definitely full-time, sometimes with support roles around it.
- If your team is brand new to Scrum, dealing with lots of stakeholders, or constantly interrupted, it’s basically full-time just to keep the wheels on.
Why does it take that much time? Because the real work sits between the lines:
- Coaching the team to improve flow and quality
- Working with leaders to reduce disruption
- Resolving cross-team dependencies
- Helping refine the backlog and slicing work smaller
- Spotting patterns in delays and defects
- Protecting the team’s focus so they can actually finish things
If you only have someone “facilitating the ceremonies”, you’re getting a tiny slice of the value. It’s like hiring an accountant to tidy your receipts but never look at your cashflow.
When it’s not full-time (yes, there are exceptions)
If your team is mature, stable, trusted by the business, and already strong at self-management, the Scrum Master workload can reduce. In those cases, a Scrum Master might support more than one team.
But note the difference. That’s not “a developer also doing it”. That’s a Scrum Master serving multiple teams because the teams are already healthy and the organisation isn’t constantly throwing grenades into the sprint.
Can a developer also be Scrum Master
Technically, yes. Practically, it’s a gamble.
The conflict isn’t about capability. Plenty of developers care deeply about teamwork and delivery. The conflict is about time, attention, and incentives.
A developer’s day gets swallowed by:
- building features
- fixing bugs
- reviewing pull requests
- helping others unblock technically
- dealing with production incidents
- context switching across tasks
A Scrum Master’s day gets swallowed by:
- removing blockers that are not coding problems
- coaching behaviours and communication
- working with stakeholders to shape priorities
- improving planning, flow, and predictability
- protecting the team from overload
Put those together and you often get one of two outcomes.
- The person stays a developer. Scrum Master work becomes “nice to have”. The process degrades quietly.
- The person tries to do both properly. They burn out, or their coding output drops, or both.
The biggest risk: you lose your feedback loop
A Scrum Master needs to call out patterns like:
- “We keep overcommitting.”
- “We’re not finishing work.”
- “Stakeholders keep bypassing the Product Owner.”
- “We’re treating carryover as normal.”
If the Scrum Master is also a key developer, it’s harder to have those conversations cleanly. Sometimes the Scrum Master needs to challenge technical decisions too. That gets awkward fast if they are the one making those decisions.
A quick comparison table you can use
| Approach | When It Can Work | Common Failure Mode | What It Costs You |
|---|---|---|---|
| Developer is Scrum Master | Tiny team, low change, calm stakeholders | Scrum Master work gets skipped | Slow improvement, rising stress |
| Part-time Scrum Master (non-dev) | Team is fairly mature | Not enough time to remove real blockers | “Ceremonies-only Scrum” |
| Dedicated Scrum Master | Most teams that want consistent delivery | Needs organisational support | Real change, fewer surprises |
| Agile coach covers multiple teams | Several teams, consistent leadership backing | Too broad, spreads thin | Improvements happen slower |
If you’re a business owner reading this, here’s the simple translation. Paying for a dedicated Scrum Master is often cheaper than the hidden cost of missed deadlines, rework, staff churn, and constant “why is this taking so long” conversations.
The Scrum Master as a Servant Leader
You asked, “What is a Servent Leader?” I’ll use the common spelling: Servant Leader.
A Servant Leader leads by helping others succeed. They don’t lead by command-and-control. They lead by:
- clearing obstacles
- building trust
- encouraging ownership
- creating safety for honest conversations
- helping people grow their skills and confidence
In Scrum, the Scrum Master is a Servant Leader for the Scrum Team. They don’t manage people. They support people. They create the conditions where the team can do great work.
A simple way to think about it: a traditional manager says, “Do this.” A Servant Leader asks, “What do you need from me to do your best work?”
That sounds soft until you see how hard it is to do consistently. It takes patience, backbone, and the ability to hold boundaries. You’re serving the team, but you’re also protecting standards.
Why “people before technology” matters here
This is where I get a bit opinionated.
Scrum is not a process you install. It’s a way to help humans collaborate on complicated work. Software is complicated because people are involved. Customers change their minds. Requirements evolve. Teams learn as they build. Reality refuses to sit still.
When you treat Scrum like a checklist, you get busy teams with low delivery. When you treat Scrum like a way to support people, you get a calmer team and better outcomes.
That’s why the Scrum Master role matters. It’s the person whose job is to keep the system healthy. If that person is also coding full-time, the “system health” work is what gets sacrificed first.
What I recommend for small teams (especially SMEs)
A lot of small businesses can’t justify another full-time role on paper. Fair enough. So here are practical options I’ve seen work.
Option 1: A dedicated Scrum Master (best if delivery matters)
If software delivery is central to your growth or customer experience, make the Scrum Master role dedicated. This is often the fastest path to calmer delivery and fewer nasty surprises.
Option 2: Rotate a facilitator, but keep Scrum Master separate
If you really can’t hire a Scrum Master yet, rotate meeting facilitation among the team. That spreads the admin work. But still have someone (often an external coach or fractional Agile lead) responsible for the real Scrum Master outcomes: removing blockers, coaching, stakeholder alignment.
Option 3: Bring in a fractional Scrum Master or Agile coach
This can work well for SMEs. You get experienced guidance without a full-time cost. It’s a strong fit when you’re scaling up, hiring, or modernising legacy systems.
Option 4: If a developer must do it, protect time properly
If you choose the dual role, set expectations in writing:
- reduce their dev workload meaningfully (not “same work, new hat”)
- make Scrum Master work visible on the board
- give them authority to push back on interruptions
- review after 4 to 6 weeks and be willing to change course
If you do none of that, you’re basically hoping for magic. Magic is not a delivery strategy.
Signs you need a full-time Scrum Master right now
If you see a few of these, the role is already full-time. You’re just not paying for it yet. Your team is paying for it with overtime, stress, and churn.
- Sprint goals rarely get met
- Work carries over every sprint
- Stakeholders interrupt the team daily
- The Product Owner is overwhelmed or absent
- Meetings feel pointless or tense
- Releases are stressful and last-minute
- Quality is slipping, more bugs are escaping
- People say, “We’re busy,” but nothing finishes
What success looks like (in plain terms)
When Scrum is working well, you don’t just get more output. You get:
- clearer priorities
- better teamwork
- fewer surprises
- more predictable delivery
- less rework
- more sustainable pace
That’s what most business owners want. Calm progress. A team that ships value without drama. And yes, it’s possible.
FAQ
Q: Can a Developer also be a Scrum Master in a small team?
A: Yes, but it’s risky. If you do it, reduce the developer workload and treat Scrum Master work as real work, not volunteer hours.
Q: Is a Scrum Master a full-time role?
A: In most teams, yes. It becomes full-time as soon as you take coaching, blocker removal, and stakeholder alignment seriously.
Q: What is a Servant Leader in Scrum?
A: A Servant Leader helps others succeed by removing obstacles, building trust, and supporting growth. They lead through service, not control.
Q: What’s the biggest sign Scrum isn’t working?
A: When the team is always busy but rarely finishes committed work. That usually means interruptions, unclear priorities, or work that’s too large.
Q: What’s a good alternative if I can’t hire a full-time Scrum Master?
A: Consider a fractional Scrum Master or Agile coach, especially during growth or change.
