¿Pregunta sobre permitir temporalmente que un líder de equipo pause la gestión de proyectos para que vaya más rápido?

Realmente no entiendo la premisa de su pregunta. Pero abordaré la parte de causa y efecto de su pregunta. ¿Aplicar algún tipo de intervención, como agregar un recurso (máquina o humano), tiene un efecto en el desempeño del trabajo? En el mejor de los casos, puede establecer una causa contributiva. No es probable en este caso establecer una causa absoluta o condicional. Establecer una causa absoluta es probablemente imposible.

El trabajo es muy probabilístico. Hay innumerables variables que afectan los resultados y la mayoría de estas variables son aleatorias. Además de esto, diferentes tareas tienen diferentes grados de elasticidad de recursos. Esto significa que algunas tareas responden bien al agregar recursos adicionales, mientras que otras tareas no responderán en absoluto o incluso se degradarán.

Por lo tanto, su mejor respuesta es que el PM que realiza el trabajo de desarrollo puede haber contribuido al resultado favorable que midió, pero no tiene la seguridad de obtener resultados similares nuevamente.

EDITAR: según su comentario, parece que un líder está cuestionando la decisión tomada por el primer ministro de ayudar con el aumento para ayudar a recuperar el cronograma. No hay industria que prohíba, o deba prohibir, un enfoque de todas las manos para manejar un aumento repentino, ya sea inducido por un aumento repentino en la demanda de ese trabajo o autoinducido porque está interviniendo en el cronograma. Antes de que personas calificadas abandonen sus puestos para manejar la oleada, obviamente se debe realizar un análisis de costo-beneficio-riesgo pero, durante una oleada, los beneficios suelen ser bastante altos donde los costos y riesgos se absorben y mitigan, tomando esta decisión probable favorable en la mayoría de los casos.

Imagínese a una jefa de una sala de emergencias sentada en su oficina para continuar "manejando" mientras la sala de emergencias está siendo abrumada por las víctimas de algún evento catastrófico. Todas las manos a la obra y todo lo demás se pospone hasta más tarde, cuando la oleada se enfríe. No es gratis, por lo que hay costos que pagar.

TL;DR

Si bien es posible que tener recursos adicionales disponibles para cumplir un objetivo a corto plazo fuera útil para lograr un objetivo a corto plazo, claramente fue a expensas de un proceso requerido por la empresa (ya sea que ese proceso sea bueno o malo no viene al caso aquí ) y elude la pregunta de si la reasignación de recursos a corto plazo supera el valor (percibido) del rol de Scrum Master tal como se practica dentro de su organización.

Sin duda, es posible, e incluso probable, que el equipo haya recibido un impulso a corto plazo en la productividad al hacer que otro desarrollador asigne el 100 % de su tiempo disponible (en lugar del 50 % estimado con el sistema actual) al desarrollo de productos. Sin embargo, esto no es deseable ni sostenible dentro del marco de Scrum, y es poco probable que sea sostenible bajo cualquier marco de gestión de proyectos razonable a largo plazo.

El equipo y la organización deben repensar cuidadosamente su proceso e inspeccionar y adaptar hasta que logren más de los resultados deseados con una cadencia sostenible.

Análisis

En primer lugar, si bien es técnicamente factible que un Scrum Master también sea un desarrollador en un equipo Scrum, la Guía Scrum deja muy claro que estos son roles distintos con responsabilidades distintas. Pedirle a una persona que use ambos sombreros es generalmente un anti-patrón a largo plazo.

En segundo lugar, todos los marcos de gestión de proyectos, ya sean ágiles o no, incurren en una cierta cantidad de gastos generales. Esto a veces se percibe como una productividad reducida cuando el resultado del control del proyecto se ve como una productividad reducida en lugar de una mayor transparencia, visibilidad o control del proceso. Ciertamente, puede desviar el presupuesto y el tiempo de las actividades de gestión de proyectos y asignarlos a actividades de desarrollo, pero con el tiempo pierde el valor previsto del control empírico del proceso.

En tercer lugar, el rol de Scrum Master (cuando se realiza correctamente) es un trabajo de tiempo completo. Si bien Scrum Masters muy experimentados con equipos muy maduros pueden manejar hasta tres proyectos, ciertamente no es una práctica recomendada ni generalmente efectiva en el tipo de entorno que está describiendo. En resumen, tiene un Scrum Master a tiempo parcial cuya función se considera secundaria al esfuerzo de desarrollo del producto, que definitivamente es un anti-patrón.

