¡DEJA DE EMPEZAR,

EMPIEZA A TERMINAR!
POR ARNE ROOCK
¡Contenido
Justin el Héroe!
Problemas de
inspiración
Sobrecarga de
visualización de
capacidad limitada
Límites WIP
Reducir el trabajo
Dejar de hacer
cosas La calidad de
la ley de Little's
Sistema de
tirar
Predictibilida
d
Retroalimenta
ción
Utilización
Holgazán
Veteranos
Sarampión
Más
información
Demasiados
proyectos en
cartera Kanban
terminan
Termine la lectura
recomendada
¡JUSTIN EL

¿Puedo presentarte a Justin? Justin es un héroe. ¡Salvó todo un proyecto! Y

haciendo cosas muy simples. Pero empecemos por el principio...
PROBLEM

Justin trabaja como director de proyectos. Hace un año estaba dirigiendo un

importante proyecto de software. Su equipo se enfrentaba a algunos
problemas serios: Su plan corría el riesgo de fracasar porque no podían
cumplir con sus plazos. Justin trató de obligar a la gente a trabajar horas
extras, e incluso les ofreció bonos para que trabajaran más eficientemente.
¡Esto tuvo un efecto increíblemente pequeño!
INSPIRACIÓN

Un día Justin estaba imprimiendo un nuevo plan de proyecto porque el viejo

ya no era realmente útil. Para ser honesto, lo hacía bastante a menudo.
Mientras miraba a la impresora, la inspiración lo golpeó. La impresora
terminaba una hoja de papel tras otra y cargaba nuevas hojas
continuamente. Este fue un proceso agradable y suave, las nuevas hojas se
introducían por un lado y las impresiones completas se entregaban por el
otro. "Esto parece un flujo", pensó. Por supuesto que Justin quería que sus
impresiones fueran más rápidas, pero estaba totalmente claro para él que
la impresora sólo tenía una capacidad de impresión limitada, y que sería
absolutamente inútil atiborrar más y más papel en ella. ¿Imprimiría más
rápido? No! Tal presión conduciría sin duda a la calidad opuesta -pobre- y
tarde o temprano habría un atasco de papel!
CAPACIDAD

Nadie intentaría nunca esto con una impresora. Pero era exactamente lo
que Justin hacía en su proyecto todos los días: Atiborró nuevas tareas en su
equipo y los instó a ir más rápido. ¿Pero no es obvio que no sólo las
impresoras tienen una capacidad limitada, sino también los equipos de
desarrollo? En términos generales, se podría decir que todo tipo de trabajo
de conocimiento -desarrollo de software, marketing, dirigir un bufete de
abogados o una editorial, etc.- podría ser visto como un sistema con
capacidad limitada, o mejor dicho, con capacidad. Si introducimos
demasiado trabajo en el sistema, se sobrecargará, lo que conlleva una
menor eficiencia y una mala calidad. Ahora estaba totalmente claro para
Justin lo que necesitaba hacer: Identificar la capacidad del sistema y
asegurarse de que nunca se superaría.
VISUALIZACIÓN

¿Pero cómo se podría identificar la capacidad de un sistema para el

trabajo del conocimiento? En la manufactura esto es fácil: Si trabajas por
encima de tu capacidad, se acumularían muchas cosas, lo cual es fácil de
detectar. En el trabajo de conocimiento, sin embargo, estamos tratando con
tareas mayormente abstractas. Normalmente no podemos verlas, y por lo
tanto es difícil detectar la sobrecarga. Así que el primer paso tenía que ser
visualizar el flujo de trabajo y las tareas que el equipo de Justin necesitaba
realizar. Justin sabía cómo se podía hacer esto porque ya lo había visto en
otros equipos de su organización.
Pidió una enorme pizarra blanca y la pegó a la pared de la sala de
equipo. Cada paso del proceso que estaban usando (como el análisis, el
desarrollo o las pruebas) se visualizaba como una columna separada. Cada
característica en la que el equipo estaba trabajando se convirtió en una
nota adhesiva que se colocó en su respectiva columna en la pizarra.
Pusieron todas las características que no habían empezado todavía en la
columna de la izquierda. Etiquetaron esa columna como "Por hacer". La
columna del extremo derecho se llamaba "Hecho". Todos los boletos
terminaron allí.
SOBRECAR

El equipo de Justin sabía que tenían mucho trabajo que hacer, ¡pero lo que
vieron ahora fue aterrador! ¡El tablero estaba completamente
sobrecargado de boletos!
Lo bueno es que ahora tenían una imagen realista del estado de su
proyecto en una junta de Kanban. ¡Esto parecía mucho mejor que la lista de
deseos que solían llamar un diagrama de Gantt!
LÍMITES

Entonces Justin preguntó a los analistas, desarrolladores y probadores,

"¿Cuántas tareas puedes manejar al mismo tiempo?" Los analistas
dijeron que tres, los desarrolladores cinco, los probadores dos. Estos
números fueron escritos sobre los encabezados de las columnas. Además,
definieron una regla simple: En ningún momento debe haber más entradas
en una columna que el número en la parte superior de la misma. Al hacer
esto, limitaban su WIP, que significa Work in Progress.
Acordaron un límite general de WIP de diez para todo su sistema, lo que
significa que no podían trabajar en más de diez tareas a la vez. ¿Significaba
esto que su capacidad era exactamente diez? Definitivamente no, porque
simplemente habían adivinado estos números. Aún así, su nuevo sistema era
mucho mejor que todo lo demás que se les había ocurrido antes. Entonces
decidieron reunirse regularmente para reflexionar sobre los límites del
WIP y ajustarlos si era necesario.
REDUCIENDO EL

Pero ahora surgió un nuevo problema: Tenían muchos más boletos en

progreso de los que sus límites de WIP permitían. El equipo discutió dos
opciones para resolver este problema: La "manera difícil" habría sido
detener las tareas y reasignarlas a la columna "Por hacer". Pero decidieron
tomar otro camino, que parecía ser más suave, y por lo tanto más
apropiado para su situación. Mantuvieron todas las tareas iniciadas en el
sistema sabiendo que estaban excediendo su capacidad.
Se definió una política que decía: "No empezamos a trabajar en
nuevas tareas antes de cumplir con nuestros límites". Esta política fue
escrita en un rotafolio y pegada en la pared junto a su tablero Kanban.
PARE DE

Esta política tuvo un gran impacto en el equipo: Se concentraron en

terminar las tareas existentes y no comenzaron nuevos trabajos tan a
menudo como lo habían hecho antes. Para coordinar su trabajo, se
reunieron frente a la junta directiva todos los días. Durante estas reuniones
de pie, caminaban por la pizarra de derecha a izquierda, enfocándose en
una tarjeta tras otra y preguntando: "¿Qué podemos hacer para terminar
este boleto?" En Internet, Justin había leído una vez el eslogan de Kanban:
"¡Deja de empezar, empieza a terminar!"
Este eslogan estaba escrito sobre el tablero en letras grandes.
HACIENDO COSAS

Poco a poco el equipo se las arregló para terminar más y más boletos y así
el tablero se fue vaciando cada vez más. Después de un par de días habían
terminado suficientes tareas para despejar el desbordamiento, y todos los
límites fueron respetados. Estaba claro que se beneficiaban de esta nueva
forma de trabajo. La ventaja más obvia era que terminaban las tareas
mucho más rápido de lo que lo habían hecho antes. Al principio Justin
pensó que la única razón para esto era que habían reducido la multitarea.
Había menos cambio de tareas, y por lo tanto menos carga mental por
envolver sus cabezas alrededor de las mismas tareas una y otra vez.
LEY DEL

Pero hubo otra cosa muy interesante que Justin encontró: Existe esta
fórmula, llamada la Ley de Little. De acuerdo con la Ley de Little, el tiempo
promedio de entrega de las tareas se calcula como la relación entre el
promedio de trabajo en progreso y el rendimiento promedio. El trabajo en
progreso es el trabajo que se comienza pero no se termina. Si se quiere
acortar el tiempo de entrega, hay dos opciones: Una forma es aumentar el
rendimiento. Esto es exactamente lo que Justin ha tratado de lograr una y
otra vez durante los últimos años, comprando mejores herramientas,
forzando las horas extras y gritando a los empleados, ¡todo ello con poco
éxito! Reducir el trabajo en curso, por otro lado, era bastante simple y tenía
un gran impacto!
CALIDAD

El segundo efecto que observó Justin fue la mejora de la calidad como

resultado de ciclos de retroalimentación más cortos y menos multitarea. En
el libro Brain Rules de John Medina, Justin había leído que cuando se
procesan varias tareas al mismo tiempo no sólo se necesita un 50% más de
tiempo para completar una tarea, sino que peor aún, ¡se cometen hasta un
50% más de errores!
SISTEMA DE

