¿Cómo debe un Scrum Master manejar los tiempos de ciclo elevados de los individuos de un equipo?

En primer lugar, mira si puedes seguir dividiendo tus historias .

En segundo lugar, ¿por qué los ingenieros de su equipo no cooperan? La forma en que describe su sistema suena como si hubiera establecido un límite mínimo de trabajo en progreso de una historia por desarrollador. Por supuesto, su tiempo de ciclo es alto ( tiempo de ciclo = wip / rendimiento después de todo). En cambio, coopere en las cosas para reducir el trabajo en progreso.

Puedo decirle que sospecha que algunos de sus ingenieros son mejores que otros. Creo que lo que ya he sugerido, alentar la cooperación en las tareas, contribuirá de alguna manera a mejorar las habilidades de los ingenieros más débiles. Sin embargo, hay muchos otros factores de gestión de personas. No los enumeraré a todos, pero ¿obtienen las personas las herramientas que necesitan, la capacitación que desean, tiempo libre para mejorar sus habilidades, tiempo para ir a conferencias, etc., etc.? ¿Está involucrando a sus mejores desarrolladores como tomadores de decisiones clave en el proceso de contratación? La gente ha escrito libros sobre este tipo de cosas, así que me detendré ahí.

En primer lugar, más rápido no siempre es mejor. Uno de los ingenieros con los que trabajé terminó sus historias extremadamente rápido, mucho más rápido que el resto del equipo. Pero a menudo usaba atajos rápidos y sucios, y los evaluadores explícitamente le dieron atención adicional a las historias de usuario de este ingeniero. Produjo errores diferentes al resto de los ingenieros, más difíciles de encontrar, pero a menudo con mucho impacto.

Si hay suficiente confianza en el equipo, discuta las diferencias de velocidad con todo el equipo y pregúnteles qué factores ven que pueden explicar las diferencias. Algunas posibilidades incluyen factores personales (motivación, impulso, perfeccionismo), habilidades y conocimientos, cantidad de distracción (solistas versus personas que siempre están ayudando a otros en lugar de hacer sus propias tareas) o diferentes puntos de vista sobre la calidad/alcance/definición de hecho.

Trate de emparejar a los ingenieros más rápidos con los más lentos (y, en general, fomente la cooperación); ambos pueden aprender trabajando juntos.

Si desea reducir el tiempo de su ciclo, entonces es hora de aplicar la teoría de las restricciones . Busque dónde se acumula el trabajo, luego trabaje para eliminar el cuello de botella.

Por supuesto, el trabajo tiene que ser lo suficientemente visible primero. Un simple tablero de tareas pendientes no va a ser suficiente. Debe modelar el flujo de trabajo real para detectar el cuello de botella. Backlog-Ready-In Progress-Review-QA-Ready to Deploy-Done es un flujo de trabajo probable. Si las cosas se acumulan en el control de calidad, solicite la ayuda de algunos desarrolladores. Si las cosas necesitan revisarse más rápido, descubra cómo hacer que eso suceda. ¿Las implementaciones toman horas? Automatizarlos. Etc.

Como lo mencionaron otros, la otra palanca que debe tirar es el límite WIP. Reduzca su límite WIP y el promedio. El tiempo de ciclo debe caer.

Lo más importante es que el equipo debe dejar suficiente margen en el calendario para que pueda mejorar. No ayuda identificar un cuello de botella si nadie siente que tiene tiempo para solucionarlo.

Tuvimos los mismos problemas: el equipo del que me hice cargo como Scrum Master fue considerado lento por los PO, otros desarrolladores, etc.

Al analizarlo, estos son los problemas identificados (y las soluciones que implementamos):

• Los elementos de la cartera de pedidos no estaban claros. Se dedicó mucho tiempo a investigar historias durante el sprint => dividimos las historias en Spikes (investigación), Historias, Tareas/Subtareas, Errores. Ahora podía ver claramente cuánto tiempo tomó la investigación para una historia y cuánto tiempo la codificación real. También trabajé con el PO para investigar más antes de poner las historias en espera.
• El siguiente problema fue que las historias (después de implementar el elemento anterior) no se dividieron correctamente. Dividimos una historia para que sea tan larga como un sprint o más corta, si es posible. Le planteé este tema a Mike Cohn en su reciente capacitación sobre historias de usuarios; su recomendación es dividir las historias tanto como tenga sentido para los desarrolladores, no pierdas mucho tiempo para dividirlas en lo más pequeño posible, pero definitivamente más cortas que un sprint.
• A continuación, abordamos el problema que mencionas: ¿algunos desarrolladores son más lentos que otros? Por supuesto, pero en nuestro caso no fue porque los rápidos estuvieran entre los atajos, es por antigüedad y conocimiento del negocio y producto. Así que optamos por la programación en pareja: un programador senior se empareja con un junior para distribuir el conocimiento y el aprendizaje.

Lo anterior funcionó muy bien. Aumentamos nuestra velocidad con al menos un 30% en solo 4 sprints. Pero soy consciente de que el aumento podría provenir del hecho de que, para empezar, no estimamos las historias correctamente, por lo que seguimos trabajando y monitoreando.

TL; DR todo comienza en la planificación, cómo divides y estimas las historias. Comienza desde allí.