En cuarto lugar, ninguno de los deberes que le asigna al Scrum Master son muy parecidos a Scrum. Por ejemplo, el Product Backlog es responsabilidad del Product Owner, mientras que la gestión del Sprint Backlog y las asignaciones de trabajo son responsabilidad colectiva de los Desarrolladores. Tener un líder de equipo que asigne trabajo a las personas es lo más alejado posible de los equipos empoderados y autoorganizados. Este es otro olor de implementación del que deberías llegar al fondo.

Recomendaciones

He visto estos antipatrones en juego en muchos roles de Scrum y similares a Scrum, incluso como desarrollador, Scrum Master, propietario del producto, entrenador ágil, gerente de proyecto tradicional y ejecutivo de TI. Nunca salen bien a la larga, pero eso nunca parece impedir que la gente intente convertir las pepitas de alce en diamantes.

Aquí hay algunas recomendaciones prácticas que ayudarán a su equipo y organización a inspeccionar y adaptar el proceso en algo que proporcione una cadencia de entrega confiable.

1. Decida si realmente está tratando de adoptar Scrum o si solo está aplicando Buzzword Management℠.
2. Si realmente está adoptando Scrum, asegúrese de tener los tres roles esenciales en el equipo: Propietario del producto, Scrum Master y Desarrolladores.
3. Trate cada rol como un trabajo de tiempo completo, porque lo es. Puede tener personas que hagan bien el trabajo, o muchas personas que hagan parte del trabajo parte del tiempo, generalmente con resultados menos que estelares.
4. Scrum a menudo se describe como un marco ligero, pero aún conlleva la sobrecarga del proyecto . Todos los marcos de control de proyectos lo hacen; Podría decirse que Scrum es mucho más transparente al respecto. Estos gastos generales deben contabilizarse como un costo visible para el proyecto.
5. Un Scrum Master (o gerente de proyecto) de medio tiempo no puede mágicamente poner lápiz labial en un cerdo. Si un proyecto falla o está atrasado, solucione el problema subyacente a través de los eventos de inspección y adaptación del marco, como Sprint Retrospective , o acepte que es probable que el proyecto fracase .
6. Si es probable que el proyecto fracase, no persiga la falacia del costo irrecuperable. Hay valor en fallar temprano.
7. Si el proyecto está fallando o está fuera de tolerancia debido al presupuesto, el alcance o las decisiones organizacionales más allá del control del Equipo Scrum, escálelo a la gerencia sénior. El éxito o el fracaso es, en última instancia, su responsabilidad, y si es el resultado directo de malas decisiones estratégicas (p. ej., falta de personal o financiación insuficiente para el proyecto), entonces es su problema solucionarlo.
8. si el equipo carece de las oportunidades o la seguridad laboral para inspeccionar y adaptar honestamente el proceso para mejorarlo, la cultura de la empresa tiene la culpa. Esto también es un problema para la gerencia ejecutiva, y si rompieron la cultura, son los únicos que pueden arreglarlo.
9. Capacite a su equipo lo mejor que pueda para solucionar los problemas donde tienen conocimiento y control local.
10. Si su equipo no puede controlar ninguno de los factores negativos que afectan la productividad, entonces los inteligentes ya están actualizando sus currículos. Deberías hacer lo mismo.

Las reglas de diez nunca pretenden ser exhaustivas, pero esta es probablemente la respuesta más completa que cualquier persona ajena a su empresa puede proporcionar. Básicamente, identifique los problemas, resuelva los problemas en equipo (si puede) y remita el resto a aquellos con la autoridad para abordar los problemas que el equipo no puede resolver por sí mismo.

Que un SM dedique el 50 % de su tiempo a organizar un solo equipo y el trabajo atrasado suena demasiado. Si el SM admite varios equipos, la cifra del 50 % podría ser más creíble, pero en ese caso no parece realista que la misma persona sea también un desarrollador. Los equipos de Scrum deben organizarse por sí mismos y la carga de trabajo del SM debe gastarse en apoyarlos cuando sea necesario, no en organizarlos y su acumulación.

Sin embargo, un equipo de 3 es bastante pequeño. Debería considerar fusionar al menos dos equipos de ese tamaño. No dijiste cuál es la duración de tu sprint. Si las 4 semanas que mencionas son la duración del sprint, sugeriría que puede ser demasiado para un equipo pequeño. Los sprints largos requieren más tiempo para prepararse y planificar, especialmente con un equipo pequeño donde hay poco margen de error.

Mi consejo es observar detenidamente la velocidad del equipo, sugerir que todo el equipo y no solo el SM asuma la responsabilidad del refinamiento del backlog y asegúrese de dejar tiempo para las actividades de refinamiento al planificar un sprint.

Soy ingeniero, SM y coach ágil.