Ayúdame a reconciliar mi título de gerente de proyecto con el desempeño de funciones de un maestro scrum

He trabajado como Gerente de Proyectos, como Scrum Master y como Gerente de Proyectos en lo que vagamente se ha descrito como Scrum.

Como bien mencionas, existen grandes diferencias entre cómo trabajas como Project Manager y como Scrum Master. Probablemente la diferencia más importante es que un Scrum master no es un gerente, es un líder servidor. Esta es una diferencia fundamental e irreconciliable.

Dicho esto, es posible tener el título de Project Manager, pero asumir el rol de Scrum Master. El mayor desafío no será con el equipo, sino con su relación con la gerencia y los que están fuera del equipo. Llegará un momento en que la gerencia pedirá algo que con razón esperan de un Project Manager pero que un Scrum Master nunca haría.

Un enfoque posible es asumir el papel de Scrum Master y dedicar algún tiempo a entrenar a los gerentes y a los que están fuera del equipo sobre cómo funciona Scrum. Si hace esto y tiene una gestión de mente abierta, entonces es posible dirigir un equipo Scrum exitoso.

Si nos enfocamos en los roles y no en los títulos de trabajo, siendo el PM también un rol con actividades, entonces te das cuenta de que Scrum divide al PM del equipo tradicional en el PO y el SM. El PO gestiona el Producto mientras que el SM gestiona el proceso.

No existe un rol de Gerente de Proyecto en lo que respecta al equipo, pero el gerente de proyecto puede trabajar para el Propietario del Producto y ayudarlo a organizar los clientes y la entrega.

Tan pronto como coloque el rol de Project Manager con la supervisión del equipo, eliminará los beneficios que son el valor de Scrum.

Si usted es un PM que está tratando de cumplir con un equipo Agile, debe elegir lo que le interesa, el proceso o el producto. No pueden ser los dos...

Creo que debes recordar que un Scrum Master es un rol, no necesariamente un título. En teoría, podrías llamarte Project Master Manager Guy y seguir desempeñando el papel de Scrum Master.

En mi puesto anterior, mi título era Gerente de Proyectos de TI, pero mi función diaria era Scrum Master.

¿Por qué tan centrado en el título y no en el trabajo?

Algunas otras respuestas han mencionado esto, pero hay una diferencia entre su título y su función. Su título en la organización puede ser Gerente de proyecto, pero podría tener diferentes roles en un equipo Scrum. Puede ver elementos del Project Manager en los roles Scrum Master y Product Owner. Dado que también menciona que es el administrador funcional del Equipo de desarrollo, es posible que le interese esta pregunta que sugiere que hay problemas con ese arreglo .

Las tareas específicas que menciona tienden a asignarse a las responsabilidades del propietario del producto. La gestión de los elementos del alcance, la conciliación de los elementos de trabajo con el BRD/SRS y las solicitudes de cambio enviadas no es tan diferente de la gestión de la acumulación de productos mediante la adición, eliminación y priorización de historias y el trabajo con el equipo de desarrollo para garantizar las historias. Cumplir con los plazos también es en parte el rol del propietario del producto, ya que parte del trabajo del propietario del producto es garantizar que el valor se entregue al usuario cuando lo necesite.

No dices qué tan grande es tu equipo de desarrollo. Scrum solo tiene tres roles: Propietario del producto, Scrum Master y Miembro del equipo de desarrollo. No es inconcebible que un miembro sénior del equipo de desarrollo (preferiblemente con algún conocimiento práctico de Scrum) pueda pasar al rol de Scrum Master mientras sigue funcionando como miembro del equipo de desarrollo, lo que le permite asumir el rol completo de propietario del producto. , que se alinearía con sus responsabilidades actuales. Si, por alguna razón, tiene poca carga después de este ajuste, considere realizar algún trabajo de prueba (principalmente pruebas de aceptación) o como experto en el dominio (suponiendo que su equipo no tenga experiencia en el dominio).

En cuanto a sus cosas "no scrum", no estaría demasiado preocupado por eso. Su ejemplo específico, de dar a la gerencia una idea de qué historias se pueden asignar a los próximos sprints, puede ser una buena idea. Esto puede ayudarlos en la transición de metodologías basadas en planes donde cada tarea tiene una fecha firme a métodos más ágiles. La clave aquí es asegurarse de que todos se den cuenta de que todo es tentativo fuera del sprint actual: las prioridades pueden cambiar y cambian, por lo que no hay cantidades excesivas de compromisos firmes demasiado lejanos en el futuro.

Tenga en cuenta que Scrum es un marco. Hay algunos puristas por ahí, pero debe tener en cuenta que está pasando de métodos basados ​​en planes a métodos ágiles y lleva tiempo aprender el nuevo enfoque e implementarlo por completo, no se trata solo de presionar un interruptor. También debe adaptar el marco cuando corresponda, teniendo en cuenta las lecciones aprendidas de las personas que han hecho la transición antes que usted.

No intente ceñirse a los nombres, roles y métodos. Elija aquellos con los que usted y su equipo son divertidos para trabajar.

Dos pensamientos: 1. si no ha consultado cómo capacitarse en CSM (por ejemplo, Scrum Alliance), ya que eso le proporcionará la teoría detrás del método de entrega de Scrum. 2. reconozca que un PM en Scrum significa que usted es un entrenador y guía, no un líder. El rol de líder es con el equipo. Es un reto para un PM no ser un PM- su función es garantizar que el equipo tenga todos los recursos que necesitan para completar el sprint en el tiempo. Esto incluye el acceso a las pymes, así como el material técnico. También es para garantizar que los roles de Scrum sean claros para todos: el equipo y las partes interesadas. El propietario del producto debe estar en el negocio. Scrum Master está con el equipo (podrías ser tú). En la práctica, también creo que debe ver si existe un rol de arquitecto: hacer que la arquitectura 'emerja' pone nerviosas a algunas personas en la administración comercial / de TI. Además, proporcionar límites (arquitectura empresarial y arquitectura tecnológica) no es malo: mantiene la toma de decisiones enfocada. Ideal - ¡experimenta! Intente cambiar los roles y vea qué mejora. Pregunte al equipo qué necesitan. Lo mismo para el propietario del producto. ¡Podría ser divertido!