viernes, 20 de julio de 2012

Limitar el WIP, una buena idea, pero con matices y alternativas

El WIP (Work-in-Progress), es número de ítems de trabajo que en un momento están en una actividad del workflow representado en un tablero kanban. Las columnas de un tablero kanban son las actividades del workflow, y los ítems fluyen de izquierda a derecha pasando de una columna a otra. David J. Anderson en su libro Kanban (la K con mayúscula para referirse a su propuesta de método) destaca que hay que limitar el WIP, es decir, poner una cota máxima de ítems para las actividades (no necesariamente en todas). Esta idea de limitar el WIP parece natural como medida para que una columna no acumule demasiado trabajo y pueda perjudicar el flujo. 

Los indicadores para medir el flujo son el Lead Time, el tiempo (promedio) que un ítem tarda en ser procesado y recorrer el tablero kanban desde que fué introducido en él hasta llegar a DONE en su extremo derecho, y el Cycle Time, que es similar, pero contando como comienzo el momento en el cual el ítem es cogido desde el Backlog (que correspondería a la primera columna del tablero kanban), y el Throughput, el número de ítems terminados por unidad de tiempo. Lo deseable es mantener los valores de Lead Time y Cycle Time en su nivel mínimo, y aumentar todo lo posible el Throughtput. La monitorización del flujo se visualiza en un Cumulative Flow Diagram (CFD), una gráfica de áreas acumuladas que se construye con los contadores de ítems en cada actividad, día a día, ilustrando por áreas de colores la evolución de la cantidad de ítems en cada actividad. A continuación se muestra una gráfica CFD indicando los conceptos básicos para su interpretación.



El siguiente ejemplo muestra un período de 24 días y las contabilizaciones de ítems en cada una de las actividades del tablero kanban (indicadas según la leyenda del recuadro).
Si una columna empieza a acumular ítems (y probablemente a perjudicar el flujo) quedará en evidencia puesto que la correspondiente franja en la gráfica se irá ensanchando. Esto ocurrirá cuando el ritmo de entrada de ítems a la actividad exceda al ritmo de salida. La acción correctiva evidente es reducir el ritmo de entrada o aumentar el ritmo de salida (concentrando esfuerzo en la finalización de ítems en dicha actividad). Una acción preventiva sería limitar el WIP de una actividad que tienda a sufrir estas situaciones. Limitar el WIP está alineado con la idea de un "sistema pull", es decir, una cadena de producción donde desde una actividad previa no deberían pasarse ítems a la siguiente actividad, sino que quien esté encargado de trabajar en una actividad coja ítems terminados (DONE) desde la actividad previa.

Hasta aquí todo parece bastante claro e intuitivo. La mayoría de las herramientas que ofrecen soporte para un tablero kanban tienen funcionalidad asociada a limitar el WIP de las columnas. Dicho límite se puede definir para una columna y posteriormente se utiliza como una restricción para advertir cuando se podría superar o directamente impedir que se supere.  

