KANBAN, el origen: The Goal (Theory of Constraint)

¿Por qué podría interesarle a un ingeniero de software leer una "novela" sobre organización industrial? Bueno, si estás interesado en la aplicación del método Kanban en el proceso de desarrollo de software es muy posible que te interese leer The Goal: A Process of Ongoing Improvement  (Theory of Constraint) de E. Goldratt [1] puesto que fue la Teoría de Restricciones la que llevó a David J. Anderson a aplicar una primera aproximación de Kanban en un equipo de desarrollo en Microsoft. De hecho, en From Worst to Best in 9 Months: Implementing a Drum-Buffer-Rope Solution in Microsoft’s IT Department no encontrarás ninguna referencia a Kanban puesto que se trata de la aplicación de Theory of Constraints (TOC). Después de esta publicación, Donald Reinertsen hizo ver a Anderson que su adaptación de TOC se ajustaba al método Kanban por lo que Anderson continuó utilizando Kanban en lugar de TOC, entre otras razones porque es un método asociado a la filosofía Lean (más de moda en estos momento). En cualquier caso, ambos métodos tienen muchos puntos de unión y una visión común: la mejora continua o Kaizen (que lo llaman los japoneses).

Alguna razón para "invertir" el tiempo en su lectura:

• El libro fue editado en 1984 por lo que está a punto de cumplir 30 años. Si pasado tanto tiempo continúa editándose y se ha aplicado en empresas de la talla de General Motors o Microsoft... algo debe tener.
• Trata muy diversos e interesantes temas como las competencias de un buen gestor, la influencia de la presión profesional en la vida personal , las relaciones laborales, gestión del cambio, innovación, el método Socrático... y por supuesto mucho de Teoría de Restricciones... Hmmm, de software lo único que menciona es su incapacidad para localizar los cuellos de botella...
• Si tienes algún interés profesional o vocacional en la formación o divulgación de conocimiento The Goal  es todo un ejemplo de didáctica. Es capaz de introducirte, por ejemplo, en la relación que tienen los eventos dependientes y las fluctuaciones estadísticas en el rendimiento de una planta industrial, de tal forma que te acaba por resultar hasta interesante. La combinación del método Socrático con el formato novela es la clave para conseguir que aquellos que no estamos interesados en la reorganización industrial nos resulte interesante el libro y encontremos nuevas formas de aplicación de sus principios...es una buena forma de transferir conocimientos y de hecho me recuerda por un lado los Cibercuentos de @jgarzas, (este es un ejemplo), y el prólogo que escribe @jmbeas en Deseño Ágil con TDD de Carlos Blé. Es curioso que la gente que probablemente tiene más que decir es capaz de simplificarlo de forma que todo el mundo lo entienda.

Ahora bien, como el tiempo es escaso y los recursos de lectura prácticamente ilimitados te diría que yo no leería el libro:

• Si lo que te interesa es conocer por encima qué hay detrás de alguna palabra de moda como Lean o Kanban. Para eso te aconsejo "googlear" un poco. Existen suficientes recursos Online en castellano como para hacerte una idea. 
• Si quieres profundizar un poco más y te estás planteando si esta u otra práctica puede resultarte interesante...te aconsejo que te hagas con un ejemplar de Gestión Ágil de Proyectos Software [2]. Aquí encontrarás toda esta información procesada y ordenada. Es un buen punto de partida si tu equipo/departamento necesita un cambio pero todavía no estás seguro del camino a seguir. 
• Si te estás planteando la aplicación de Kanban al desarrollo de software te aconsejo que primero leas [3] y [4] y luego, si te interesa, profundices en The Goal. 
• Si nada de lo anterior te interesa deja aquí este post (es algo extenso) y salta a otra lectura que seguro las encontrarás más interesantes...

Estas son algunas de las reflexiones que te puedo dejar de su lectura:

• La importancia de las métricas. El libro continuamente refleja la necesidad de tomar medidas a lo largo de toda la cadena productiva, tanto en tiempos de procesado como en calidad del producto; hay que tener en cuenta que sin una referencia clara de "donde estamos" en muy difícil decidir si aplicando determinadas medidas mejoramos. Las métricas no les gusta a nadie (tampoco en el entorno industrial) pero son imprescindibles. En el mundo del software me temo que acostumbramos a situarnos en uno de los extremos: Un gran número de proyectos no mide ni el rendimiento del proceso ni la calidad del producto, pero cuando nos planteamos la necesidad de las métricas, dado que tenemos una gran facilidad para generar/manejar datos (es lo nuestro, claro) nos solemos pasar de largo y empezamos a medir a discreción. Si actualmente no utilizas ninguna métrica, deberías plantear unas pocas interesantes (en Kanban las básicas son LeadTime y CycleTime)... el ratio de errores, el acoplamiento de clases, la complejidad ciclomática, la profundidad de herencia, las adecuación a normas de programación, están muy bien, pero deberías introducirlas poco a poco...y sobre todo después de plantearte por qué tiene importancia determinada métrica en el contexto de un proyecto concreto.
• Debe de existir más de una docena de referencias al sentido común en el libro, para acabar concluyendo que "el sentido común no es tan común"... Y lo cierto es que The Goal basa la mayor parte de su plan de mejora en tomar decisiones de "sentido común" a simple vista nada excepcionales. Por otra parte, como finalmente acabó recalcando Anderson en [3] no se necesita de mentes prodigiosas ni de disponer de los mejores técnicos del mundo (que no digo yo que esté mal...en cualquier caso no te costará encontrarlos, el 80% de la gente se considera más inteligente que la media...), sino que la mayor parte de las mejoras introducidas es fruto de aplicar medidas de sentido común que habitualmente no se aprecian porque chocan con la cultura preestablecida, por lo que al sentido común yo añadiría valentía para cambiar la forma habitual de hacer las cosas.
• Respecto a la innovación y el rechazo al cambio muestra la dificultad que presentan determinadas organizaciones para introducir un cambio de pensamiento incluso en situaciones críticas como la descrita en The Goal. La novela trata este rechazo al cambio dejando patente que es capaz incluso de llevar a la quiebra a una empresa. De hecho, el "no tener nada que perder" es lo que en este caso finalmente impulsó el cambio. Si hubiera existido alguna posibilidad de salvar la situación con las normas preestablecidas probablemente no se habrían tomado las medidas que mejoraron el rendimiento de la planta de producción que finalmente salvó el resto de la división. Esta idea es el eje central de El Dilema de los Innovadores [5] donde puedes encontrar documentados casos concretos de agentes dominantes de un mercado que acaban desapareciendo ante su incapacidad de adaptación a determinadas innovaciones. Se detallan dos casos en sectores muy diferentes: las maquinarias de perforación con la aparición de los cilindros hidráulicos en sustitución de las poleas y las empresas tecnológicas de fabricación de dispositivos de almacenamiento (discos duros) con su necesidad continua de duplicación de capacidad. 
• En la cadena de producción la reducción del tamaño de los lotes repercute en una reducción del inventario en los buffers intermedios, disminuyendo, por tanto, el tiempo perdido en estos buffers a la espera de capacidad productiva, lo que deriva en una condensación del LeadTime (tiempo transcurrido desde la aceptación del pedido hasta la entrega). Lo anterior tiene un punto débil: implica "perder" más tiempo en configuración de la maquinaria... pero si estas máquinas no son cuellos de botella del proceso, el rendimiento global no se ve penalizado.  Ufff, complicado analizarlo en un párrafo... pero resumiendo mucho, la idea es que cuanto menores sean nuestros trabajos (tareas de desarrollo) menos tiempos de ingeniería (obviamente) y de espera a que alguien pueda hacerse cargo de ellos, por lo que el tiempo de ciclo disminuye.
  En líneas generales los trabajos en nuestros procesos de desarrollo consumen tiempo en:

• Actividades de ingeniería (análisis, diseño, construcción,...).
• Configuración del entorno.
• Tiempo de espera para iniciar el trabajo en una determinada actividad de ingeniería.
• Tiempo en espera de otras partes (en el caso de trabajos más grandes: temas o epopeyas).


Si los trabajos son muy grandes desperdiciaremos tiempo principalmente en los dos últimos puntos. 

El problema es que disminuyendo el tamaño aumentamos el tiempo de configuración (puesto que tendremos que preparar el entorno más veces). En el mundo industrial este tiempo se pierde configurando la maquinaria para que comience a trabajar con una pieza concreta pero en desarrollo de software se pierde en, por ejemplo, configuración del entorno y escenarios de pruebas... de aquí la  necesidad de automatización de las pruebas y del proceso de despliegue.

• Otro tema interesante es el tiempo "ocioso". The Goal muestra la dificultad de hacer entender a la dirección que el hecho de parar una maquinaria (y sus operarios) en intervalos concretos sea rentable a la empresa. El "sentido común" decía que para amortizarlas, esta máquinas debían trabajar al 100% de su capacidad. En realidad esto generaba inventario innecesario en los buffers intermedios ¿recuerdas el efecto en el tiempo de ciclo? Goldratt concluye que tener a maquinaria y personal parados bajo determinadas circunstancias resulta rentable...
  Hmmm, un poco duro de aplicar al mundo del software, ¿verdad? Pues bien, te recomiendo el artículo Scaling Agile @ Spotify donde explican cómo gestionan ellos estos "tiempos ociosos". Te lo resumo: todo el mundo dispone de un 10% de su tiempo para dedicarse a actividades que consideran interesantes pero no directamente asociadas a compromisos de sus proyectos. Generalmente suelen agrupar ese 10% y cada dos semanas disponen de un "hack day" (algo así como un "día de escaqueo en el trabajo"). Se podría argumentar que estos "hack days" no tienen el mismo objetivo que en The Goal, de hecho en la planta industrial pretendían eliminar inventario intermedio mientras que en Spotify buscan generar innovación, pero en ambos entornos resulta rentable que los recursos no trabajen siempre al 100%. La aproximación de Anderson (y la mía personal) es aprovechar los tiempos de bloqueos producidos por los WIP del tablero Kanban para generar estos espacios de innovación, de esta forma no existe tanta tensión cuando una persona del equipo no puede coger ningún trabajo puesto que puede dedicar ese tiempo a asuntos de interés general no asociados a proyectos concretos. Reconozco que me sigue gustando más la idea de los "hack day" pero... no todos trabajamos en Spotify...

Aquí lo dejo, pero ten en cuenta que está todo muy destilado, si te resulta interesante en The Goal encontrarás otros asuntos que por extensión no he querido tratar como el concepto de contabilidad de costes, la definición de trabajo finalizado, la inercia del proceso de mejora, la aplicación de TOC a actividades "no materiales" como la gestión, el flujo continuo y regular,...

Referencias:
[1] Goldratt, E. y Cox, J. (2012). THE GOAL: A Process of Ongoing Improvement (Third Revised Edition), North River Pr.
[2] Garzás, J., Salamanca, J.A., e Irrazábal, E. (2012). Gestión Ágil de Proyectos Software, Kybele Consulting.
[3] Anderson, David J., y Dumitriu, D. (2005). From Worst to Best in 9 Months: Implementing a Drum-Buffer-Rope Solution in Microsoft’s IT Department. Proceedings of the TOC-ICO World Conference, Barcelona.
[4] Anderson, David J. (2010) Kanban: Successful Evolutionary Change for Your Technology Business, Blue Hole Press.
[5] Christensen, C.M. (2000). El Dilema de los innovadores, Granica.