¿Cuál es la diferencia entre Lead y Cycle Time en Kanban?

En mi último curso expliqué los dos conceptos y una de las alumnas salta y dice: "eso es como cuando coges el metro, Cycle Time, o tiempo de servicio, es cuando subes al metro y piensas lo bien que funciona y que enseguida estás en casa, y Lead Time, tiempo de entrega, es cuando llegas al andén y ves como se va un tren, sientes la rabia de haberlo perdido y durante la espera piensas lo mal que va el servicio". Me pareció una analogía muy ilustrativa que me animó a escribir este post.

Imaginemos que tenemos un tablero Kanban con el que gestionamos el flujo de trabajo de las peticiones de nuestro servicio de mantenimiento y soporte. Lead Time es el plazo de ejecución que se inicia cuando el cliente hace la petición y que termina en la entrega. Cycle Time es el tiempo que se inicia cuando el equipo comienza el trabajo sobre la petición e igualmente termina en la entrega, realmente se trata del esfuerzo medido en tiempo:

Lead y Cycle Time sobre un tablero Kanban

• Lead time (tiempo de servicio): tiempo importante para el cliente ya que mide el tiempo de resolución de sus peticiones
• Cycle time (tiempo de entrega): tiempo de trabajo sobre la petición, importante para el proveedor ya que viene a ser una medida de la capacidad del proceso

En el contexto de los servicios de manteamiento suele haber un ANS o SLA (Acuerdos de Nivel de Servicios o Service Level Agreement) en que se mencionan los tiempos de resolución requeridos, usualmente estos suelen ser Lead Time. Si no añadimos nada más esto puede llevarnos a una situación comprometida, si nuestro cliente nos hace peticiones por encima de nuestra capacidad tendrá una percepción muy negativa de nosotros. Aunque nuestro Cycle Time pueda ser excelente, se nos acumulan las peticiones en la columna de "Pendiente" y el cliente percibe que no somos capaces de resolver a su ritmo.

Lo que aconsejo en este caso es limitar el WIP en la columna "Pendiente", buscando igualar lo máximo posible Lead y Cycle Time, y así conseguir que en el momento en el que nuestro cliente haga una petición, esta entre lo antes posible a "En curso". En este caso la percepción del cliente será muy distinta, percibe que tal como solicita nos ponemos a trabajar en ello. Los ANS o SLA no son solo para que nuestros clientes pongan sus condiciones, también los proveedores podemos poner las nuestras, y si un cliente paga por un equipo de tamaño determinado hemos de ofertar de forma proporcional a la capacidad de resolución del equipo. Encontrar el WIP adecuado no es inmediato, requiere cierto rodaje, por tanto un periodo de adaptación debería de ser tratado en el ANS.

¿Qué ventajas financieras aporta Scrum frente a proyectos en cascada?

Como coach ágil acabas moderando, formando y explicando Scrum a muy diferentes perfiles dentro de las compañías, y a cada uno de ellos hay que hablarles en un idioma adecuado, uno que cada uno de ellos pueda entender. Uno de estos perfiles son los directores financieros y para cuando tengamos que tratar con estos podemos utilizar este gráfico que muestra una comparativa de como se comporta el ROI en ambos marcos de trabajo.

Gráfico comparativa comportamiento ROI por Carlos Peix

En el punto "0", el origen de coordenadas, encontramos el punto donde se inicia nuestro proyecto. El punto "E" sobre el eje de abscisas representa deadline, el momento de la entrega del proyecto. En el eje de ordenadas por encima del origen de coordenadas se representan las ganancias (ROI), y por debajo del mismo las pérdidas (inversión).

Miremos primero lo que ocurre con la curva "B" que representa un proyecto con metodología tradicional en cascada. Desde el inicio del proyecto hasta su entrega tenemos una inversión constante, pagamos sueldos, recursos y todo lo que conlleve el proyecto. No es hasta que entregamos el proyecto cuando recuperamos poco a poco la inversión con los beneficios que este va reportando. En algún momento más allá de la entrega la curva se vuelve de color verde y dará beneficios a la compañía.

Ahora estudiemos la curva "A". Esta representa un proyecto bajo el marco de trabajo de Scrum. Con cada sprint, señalados con la letra "S", obtenemos un incremento instalable en producción. Ya en los primeros sprints vemos que la inversión da sus frutos, ya que el incremento puesto en producción, por tanto lanzado al mercado, ya empieza a dar beneficios y a producirse el retorno de la inversión. El ROI es moderado pero crece a medida que avanza el proyecto y mucho antes de la fecha de entrega "E" la curva se vuelve verde.

¡Un director financiero eso lo entenderá muy muy bien! :-)

