30 de julio de 2012

27 de julio de 2012

La pieza perfecta - Clases de Cerámica y Desarrollo de Software

Intento traducir a continuación una anécdota del libro Art & Fear, de David Bayles y Ted Orland, que leí en el post When good is bad de John Sonmez:
"El primer día del curso de cerámica, el profesor dividió el grupo en dos partes. Dijo que todos aquellos en el lado izquierdo del estudio, serían evaluados únicamente en función de la cantidad de piezas que produzcan, mientras todos los de la derecha serían evaluados en función de la calidad de las piezas producidas. 
Su procedimiento era simple: en el último día de clase pesaría con su balanza de baño las piezas de calidad "A" (la mejor calidad), luego las piezas de calidad "B" (la segunda calidad), y así sucesivamente. Para los evaluados únicamente en función de la calidad (el segundo grupo), alcanzaría haber producido una sola pieza perfecta, de calidad "A".
Llego el momento de la evaluación, y paso algo curioso: el trabajo de mejor calidad fue producido exclusivamente por el grupo "cantidad". Parece que mientras el grupo "cantidad" estaba ocupado en producir pilas de piezas -y en aprender de sus errores-, el grupo "calidad" estaba teorizando el concepto de perfección, y al final no tenían para mostrar como fruto de sus esfuerzos mucho más que teorías grandiosas y una pila de arcillas muertas."
Más allá de la muy buena reflexión que propone John Sonmez en su post, me surgen muchos paralelos para el grupo "Calidad" con algunos vicios que se ven en el desarrollo de software, como por ejemplo el Big Upfront Design, el Análisis-Parálisis, el Sprint 0 Eterno, el ante-proyecto que dura meses/años, los 6 meses de especificaciones, etc.

Y para el grupo "Cantidad" veo muchas relaciones con algunos conceptos y valores claves de las practicas ágiles como el empirismo, el descubrimiento continuo de las necesidades, la inspección y adaptación del producto, la mejora continua, aceptar el cambio, etc.

Creo que muchas veces perdemos mucho tiempo antes de empezar un trabajo, tratando de predecir algunas cosas que es más fácil descubrir sobre la marcha, aunque no parezca muy natural.

Para cerrar me gustaría citar a Pitágoras:
 "El inicio es la mitad de todo"

25 de julio de 2012

19 de julio de 2012

16 de julio de 2012

13 de julio de 2012

Las 3 métricas claves del kanban

Me gusta explicar Kanban a equipos de TI con las siguientes tres reglas esenciales:

1. Mostrar el proceso y el trabajo en curso
2. Limitar el trabajo en curso
3. Optimizar el flujo de trabajo

En este post quiero detenerme en particular sobre 3 métricas que me parece fundamental monitorear para trabajar la tercera regla.

¿Cuáles son las tres métricas?

Cycle Time: Es la métrica que registra el tiempo que sucede entre el inicio y el final del proceso, para un ítem de trabajo dado. Se suele medir en días de trabajo. 

Lead Time: Es la métrica que registra el tiempo que sucede entre el momento en el cual se está pidiendo un ítem de trabajo y el momento de su entrega (el final del proceso). Se suele medir en días de trabajo. 

La siguiente traducción de la explicación de Corey Ladas sobre la diferencia entre Cycle Time y Lead Time ayuda a entender mejor estos conceptos:
"El reloj del Lead time se inicia cuando se hace el pedido y termina cuando se entrega. El reloj de Cycle Time se inicia cuando el equipo empieza a trabajar sobre el ítem y se termina cuando el ítem está listo para la entrega. El Cycle Time es una medición más mecánica de la capacidad del proceso. El Lead Time es lo que ven clientes. El Lead Time depende del Cycle Time, pero también depende de la buena disposición para mantener un backlog de ítems de trabajo, de la paciencia de clientes y de la disponibilidad para recibir la entrega por clientes. Otra forma de mirarlo: el Cycle Time mide el ritmo de terminación, mientras el Lead Time mide el ritmo de entrega."


Touch Time: Descubrí el concepto en el libro Lean From The Trenches, de Henrick Knibberg (y al poco tiempo lo empezamos a registrar en el kanban de un equipo de testing):

Es la métrica que registra el tiempo en el cual un ítem de trabajo fue realmente trabajado (o "tocado") por el equipo. Dicho de otra forma: cuantos días hábiles pasó este ítem en columnas de "trabajo en curso", en oposición con columnas de cola / buffer y estado bloqueado o sin trabajo del equipo sobre el mismo.

Con lo cual, para un mismo ítem: 

¿Cómo registrar las tres métricas?

