¿Quién es el jefe de proyecto en un proyecto ágil – Scrum?

No hay proyecto ágil en el que participe en el que no salga el tema… ¿y quién es en Scrum el jefe de proyecto? Ya saco Jesús Corrochano el tema hace unos días en el post hablemos de la nueva Ingeniería de Software. Y con este post quiero volver a reforzar el tema.
En Scrum, el papel tradicional del jefe de proyecto no existe como tal, está realmente dividido en dos: las funciones del Product Owner (si no conoces el término aquí tienes una buena recopilación sobre el rol de product owner) y las del Scrum Master (te dejo más información sobre el Scrum Master en este post). Sin olvidar, que parte de la responsabilidad recae sobre todos los miembros del equipo Scrum (recuerda que es auto-organizado y multifuncional).
– El Product Owner es responsable de definir el alcance del proyecto, priorizando el trabajo, conocer para ello la velocidad del equipo, etc. El Product Owner gestiona todo lo que  sucede fuera del equipo y es el único punto de contacto desde y hacia el equipo.
– El Scrum Master es más orientado al equipo, gestiona el proceso, soluciona problemas, busca que el equipo no pierda velocidad, etc.
Por ello, pensar en el Scrum Master como el jefe de proyecto es un error. Y en mi opinión, recae incluso más responsabilidad de las tradicionales del jefe de proyecto en el Product Owner que en el Scrum Master, por lo que, por cierto, pensar en el Product Owner como un comercial es también un error (los comerciales son «stakeholder»).
Y, antes de que lo pienses, no es nada recomendable combinar el papel de Product Owner y el de Scrum Master en una única persona, para volver a tener un jefe de proyecto, deben ser personas diferentes. El Product Owner trabaja desde la perspectiva del usuario final y el cliente, con el objetivo de entregar el mayor valor y que se construya lo correcto. El Scrum Master es parte del equipo técnico y busca que se cumpla el proceso y eliminar problemas.

0 comentarios en “¿Quién es el jefe de proyecto en un proyecto ágil – Scrum?”

  1. Hola Javier:
    Qué tema más recurrente… jejeje. Se agradece leer tu opinión sobre el tema.
    Estoy totalmente de acuerdo en que el ScrumMaster y el Product Owner no sean la misma persona, no ofrece discusión.
    Pero tengo una ligera discrepancia con respecto a la última frase del artículo: El Scrum Master es parte del equipo técnico y busca que se cumpla el proceso y eliminar problemas.
    Personalmente creo que el Scrum Master no debe ser parte del equipo. En mi blog tengo una entrada que plantea precísamente este dilema ¿El ScrumMaster puede formar parte del equipo de desarrollo?
    El ScrumMaster, como responsable del método, debe velar para mantener el equilibrio entre los distintos roles. Si forma parte del equipo de desarrollo, es posible que tenga una visión del método más cercana a este (al equipo) que al producto, alejándose del Product Owner. No quiero suponerle falta de profesionalidad, es más bien una tendencia natural.
    Veo más factible que el Product Owner forme parte del Equipo de desarrollo, a que lo haga en ScrumMaster. Sin embargo, frecuentemente, leo y veo cómo el rol de ScrumMaster lo desempeña un miembro del Equipo, y en ocasiones de forma rotativa. ¿Será por motivos estructurales impuestos por la organización?
    ¿Cómo ves este tema?
    Saludos, enhorabuena por tu trabajo y gracias por compartirlo.
    Óscar R. Onrubia

  2. ¿Y no podemos partir del conocimiento de SCRUM, XP, RUP, etc y aplicar el sentido común?
    He visto auténticas barbaridas por querer seguir SCRUM al pie de la letra…
    Está claro, no soy fundamentalista… 😉

  3. Antonio Bachiller Cáceres

    Muy buenas,
    Estoy empezando a formarme sobre Scrum.
    La verdad es que leyendo las primeras líneas ya estaba pensado en unir los dos roles.
    En mi caso lo normal es que el responsable técnico además de decidir el enfoque técnico (diseño + tecnología) gestione tareas y plazos. Ademas es muy normal participar en la viabilidad de los requisitos.
    En un equipo reducido (max 5 peronas) solemos hacerlo así.
    ¿Que enfoque le daríais a este tipo de equipos?
    ¿Como se repartirían los roles?
    PD: Excelente post, muy reflexivo.
    Gracias.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Share This
Ir arriba