La tercera ventaja de establecer los límites del WIP fue que los miembros
del equipo experimentaron menos sobrecarga que antes y disfrutaron
trabajando de nuevo! Ahora había un límite explícito para el trabajo que se
suponía que debían hacer, y a nadie se le permitía introducir más y más
tareas en el sistema.
El mayor desafío para Justin era que tenía que contenerse y confiar en
que su equipo estaba haciendo lo mejor posible. Después de un tiempo no
hubo más dudas: Se pusieron a trabajar una y otra vez, ¡y estaban
trabajando mejor que nunca!
PREDICTABILID

Más tarde, Justin descubrió otra ventaja: la previsibilidad. En su sistema

de WIP-limitado, la cantidad de trabajo se mantuvo más o menos
constante todo el tiempo. Era mucho más fácil predecir cuando un solo
ticket sería
terminado, lo que le ayudó a establecer Acuerdos de Nivel de Servicio para
futuros proyectos con sus interesados, así como la liberación ligera pero útil
planificación. Por supuesto que Justin sabía que no existe la predicción al 100%,
al menos no en el trabajo de conocimiento.
FEEDBACK

Había incluso una ventaja más, una que se hizo más y más importante para
Justin con el tiempo. Con plazos de entrega más cortos, el equipo recibió
una retroalimentación más rápida para su trabajo. Ahora reconocían antes
si habían desarrollado un sistema por el que sus clientes estuvieran
dispuestos a pagar, si habían hecho las suposiciones correctas y dónde se
habían equivocado. En resumen, ahora podían aprender más rápidamente y
con mayor frecuencia, y podían utilizar esta información para su trabajo
en curso.
UTILIZACIÓN

¡Pero algo tenía que estar mal aquí! Claro, todo iba bastante bien, pero la
utilización de su personal se redujo drásticamente! Debido a los límites de
la WIP, el trabajo se estaba estancando. Comenzó en un cierto punto y
eventualmente afectó a todo el sistema. Parecía que tarde o temprano los
miembros del equipo no podrían continuar trabajando debido a los límites
del WIP! Este
fue un desastre. Como todo el mundo, Justin había aprendido que la
utilización es el criterio más importante para la optimización!
SLACK

Justin lo pensó bien. Los tiempos de entrega de sus tareas se habían

acortado, y el rendimiento de su sistema era mayor que nunca. Entonces,
¿realmente importaba que la gente fuera utilizada en su totalidad? En
realidad, ¡le gustaba esto! El sistema funcionaba mejor que antes, y el
equipo ya no estaba sobrecargado. Entonces, ¿por qué debería molestarle
esto? "Es mejor que la gente espere para trabajar que al revés", pensó.
Pero era incluso mejor que eso! Los miembros del equipo utilizaron su
tiempo libre para ayudar a sus colegas y para pensar en mejoras generales
del sistema. Un resultado de esto fue el desarrollo de las primeras pruebas
de aceptación automatizadas. Ahora Justin entendió lo que David Anderson
quiso decir al decir, "¡La holgura es el arma definitiva!"
VETERAN

Todo seguía yendo bien, pero después de un tiempo se hizo evidente que la
situación no había cambiado significativamente para algunos miembros del
equipo. Para algunos, la carga de trabajo no había disminuido realmente.
Había dos tipos que habían trabajado para esta compañía durante años y
que conocían el sistema muy bien. Otros miembros del equipo se acercaban
a ellos todo el tiempo para preguntarles sobre el código, la arquitectura y
otras cosas. Justin programó un taller para poder ver más de cerca el
problema. El resultado fue que el equipo decidió introducir otro tipo de
limitación: los límites personales. Se hicieron pequeños avatares para
representar a los dos "veteranos del proyecto", que luego fueron adjuntados
a los tickets en los que trabajaban. Debido a que sólo había tres avatares
por persona, los veteranos no podían trabajar en más de tres entradas a la
vez.
Antes de poder empezar un nuevo boleto, necesitaban terminar uno viejo primero.
MEDIDAS

Cuando alguien necesitaba la ayuda de un veterano cuando todos sus

