Kanban

En este post quiero empezar a hablar del uso de Kanban para soporte a producción. En entornos en los que se utiliza SCRUM para el desarrollo de productos, muchas veces hay aspectos del paradigma SCRUM que no son apropiados para resolver las necesidades de los equipos de operaciones o de infraestructuras.

Por ejemplo:

• Iteraciones: El concepto de iteración puede resultar no apropiado porque los equipos que dan soporte a producción necesitan tener tiempos de respuesta más rápidos (apaga fuegos).
  
• Equipos multidisciplinares vs. equipos especializados: Una de las bases de SCRUM, los equipos multidisciplinares (¿Quien no sueña con un desarrollador de esos a los que a veces se llama “renaissance developer”?), no puede ser aplicable en departamentos de operaciones o infraestructuras, con perfiles altamente especializados.
  

Y es en esos casos donde se puede utilizar Kanban. Pero… ¿qué es Kanban? ¿Cómo se compara con SCRUM? En este post daré las bases de Kanban, y en otros sucesivos me centraré en problemas más particulares y detalles de ponerlo en marcha.

Kanban se puede resumir de la siguiente forma:

• El flujo de trabajo debe ser visible: La famosa “pizarra” de SCRUM. O, en otras palabras, divide el flujo de trabajo en diversas etapas y muéstralas. En la siguiente ilustración he puesto un ejemplo de panel Kanban que utilicé en un proyecto:
  
  
  
  
  En este caso, los diferentes colores correspondían a tipos de tareas. No es necesario distinguir entre tipos de tarea, aunque a veces puede ser útil. También se pueden utilizar diversos tableros Kanban si se tienen diversos equipos, o bien un solo tablero para todos. Además, el diseño del tablero también se puede customizar: los estados de trabajo en vertical y diferentes proyectos / departamentos en horizontal, etc.
  
  
  ¿Qué tarea se escoge para pasar al siguiente estado? Por ejemplo, dentro de la lista de tareas que están pendientes, ¿cuál será la siguiente en la que se trabajará? Kanban no prescibe un método en particular. Se pueden realizar reuniones de priorización, o bien un método más fácil: La más antigua, por ejemplo. Esto es una diferencia con el Product Backlog con prioridades de SCRUM.
  
  
• Limita el Work in Progress: Este es el concepto fundamental. El equipo sólo puede trabajar en x elementos a la misma vez. Este número es más difícil de establecer correctamente de lo que parece a simple vista. En un principio, casi seguro que los equipos se equivocarán. Pero por la naturaleza de “prueba y error” de Kanban, el numero se irá modificando hasta que funcione.
  
  Es el número 4 del ejemplo gráfico anterior:
  
  
  
  
  
  Significa que el equipo, pase lo que pase, sólo puede trabajar en 4 elementos a la vez.
  
  En general:
  
  • Si el limite WIP es demasiado bajo, podemos tener a miembros del equipo de brazos cruzados. Esto es especialmente crítico si el tipo de tareas no son fácilmente compartidas (tipos de trabajo en los que poner a más personas trabajando en ellas sólo creará problemas).
    
  • Si el límite WIP es demasiado alto, baja el tiempo de respuesta. Nos acercamos a la forma de trabajar tradicional (estamos en mil cosas y no acabamos ninguna). No se sabe nunca cuando el negocio tendrá resolución y, además, no hay presión para solventar cuellos de botella porque el equipo se puede poner a trabajar en otra tarea sin problemas.
    
  
  
  A veces, encontrar el límite de WIP correcto llega a parecerse más a un arte que a una ciencia.
  En algunos casos, también se pueden poner límites en otras columnas. Por ejemplo, en “paso a producción”. Esto ayuda porque así evita que se acumulen elementos en cualquier estado.
  En general, las ventajas son que limitando el WIP tenemos una forma muy gráfica para detectar cuellos de botella y que conseguimos que el equipo se concentre en resolver el trabajo que tiene entre manos.
  
  
• Mide y optimiza el tiempo medio para completar un elemento: A esto se le llama “tiempo de ciclo”, en inglés “Lead time”. Es importantísimo porque el “Lead time” es la base de las expectativas de negocio y también se utilizará para ir adaptando el límite de WIP hasta llegar a un valor óptimo para cada equipo.
  
  
  
  
  Aunque ahora no me extenderé sobre el tema, es bastante lógico deducir que para que la métrica de “Lead time” tenga sentido, las tareas deben tener tamaños más o menos equivalentes. O, si no es así, tener una medida en “horas-hombre”, “puntos de historia”, etc. Las tareas se priorizan y se estiman en reuniones de planificación, que en el caso de Kanban se pueden establecer cuando sea más necesario.
  

