¿Cómo captar en un Scrum Sprint el hecho de que el miembro más nuevo del Equipo está consumiendo un tiempo significativo de otros miembros del Equipo?

Contexto

Ha habido una reestructuración donde trabajo y nuestro equipo ahora está dirigido por un tipo que solía supervisar dos equipos. Hasta hace muy poco, se ocupaba principalmente de la actividad del otro equipo, por lo que sabe muy poco sobre lo que está haciendo nuestro equipo.

Como tiene que liderar un solo equipo, la gerencia le dijo que dedicara al menos el 30% del tiempo a las tareas de desarrollo. Si bien el tipo está manejando proyectos heredados y tareas de soporte L3 bastante bien, necesita ayuda constante para hacer cualquier cosa en nuestro proyecto. Mi estimación es que el Equipo dedica aproximadamente media hora a ayudar o arreglar su código por cada hora que trabaja.

Asunto

Nuestro Sprint tiene algunos puntos de historia para manejar incidentes (también para algunas aplicaciones satelitales), (opcionalmente) algunos puntos de historia para manejar una historia de requisitos no funcionales (por ejemplo, arreglar una gran deuda tecnológica, optimización del rendimiento). Todo lo demás se destina al manejo de historias requeridas por el cliente interno.

El equipo es muy pequeño, pero logramos tener una velocidad bastante estable. Sin embargo, debido a que los miembros del equipo pasan mucho tiempo ayudando al líder del equipo con sus tareas, el equipo no se está desempeñando mejor a pesar de ser un poco más grande.

Me pregunto cómo indicar formalmente dentro del sprint que los miembros del equipo pueden comprometerse menos porque necesitan ayudar al miembro más nuevo.

Una forma sería aumentar los puntos de historia para las historias asignadas al miembro más nuevo para que el esfuerzo refleje la realidad (tiempo extra dedicado a resolverlo) y tomar un poco menos para las otras historias. Sin embargo, esto podría hacer que el PO se pregunte por qué los mismos miembros del equipo pueden comprometer menos trabajo individual.

Si el miembro más nuevo hubiera sido Junior (en lugar de ser un desarrollador senior ascendido a líder de equipo), habría sido fácil, porque cualquier persona en su sano juicio entiende que los miembros junior necesitan ayuda y tutoría.

Después de leer esta respuesta y algunas más sobre Agile, me doy cuenta de lo extraño que estamos trabajando en sprints: cada miembro del equipo maneja una historia de principio a fin (paralelismo máximo) y como consecuencia, casi todas las historias se hacen en el segundo. parte del sprint.
Ambas respuestas dadas son buenas, solo preferiría ajustar la capacidad planificada para los sprints de incorporación en lugar de agregar historias de incorporación artificiales que realmente no agregan valor al sprint. Así como debería reducir la capacidad de planificación de sprints cuando un colega se va de vacaciones o asiste a una conferencia, estas no son actividades que crean valor para el cliente, aunque pueden ayudar a mantener o mejorar la velocidad del equipo a largo plazo.
@Alexei no es necesariamente un problema tener un solo miembro del equipo trabajando en una sola historia. Realmente depende de qué tan grandes sean las historias y qué tan bien se puedan descomponer. Tienes que equilibrar la sobrecarga de comunicaciones entre los miembros del equipo frente a hacer diferentes partes de la historia en paralelo.

Respuestas (3)

Cuando incorpora a un nuevo miembro del equipo, hay dos cosas que debe hacer:

  • Reflejar el cambio en su capacidad para trabajar
  • Informe a sus partes interesadas del impacto de la incorporación

Depende de usted cómo hacer estas cosas. Por ejemplo, algunos equipos pueden agregar 'tareas de incorporación' a su cartera de pedidos que cubren el tiempo necesario para que el nuevo miembro del equipo se ponga al día. Otro enfoque sería simplemente permitir que la velocidad de su equipo se adapte al cambio (es probable que disminuya al principio y luego se recupere).

Una buena forma de informar a las partes interesadas es mencionar la incorporación y el impacto que está teniendo en las reuniones de revisión del sprint.

Lo importante es ser transparente sobre el cambio y el impacto que está teniendo. La incorporación de cualquier nuevo miembro del equipo inicialmente reducirá la capacidad del equipo para entregar el trabajo. Esto es cierto incluso si está incorporando a un desarrollador senior y experimentado.

Una forma sería aumentar los puntos de historia para las historias asignadas al miembro más nuevo para que el esfuerzo refleje la realidad (tiempo extra dedicado a resolverlo) y tomar un poco menos para las otras historias.

