Mejorar la velocidad de equipos de desarrollo

version en video:

 

 

hace poco lei un articulo que me pareció muy poderoso titulado “teams that finish early accelerate faster” traducido los equipos que terminan temprano se aceleran más rápido, me pareció bacano por que nos presenta algunas estrategias para equipos de desarrollo que trabajan con scrum para que estos generan más valor.

Empieza poniendo unos criterios para aplicar estas estrategias entre ellos que los equipos sigan buenas prácticas y que sean estables, después de esto empiezan a comentar unas estrategias que pueden ayudar a generar equipos de alto desempeño.

El buffer comenta que si el equipo espera soporte o tareas inesperadas se debe tener un buffer(no mayor al 30% de la capacidad del equipo) que le permita atacar estas tareas si aparecen. para la implementación de este buffer es común que se asigne y rote una persona que está en soporte encargada de estos inesperados.
VInculado a este buffer comentan la necesidad de un procedimiento de emergencia si estas tareas inesperadas(y mas importantes que las tareas del sprint actual por que sino no entrarían) superan el 30%, se deben seguir unos pasos (no necesariamente todos).
cambiar la forma como se trabaja para que esto no sea un 30% extra(intentar encontrar innovación)
buscar alternativas aka intentar entregar este trabajo a otros.
cancelar el sprint y re planearlo informando las nuevas fechas a los jefes.

yesterday weather(el clima de ayer) consiste en determinar la capacidad que el equipo tiene basado en los 3 o mas ultimos sprint, se promedia la velocidad de estos como base para determinar los compromisos de los próximos sprints(rolling average)

Swarming esta nunca la he visto ni de cerca implementada, consiste en que se trabaje 1 historia de usuario a la vez, donde una persona hace de capitán y el resto del equipo lo ayuda en todo los que necesita.

Mantener un equipo estable sin gente que deje el equipo, e incluyendo una persona cada 6 meses a un año para traer ideas nuevas (un equipo de entre 4 y 6 personas). esto ciertamente es dificil de conseguir una recomendación que hacen el artículo es rastrear la felicidad del equipo( con algunas preguntas por escala numerica ) y se disminuye la felicida mucho investigar a fondo hablando con las personas del equipo que esta pasando.

Con estas estrategias el articulo reporta que hubo mejoras drasticas en los equipos del x40 o mas de la velocidad previa, ante esto supongo que habra que ver para creer.

Del lado de la implementacion de estas estrategias en http://scrumbook.org/ se habla de kaizen-pulse como un meta patron para hacer mejora continua (por ejemplo para ir implementando alguna de las estrategias anteriores) la idea es reunir data de como se comporta el equipo antes del cambio su velocidad y la varianza en esta velocidad, teniendo esto se procede a realizar un cambio (esto no lo dicen pero es mas probable que se acepte un cambio si se presenta de manera que parezca una propuesta del equipo mismo y no una descision unilateral) se procede entonces a medir como cambia la velocidad y la varianza(en la velocidad) del equipo a lo largo de varios sprints ( por que la apdatacion a cualquier cambio toma tiempo) posiblemente realizando pequeñas adaptaciones segun las discuciones del equipo. un cambio fue bueno si disminuye la varianza del equipo o si aumenta la velocida del mismo(sin aumentar drasticamente la varianza). en kaizen pulse este proceso se repite por cada cambio.