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.
Por qué importa
Una oficina de proyectos vale por las decisiones que hace posibles, no por los reportes que produce. Cuando la PMO se convierte en el área que persigue actualizaciones de estado, ya perdió: el equipo aprende a llenar el formato y la información real vuelve a viajar por los pasillos.
Mi filtro es la calidad del reporte de estado. Si todos los proyectos están en verde, el sistema de información no sirve: en cualquier portafolio real hay iniciativas en problemas, y una organización sana las muestra a tiempo en vez de descubrirlas en el comité de cierre.
Lo que suele salir mal
Donde suele romperse es en el traspaso a operación. El proyecto se declara terminado cuando se entrega, no cuando el área que lo recibe puede sostenerlo. Tres meses después el equipo se disolvió, nadie documentó nada y la operación convive con algo que no entiende y no puede modificar.
Qué mirar
- El tamaño de la primera entrega útil: mientras más lejos esté, más se parece a una apuesta.
- Cómo se estimó y qué tan cerca estuvieron las estimaciones anteriores de la misma organización.
- Quién es el patrocinador y con qué frecuencia real aparece — no en el organigrama, en la agenda.
Cómo leo esta entrada
La forma en que yo bajaría esto a tierra es reduciendo el tamaño de las entregas. Un proyecto de dieciocho meses sin nada visible antes del mes doce es una apuesta, no un plan. Prefiero seis entregas que sirvan por separado, aunque el total tarde un poco más, porque cada una corrige el rumbo.
La noticia original está publicada en otro idioma; acá se cita el extracto tal como lo entrega el medio y el comentario se escribe en español.
Comentarios
Todavía no hay comentarios. El primero puede ser el tuyo.
¿Lo estás viviendo en tu equipo?
Abrí el chat y contame cómo lo están manejando. Me interesa comparar notas.
