El Cycle Time y otras maneras ver la eficiencia del proceso Ágil

En varios post lo hemos hablado (aquí hace poco y aquí el año pasado): tenéis, es muy recomendable, que medir la eficiencia del proceso (que no es medir la de las personas, ojo).

La eficiencia es diferente a la eficacia, la primera está relacionada con cómo de bien lo hacemos, con detectar desperdicios, la segunda con el valor que de verdad entregamos. 

Hay diferentes maneras de medir la eficiencia, algunas más ligeras y otras menos, pero la elección de una manera u otra depende del punto en el que esté cada equipo. 

Número de Historias (items) por Sprint (iteración)

Esto es lo más simple, de echo aunque uses otra manera de hacerlo, siempre deberías complementarla viendo cuántas Historias (Historias de verdad, ya lo hemos hablado, la importancia de llamar a las cosas por su nombre) se terminan por Sprint. 

Gran parte de las inicitivas #noestimates van por aquí. No me extiendo más en este punto, hay varios post sobre ello (como el que te dejé antes) y hasta te grabé un video (el de abajo).

El problema que encuentran muchos equipos es que medir en número de Historias funciona si son todas más o menos del mismo tamaño. De ahí que apareciera otra manera…

Medir en Puntos Historia

Es la tradicional. De hecho, aunque la terminología es confusa, hay quien asocia velocidad con puntos historia (para mí es una de las muchas maneras de medir la velocidad, de medir la eficiencia).

Medir en Puntos Historia puede, en muchas ocasiones, ser la única manera que tienes, pero debería ser una situación temporal, ya que tiene muchos desperdicios o añadidos (como saber también si estamos estimando correctamente los Puntos) y conlleva complementarlo con el punto anterior, medir el número de Historias (esto te lo conté en el anterior vídeo). 

Cycle Time

Una tercera vía (sin descartar que hay más y variantes) es el Cycle Time. El Cycle Time es súper antiguo (al menos, en 2011, hace 8 años, en un post muy viejuno, ya te había hablado de él), y es un clásico en el mundo Kanban. 

Simplificadamente, el Cycle Time es el tiempo que le lleva a un equipo (recuerda, equipo, no persona) terminar un item (luego puedes sacar medias, etc.), típicamente una Historia.

En un tablero normal (no entro en esto, que ya tienes un post, tableros ágiles sospechosos), con su «TODO», «DOING» y «DONE», es el tiempo que la Historia pasa en el DOING. 

Obviamente, tendríamos que provocar que el Cycle fuera lo menor posible, lo que implicará:

  • Tener Historias lo más pequeñas (recuerda que las Historias deberían ser pequeñas)
  • Tener el mínimo de cosas en el DOING, así el equipo se concentra en cerrar en vez de abrir y en el Swarming (mayor colaboración).
  • Evitar desperdicios, como interrupciones, cambios de contexto, reuniones, etc., en pro de reducir el Cycle. 

Terminando

No sé cuantas veces he dicho y escrito que medir velocidad o eficiencia (y no sólo lo digo yo, si quieres referencias de «famosos», aquí tienes, y aquí, o aquí) es muy recomendable, pero que no puedes hacerlo descuidando el desperdicio y la deuda técnica, ya que podríais propiciar en hacer las cosas rápido pasando por encima de hacerlas bien, en su justa medida, lo que hará que, a medio plazo, vayáis más lentos (pues aquí lo vuelvo a repetir).

jgarzas

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.

Dejar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *