¿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.

¿Hay algún tipo de tablero para las reuniones de retrospectiva?

Plantilla de retrospectiva, gracias pmoinformatia.com

Si los hay, como por ejemplo el que ofrece la oficina de proyectos de informática (pmoinformatia.com) en forma de plantilla de Scrum, en el que se muestran las tres columnas típicas de una retrospectiva con "qué salió bien durante la iteración", "qué no salió bien" y "cuáles son las mejoras que se pueden implementar en el próximo sprint". 

Junto con la plantilla se presenta otra plantilla que sirve para documentar el resultado de la reunión, representa sólo una forma de realizar una retrospectiva, no pretende ser restrictiva, como todo en Agilidad, es susceptible de ajustarse a las singularidades de y a lo que le sea más útil al equipo.

Cada miembro escribe sus aportaciones en post-its y los coloca en la columna correspondiente, para después hablar con total transparencia sobre ello. Con el uso del tablero los equipos suelen experimentar como ventaja su automoderación y que todos mantienen la conversación centrada en los temas planteados en el mismo.

Para que las retrospectivas funcionen es importante que haya alguna acción sobre las mejoras recopiladas, que se evidencie un resultado, pero solo sobre una de ellas. Como equipo debemos limitar el WIP y elegir un objetivo, y sólo uno, para el próximo sprint. Si incorporamos más mejoras puede ocurrir que desviemos el foco del "en qué" trabajamos al "como" trabajamos y así no cumplamos con la pila de sprint. Una vez seleccionada la mejora la implementamos, la dejamos asentar para finalmente convertirla en un hábito del equipo.

Recientemente participé en una retrospectiva liderada por una chica y me encantó su forma de apelar a la inteligencia emocional en el tablero. Pegó cuatro post-its en la pared, los de la imagen abajo a la derecha, y las aportaciones del equipo las fueron pegando alrededor de estos. Incorporó una cuarta columna para mi inusual, una de agradecimientos, y resultó que lo escrito en los post-its de esta columna hizo que el equipo se sintiera bien, con un muy buen estado de ánimo y buena disposición para el resto del día.

Post-its de encabezamiento
para un tablero más dirigido
a personas, gracias Esther :-)

La bombilla evoca a ideas, las mejoras, como ejemplos:

• Agilizar la sprint planning
• Tareas o minitareas más definidas
• Investigar la aplicación de BDD
• Lectura de las fuentes del proyecto para proponer mejoras

El ramo de flores evoca los agradecimientos, como ejemplos:

• Gracias a todos por hacer una entrega tan completa
• Raúl por su paciencia porque el pobre no le hacemos caso
• Gracias Miguel por haberme ayudado a esclarecer el conflicto que apareció en el código durante el batch
• En especial a Dani y a Juan por el esfuerzo

La carita sonriente lo que nos pone contentos, lo que salió bien, como ejemplos:

• Buena comunicación con cliente y dentro del equipo
• Nuestro apoyo mutuo en las dudas
• Ser un equipo que adoptado bien Scrum
• Por fin un entorno de pruebas automatizadas

La carita triste lo que nos pone tristes, lo que no salió bien, como ejemplos:

• No hemos llegado al 100% del sprint
• Falta de puntualidad en las daily, eso nos hace perder tiempo y las hace más largas de lo necesario
• Tener que hacer informes para la PMO que solo entorpecen mi trabajo
• No revisamos lo suficiente, se nos cuelan bugs por no probar desde la perspectiva del usuario

Las mejoras, una camino hacia el sol :-D

Finalmente el equipo vota con palitos, en nuestro caso 3 a distribuir a discreción, entre las ideas y aquello que no ha salido bien.

El post-it o los post-its con más interés o preocupación por parte del equipo, los llevamos a un área específica para tratar de buscar mejoras. El post-it que encabeza este área se identifica con una flecha que apunta al sol :-D.