No recomendaría este enfoque. Los puntos de la historia son una medida de la dificultad relativa del equipo que realiza una tarea, no de un individuo.

Habiendo dicho eso, el nuevo miembro del equipo ahora también debería contribuir a las estimaciones. Por ejemplo, puede tener una conversación como esta al estimar:

Miembro del equipo existente: "Esta historia se siente como unos 3 puntos"

Nuevo miembro del equipo: "No tengo mucha experiencia haciendo este tipo de trabajo y probablemente tendría problemas con esta historia. Podría ser una historia de 8 puntos para mí".

Miembro actual del equipo: "Está bien, ¿debemos reflejar eso al hacer de esta una historia de 5 puntos, para tener en cuenta la capacidad de todos en el equipo para hacer este trabajo?"

Cualquier nuevo miembro del equipo requerirá tiempo para aprender los trabajos del proyecto y requerirá tiempo de otros miembros del equipo para ayudarlos y ofrecerles apoyo. Nadie comienza a correr, sin importar si es senior, junior o alguien que manejó equipos.

Muchos piensan que agregar un nuevo miembro al equipo agrega inmediatamente resultados positivos para el equipo y la progresión a partir de ese momento para el individuo se verá así:

ingrese la descripción de la imagen aquí

Sin embargo, la realidad es que la productividad se hunde con cualquier nuevo miembro y las cosas se estabilizarán en algún momento, con una trama realista que se ve así:

ingrese la descripción de la imagen aquí

Si quieres que esto sea visible:

  • Podría colocar un "pico de incorporación" en el sprint para que sea visible que se está trabajando para ayudar a alguien a ponerse al día. Puede estimarlo en puntos de la historia si eso es lo que suele hacer con los picos, aunque a menudo solo tienen un límite de tiempo.
  • O, cuando planifique su sprint, podría disminuir la capacidad del equipo para reflejar que algunos miembros han reducido su capacidad esta vez y no todo puede destinarse a desarrollar características reales. Es como si alguien estuviera de vacaciones unos días más o menos. La capacidad está ligada a la velocidad, por lo que la velocidad disminuirá, pero eso es lo que sucede cuando cambia la estructura del equipo.
  • O simplemente toma menos funciones en el sprint para acomodar el tiempo necesario para ayudar a alguien nuevo.

Realmente no importa mientras la gente entienda por qué hay un cambio en el equipo y cómo eso se refleja en la entrega de una forma u otra. Si la gente cree que las cosas mejorarán instantáneamente si agrega un nuevo cuerpo cálido a un equipo, entonces eso es una ilusión y está sujeto a otra pregunta/respuesta.

"simplemente tome menos funciones en el sprint para acomodar el tiempo necesario para ayudar a alguien nuevo". - Creo que este es el camino a seguir en mi caso. La principal preocupación es que la persona no es exactamente nueva y que sus habilidades tecnológicas están significativamente por debajo de las esperadas. Sin embargo, esto es principalmente un problema de "SE en el lugar de trabajo", no uno de PM SE. Gracias.
A menudo, la percepción está aún más alejada de la realidad que el primer gráfico: los gerentes a menudo esperan que la velocidad salte inmediatamente a (n+1)/n y se quede allí.

Eso depende. Si la organización en cuestión está generalmente acostumbrada a que las personas entren y salgan de los equipos, y si todos están al día técnicamente y son infinitamente adaptables en términos psicológicos, entonces la capacidad efectiva de recursos y el número de personas es casi el mismo, al menos. todo el tiempo. Suerte si eso sucede.

Sin embargo, si la creación de equipos es rara, o incluso ocasional, y se trata de humanos normales, entonces puede esperar al menos uno de estos efectos:

  • Curva de aprendizaje a medida que la nueva persona se acostumbra al aspecto técnico del trabajo. Consulte la curva de Bogdan, por ejemplo. A medida que se acostumbran a qué es dónde y cómo se llaman las cosas, hacen menos preguntas y todos los demás pueden seguir con sus cosas.
  • Movimiento de la etapa de equipo de regreso a la etapa de Asalto (consulte el conocido modelo de Tuckman).
  • Ajuste de la cultura laboral: los aspectos menos técnicos de los roles del equipo (por ejemplo, los tipos de Belbin) pueden cambiar a medida que la nueva persona tiene un impacto.

No puede ser prescriptivo sobre cuánto tiempo podría llevar esto. Podría ser un par de semanas, o tal vez años.