No soy muy amante de las herramientas para soportar los tableros kanban, pero en el caso de usarlos, seguro tendrán funcionalidades muy lindas para registrar y monitorear estas 3 métricas (y mucho más).

Para quienes tienen suerte usando tableros fiscos de kanban, es bastante fácil mantener el registro de estas métricas sin que sea una carga administrativa pesada. Lo que en mi experiencia funciona bien es anotar en los post-its de los items de trabajo alguna información y luego completar una planilla digital con esta información en el momento de finalización del proceso de trabajo de cada ítem.

  • Información a registrar para Cycle Time y Lead Time
El tablero debería contar con una columna "Backlog" donde se agrega un post-it de ítem de trabajo cada vez que se hace un pedido de trabajo. La idea es anotar en el mismo post-it la fecha en la cual se agregó el post-it al tablero (=fecha de pedido). Por otro lado, cuando un ítem de trabajo se empieza a trabajar (y su post-it ingresa a la primera columna de trabajo del tablero), se registra la fecha en el mismo post-it (=fecha de inicio).

  • Información a registrar para Touch Time
Un mecanismo simple para eso es agregar un punto rojo en el post-it de un ítem de trabajo para cada día en el cual el equipo no hizo nada para este ítem. Típicamente esto ocurre cuando un ítem permanece en una columna de cola / buffer, cuando surge un bloqueo externo al equipo o cuando el equipo está trabajando sobre otros ítems. Si el equipo hacer reuniones diarias de actualización del tablero, es bastante fácil de implementar durante la reunión. 



  • Planilla de calculo de las métricas
El ultimo paso es ingresar esta información en una planilla de calculo. La idea es que cada vez que un item se entrega (=ingresa a la columna de "Terminado" del tablero), se vaya guardando cierta información del post-it en una planilla de calculo. En particular: la fecha de pedido (1), la fecha de inicio (2), la fecha de entrega (3)  y la cantidad de días bloqueados (4)

En esta planilla se pueden armar los cálculos siguientes para las 3 métricas: 
    • Cycle Time = DíasHabilesEntre(3-2)
    • Lead Time = DíasHabilesEntre(3-1)
    • Touch Time = Cycle Time - 4


DiasHabilesEntre(fecha1, fecha2) se puede resolver por ejemplo con la función "NETWORKDAYS" en las planillas de google docs. Ver esta planilla de ejemplo (con los feriados del 2012 de Argentina).


¿Qué monitorear?
En mi experiencia, es importante revisar periódicamente o durante retrospectivas los números a continuación. En la tabla también explico posibles interpretaciones de las tendencias y algunas pistas para mejorar: 
¿Qué monitorear?
Tendencia
Posibles Interpretaciones
Posibles Acciones
Promedio del Cycle Time Está bajando - El equipo está mejorando
- Proceso más fluido 
- Seguir así!
Promedio del Cycle Time  Está subiendo - Se complejiza el trabajo
- Hay bloqueos y/o cuellos de botella
- Se desmotiva el equipo
- Analizar cuellos de botella y bloqueos de trabajo
- Revisar motivación del equipo y/o capacidad del equipo para el trabajo 
Promedio del Lead Time  Está bajando - No hay pedidos
- El equipo está sobre-dimensionado
- Mejoramos 
- Analizar si no deberían llegar más pedidos
- Analizar dimensionamiento del equipo
Promedio del Lead Time  Está subiendo - Hay muchos pedidos
- El equipo está sub-dimensionado
- El ritmo de trabajo no es suficiente

- Revisar validez de los pedidos
- Analizar dimensionamiento del equipo
- Revisar motivación del equipo y/o capacidad del equipo para el trabajo 
Variabilidad Cycle Time Muy variable- Muchas diferencias de complejidad entre los items
- Deuda técnica acumulada surge en cualquier ítem en forma aleatoria
- Separar items en varias clases de servicios o según complejidad (alta, media, baja)
- Atacar la deuda técnica e implementar prácticas para bajarlas (XP)
Promedio Touch Time / Promedio Cycle TimeBaja proporción- Mucha espera en el proceso
- Muchos bloqueos en el proceso y cuellos de botella
- Mucho mult-tasking
- Bajar los limites de WIP y trabajar sobre puntos de bloqueos y cuellos de botella
- Identificar puntos de espera externa y trabajar sobre su optimización
Promedio Cycle  Time / Promedio Lead TimeBaja proporción - El equipo está sub-dimensionado
- El ritmo de trabajo no es suficiente
- Analizar dimensionamiento del equipo
- Revisar motivación del equipo y/o capacidad del equipo para el trabajo 

¿Usan estas métricas? ¿Tienen otras en su Kanban?

