What Nobody Tells You About Becoming a Scrum Master

When I got my CSM certification, I assumed the framework would do most of the work for me. Run the ceremonies, protect the sprint, remove blockers — the textbook made it sound almost mechanical. Show up, facilitate, repeat.

What the certification doesn't prepare you for is that a Scrum Master's real job starts where the framework ends. Standups are easy to schedule. Getting a team to actually say what's blocking them, instead of a polite "no updates, all good," takes months of trust-building — and trust doesn't show up on any certification syllabus.

Velocity is a compass, not a scoreboard

Early on, I treated velocity like a KPI to defend in front of stakeholders. Every sprint review, I'd walk in ready to explain why the number went up or down, as if I were reporting quarterly earnings. That backfired badly — teams quietly started padding estimates to hit a "safe" number instead of forecasting honestly, and the metric stopped meaning anything.

Velocity is only useful for the team's own planning conversations: how much can we realistically commit to next sprint, based on what we've actually delivered before. The moment it becomes a number reported upward and judged, people optimize for the number instead of the work. I've since made it a rule to keep velocity conversations entirely inside the team, and to talk to stakeholders in terms of scope and dates instead.

Retrospectives die from repetition, not from bad formats

The "what went well / what didn't go well / what will we improve" template works great for exactly three sprints. After that, people go through the motions — same three sticky notes, same vague action items nobody follows up on. I've sat through retros where I could predict what would be said before anyone spoke.

Rotating formats keeps people actually thinking instead of reciting. Sometimes it's as simple as a themed retro — "if this sprint were a movie, what genre was it and why." Sometimes it's flipping the format entirely and asking the team to identify what they'd stop doing if there were zero consequences. The format matters less than the fact that it's different enough to interrupt autopilot.

Removing impediments is often a people problem disguised as a process problem

The blocker is rarely "the API is slow." It's usually "nobody feels safe escalating that the API is slow, because the last person who raised it got told to just work around it." Fixing the second problem fixes the first one permanently — and it usually means having a direct, sometimes uncomfortable conversation with whoever created that atmosphere, rather than filing another ticket.

I've learned to ask a different question when someone raises a blocker: not "how do we fix this," but "how long has this actually been a problem, and why is today the first time I'm hearing about it." The answer to that second question is almost always more useful than the blocker itself.

The certification gets you in the room. Everything after that is earned

If you're starting this path, get comfortable with the fact that your job title says "Scrum Master" but your actual daily work is closer to organizational therapist, translator between business and engineering, and occasional bad-news-deliverer. None of that is in the two-day course. It's built one uncomfortable conversation, one honest retro, and one quietly-resolved conflict at a time — usually invisible to anyone outside the team, which is exactly the point.