Si está obteniendo un código podrido, entonces el equipo realmente no está completando las historias, ¿verdad? Supongo que su definición de Listo incluye tener suficientes pruebas unitarias y pruebas de aceptación, hacer que pasen y tener un código bien estructurado (es decir, refactorizado); si no es así, te recomiendo que lo cambies para que lo sea.

Supongo que si el enfoque está en hacer tareas individuales, entonces:

1) Las tareas individuales son visibles para el equipo, y el valor general entregado por el sprint no lo es, y

2) Los miembros del equipo son recompensados ​​o calificados individualmente de acuerdo con el número de tareas reportadas realizadas, y no por el valor total entregado por el sprint.

Si desea que el equipo entregue valor en general, debe medir (y hacer visible) el valor a nivel de equipo , no el esfuerzo a nivel individual . (Este es un ejemplo de Ver todo , por cierto.)

El rendimiento también es una cuestión de todo el sistema, de una manera diferente: las únicas partes del sistema en las que desea esforzarse para acelerar son los cuellos de botella. Ser un cuello de botella no es una propiedad de una parte del sistema (incluso de la parte que actualmente es un cuello de botella), sino del todo.

Le recomiendo que mida el rendimiento del sistema con frecuencia, ya sea todos los días o en cada integración, lo que sea más frecuente. Esto le permitirá saber cuándo el rendimiento cae por debajo de un umbral y le dará una idea de qué cambios lo desencadenaron parcialmente. La mejora del rendimiento probablemente debería tomar la forma de historias: generalmente un aumento para probar un enfoque de optimización particular, luego (si tiene éxito) una historia de desarrollo para implementarlo.

La refactorización constante lo ayudará a lograr 3 (Decidir lo más tarde posible). Las retrospectivas periódicas ayudarán a su equipo a lograr 7 (ver el conjunto). También son una oportunidad para 1 (Eliminar desperdicios), especialmente si incluyes una actividad en tu retrospectiva enfocada en identificar desperdicios (pista: busca trabajo amontonándose en las colas).

Espero que esto sea útil.

Lo animo a leer esta publicación de blog, ya que ofrece una variedad de prácticas destinadas a promover la planificación bajo demanda, la participación del equipo y la entrega rápida. Además, en mi opinión, puede realizar los tres tipos de reuniones para la colaboración en equipo: reunión de planificación, reunión diaria, reunión retrospectiva. Este enfoque le permitirá comunicarse e interactuar con su equipo, manteniéndolos ocupados y conscientes de la situación actual de su proyecto.

What we feel is now that the team is more focused on completing individual tasks instead of thinking 

Solía ​​tener experiencias como la tuya, en las que los programadores compiten entre sí para obtener más puntos durante la revisión del sprint cuando mostramos el gráfico de quemado. El formato de mi tabla de quemado es por individuo. Lo que trato de hacer para aumentar el trabajo en equipo es eliminar el gráfico de quemado que solo muestra cuántos puntos quemó un programador.

Para mejorar aún más eso, solo pongo cuántos puntos se queman por proyecto. Digamos el Proyecto A, tengo 5 programadores trabajando en él, luego al final del día (Revisión de Sprint) mostraré lo que hemos hecho

Para hacer que los desarrolladores "vean el todo", el PO necesita discutir la visión con ellos. Necesita definir, al menos, el próximo objetivo general del proyecto y explicárselo a los desarrolladores. Por ejemplo, podría hacer una planificación de hitos. Los hitos suelen consistir en múltiples historias/epopeyas. Discutir el próximo hito cuando se alcanza el último, brinda a los desarrolladores una visión general.

Desafortunadamente, en mi experiencia esto puede poner en peligro "decidir lo más tarde posible". Los desarrolladores que conocen "el todo" tienden a tratar de anticipar las cosas. El principio del diseño simple es una de las cosas más difíciles de aprender. Este es un problema de experiencia y mentalidad. Aunque soy perfectamente consciente de esto, muchas veces lo hago mal. El problema es que intuitivamente es lo incorrecto. De hecho, anticipar las cosas no está mal. Es solo que generalmente anticipamos las cosas equivocadas, porque aún no vemos la imagen completa. En mi opinión, la única forma de aprender esto es forzarte a implementar "lean" y experimentar lo que sucede. Haga programación en pareja, revise el código y trate de recordarse mutuamente su filosofía de aprendizaje. Será más fácil con el tiempo. Y experimentarás que funciona.

"Empoderar al equipo" es inminente en Scrum. "Entregar lo más rápido posible" proviene de "decidir lo más tarde posible"/"Diseño simple" + "Hacer una cosa antes de comenzar la siguiente" de Scrum. "Eliminar desperdicio" está estrechamente relacionado con "Diseño simple"; si implementó demasiado: no tenga miedo de tirarlo. Par programación/revisiones "amplifican el aprendizaje" increíblemente mucho; también brinde a los desarrolladores tiempo para leer sobre código limpio, refactorización, ... y practicarlo.

1 Elimine el despilfarro: encuentre una forma de medir lo que se desperdicia (características no utilizadas, características incompletas, características poco utilizadas, fallas de comunicación, traspasos, etc.), cualquier cosa que no agregue valor al resultado final.

Medir el desperdicio es probablemente uno de los lugares más fáciles para comenzar y, en mi experiencia, el desperdicio es uno de los mayores drenajes en cualquier proyecto de desarrollo de software. Impregna el nivel más alto de funcionalidad de cara al usuario hasta los niveles más profundos de código innecesario. El problema es que a nadie le gusta eliminar la funcionalidad, por lo que se acumula como un cáncer con el tiempo. Cuanto antes se elimine, antes nadie tendrá que preguntarse cuál puede ser su valor.

Comience midiendo el uso de la aplicación en áreas de alto nivel. Si nota un uso bajo, amplíe su monitoreo en el área correspondiente. Una vez que identifique áreas de funcionalidad innecesaria, planee eliminarlas y luego descubra cómo llegó a ser en primer lugar. Es probable que la funcionalidad innecesaria provenga de otra forma de desperdicio, como una falla de comunicación inicial o un traspaso de la toma de decisiones.

Por supuesto, no se vuelva loco, asegúrese de que su inversión en la identificación de desechos sea razonable y no desperdicie en sí misma :) a medida que disminuyan los rendimientos, no siga invirtiendo en niveles más altos de monitoreo... eventualmente puede cambiar la capacidad de identificar desechos ser sincero para evitar fallas de comunicación y traspasos, negando así la necesidad de monitorear después del hecho.