wip

Vive la experiencia de limitar el WIP con Featureban

Featureban es un juego diseñado por Mike Burrows para experimentar el efecto que tiene limitar el trabajo (WIP)

Uno de los problemas más habituales en organizaciones que pretenden usar Kanban es la resistencia al WIP. Normalmente dicha resistencia viene dada por las presiones y el conocimiento convencional de que la gente debe estar ocupada.

Sin embargo, pocos tienen en cuenta algo importante cuando se concentran en realizar trabajo, focalizándose en la eficiencia en lugar de en el flujo de valor.

Lo normal es que surjan bloqueos que finalmente redundan en grandes cantidades de trabajo a medio hacer y no terminado. Lo que en empresas industriales se conocen como inventario.

Diferencias entre flujo y lotes

Cuando trabajamos, tendemos a hacerlo en lotes de trabajo. Pensamos que es la manera más eficiente de hacerlo. En lugar de realizar una tarea al completo, desde el primer estado hasta el último, tendemos a realizar todas las tareas de un estado para pasarlo a la siguiente fase. Eso se llama procesamiento en lotes. Es eficiente pero muy lento.

El trabajo basado en flujo es un paradigma distinto, en el que obviamos la eficiencia y nos centramos en terminar pequeñas partes del trabajo de forma continua. Ese tipo de trabajo es el que llevó a Toyota a convertirse en el fabricante de automóviles más importante del mundo.

Este vídeo explica muy bien estos dos paradigmas.

Agilidad y WIP

El vídeo nos muestra cómo la diferencia de tiempo –lead time– es espectacular entre cada una de las formas de procesamiento. Para poder mejorar la agilidad del negocio, es necesario limitar el WIP para un procesamiento basado en flujo, en lugar de uno basado en lotes.

Este concepto es difícil de entender. Gracias al taylorismo y a la producción en cadena, tendemos intuitivamente a pensar en lotes en lugar de flujo. Featureban es un juego que ayuda a romper esa barrera mental.

A través de un ejercicio de simulación, el equipo se enfoca primero en ser lo más eficiente posible y después en limitar el WIP para observar las diferencias de flujo. Se puede descargar gratuitamente de la página de agendashift.

[slideshare id=39065931&doc=featureban-slides-140914090927-phpapp02]

¿Cual es el WIP ideal?

Depende. Algunas personas empiezan limitando el WIP al número de personas implicadas en el proceso. Otros utilizan la fórmula 2n-1. La realidad es distinta.

El WIP es una variable de la que dependen otras dos:

Thoughtput (número de ítems entregados): Cuanto más bajo sea nuestro WIP, más alto será nuestro thoughput por unidad de tiempo. Por eso el procesamiento por lotes es más eficiente. Si calculamos la inversa del throughput, obtenemos el Cycle Time medio por ítem.
Lead time (Tiempo medio de entrega de un ítem terminado): El Lead Time es la segunda variable. Un WIP más alto significa un lead time más alto y un Cycle Time más largo, mientras que un WIP más bajo significa tiempos más cortos y tiempos de ciclo más corto.

El WIP hay que diseñarlo dependiendo del throughput y del lead time que queramos, ya que dependiendo de las situaciones y restricciones internas de nuestro sistema, uno será más eficiente que otro. Tienes más información en este artículo sobre métricas ágiles y en este vídeo.

Mi cuñado dice que se puede ser muy eficiente y entregar con mucha agilidad

Dile a tu cuñado que si eso fuera así, yo no tendría trabajo y estaría pidiendo en la puerta del sol. La última vez que miré… todavía tenía cosas que hacer.

6 errores evitables que cometen los equipos Scrum

El otro día alguien me preguntó cuales eran los errores típicos que veía en equipos Scrum que empezaban.
Mi respuesta fue sorprendente: ¿Los que empiezan? Los que más problemas tienen son aquellos que ya llevan mucho tiempo funcionando.

Error 1: Mucho Work in Progress

Acaba la primera parte del Sprint Planning y el equipo empieza a desgranar los PBIs en tareas, los estiman y cada uno de los miembros del equipo empieza a trabajar en un ítem distinto.

Eso provoca que luego haya problemas de integración y silos en los cuales el equipo no tiene ni idea de que está pasando. Los equipos maduros empiezan algo y no empiezan lo siguiente hasta que no lo terminan, manteniendo una o dos tareas en paralelo al mismo tiempo.

Cuando llega el final del Sprint, la mayoría de las cosas están a medio acabar y no da tiempo a integrar. Sin embargo el Product Owner aprieta para mostrar cuanto más mejor en el Sprint Review y el equipo de desarrollo añade la “deuda técnica” al backlog, para re visitarla… nunca.

Error 2: Falta de Sprint Goal

El Sprint Backlog se convierte en un cajón de sastre en el que entran decenas de cosas que no tienen nada que ver las unas con las otras, lo que hace que no haya coherencia y se pierda el desarrollo iterativo e incremental y la transparencia.