Alli tratamos posibles soluciones para los top de aquello que queremos tratar, podemos aplicar técnicas como el diagrama Fishbone (Ishikawa) o los 5 Why's para encontrar causas raíz y sus soluciones, para finalmente elegir una sola mejora a aplicar para el siguiente sprint.

Retrospectiva en marcha, gracias Alberto, Francisco, Jorge, Raquel, Sandra y Miguel

¿Qué son los ScrumButs o ScrumPeros?

Hay empresas que para tomar su camino hacia la Agilidad adoptan Scrum, y otras, adaptan Scrum. Adaptar Scrum para pasar de scrum técnico, basado en reglas, a scrum avanzado y así aplicar directamente principios de gestión ágil con el conocimiento y experiencia de los equipos, y con una cultura ya ágil en la organización, trata de la madurez en Agilidad. Pero adaptar Scrum de entrada sin una cultura ágil es cosa muy distinta... mi compañero Aníbal suele decir "cómo una empresa que está lidiando a duras penas con su producto en el mercado puede pretender diseñar una metodología"... en mejor de los casos se trata de organizaciones que hacen cambios a corto plazo para dar tiempo a corregir sus deficiencias.

¿Adoptar o no ScrumButs?

ScrumButs/Peros son malas prácticas por las que los equipos no pueden sacar el máximo provecho de Scrum para resolver sus problemas y hacer realidad los beneficios del desarrollo de productos con este marco. Cada rol de Scrum, artefacto, regla, y timebox se ha diseñado para proporcionar los beneficios descritos, y abordar problemas recurrentes predecibles. Normalmente los ScrumButs implican que Scrum ha puesto de manifiesto una deficiencia que está contribuyendo al problema, pero es demasiado difícil de solucionar. Un ScrumBut conserva el problema al modificar Scrum para que la deficiencia no sea visible y no se considere como problema del equipo.

Por ejemplo, la definición de hecho (DoD) podría no incluir inicialmente regresión y pruebas de rendimiento, ya que tomaría varios meses desarrollar las pruebas automatizadas. En este caso durante los meses sin pruebas automatizadas el desarrollo estará penalizado por una deuda técnica, y esta se debe de restaurarse tan rápidamente como sea posible.

Un ScrumBut tiene la siguiente sintaxis:

(ScrumBut) (Razón) (Workaround)

Un ejemplo ScrumBut:

• Estamos haciendo Scrum, pero las retrospectivas no son eficaces, por lo que sólo las hacemos cada tres meses.

Las retrospectivas a menudo son ineficaces porque no se hace nada acerca de las cuestiones planteadas, es más probable que el equipo necesite mejores retrospectivas en vez de menos.

Otros ejemplos:

• Estamos haciendo Scrum, pero nuestros clientes e interesados están demasiado ocupados para asistir a las revisiones de sprint, por lo que dejamos de hacerlas.
• Estamos haciendo Scrum, pero no conseguimos acabar los incrementos en dos semanas, por eso ahora dejamos que nuestros sprints sean abiertos sin duración fija.
• Estamos haciendo Scrum, pero a veces nuestros gerentes nos dan tareas "especiales", por lo que no siempre tenemos tiempo para cumplir con la definición de hecho (DoD) .

¡Esto NO es Scrum!

Hay una página en la que se puede hacer un test de ScrumButs, lo interesante es que muestra la distribución en tarta de los diferentes ScrumButs aplicados con mas frecuencia.

En general los expertos en Scrum nos oponemos a los ScrumButs porque casi siempre esconden un impedimento o deficiencia que, de ser abordado y eliminado, mejoraría muchísimo las cosas. Mi consejo es preguntar en primer lugar por el porqué, a veces hay que escalar la pregunta hasta llegar a la causa raíz, y es usual llegar a respuestas como "como siempre se ha hecho así..." resultando que si se puede cambiar y por tanto hemos adoptado un ScrumBut sin necesidad. En segundo lugar mi consejo es "adoptar antes de inspeccionar y adaptar".