avatares fueron tomados, tenían que esperar. Estos boletos estaban
marcados con signos de exclamación rojos. El gran número de signos de
exclamación rojos en la pizarra dejaba dolorosamente claro que tenían un
verdadero problema aquí: ¡Uno de cada tres boletos estaba bloqueado! El
equipo dijo, "¡Nuestra junta tiene el sarampión!" Una vez que vieron el
problema, se sintieron presionados a buscar una solución. Decidieron
establecer una nueva política: No se permitiría a los veteranos trabajar
solos en ninguna tarea. En su lugar, trabajarían en pareja con los novatos
hasta que su experiencia se hubiera extendido a todo el equipo. Justin
observó que había mucha más colaboración entre especialidades que nunca
antes!
MÁS

Cuanto más exploraba Justin los límites del WIP, más aprendía. Por
ejemplo, un colega de otra unidad de negocios le contó sobre la
implementación de Scrum. Durante la planificación del sprint, el equipo
decide cuántos artículos sacará del stock de productos para el próximo
sprint. Nadie está autorizado a empujar más artículos en el sprint. Justin se
dio cuenta de que este era otro tipo de límite de WIP. Aquí, el sprint
protegido y con cronómetro funciona como un mecanismo de limitación, así
que evita que los equipos se sobrecarguen. Justin pensó, "¿Por qué no sería
posible combinar este concepto con otros tipos de límites WIP?" Decidió
probar esto en un proyecto futuro.
DEMASIADOS

Las cosas continuaron mejorando para su equipo, y estaban en camino de

convertirse en una cultura Kaizen, una cultura de mejora continua. Pero
Justin quería más. Le parecía que su organización estaba trabajando en
demasiados proyectos al mismo tiempo, lo que estaba creando los mismos
efectos de sobrecarga que había observado en su equipo, pero a un nivel
más alto. ¿Qué tal si se implementa un sistema similar, y se limita el WIP a
nivel de cartera?
La principal diferencia sería que las entradas representarían proyectos
enteros en lugar de características. Habló con algunos jefes de producto
sobre sus ideas y acordaron intentarlo.
CARTERA KANBAN

Por supuesto, su nueva junta de portafolio se veía diferente. Las columnas se

llamaban Idea, Visión, Envisionamiento, Desarrollo y Vivo. Los boletos
estaban codificados por color, para que cada departamento tuviera su
propio color. Ahora todo el mundo podía ver de un vistazo cuánta capacidad
estaba gastando la organización en cada producto. Justin pensó que esta
junta también necesitaría límites de columnas, y ya tenía algunas ideas al
respecto. Pero los gerentes de producto no querían este tipo de limitación
por cualquier razón. Así que, había una necesidad de otro tipo de limitación.
Los gerentes de producto se reunían una vez a la semana y hablaban de la
junta y de las entradas. Justin facilitó estas reuniones. Cada vez que alguien
quería comenzar un nuevo proyecto, Justin preguntaba: "¿Tenemos la
capacidad extra para hacer esto ahora?" Y, si no, "¿Cuál de los proyectos ya
en marcha queremos detener para iniciar uno nuevo?" Estas preguntas
llevaron a discusiones interesantes y fructíferas.
Justin sintió que ahora tomaban mejores decisiones y que habían mejorado
la colaboración a través de las fronteras de los departamentos. Así que lo
que realmente estaban implementando era una limitación del WIP basada en
la discusión.
WRAP UP
¿Por qué deberíamos limitar nuestro trabajo en

progreso?
WRAP UP
¿Cómo podemos limitar nuestro trabajo en curso?
LECTURA RECOMENDADA

El cerebro manda: 12 principios para sobrevivir y prosperar en el trabajo,

el hogar y la escuela
Por John Medina

Kanban: Exitoso cambio evolutivo para su negocio de tecnología

Por David J. Anderson

Reabastecimiento: Un Kanban sencillo

Por Markus Andrezak y Arne Roock (www.kanban-kata.com)

Los principios del flujo de desarrollo de productos: segunda generación de

desarrollo de productos magros
Por Donald G. Reinertsen

www.limitedwipsociety.org
www.leankanbanuniversity.com
www.kanban-kata.com
www.it-agile.de/kanban
IMPRESIÓN:
Universidad Lean-Kanban
Copyright © 2012 it-agile GmbH
Texto: Arne Roock
Obras de arte: Claudia Leschik
Diseño: Jasna Wittmann/Vicki Rowland
Primeras ediciones digitales de
EE.UU. 2012 Kindle ISBN: 978-0-
9853051-7-8
ePub ISBN: 978-0-9853051-8-5
www.it-agile.de/kanban (Alemania)
www.leankanbanuniversity.com