El Sprint Goal es una dirección general que ayuda al equipo a mantener el foco en cual es el objetivo de este incremento. El Sprint Backlog puede cambiar, el Sprint Goal no. Eso permite flexibilidad para lidiar con cosas que no estaban planeadas y un mejor enfoque en las necesidades de negocio.

Cuando no tenemos un Sprint Goal que de dirección, perdemos una herramienta muy potente que promueve dos de los valores de Scrum: Coraje y Compromiso. Entonces Scrum se convierte en un proceso más dentro de la compañía, además de perder foco en el valor de negocio entregado en cada incremento.

Error 3: Asignación individual de tareas

Los miembros del equipo de desarrollo trabajan individualmente en tareas hasta que las completan y luego pasan a trabajar en otra cosa. Eso provoca, de nuevo, falta de integración y posibles problemas de dependencias.

Algunos equipos tienen normas para lidiar con esto. Por ejemplo, tiene que haber un code review por al menos dos miembros del equipo. Trabajar en pares. Muchas veces con poca efectividad, sobre todo si la carga de trabajo es alta.

La única manera de lidiar con esta situación es, lamentablemente, reducir la carga de trabajo. Paradójicamente, el ahorro de entregar más rápido se traduce en cuatro veces más para reparar la deuda técnica y de conocimiento que supone ese ahorro.

Además, cuando se maximiza la utilización, se tiende a perder valor. ¿Cómo? Aumentando el tiempo de entrega. Cuando el equipo se enfoca en entregar unas cuantas cosas bien hechas, quizás esté perdiendo eficiencia, pero se asegura de entregar, lo cual ya supone una gran diferencia con muchos equipos, que trabajan en cosas durante meses sin llegar a entregarlas… nunca.

Error 4: Falta de responsabilidad

En Scrum, el rol responsable de dar cuentas sobre el incremento es el equipo de desarrollo. Que el nombre no nos lleve a engaño. Todos los miembros del equipo de desarrollo dan cuentas sobre todo el incremento.

No existe la individualidad del desarrollador en Scrum. Desafortunadamente, eso lleva a muchos miembros del equipo de desarrollo a quejarse porque ellos sí hacen su trabajo.

La manera de actuar es la de dejar que el equipo se autoorganice y lidia con esos problemas. Y la del Scrum Master no es actuar sobre los miembros que consideramos destacados o vagos, sino mantener esa discusión dentro del equipo, sin que escale en la organización.

En el caso del Product Owner, él es el responsable de dar cuentas de la inversión que hace en el equipo de desarrollo cada Sprint. Y tiene que hacerlo con datos. Si la calidad técnica del producto falla, de rebote el Product Owner se convierte en responsable.

Error 5: Maximización de utilización o eficiencia

Este es, sin duda, uno de los peores que puede tener una organización. Enfocarse en que la gente trabaje muchas horas en lugar de generar valor.

No nos equivoquemos. Estos dos objetivos son totalmente incompatibles. El desarrollo de software, por su propia naturaleza, incurre en una variabilidad muy grande y no es posible estandarizar tareas, duraciones, problemas o buenas prácticas.

La realidad es que cada vez que hacemos algo en software, por muchas veces que creamos haberlo hecho antes, nos enfrentamos a algo totalmente nuevo, en un entorno nuevo, un sistema nuevo, que nunca habíamos hecho antes. Es ineficiente porque aprendemos sobre la marcha.

Las ineficiencias aparecen en forma de miembros que no tienen suficiente trabajo, otros que están sobrecargados y otros problemas intermedios. El temor a que la gente esté parada lleva a introducir trabajo no necesario para generar valor y que la gente esté ocupada.

El resultado es que cuando el trabajo que tienen que hacer esos miembros es necesario, están ocupados haciendo otra cosa. Están siendo eficientes. Y haciendo perder dinero a la compañía.

Error 6: El equipo de desarrollo es el equipo de desarrolladores

El último es, quizás, el más desconocido. Debido a su nombre, los profesionales en Scrum piensan que un equipo de desarrollo tiene que estar formado por gente técnica: programadores, ingenieros de operaciones o calidad.

Nada más lejos de la realidad. El equipo de desarrollo tiene todos los perfiles necesarios para poder entregar un incremento de producto. Si eso supone que tienen que incorporar a un Business Analyst, un especialista en SEO o un diseñador, también son miembros del equipo de desarrollo.

Si ves que tu equipo se está acercando a alguno de estos errores o que el proceso de Scrum no está desarrollando adecuadamente, te recomiendo el artículo Cuatro señales de que Agile no funciona en tu organización.

Métricas ágiles fundamentales (I)

La principal medida de progreso en marcos de trabajo ágiles no son los puntos de historia, sino el software terminado. Muchos equipos siguen utilizando una medida de estimación subjetiva como una métrica absoluta para predecir. Malas noticias. Los puntos de historia (story points) no sirven para nada. Las buenas. Existen varias métricas ágiles que son fundamentales y pueden empezar a usarse inmediatamente. Veámoslas.

Métricas Macro

Las métricas macro son aquellas que permiten obtener información a alto nivel de una pila de tareas por hacer, lo cual permite tomar decisiones o plantear teorías para el conjunto de equipos que desarrollan un producto.

El Cumulative Flow Diagram (CFD)

Este diagrama indica cuantos Product Backlog Items hay en cada uno de los estados del backlog. Para obtenerlo, se puede usar software -en el caso de la imagen, JIRA- o de forma manual de forma muy sencilla. Esto es, dibujando un diagrama, y al final de cada día, actualizando el valor acumulado de cada uno de los elementos que tenemos en el Product Backlog.

WIP

La primera de nuestras métricas ágiles es el WIP. El WIP nos indica en cualquier momento el trabajo que está en curso. Si miramos el diagrama detenidamente, podemos obtener el trabajo en curso en cualquier momento midiendo la distancia entre el trabajo pendiente del backlog y el trabajo que todavía no ha sido entregado. Esta medida nos indica, de un vistazo, si los equipos están trabajando en demasiadas cosas a la vez.

Reducir el trabajo en curso contribuye a reducir la frecuencia de entrega. En entornos ágiles, las entregas frecuentes son muy importantes y permiten obtener un feedback rápido del cliente para poder adaptar la estrategia.

Algunas organizaciones tienen 6 o más meses de trabajo en curso. ¿Que significa eso en métricas de negocio? Que existe una inversión que no está produciendo ningún resultado y que conforme pasa el tiempo, reduce su posible retorno (ROI) y por tanto aumenta el riesgo. Reducir el trabajo en curso se hace más fácil relacionando las métricas de producto con las métricas de negocio de esta manera.

De esta manera, se justifica la necesidad de introducir técnicas de Continuous Delivery o DevOps en los equipos de desarrollo, o incluso de refactorizar la base de código para facilitar entregas más frecuentes.

Average Customer Lead Time

Si trazamos una línea horizontal en el diagrama de flujo acumulado, obtenemos el tiempo medio de entrega al cliente para el conjunto de nuestro Product Backlog. A pesar de ser un concepto de Scrum, también se puede utilizar en Kanban u otros métodos.

El tiempo medio de entrega al cliente nos dice cuanto pasa, de media, desde que ponemos algo en el backlog hasta que esto está entregado. Es un concepto macro. Puede que haya elementos del backlog que normalmente tarden mucho menos o mucho más.

Si un equipo no se siente identificado con un customer lead time muy alto ya que normalmente tardan poco en completar los ítems, hay que observar varios factores.

El primero es si la definition of done de ese equipo permite realmente poner el software en producción. Que una tarea esté hecha por el equipo y tenga que esperar un proceso de puesta en producción hace que su ROI descienda con el tiempo.

El segundo puede ser que el Product Backlog se haya convertido en la “carta a los reyes magos”. Eso hace que las posibles ideas junto con el análisis de su beneficio vayan perdiendo sentido con el tiempo y que el Product Owner no esté trabajando lo suficiente para mantener un backlog que aporte valor al negocio.

Cycle time

Si trazamos la diagonal entre el WIP y el Customer Lead Team, obtenemos el tiempo de ciclo. Esto es, el tiempo que el equipo pasa trabajando en la tarea hasta que esta está entregada. Esto no es el tiempo real que un desarrollador tarda en realizar la tarea, sino el total desde que se empezó hasta que se dio por terminada.

Se puede ver la relación obvia entre estas tres métricas. Reducir el WIP afecta al customer lead time y al cycle time. Para reducir el Cycle Time no nos queda más remedio que reducir el Customer Lead Time.

La ley de little

En realidad, todo esto tiene un nombre: la ley de Little. Este señor demostró la relación entre el número medio de clientes en una tienda, su frecuencia de llegada y el tiempo medio que pasaban en la tienda. A pesar de sonar bastante inofensivo, es la base de Kanban.

Por otro lado, aunque usemos Scrum, podemos tratarlo como un sistema Kanban, dado que tenemos acceso a el diagrama de flujo acumulado del cual podemos extraer las métricas. En otro artículo hablaré de cómo hacerlo con números.

Así, si una organización quiere aumentar la agilidad ofreciendo software en ciclos más cortos, no tiene más remedio que invertir en mejorar las herramientas que favorecen que el software se ponga en producción, esto es, operaciones y desarrollo. Aquí entra en juego el factor humano. No se puede simplemente añadir más miembros a un equipos, sino que requiere tener en cuenta otro triángulo de hierro: El de infraestructura/arquitectura, producto y personas. En el próximo de la serie, hablaremos de métricas micro.