La velocidad del equipo, es uno de los conceptos claves para entender la dinámica de los métodos ágiles.
Imagina que recién compras una Secadora, y como todo buen usuario no lees las instrucciones y si la lees no te indica cuántos pantalones, camisas y medias puedes ingresar a secar. ¿Cómo sabes cuánta ropa puedes secar?
El primer intento (Sprint #1), es el más difícil de medir ya que por ser el primero no tenemos ninguna referencia que podamos utilizar por analogía. Ingresas ropa en exceso, por lo cual al sacar la ropa te das cuenta que aún sigue húmeda. Adicionalmente, si sigues cargando con exceso la secadora, es probable que tengas que llevarla a reparar en corto tiempo.
Segundo intento (Sprint #2), luego de la retrospectiva del 1er intento aprendimos que debemos colocar mucho menos ropa. Arrancamos nuestra secadora con mucho menos ropa y al terminar toda la ropa queda bien seca, sin embargo, notamos que sub-utilizamos el ciclo de la secadora por lo cual gastamos energía innecesaria (totalmente en contra de nuestras premisas ecologistas).
La razón es que la Secadora tiene una "capacidad de uso ideal" de manera de evitar que la ropa quede húmeda o desperdiciar energía, es por ello que se debe ingresar una "cantidad razonable de ropa" en cada secada. Esa capacidad de uso ideal, es análoga a la velocidad natural del equipo y la cantidad razonable de ropa es lo que conocemos por ritmo sostenible, ni más ni menos.
En un tercer intento (Sprint #3) ya tenemos una mejor noción de cuántos pantalones, camisas y medias podemos secar en un ciclo.
Cuando hablamos de equipos de trabajo la cosa no es tan sencilla, ya que los humanos somos un poco más complejos y variables que las secadoras, sin embargo, lo verdaderamente importante a tomar en cuenta es que cada equipo de trabajo tiene su propia velocidad natural, la cual responde a distintos factores como: experiencia del equipo, experticia, teamware, característica del proyecto, entre otros. Debemos respetar esa velocidad natural de los equipos, de manera de poder cumplir con entregas razonables y evitando el desgaste del equipo de trabajo; es decir, no debemos estar cruzados de brazos, pero tampoco con jornadas de 14 horas al día.
Recuerden que a diferencia de la secadora no tenemos ni manual de uso ni garantía por 2 años.. :)
+10.12.44.png)
7 comentarios:
Excelente analogía!!....
Esperemos que el paradigma de la gestión de proyectos cambie aún más, pensando como cuando uno está en una lavandería ;).
Fácil explicación con un sencillo ejemplo. Todos nosotros lo deberíamos de tener en cuenta.
Gracias Gustavo!.
Gracias por el comentario amigo Marco!
Un hint
La de velocidad ha estragos en equipos agiles, porque se puede derivar es posible acelerar al equipo (ve este artículo http://www.allaboutagile.com/velocity-is-killing-agility/)
En realidad lo que mides es cercano al ancho de banda del equipo, que si lo saturas comienza a disminuir el flujo (al igual que una carretera llena de autos)
Saludos
Agustin
Yo veo la velocidad como un indicador para el equipo que le permite decidir cuantas historias comprometer en la próxima iteración con base en la historia.
Nadie fuera del equipo debiera preocuparse por la velocity siendo, como es, algo tan subjetivo.
Cuando la velocity llega a los "project managers" estamos perdidos.
Agustin, gracias por el comentario. Lamentablemente no se puede leer completo el post ya que los links dan error. Vreo que efectivamente los equipos se pueden acelerar, pero siempre y cuando respetemos la metáfora del "spring", es decir, que no busquemos acelerar ni mas de lo que podemos ni tan prolongado que luego tengamos daños musculares. Es por eso que considero necesario el concepto de Velocidad. Nos seguimos leyendo y creando estas discusiones tan nutritivas para todos.
Carlos concuerdo contigo que el concepto de "Velocidad" puede ser dañino en manos de personas que no entiendan bien su naturaleza, por ejemplo un PM. Gracias y Saludos.
Cada día más los PMs estan incursionando en Agilidad y manejan bastante bien sus conceptos y espíritu, en el comentario anterior me refiero a aquellos PMs tradicionales sin conocimiento de agilidad.
Publicar un comentario