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.
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.
Cuando incorpora a un nuevo miembro del equipo, hay dos cosas que debe hacer:
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í:
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í:
Si quieres que esto sea visible:
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.
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:
No puede ser prescriptivo sobre cuánto tiempo podría llevar esto. Podría ser un par de semanas, o tal vez años.
Alexéi
Hans Martin Mosner
davidg