Supongo que eres el líder técnico.

Pide prioridades

Tan pronto como conozca la lista de tareas, envíe un correo electrónico a su gerente:

Hola [Nombre], (o Hola Sr(s) [Nombre] si no son tan cercanos)

He visto las tareas que se supone que debemos realizar para este sprint y, según las estimaciones, no podremos realizarlas todas. ¿Podría por favor priorizar la tarea?

Saludos,

[Blabla]

(también puede presentar una lista de prioridades y pedir acuerdo)

De esa manera, si responde y solo realiza tareas de máxima prioridad, puede usar esto como argumento. Si no responde, podrá decirles que envió una alerta y la ignoraron. Hiciste tu trabajo.

Deja de trabajar en una 'zona desconocida'

Como empresa, se debe tomar una decisión: ¿desea avanzar hacia una forma ágil de trabajar con Sprints y todo lo demás que implica o desea adoptar un enfoque más "clásico"?

Si se van a utilizar sprints, las únicas personas que pueden decidir qué trabajo se realizará en un sprint son el equipo de scrum: el propietario del producto y los desarrolladores. Tenga en cuenta que no hay ningún "director de proyecto" en este escenario. El propietario del producto es quien decide la prioridad de todas las diferentes historias y funcionalidades y luego el equipo de scrum decide durante la planificación del sprint qué elementos recogerán durante esa iteración. Aquí no hay lugar para que nadie obligue a los desarrolladores a realizar más trabajo. Si los diferentes gerentes de proyecto (que se convertirán en partes interesadas en la nueva estructura) quieren que cambien las prioridades, deberán convencer al propietario del producto para que cambie las prioridades. Si durante un sprint resulta que todas las historias están completas (incluidas las pruebas) y hay espacio para más trabajo, el equipo de scrum tendrá una reunión rápida para decidir qué historias incluirán en el sprint además de las historias que se decidieron durante la planificación del sprint. Si varias partes interesadas tienen prioridades en conflicto, el propietario del producto debe reunirse con todos ellos y hacer que decidan juntos cuáles creen que deberían ser las prioridades, de las cuales pueden intentar convencer al propietario del producto.

En un enfoque más clásico, algo similar debería suceder. Dado que los gerentes de proyecto no son los que hacen el trabajo, deben dejar el juicio de lo que se puede hacer dentro de un período de tiempo determinado a los expertos: los líderes tecnológicos. Siempre pueden pedir más, pero deben confiar en el juicio de los líderes tecnológicos. Si varios gerentes de proyecto dependen del mismo grupo de personas para realizar sus tareas, esos gerentes de proyecto deben decidir entre ellos cuál debe ser el orden de prioridad en las tareas y luego confiar en los líderes tecnológicos para garantizar que se respete este orden. En este caso, no existe tal cosa como un 'objetivo de extensión': el trabajo se completa en orden de prioridad y si alguien se queda sin tareas, ascenderá por la proverbial cadena alimenticia para preguntar cuál debería ser su próxima tarea.

Al tratar de trabajar de la manera clásica dentro de una estructura Agile/Scrum de sprints, se crea una increíble cantidad de presión sobre los desarrolladores, lo que prácticamente siempre es contraproducente. En una estructura tan clásica, nunca debe depender del desarrollador decidir si debe trabajar en una tarea para un gerente de proyecto u otro, ya que no puede evaluar correctamente qué tarea tiene el mayor valor comercial. La forma de trabajar que parece describirse en la pregunta aquí conducirá al agotamiento de los desarrolladores, lo que lleva a los desarrolladores a buscar pastos más verdes.

¿Qué hacer con los Gerentes de Proyectos de Software sobrecargando agresivamente a los Líderes Técnicos?

Necesita administrar sus expectativas estableciendo límites . Es un tema sobre el que podrías escribir libros enteros, así que cubriré solo el problema específico con el que te encuentras: los PM sobrecargan a tu equipo con solicitudes que saben que no son razonables.

La forma en que han redactado esto en realidad te ayuda mucho, porque hace que sea más fácil retroceder. La próxima vez que un PM le pregunte por qué no se realizaron las funciones X, su respuesta debe incluir algunas de las siguientes frases:

• Como saben, asumimos más de lo que podíamos entregar, por lo que tuvimos que priorizar X, Y y Z.

• Como recordará, mencioné que no podríamos hacer más que X y que solo haríamos Y si nos adelantábamos significativamente al cronograma.