Pero veamos que más beneficios aporta Scrum. Imaginemos que en el punto "I" se produce una interrupción del proyecto, no tanto por una cancelación, sino porque se hayan producido cambios significativos en el alcance derivados de las variaciones del mercado. En un proyecto en cascada es complicado cambiar, el proyecto se ha diseñado para llegar a "E" y lo más probable es que en "I" tengamos muchas cosas empezadas, cosas que

Gráfico de funcionalidades obtenidas, thanks to Silvana

habrá que finalizar o desechar. Usualmente esto pasa porque en proyectos en cascada se suele trabajar por capas horizontales, a diferencia de Scrum dónde se trabaja por lonchas verticales. Veamos ahora lo que pasa en Scrum. Scrum abraza el cambio, por tanto lo único que sería necesario es finalizar el sprint en curso, luego los cambios se incorporarán de forma natural al proyecto. Aún en el caso de una cancelación total del proyecto, lo construido hasta entonces, dado que está en producción, en el mercado, seguirá dando sus beneficios. En el gráfico a la izquierda se ve claramente la diferencia en funcionalidades obtenidas, en el proyecto en cascada no habremos obtenido nada, porque todo lo obtendremos en "E", en cambio en Scrum habremos obtenido la suma de funcionalidades construidas en los diferentes sprints "S".

Es interesante ver el comportamiento del riesgo "R", en cuanto la curva "A" se vuelve verde ¿hay riesgo financiero? ¡Podemos seguir desarrollando y no perdemos dinero! Uno de los beneficios de Scrum es que, al poner los problemas sobre la mesa en cuanto estos se producen, trae los riesgos al principio del proyecto.

¿Qué hacer cuando la fricción del ambiente hace que el equipo nunca cumpla con la pila de sprint?

Gráfico burn-down de un sprint con fricción ambiental

Partimos de la base de que tenemos un equipo formado y motivado, que lleva unos pocos sprints a su espalda y que ha alcanzado un cierto grado de autoorganización. Todo debería ir bien, pero la fricción del ambiente hace que con cada sprint se obtenga un gráfico burn-down con un patrón semejante al de la imagen de la izquierda.

Para que funcione Scrum y la Agilidad no sólo debemos de tener equipos ágiles, nuestros clientes y usuarios, los que entienden de negocio, también deben de ser ágiles. El grado de Agilidad de nuestros clientes también afecta, y cuando estos tardan en responder, en decidir o proveer, se produce lo que se llama la fricción del ambiente. En estos casos esta fricción es la responsable de que no se cumplan los sprints, los ciclos de respuestas de nuestros clientes son más largos que los sprints y por tanto la solución sería alargar la duración de los mismos para dar el tiempo necesario a los ciclos del cliente. Los sprints serán más largos y contendrán más historias de usuario, pero permitirán que los ciclos del cliente se acompasen con estos.

¿Cómo decidir a qué candidatos contratar para un equipo ágil?

Es una pregunta que se repite a lo largo de la mayoría de los cursos que doy, así como en los que asisto como co-trainer y alumno.

Contratado el candidato acertado

Los equipos ganadores, o de excelencia, dónde los miembros están integrados y confían unos en otros, están formados por personas con perfiles tipo "T", con las aptitudes necesarias para realizar su trabajo específico y a la vez con interés y curiosidad por todo lo que les rodea dentro del contexto del proyecto. Quién quiera saber un poco más sobre las personas tipo "T" y tipo "I" puede leer mi post ¿Cómo han de ser las personas que integran los equipos de trabajo?

Para encontrar perfiles tipo "T" podemos utilizar Killer-Questions como ¿Al integrarse en nuestro equipo como se ve usted, más como alguien que puede enseñar o alguien que puede aprender? 

Dentro del mundo en que vivimos, incluidas las TI, en que el cambio es constante, una persona tipo "T" comprende que ha de aprender para adaptarse y da la bienvenida al aprendizaje continuo. De hecho, si una persona no quiere formarse y seguir evolucionando, la compañía seguramente tendrá un problema en cuanto se acabe el trabajo de su especialidad... no habrá un lugar donde reubicarle. La contratación inteligente de personal pasa por fichar aquél que aprende más rápido, no tanto por sus aptitudes, sino por su talento. Podemos tener dos curriculums iguales pero las dos personas que hay detrás ser radicalmente opuestas en productividad, la diferencia es el talento y la pasión. La ingeniería de software es una industria que trata con el talento extremo, y el éxito, sea con metodología tradicional o métodos ágiles, dependerá de las personas más acertadas.

Simon Sinek - No contrates por aptitudes,
contrata por actitud, las aptitudes se aprenden

