Image I love being a Scrum Master. What I love about it is helping a team accomplish something and honestly just making Developers' work lives as hassle-free as possible. I love working with smart people and seeing them accomplish amazing things.As a Scrum Master, most of us want to help.
Image I love being a Scrum Master. What I love about it is helping a team accomplish something and honestly just making Developers' work lives as hassle-free as possible. I love working with smart people and seeing them accomplish amazing things.As a Scrum Master, most of us want to help.
As a Scrum Master, most of us want to help. But sometimes we think we are helping when we’re actually hurting the team.
As a case in point, when I was a new Scrum Master, I was looking for how to add value to the team. So, I observed that submitting security and access requests was an annoying administrative job for the Developers. I suggested that I could help take those over for Developers. What began as a way to help quickly became a bottleneck. Pretty soon one of the Developers asked me, in an annoyed tone, if they had to submit these through me because it would be faster just to do it themselves. It was a lesson I haven’t forgotten. Sometimes helpfulness can be annoying.
Sometimes knowing what NOT to do can be as helpful as knowing what TO do. Here are five things that the Scrum Master shouldn’t be doing.
1) GatekeeperNo, I’m not talking about security access again. I once worked at an organization where instead of being the Scrum Master I was a stakeholder. I needed to request work from the Scrum team, and I knew it was a quick five-minute job, so I emailed my request to the Product Owner. Instead of adding the request to the Product Backlog (or telling me “no”), I got a snippy email from the Scrum Master a week later telling me that all requests for the Scrum team had to go through her. I decided to play by her rules and sent her a reply with my request, explaining that it was urgently needed. Ten back-and-forth emails and a couple of unanswered calls later, I finally actually gave up.
In context
- Topic: Proyectos, PMO y Riesgos — Gestión de proyectos, oficinas de proyecto y riesgo del portafolio.
- Source: Scrum.org
- Published: 04/10/2026
Continue reading at the original source →
Excerpt published automatically by the site radar. The full text belongs to its publisher and is linked above.
Why it matters
A project management office is worth the decisions it makes possible, not the reports it produces. Once the PMO becomes the function chasing status updates, it has already lost: the team learns to fill in the template and the real information goes back to travelling through the corridors.
My filter is the quality of the status report. If every project is green, the reporting system is not working: in any real portfolio some initiatives are in trouble, and a healthy organisation surfaces them in time rather than discovering them at the closure committee.
What usually goes wrong
Where it usually breaks is the handover to operations. The project is declared finished when it is delivered, not when the receiving area can sustain it. Three months later the team has dissolved, nobody documented anything, and operations lives with something it does not understand and cannot change.
What to watch
- The size of the first useful delivery: the further out it is, the more it resembles a bet.
- How it was estimated and how close the same organisation's previous estimates turned out to be.
- Who the sponsor is and how often they actually show up — not on the org chart, in the calendar.
How I read this entry
The way I would bring this down to earth is by shrinking the size of the deliveries. An eighteen-month project with nothing visible before month twelve is a bet, not a plan. I would rather have six deliveries that stand on their own, even if the total takes a little longer, because each one corrects the course.
This entry is an excerpt from the original source, selected by the site radar. The commentary above is the site's own and does not belong to the cited publisher.
Comments
No comments yet. Yours can be the first.
Living through this in your own team?
Open the chat and tell me how you're handling it. I'm interested in comparing notes.