A continuación mencionaré los "detalles" con los cuales nos hemos enfrentado intentando dar cabida a las ideas anteriores en el marco de nuestra metodología y herramienta TUNE-UP.
  • Considero que es más importante supervisar el WIP que tiene cada actividad del proceso en cada momento que el encontrar un límite para el WIP de las actividades. Llevamos años trabajando con un tablero kanban en nuestra herramienta (y aplicándola a proyectos de diverso tamaño y ámbito), el cual tiene una vista resumida en la cual se muestran los WIPs del momento en cada actividad, es decir, contadores de ítems en TO DO o DOING en cada actividad. Cualquier seguimiento del trabajo en curso comienza examinando dicho kanban resumido y de allí acceder al detalle de los ítems. Sin embargo, el determinar un límite para dicho WIP en muy pocas ocasiones nos ha surgido como una necesidad. Cuando se detecta cierta acumulación de trabajo en una actividad es obvio que no tiene sentido que la o las actividades previas mantengan un ritmo de trabajo que aumente dicha acumulación. Esta es la idea clave aportada por la Teoría de Restricciones de Goldratt, centrarse en mejorar la actividad que constituye la mayor limitación del sistema pues es ella la que impone el ritmo a todo el sistema. Entre las posibles acciones de mejora estaría el concentrar (momentáneamente) recursos en la actividad , probablemente cogiéndolos desde las actividades que no presentan acumulación (las cuales podrían incluso detenerse). Sólo en el caso que una actividad presente repetidamente está anomalía podría ser recomendable indagar más en su causa y aplicar otras medidas (como se comenta en el siguiente punto). Por otra parte, sobrepasar el límite de WIP no es el único factor a considerar, a veces actividades que tienen un WIP bajo pero son del inicio del workflow, deben hacerse prioritarias cuando sus ítem no son atendidos y van sufriendo cierta postergación (lo cual perjudicaría su Lead Time y Cycle Time). La siguiente imagen muestra el kanban de TUNE-UP Process, a la izquierda la vista resumida con los contadores de WIP en cada actividad y en cada sub-estado (TO DO, DOING o DONE), a la derecha la lista de  ítems en la celda seleccionada (en este caso los ítems de la actividad Diseño e Implementación en el estado TO DO). Nuestro kanban puede sintetizar el trabajo de todos los participantes, de todos los productos/servicios y de todas las versiones. En el ejemplo de la figura, se muestra un kanban filtrado para mostrar solo la información del producto TUNE-UP en su versión 1.3.6 y para todos los agentes participantes.


  • El propósito que hay detrás de la idea de limitar el WIP conlleva una actitud y atención hacia la mejora del flujo, es decir, remover los impedimentos o actitudes que no favorezcan dichos indicadores de flujo.  Importantes mejoras pueden detectarse observando la forma cómo se llevan a cabo las actividades para, por ejemplo: eliminar los desperdicios (waste), es decir, quitar de todo aquello que no sea imprescindible, o mejorar la productividad automatizando ciertas tareas, etc. Otra fuente para la degradación del rendimiento en una actividad se produce cuando quien la debe realizar interrumpe su trabajo por atender otras tareas. En foros he visto mencionada la "actitud pulpo", para referirse a un miembro del equipo que tiende a coger nuevos ítems trabajo sin terminar los que ya tiene. Esta actitud llevada a un extremo obviamente puede reducir el desempeño de dicha persona pues los cambios de un ítem a otro generan pérdidas de tiempo por cambio de contexto, es decir, estos cambios deberían ser los mínimos, ojalá sólo para pasar desde termino a comienzo de actividades, evitando interrupciones que mantengan actividades sin completar. Pero no todas las interrupciones son malas, aquellas propuestas por la Técnica Pomodoro repercuten positivamente en el desempeño. Lo importante es, que en lo posible, los miembros del equipo puedan dedicarse a una actividad hasta finalizarla (recomiendo leer "La magia de hacer una sola cosa a la vez").
  • La cantidad de ítems en una actividad no es determinante respecto a que siempre constituya una anomalía. Si tenemos,  por ejemplo, solo un miembro del equipo que realiza una cierta actividad y en ella tenemos en cierto momento muchos ítems, probablemente se trate de una situación anómala. Pero si, por ejemplo en el extremo opuesto, si una actividad puede realizarla cualquier miembro del equipo, el tener muchos ítems en ella puede que no represente un problema cuando se trata de trabajo en paralelo de muchos miembros. En el caso de equipos cuyos miembros NO tienen roles específicos y fijos será difícil establecer un límite preciso al WIP de una actividad. Por otra parte, no hay que olvidar que el tablero kanban se originó en un contexto de producción de bienes físicos, en el cual las cuando un ítem está en una actividad el esfuerzo asociado es bastante predecible y similar para todos los ítems del mismo tipo. Además, la demanda de ítems puede ser en muchos casos prevista de antemano. En contextos como el de desarrollo de software o el de atención de incidencias no se dan dichas características. Aún si clasificáramos los ítems en términos de correcciones de fallos, mejoras o nuevos requisitos, en cualquiera de dichas categorías podríamos tener mucha variabilidad en cuanto a esfuerzo requerido y también suele ser difícil anticipar la demanda. 
  • Según el punto anterior, para determinar algún límite parece más preciso considerar la capacidad del equipo en una actividad y el esfuerzo asociado a los ítems que llegan a la actividad, y no solo basarse en la mera contabilización de ellos, sin considerar sus particularidades. Sin embargo, en el método Kanban la estimación para los ítems es opcional. Además, el cálculo de la capacidad siempre está asociado a un rango temporal, por ejemplo "horas ideales de progamación por semana", pero el método Kanban no prescribe el uso de iteraciones (o Sprints), pues lo importante es el flujo continuo, aunque paradógicamente, para analizar el flujo se necesita estudiar su comportamiento entre fechas y también las tendencias de dicho comportamiento a lo largo del tiempo. 
  • Finalmente, si en el proceso puede existir retrabajo, es decir, que actividades aparentemente terminadas para un ítem tengan que volver a realizarse de forma total o parcial. El ejemplo más frecuente es cuando el en testeo se detecta un fallo en el ítem, que debe ser resuelto en programación (que previamente se había dado por finalizada para el ítem). Así, cuando al ítem se le tenga que aplicar de nuevo una actividad por la cual ya ha pasado ¿se le aplicaría también la restricción de no superar el límite de WIP en dicha actividad? Precisamente lo deseable en un caso de retrabajo es que en dicha actividad sea prioritario el completar los ítems que han sido devueltos. El ítem podría NO devolverse a la columna previa, pero esto restaría legibilidad al tablero aunque se añadan decoraciones al ítem. Lo más claro sería que el ítem esté en la actividad en la cual se está trabajando en él. Pero un ítem puede estar en más de una actividad a la vez ya sea porque se hace retrabajo mientras se mantiene en una actividad posterior o porque está en una actividad previa y se comienza a adelantar trabajo asociado a una actividad posterior.
Limitar el WIP es una idea interesante pero su implantación tiene matices y alternativas para sacarle provecho, eso sí, prescindiendo de una interpretación radical o purista de dicho concepto :-).

En TUNE-UP Process se ofrece funcionalidad para limitar el WIP de una actividad, tanto en su cola de entrada (la columna TO DO que tiene por defecto cada actividad) como en la actividad en sí misma (la columna DOING de la actividad). Además, respecto del efecto cuando se establece dicho límite, se puede configurar para cada actividad y columna (TO DO o DOING) que se impida superar el límite o que solo se advierta. Por otra parte, para analizar el flujo y detectar posibles anomalías tales como cuellos de botella, Tune-up ofrece tres Cumulative Flow Diagram con diversos filtros. Estas gráficas se generan automáticamente mediante la generación de snapshots diarias del tablero kanban. 



Patricio Letelier