Resumiendo, muchas veces se utiliza Kanban para el soporte a produción y SCRUM para el desarrollo. Ambos comparten principios comunes, lo que los hace perfectamente compatibles. Sobretodo, los dos están basados en la evaluación continua. El método de la prueba y el error. En este aspecto, SCRUM es más restrictivo que Kanban. En SCRUM, la reunión de retrospective es imprescindible y se realiza al final de una iteración. En Kanban, no hay limitaciones al respecto. Y cuando “insertamos” retrospectives de forma más o menos organizada en un método Kanban, estamos llegando a un sistema que se ha empezado a llamar “Scrumban”.

In this post I want to talk about using Kanban for production support. In environments where SCRUM is used for product development, often some aspects of the SCRUM paradigm are not appropriate to meet the needs of operations or infrastructure teams.

For example:

• Iterations: The concept of iteration may be inappropriate because the teams that give support to production need faster response times (a “firefighting” approach).
  
• Multidisciplinary teams vs. specialized teams: One of the foundations of SCRUM, to have multidisciplinary teams (who does not dream of a "renaissance developer", as sometimes multidisciplinary developers are called?) may not be applicable in operations or infrastructure departments, with highly specialized profiles.
  

And in those cases where SCRUM is not appropiate, we can use Kanban. But ... what is Kanban? How does it compare to SCRUM? In this post I will give the basis for Kanban, and in further ones I will focus on first-hand problems and details of how to put it to work.

Kanban can be summarized as follows:

• The workflow must be visible: This is similar to the famous SCRUM whiteboard. What this means is to divide the workflow in several stages and make them visible in a whiteboard or panel. I have created a graphic of a Kanban panel I used in a project:
  
  
  
  
  
  In this case, different colors corresponded to different types of tasks. It is not necessary to distinguish between task types; each case is different. You can also use various Kanban boards if you have different teams, or just a single board for all teams. You can also customise the board itself: different work stages in vertical and different projects / departments in horizontal, etc..
  
  What task is chosen to be moved to the next state? For example, in the list of pending tasks, which one will be next? Kanban does not prescibe a particular method. You can have prioritisation meetings, or chose an easier way: Take always the oldest task, for example. This is a difference with the SCRUM’s prioritised Product Backlog.
  
  
• Limit the Work in Progress: This is the fundamental concept. The team can only work on x items at once. This number is more difficult to establish correctly than it would seem at first. Initially, the teams will almost certainly be wrong when choosing a work limit. But by the "trial and error" law used in Kanban, the number will be adapted until we find a limit that works for the team.
  
  The WIP is the number 4 in this example:
  
  
  
  
  It means that the team, no matter what happens, can only work in 4 items at once.
  
  In general:
  
  • If the WIP limit is too low, we have members of the team doing nothing. This is especially important if the tasks are not easily shared.
    
  • If the WIP limit is too high, you end up with poor response times. We get closer to the traditional way of working (we are working in a thousand things at the same time and we are not geting anywhere). The business does not know when a problem will be fixed and there is no pressure to fix bottlenecks because the team can work in another task without problems.
    
  
  
  This is why, sometimes, choosing the right WIP limit is more an art than a science.
  Also, in some cases you can also set limits in other columns. For example, in "Release". This is helpful as it prevents the accumulation of elements in any state.
  In general, limiting WIP is a very good method to graphically detect bottlenecks.
  And limiting WIP, we got the team to concentrate on solving the job at hand.
  
  
• Measure and optimize the “Lead time”: The time to complete an item. It is very important because the "Lead time" is the basis for business expectations and also will be used to gradually adapt the WIP limit, up to an optimal value for each team.
  
  
  
  
  Although now I will not dwell on the subject, it is quite logical to deduce that for the metric of "Lead time" to make sense, the tasks should have roughly equivalent sizes. Or if not, we need to have them estimated in "man hours", "story points", etc.. The tasks are prioritized and estimated at planning meetings, which in the case of Kanban can be set when needed most.
  

In short, Kanban is often used for support as SCRUM is used for product development. Both share common principles, which makes them fully compatible. Above all, both are based on continuous assessment: the method of trial and error. In this regard, SCRUM is more restrictive than Kanban. In SCRUM, the retrospective meeting is required and is to be held at the end of an iteration. In Kanban, there are no constraints on the matter. And when we start having retrospectives in a organised way, sometimes scheduling them aligned with the SCRUM teams, we are getting close to what is started to be known as "Scrumban."