Para aprender más sobre Kanban, te recomiendo el taller Lean y Kanban en acción, de Kleer. 

10 de julio de 2012

5 de julio de 2012

4 de julio de 2012

Dinámica de Retrospectiva: Back to the Future


Vi esta dinámica de retrospectiva en varios lugares, y si bien la usé una sola vez y hace mucho tiempo, me parece muy interesante.
  • Nombre: Back to The Future
  • Participantes: 5 a 12 personas
  • Duración: 1 hora
  • Alcance: al principio de un proyecto o al principio de una etapa importante
  • Propósito: identificar y elegir acciones de mejoras, definir una visión compartida del éxito
  • Facilitador: necesario 
  • Objetivos: con esta dinámica el equipo va a intentar imaginar en el futuro el éxito del proyecto, y luego pensar los mecanismos claves para poder concretarlo.
  • Material y Preparación: un pizarron con marcadores. Eventualmente post-its y hojas si se hacen brainstorming y/o votaciones.
  • Pasos
    1. Establecer el marco - El facilitador explica el objetivo de la actividad y setea el marco: en que momento del futuro nos estamos proyectando y en que situación. Por ejemplo: "nos encontramos el día del cierre del proyecto X, y el Gerente de Negocio da un discurso de felicitaciones a todos los involucrados", o "se comunican los resultados del concurso del proyecto más exitoso del año, y sale nuestro proyecto", o "pasaron 20 iteraciones y estamos trabajando muy bien y logrando resultados superiores a las expectativas".
    2. Definir el éxito futuro - El equipo trata de imaginar, en el marco ficticio acordado, cuales son los resultados exitosos logrados. Se puede facilitar como un brainstorming, o una reflexión de grupo. Es importante que el facilitador vaya anotando a la vista de todos  los entregables o resultados concretos que se mencionan, con sus principales características (por ejemplo: "hubo 50.000 downloads del producto en una semana", "se cubrieron todas las expectativas del sector de marketing", "nos hicieron una nota en una revista", "después de 2 semanas en producción no surgieron bugs importantes", etc.). Si son muchos puntos identificados, se pueden priorizar en función se su importancia en el éxito
    3. Identificar mecanismos claves del éxito - En sub-grupos de 2 o 3 personas, trabajar sobre cada punto identificado en el paso anterior. El objetivo es identificar lo que permitió llegar al resultado exitoso correspondiente. Por ejemplo, para el resultado "después de 2 semanas en producción no surgieron bugs importantes", se podría identificar los mecanismos siguientes: "implementamos TDD en todos los módulos" y "hicimos una prueba piloto de una semana con la sucursal X". Luego cada grupo presenta sus mecanismos y el grupo completo vota por los mecanismos que parecen más eficientes para cada resultado exitoso. 
    4. Volver al presente - Ahora se vuelve al presente. Sobre los mecanismos más votados, el equipo identifica las acciones concretas que el mismo grupo podría implementar en la próxima iteración (o a corto plazo). Eventualmente se pueden priorizar las acciones si surgen varias, de tal forma que el grupo se quede al final con pocas acciones concretas a implementar en el corto plazo.
  • Variantes
    • Para el paso 2, el facilitador puede pre-definir los resultados exitosos logrados y no dejar que el equipo lo defina. Eso permite ahorrar tiempo de retrospectiva, pero por otro lado la visión propuesta no tiene la misma fuerza que si la define el mismo equipo.
    • En el paso 3, se pueden elegir solamente algunos resultados del paso 2 para trabajar.
    • En el paso 2, se puede hacer primero un trabajo personal donde cada uno escribe en su hoja 2 o 3 resultados exitosos y luego hacer una puesta en común grupal y eventualmente priorizar los resultados. 
  • Tips
    • Recomiendo guardar registro de los resultados del paso 2, y eventualmente dejarlo bien visible en algún lugar de trabajo del equipo. Es un buen material para referenciar y volver a consultar a lo largo del proyecto y al final. Cuando más identificación del equipo haya con estos logros a conseguir mejor.
    • En el paso 3 es importante que el facilitador mantenga el foco sobre lo que está al alcance del equipo. El riesgo es que se identifiquen mecanismos fuera del alcance del equipo: "la empresa competidora entro en banca rota", "nos pagaron premios millonarios", que no son muy útiles a la hora de identificar acciones de mejora. 
    • En el paso 4 es importante llegar a acciones concretas, que el mismo equipo pueda implementar y de corto plazo.
  • Origen: no se exactamente de donde sale esta dinámica, pero la vi en varios lados como por ejemplo  el post Future-spectives de Anders Laestadius.
¿Ya usaron esta dinámica o algo parecido? ¿Como les fue?

2 de julio de 2012