Pruebas PMP vs Scrum Master vs Agile: evaluación de liderazgo de proyectos
Tres roles, tres señales diferentes
Un PM lidera entre organizaciones. Un Scrum Master entrena a un equipo. Un Agile Coach ayuda a las organizaciones a escalar frameworks. Comparten vocabulario pero requieren destrezas completamente diferentes. Sin embargo, la mayoría de los equipos los evalúan de la misma forma — o peor, confunden el rol.
El resultado: contratas un Scrum Master que no puede navegar la política, o un PM que no puede construir cohesión en el equipo, o un coach que nunca ha lanzado nada. Este post desglosa los tres roles, qué evaluar en cada uno, y las evaluaciones que funcionan.
Los tres roles definidos
Project Manager
Posee el resultado de un proyecto o iniciativa específica. Tiene autoridad (o puede construirla) para asignar recursos, tomar decisiones sobre trade-offs, y coordinar entre equipos. Es responsable de la línea de tiempo, el alcance, y a menudo el presupuesto.
Decisión clave: "Podemos lanzar a tiempo con menos funcionalidades, o tarde con todas, o caro con contratistas. Elijo: menos funcionalidades porque la fecha límite de decisión del cliente es agosto, no el impacto de ingresos del conjunto de características."
Scrum Master
Entrena a un equipo ágil. Elimina impedimentos, facilita ceremonias, y ayuda al equipo a mejorar su proceso. No tiene autoridad sobre el producto o la contratación; eso es del propietario del producto y del líder del equipo.
Decisión clave: "El equipo está derivando en reuniones de refinamiento. Ejecutaré una sesión separada para definir qué significa 'hecho', luego la usaré en futuros refinamientos para ser más rápido."
Agile Coach
Ayuda a las organizaciones a implementar o escalar frameworks ágiles. Trabaja en varios equipos, asesora al liderazgo sobre cambios estructurales, y resuelve conflictos entre equipos o frameworks.
Decisión clave: "La organización tiene tres equipos usando prácticas de estimación diferentes. Propongo una taxonomía común, la pruebo con un equipo, y si funciona, la implemento en los tres."
Por qué PMP tradicional no funciona para Scrum Masters
La certificación Project Management Professional (PMP) evalúa programación predictiva, gestión de riesgos, control de costos, e integración de partes interesadas en todo un ciclo de vida del proyecto. Asume que el PM tiene autoridad y un alcance definido.
El trabajo de un Scrum Master es diferente: eliminar bloqueadores para un equipo, mejorar la velocidad de iteración, y mantener ceremonias. No tienen autoridad para reasignar recursos o reducir el alcance del producto. PMP enseña el modelo mental equivocado.
Si contratas un PMP para un rol de Scrum Master: Querrán controlar el alcance, pelear con el propietario del producto, e intentar predecir cosas que no se pueden predecir en trabajo ágil.
Si contratas un Scrum Master para un rol de PM: Facilitarán discusiones pero no tomarán decisiones. Preguntarán al equipo "¿cómo manejamos esto?" cuando deberían estar decidiendo.
Evaluación por rol
Para Project Managers: Toma de decisiones + navegación de partes interesadas
Evalúa lo que importa:
- Problema de escenario (30 min): ¿Pueden tomar decisiones claras de trade-off bajo restricciones?
- Problema de priorización (20 min): ¿Pueden distinguir importante de urgente y defender la clasificación?
- Evaluación de riesgos (15 min): ¿Pueden identificar dependencias entre equipos y mitigar proactivamente?
- Entrevista comportamental (30 min): ¿Han navegado política, reestablecido expectativas, entregado malas noticias?
Criterio de contratación: Puntaje 4+ en toma de decisiones y juicio de riesgos. Puntaje 3.5+ en influencia de partes interesadas. Menor en ceremonia o conocimiento de procesos.
Para Scrum Masters: Coaching de equipo + diseño de procesos
Evalúa lo que importa:
-
Problema de impedimento (20 min, en vivo): "Tu equipo es lento en stand-ups, el refinamiento es caótico, y dos ingenieros están en conflicto sobre el objetivo del sprint. ¿Qué haces?"
- Señal alta: Hacer preguntas aclaratorias primero ("¿Qué significa 'lento' — hablamos 45 minutos cuando deberíamos hablar 15?"). Proponer intervenciones específicas vinculadas al problema. No asumir que puedes despedir a alguien o remover un miembro del equipo.
- Señal baja: "Mejoraría la comunicación" o "Ejecutaría mejores ceremonias."
-
Respuesta retrospectiva (15 min, en vivo): "Tu equipo hizo una retro y sacó a la luz que está bloqueado por la API de otro equipo. Están frustrados. ¿Cómo los ayudas a avanzar?"
- Señal alta: "Los ayudaría a articular el bloqueador específico, luego establecería una sesión de trabajo con el líder del otro equipo para desbloquearlo." (Propiedad a través de influencia, no autoridad.)
- Señal baja: "Lo escalaría" o "Les diría que simplemente trabajen alrededor."
-
Entrevista comportamental (30 min): ¿Han entrenado individuos, resuelto conflictos de equipo, o impulsado mejoras de procesos?
- Buenos ejemplos: "Noté que el equipo no estimaba correctamente el tamaño de la historia, así que ejecuté una sesión sobre story pointing y nos vimos mucho más rápidos."
- Malos ejemplos: "Le dije al equipo que siga el framework de Scrum" o "Escalé el problema al PM."
Criterio de contratación: Puntaje 4+ en coaching y empatía. Puntaje 3.5+ en diseño de procesos. Menor en pensamiento estratégico o influencia entre organizaciones.
Para Agile Coaches: Diseño organizacional + facilitación
Evalúa lo que importa:
-
Problema de escalamiento (30 min, en vivo): "Una organización tiene cuatro equipos. Dos usan Scrum, uno usa Kanban, uno usa cascada-ágil personalizada. Lanzan en ciclos diferentes, y es difícil para el liderazgo rastrear progreso entre equipos. ¿Cómo los ayudas a alinearse?"
- Señal alta: "Primero entendería por qué cada equipo tomó su decisión (¿tipos de producto diferentes? ¿liderazgo diferente? ¿madurez diferente?). Luego propondría una cadencia común — no un framework común — para que todos los equipos revisen progreso cada dos semanas. Eso deja que el liderazgo rastree entre equipos mientras respeta autonomía a nivel de equipo."
- Señal baja: "Les diría a todos que usen Scrum" o "Es complicado."
-
Resolución de conflictos (15 min, en vivo): "Un PM quiere que un equipo se comprometa a una fecha. El Scrum Master dice que no puedes comprometerte en ágil, solo pronosticar. ¿Cómo reconcilias esto?"
- Señal alta: "Separaría preocupaciones: podemos hacer un plan de capacidad (pronóstico), y por separado, podemos identificar riesgos de negocio y construir amortiguador en el plan (compromiso). El PM obtiene una fecha que puede usar con clientes; el equipo obtiene expectativas realistas."
- Señal baja: "Ágil no hace compromisos" o "El PM necesita aprender ágil."
-
Entrevista comportamental (30 min): ¿Han impulsado cambio organizacional, escalado frameworks, o resuelto conflictos multi-equipo?
- Buenos ejemplos: "Dos equipos tenían definiciones incompatibles de 'hecho', lo que bloqueaba entregas. Lideré un grupo de trabajo para definir un estándar compartido, lo probé con un equipo, luego lo implementé entre todos."
- Malos ejemplos: "Entrené gente en ágil" o "Creé un documento de proceso."
Criterio de contratación: Puntaje 4+ en pensamiento organizacional y gestión del cambio. Puntaje 3.5+ en facilitación. Menor en coaching de equipo práctico.
Errores comunes de contratación
Error 1: Publicar para un rol de "Project Manager/Scrum Master". Estos son trabajos diferentes. Si estás construyendo un equipo pequeño, necesitas un Scrum Master, no un PM. Si estás lanzando una gran iniciativa, necesitas un PM.
Error 2: Usar la misma evaluación para los tres roles. Un PM debe ser evaluado en toma de decisiones. Un Scrum Master debe ser evaluado en coaching. Un Agile Coach debe ser evaluado en pensamiento de sistemas. Reutilizar la misma prueba es como evaluar ingenieros y diseñadores de la misma forma.
Error 3: Sobrepesar certificaciones. Las credenciales PMP, CSM, y CAL muestran que alguien ha estudiado frameworks. No muestran juicio. Si alguien dice "Tengo un PMP, entonces puedo manejar cualquier cosa," sé escéptico. Evalualos en el rol que realmente tienes.
La matriz de comparación
| Dimensión | Project Manager | Scrum Master | Agile Coach |
|---|---|---|---|
| Autoridad | La tiene; toma decisiones de trade-off | No la tiene; influye a través de coaching | No la tiene; influye a través de frameworks |
| Alcance de enfoque | Proyecto completo, multi-equipo | Un equipo | Múltiples equipos, sistemas organizacionales |
| Destreza clave | Toma de decisiones bajo restricción | Coaching de equipo y diseño de procesos | Cambio organizacional y alineación |
| Bandera roja | No puede decidir; se cubre | No puede entrenar; escala | No puede pensar sistemas; prescribe un framework |
| Prioridad de evaluación | Juicio de riesgo + destreza de partes interesadas | Ejemplos de coaching + pensamiento de procesos | Gestión del cambio + facilitación |
Cómo elegir qué rol necesitas
Necesitas un Project Manager si: Estás lanzando un nuevo producto, integrando dos equipos, o lanzando una iniciativa que abarca múltiples equipos y tiene una fecha límite fija.
Necesitas un Scrum Master si: Tienes un solo equipo que está teniendo dificultades con ejecución de sprints, refinamiento, o conflictos dentro del equipo.
Necesitas un Agile Coach si: Tu organización está escalando prácticas ágiles, los equipos están usando frameworks diferentes, o intentas mejorar entre equipos.
Muchas organizaciones contratan un PM y un Scrum Master. Ambos son útiles, pero son diferentes. Evalualos diferentemente, contrata por diferentes fortalezas, y establece diferentes métricas de éxito.