Mencionar también que hay que tener mucho cuidado con las personas tipo "O", son aquellas cuyas aptitudes cubren todo el espectro multidisciplinar, desde analista a desarrollador y a tester, es una persona que puede hacer cualquier tipo de trabajo del equipo, pero tiene una actitud de "Prima Donna", actuando de forma individual y egocéntrica como el máster del universo, pudiendo penalizar y hasta anular a un equipo que siempre ha funcionado bien. En Scrum no hay lugar para héroes, los héroes no suelen aceptar que su opinión no siempre es la que adopta el equipo, un héroe compite, no colabora.

Quién contrata suele ser el que paga, por tanto quién contrata suele ser quien representa al cliente y que a la vez está comprometido con el proyecto, puede que el Propietario del Producto. Si fuera el caso es muy recomendable que el Scrum Master acompañe al Propietario del Producto en la entrevista y dé sus sugerencias, ya que este tiene la visión social del candidato versus al equipo.

En caso de equipos ya establecidos también es recomendable la participación final del equipo, al fin y al cabo el nuevo candidato formará parte de este y trabajará con este, y será más fácil integrarlo si el propio equipo ha formado parte de la toma de decisión. Yo lo que hago es decirle al candidato al final de la entrevista que voy a enseñarle las instalaciones y a presentar al equipo con el que pudiera acabar trabajando. En complicidad con el equipo éstos tienen una breve charla de 5 a 10 minutos con el candidato, su veto es determinante, si no lo quisieran el candidato queda directamente descartado.

Quiero acabar el post con una frase de Emilio Duró:

Yo ficho a la gente por cómo sube las escaleras

La motivación y la actitud de las personas se lee claramente en como suben las escaleras, si lo hacen con energía se puede leer valentía e ilusión... candidatos ideales para equipos con los que hacer grandes cosas.

¿Existe alguna dinámica para las retrospectivas enfocada a interacciones?

Existen varias dinámicas, mi preferida y la que aplico usualmente para tratar las interacciones es una variante del triángulo retrospectivo. La dinámica original la encontraréis en el blog de Thomas Wallet en su artículo Dinámica de Retrospectiva: El Triangulo Retrospectivo.

Equipo votando las interacciones

Su dinámica está pensada para un equipo de 3 personas y en el caso en el que yo quería aplicarlo trataba de un equipo de 5 personas. Intenté imaginarme el tipo de figura geométrica que necesitaría para representar las interacciones entre 5 personas, ¡me resultó imposible! Finalmente se me ocurrió mantener la forma de triángulo y variar los vértices. Me decidí por los siguientes tres vértices: miembro del equipo, equipo y otros, dónde otros son el Propietario del Producto, el Scrum Master y los interesados. Las interacciones representadas, las líneas, son de un miembro al equipo, de un miembro a otros y del equipo a otros.

Los pasos para la dinámica son los siguientes (basados en los pasos del triángulo retrospectivo de Thomas Wallet):

• Se arma en una superficie plana un gran triangulo con cinta, y en cada vértice del triangulo se pone un post-it con los siguientes textos: "Miembro Equipo", "Equipo" y "Otros (PO, SM, INT)"
• Cada participante escribe en post-its las interacciones que vivió como miembro o como equipo durante el último sprint (1 interacción = 1 post-it)
• De a uno y hasta que se acaben los post-its generados, se repiten los pasos siguientes:



La retrospectiva resultante
(con un vacío de interacciones
en el centro)

• Cada participante explica uno de sus post-its
• Luego lo ubica en el triángulo: en el lado externo de la línea que une dos actores cuando es una interacción entre dos, o en el medio si es una interacción entre todos
• Si otro participante tiene un post-it similar o relacionado, lo cuenta, se pegan juntos y se reformulan si fuera necesario
• Se revisa el triangulo generado con el objetivo de descubrir interacciones faltantes y/o unir/agrupar varias interacciones
• Cada participante vota con color verde con un solo "1" un solo "2" y un solo "3" a tres de los post-its que asimila a interacciones que fueron positivas/fortalezas
• De la misma manera que en el punto anterior, cada participante vota con color rojo los post-its que asimila a interacciones que fueron negativas/problemáticas
• Se revisan los resultados de la votación:
• Entre los que suman los números rojos más altos se elige el o los problemas a analizar luego
• Entre los que suman los números verdes se repasan para conocer las fortalezas de equipo y de lo que se está haciendo bien
• Por último se revisa como de balanceados están los post-its, por ejemplo en la imagen de ejemplo el centro tiene pocas interacciones (en este caso no está la reunión de planificación de sprint, posible signo de que no se le esté dando la importancia debida)

La experiencia fue muy positiva, los resultados fueron similares a los de otras técnicas, pero la gamificación a través de la dinámica convirtió una actividad a priori aburrida en una actividad divertida en que todos participaron de forma muy activa.