What Being Scrum Master on Dopmin's Web Platform Actually Taught Me
Running sprints for a small cross-functional team is a different skill from writing the code — here is what stuck after leading Dopmin through several sprint cycles.
Leading Dopmin's corporate web platform as Scrum Master, on top of writing a lot of the code myself, taught me that the hardest part of Scrum isn't the ceremonies — it's protecting the team's focus between them.
A two-week sprint dies by a thousand small interruptions: a client message that becomes an unplanned mid-sprint request, a "quick" bug that eats a full day, a scope conversation that should have happened at planning instead happening on day 8. My job stopped being just about code and became about noticing when scope was quietly drifting and saying so out loud before it became a crisis at the retro.
The other thing that surprised me: velocity numbers are far less useful than the conversation you have about why they moved. A sprint that "under-delivered" but surfaced a real architectural risk early is a good sprint. A sprint that hit every point but shipped something nobody double-checked against the actual requirement is a quiet failure.
Since then, I try to run retros around one question: what almost went wrong that we caught in time, and what didn't we catch? That question surfaces more useful signal than a burndown chart ever has.