Cómo lidiar con un PM / scrum no técnico que impulsa cada tarea como una tarea técnica

Answer 1

Bueno, tu Scrum Master (CSM) no debería ser un PM. También debe tener un Propietario del producto (CSPO), que se enfrenta al cliente y está específicamente a cargo de reunir los requisitos.

El propietario del producto reúne y enumera los requisitos en forma de Historias de usuarios, pero no enumera ni asigna tareas .

El Equipo de desarrollo (programadores) toma las Historias de usuario (requisitos) y las divide en tareas técnicas que ellos mismos asignan.

Scrum Master de NINGUNA MANERA …. NUNCA asigna tareas, reúne requisitos o dicta lo que hace el equipo.

De hecho, Scrum Master es la persona que debe resolver todos los problemas, impedimentos, obstáculos, etc. (incluido este).

Parece que su Scrum Master, Scrum Team y / o toda la compañía necesitan reevaluar la forma en que ejecutan Scrum. Este tipo de Scrum Repair es en realidad exactamente lo que hacemos.

Si tienes alguna pregunta o necesitas más, ayúdame a enviarme un correo electrónico:
[email protected]

Answer 2

Uno de los principios básicos de trabajar en Agile es tener coraje para hablar. En esta situación, debe tener el valor de decir lo que más valora para su cliente. Después de todo, ágil tiene que ver con el valor empresarial.

Es bastante claro, un requisito técnico de recopilación de clientes potenciales no es un estado óptimo para los riesgos principales de proyectos en la pérdida de perspectivas clave de negocios que Business Analyst debería poder ayudar.

Tome esta conversación y la ayuda de Business Analyst por separado en esto. A ver si esto funciona. Si la situación no mejora aún, tenga una reunión uno a uno con PM fuera del entorno oficial, probablemente durante el almuerzo y exprese su opinión.

Las cosas deberían mejorar. En lugar de saltar a conclusiones, intente entender desde la perspectiva de su PM antes de tomar cualquier paso para resolver su situación.

¡Espero que esto ayude!

Answer 3

No sé lo suficiente sobre los detalles de su situación para darle un mejor consejo que este, así que piense mucho antes de actuar. En mi opinión, este comportamiento no debería continuar. Las amenazas no son parte de la gestión de un proyecto. Desacuerdos, claro, pero no amenazas.

Primero hablaría con el gerente del proyecto y les haría saber que sus amenazas no son necesarias, y que ambos estamos tratando de hacer lo mejor para el proyecto, aunque no estemos de acuerdo sobre cómo hacerlo. Les preguntaría cómo podemos proceder sin amenazas. Me preocupa que hacer tareas técnicas no contribuya a resolver problemas reales de negocios, y que eso sea una pérdida de tiempo y esfuerzo, que se dedique mejor a comprender las necesidades de negocios. ¿Por qué, en particular, piensan que deberíamos hacer estas tareas técnicas en lugar de tratar de entender mejor las necesidades del negocio?

Si el gerente de proyecto no quiere hacer esto y las amenazas continúan, entonces procederé en función de cuánto necesitaba el trabajo. Si necesito el trabajo, buscaría una oportunidad para trabajar en otro proyecto, lejos de este gerente de proyecto. Preguntaría sobre otras oportunidades dentro de la empresa y nunca hablaré sobre por qué deseo cambiar de proyecto. Si no necesito el trabajo, o si me siento confiado en mi posición en la empresa, entonces hablaría con el gerente del gerente del proyecto y les diría sobre la situación. Si este gerente superior es compatible con el comportamiento del gerente de proyecto, entonces ciertamente necesito buscar otro lugar para trabajar. En el mejor de los casos, el gerente superior hace algo para mejorar la situación.

Esto no es divertido. Buena suerte.

Answer 4

Solo aprovecha la oportunidad que se te acerca. Al ser un líder técnico, puede participar parcialmente en el análisis de requisitos con PM no técnico o Scrum Master. Es bueno, de una manera, de lo contrario, el PM no técnico puede cometer algo y más adelante puede verse obligado a realizar esas tareas en un entorno no factible.

Answer 5

Deja para un mejor equipo.

Donde scrummaster es ágil, y nunca sería etiquetado como “PM”.

Donde el propietario del producto es tan competente en tecnología como lo es en la creación de cuota de mercado.

Donde los miembros del equipo no dicen “no es mi rol”, “no es mi trabajo”, “no es mi problema”.

Answer 6

no “tratar” con él. Arreglarlo antes de que se salga de control. Ambos son adultos, trabajen.