• Nuestra estimación original era bastante precisa, por lo que no tuvimos tiempo de analizarla.

Si está asumiendo una carga de trabajo regular, un PM agrega funciones adicionales además de eso y luego se queja de por qué no se hicieron esos extras, use una variación de:

• Según tengo entendido, X e Y se consideraban extras que tomaríamos si todavía tuviéramos tiempo disponible. Nuestra estimación/objetivo original era bastante precisa, por lo que no pudimos tomar esta.

• No estoy seguro de seguir, dijiste que estos eran objetivos falsos, ¿verdad? Nos enfocamos en los objetivos principales (X, Y y Z) y ya están listos, pero no tuvimos tiempo para abordar los objetivos extensos.

Si está utilizando un modelo de entrega ágil, puede ayudar a cambiar la jerga:

• como discutimos, ese era un objetivo ambicioso que estaba fuera de nuestro pronóstico
• tuvimos que refinar el backlog
• tendremos que llevar esto al siguiente sprint

El punto es dejar en claro que su equipo tiene una capacidad limitada y que obviamente debe priorizar cuando se le asigna más de lo que es factible entregar.

Tenga en cuenta que todo lo anterior solo funciona si está en una posición semifuerte, que como líder tecnológico debería estar. Hacer retroceder los requisitos poco realistas siempre es complicado porque tienden a provenir de personas poco realistas. Necesita saber cómo hacer retroceder a las personas que exigen más horas de las que su equipo prácticamente puede cumplir, que insisten en las horas extras cuando no tiene sentido pedírselas a su equipo, que dicen que algo es una meta exagerada cuando en realidad lo que quieren decir es "No aceptaré un no por respuesta". Manejar eso bien viene con la experiencia.

Suponiendo que conoce su velocidad, está restringido por la cantidad de puntos de historia que puede completar.

La empresa necesita priorizar la carga de trabajo con el director del proyecto.

No puedo recomendar sobrecargar el sprint (porque si no cumple con lo acordado, anula el propósito de planificar y ser ágil). Si las historias no se entregan a tiempo, la responsabilidad finalmente recae en el PM.

Además, suponiendo que el PM sea razonable (y sepa cómo trabajar en Agile), debe saber que si se agrega algo al sprint, entonces se debe eliminar algo más; esto también es su responsabilidad.

Si te preocupa que sea tu culpa, no lo hagas . La responsabilidad se detiene con el director del proyecto para gestionar el proyecto correctamente.

Editar: solo estoy volviendo a leer tu publicación: un ' objetivo ampliado ' está perfectamente bien. Simplemente significa que, si el equipo completa todo el trabajo del sprint, puedes traer trabajo adicional... pero solo si terminas lo acordado. Rara vez sucede, en mi experiencia.

El trabajo del líder tecnológico es gestionar las expectativas del PM. El trabajo del PM es impulsar el proyecto y hacerlo bien, tan rápido y como sea posible.

Como líder técnico, estos son algunos consejos para mejorar eso:

• Requerir que cualquier solicitud para completar "Más puntos" sea una solicitud específica sobre las historias que desean ver priorizadas sobre el trabajo actual.
• Explique que usted hace el trabajo como está priorizado en la pizarra. Que su equipo trabaje tan rápido y diligentemente como se puede esperar razonablemente, y que si el PM tiene inquietudes sobre miembros específicos del equipo que no están haciendo todo lo posible, debe dirigirse a aquellos con el líder del equipo.
• Sugiera que si su PM quiere ver un aumento en los Puntos MVP completados, la mejor manera sería aumentar el tamaño del equipo. Tenga en cuenta que si tiene una fecha límite inminente, esta opción no es práctica. Si le quedan meses de trabajo, entonces lo es.
• Cuando su PM intenta hacer algo fuera de la metodología Agile, sus prácticas comerciales le explican al PM lo que están haciendo, por qué es un problema y cómo abordar adecuadamente sus inquietudes dentro de la metodología que se está utilizando.

Nombrar las cosas es la mitad de la batalla.

No se refiera a ellos como "objetivos de extensión", refiérase constantemente a ellos como "preparando el próximo sprint". Si se le cuestiona directamente, puede decir "no tenemos objetivos en Agile, tenemos pronósticos y no existen los pronósticos extensos".

Si eventualmente otras personas dejan de llamarlos objetivos complicados, probablemente hayas ganado.