Kanban en Accion

Por: Ernesto J.J.
Canquiz
Kanban en Acción
La labor de traducir este libro fue realizada por Ernesto Canquiz, bajo la ayuda exclusiva de la
herramienta Google Traductor tratando en la medida de lo posible de respetar el sentido de lo
expresado en el texto original. La motivación que lo impulsó a traducir esta obra, de manera
voluntaria, fue solo el deseo de compartir la información contenida en este documento con la
comunidad de habla hispana, desechando cualquier intención de comercialización que se pudiera
generar de la misma.
Kanban en Acción
MARCUS HAMMARBERG
JOAKIM SUNDÉN
Para obtener información en línea y ordenar este y otros libros de Manning, visite
www.manning.com. El editor ofrece descuentos en este libro cuando se lo ordena en cantidad.
Para obtener más información, póngase en contacto
Special Sales Department

Manning Publications Co.
20 Baldwin Road
PO Box 261
Shelter Island, NY 11964
Email: orders@manning.com
© 2014 por Manning Publications Co. Todos los derechos reservados.
Ninguna parte de esta publicación puede ser reproducida, almacenada en un sistema de

recuperación o transmitida, en cualquier forma o por medios electrónicos, mecánicos, fotocopia, u
otros, sin previa escritura permiso del editor.
Muchas de las designaciones utilizadas por fabricantes y vendedores para distinguir sus productos
son reclamados como marcas registradas. Donde esas designaciones aparecen en el libro, y
Publicaciones Manning tenía conocimiento de un reclamo de marca, las designaciones se han
impreso en mayúsculas iniciales o todas las tapas.
Reconociendo la importancia de preservar lo que se ha escrito, la política de Manning es tener

los libros que publicamos impresos en papel libre de ácido y hacemos todo lo posible para lograrlo.
Reconociendo también nuestra responsabilidad de conservar los recursos de nuestro planeta, los
libros de Manning son impreso en papel que es reciclado y procesado al menos en un 15 por ciento
sin cloro elemental.
Manning Publications Co. Editores de desarrollo: Beth Lexleigh, Cynthia Kane

20 Baldwin Road Editor de copia: Melinda Rankin
PO Box 261 Corrector de pruebas: Melinda Rankin
Shelter Island, NY 11964 Tipógrafo: Melinda Rankin
Diseñador de la portada: Melinda Rankin
ISBN: 9781617291050
Impreso en los Estados Unidos de América
1 2 3 4 5 6 7 8 9 10 – MAL – 19 18 17 16 15 14
contenidos breves
PARTE 1 APRENDIENDO KANBAN ...................................................... 1
1 ■ Equipo de Kanbaneros comienza 3
PARTE 2 ENTENDIENDO KANBAN ...................................................... 45
2 ■ Principios de Kanban 47
3 ■ Visualizando su trabajo 56
4 ■ Elementos de trabajo 70
5 ■ Trabajo en proceso 92
6 ■ Limitar el trabajo en proceso 109
7 ■ Gestión del flujo 130
PARTE 3 KANBAN AVANZADO. ............................................................ 165
8 ■ Clases de servicio 167

9 ■ Planificación y estimación 185
10 ■ Mejora del proceso 216
11 ■ Usar métricas para guiar las mejoras 237
12 ■ Peligros de Kanban 270
13 ■ Enseñanza de kanban a través de juegos 286
v
contenido
prólogo xiii
prefacio xvii
acerca de este libro xix
sobre los autores xxiii
sobre la ilustración de portada xxv
agradecimientos xxvi
PARTE 1 APRENDIENDO KANBAN .......................................... 1
1 Equipo Kanbaneros comienza 3

1.1 Introducciones 5
1.2 El tablero 8
1.3 Mapeo del flujo de trabajo 12
1.4 Elementos de trabajo 18
1.5 Pase los peniques 22
1.6 Trabajo en proceso 27
1.7 Agilizar los Elementos 35
1.8 Métricas 38
1.9 La despedida 41
1.10 Resumen 42
vii
viii CONTENIDO
PARTE 2 ENTENDIENDO KANBAN .............................. 45
2 Principios de Kanban 47
2.1 Los principios de Kanban 49
2.2 Comience de inmediato 53
2.3 Resumen 55
3 Visualizando su trabajo 56
3.1 Hacer políticas explícitas 58
Radiador de información 59
3.2 El tablero kanban 63
El tablero 63 ■ Asignando su flujo de trabajo a
el tablero 66
3.3 Colas 67
3.4 Resumen 69
4 Elementos de trabajo 70
41. Principios de diseño para crear tus tarjetas 72
Facilitar la toma de decisiones. 72 ■ Ayudar a los miembros del equipo a optimizar
resultados 73
4.2 Tarjetas de elementos de trabajo 75
Descripción del elemento de trabajo 75 ■ Avatares 78 ■ Plazos 79
ID de seguimiento 80 ■ Bloqueadores 81
4.3 Tipos de trabajo 83
4.4 Indicadores de progreso 85
4.5 Tamaño del elemento de trabajo 86
4.6 Recopilación de datos de flujo de trabajo
Recopilación de métricas de flujo de trabajo 87 ■ Recolectando emociones 89
4.7 Crear tus propias tarjetas de elementos de trabajo 90
4.8 Resumen 90
5 Trabajo en proceso (Work in Process) 92

5.1 Comprender el trabajo en proceso
¿Qué es el trabajo en proceso? 93 ■ ¿Qué es el trabajo en proceso para el
desarrollo de software? 96
CONTENIDO ix
5.2 Efectos de demasiado WIP 99

Cambio de contexto 99 ■ El retraso provoca trabajo adicional 101
Mayor riesgo 103 ■ Más gastos generales 104
Baja calidad 105 ■ Motivación disminuida 106
5.3 Resumen 107
6 Limitar el trabajo en proceso 109

6.1 La búsqueda de límites de WIP 110
Más bajo es mejor que más alto 110 ■ Personas inactivas o inactivas en el trabajo 111
Sin límites no es la respuesta 111
6.2 Principios para establecer límites 112
Deja de empezar, comienza a terminar 112 ■ Uno no es la
respuesta 113
6.3 Junta completa, enfoque de equipo completo 115
¡Tomar uno! ¡Toma dos! 115 ■ Ven juntos 116 ■ Desplázate
y dame 20 117 ■ Elige un número y baila 118
6.4 Limitación de WIP basado en columnas 119
Comience desde el cuello de botella 119 ■ Elija una columna que lo ayudará
a mejorar 120 ■ Una historia limitada, por favor 120 ■ Cómo visualizar los
límites de WIP 122
6.5 Limitación de WIP basado en personas 123
Formas comunes de limitar WIP por persona 123
6.6 Preguntas frecuentes 126
Elementos de trabajo o tareas: ¿qué está limitando? 126 ■ ¿Debería contar las colas contra
el límite de WIP? 127
6.7 Ejercicio: WIP es, WIP is realmente bueno 128
6.8 Resumen 128
7 Manejo de flujo 130

7.1 ¿Por qué fluir? 132
Eliminando desperdicios 132 ■ Los siete desechos del desarrollo de
software 133
7.2 Ayudando a que el trabajo fluya 134
Limitar el trabajo en proceso 134 ■ Reducir el tiempo de espera 135
Retirar bloqueadores 137 ■ Evitar retrabajos 140
Equipos multifuncionales 141 ■ SLA u objetivo de tiempo de entrega 143
x CONTENIDO
7.3 Standup diario 143

Buenas prácticas comunes alrededor de las standups 144 ■ Kanban
prácticas en torno a las standups diarias 146 ■ Aproveche al máximo su
standup 148 ■ Standups de escala 151
7.4 ¿Qué debo hacer a continuación? 154
7.5 Gestión de cuellos de botella 158
Teoría de las restricciones: una breve introducción
7.6 Resumen 163
PARTE 2 KANBAN AVANZADO .............................. 165
8 Clases de servicio 167

8.1 El caso urgente 168
8.2 ¿Qué es una clase de servicio? 170
Aspectos a considerar al crear una clase de servicio 170
Clases comunes de servicio 171 ■ Poner clases de servicios
en uso 177
8.3 Gestión de clases de servicios 181
8.4 Ejercicio: ¡clasifique esto! 184
8.5 Resumen 184
9 Planificación y estimación 185

9.1 Planificación de la programación: ¿cuándo debe planear? 187
Planificación justo a tiempo 188 Punto de pedido 189 ■ Filtro de
prioridad: visualizar lo que es importante 191 ■ Tiempos de espera de
Disneyland 194
9.2 Estimación del trabajo: relativamente hablando
Puntos de historia 197 ■ Talla de camiseta (T-shirt sizes) 199
9.3 Técnicas de estimación 201
Una línea de cartas 202 ■ Planificación Poker 203
Ricitos de Oro 206
9.4 Cadencia 208
9.5 Planificación del camino kanban: menos dolor, más ganancia 210
La necesidad disminuye 211 ■ Razonamiento lógico: la súplica del
cliente 212 ■ # NoEstimados: ¿podría prescindir por completo de esto? 213
9.6 Resumen 215
CONTENIDO xi
10 Mejora de procesos 216

10.1 Retrospectivas 218
¿Qué es una retrospectiva? 218 ■ ¿Cómo funciona? 219
10.2 Análisis de raíz de la causa 222
Cómo funciona 223
10.3 Kanba Kata 228
¿Qué es Kanban Kata? 229 ■ Qué pasó 234
¿Por qué funciona esto? 234
10.4 Resumen 236
11 Usando métricas para guiar las mejoras 237

11.1 Métrica común 238
Ciclo y plazos de entrega 238 ■ Rendimiento 243 ■ Problemas y
elementos de trabajo bloqueados 245 ■ Desempeño de fecha de vencimiento 247
Calidad 249 ■ Demanda de valor y demanda de falla 251
Ideas abandonadas y descartadas 252
11.2 Dos visualizaciones potentes 254
Control estadístico de procesos “Statistical Process Control” (SPC) 254
Diagrama de Flujo Acumulativo “Comulative Flow Diagram” (CFD) 260
11.3 Las métricas como guías de mejora
11.4 Ejercicio: ¡medítelo! 269
11.5 Resumen 269
12 Dificultades de Kanban 270

12.1 Todo el trabajo y nada de juego convierte a Jack en un chico aburrido 271
Creando cadencias para la celebración 274
12.2 Crear cadencias para la celebración 274
12.2 Timeboxing es bueno para usted 275
12.3 La revolución necesaria 279
12.4 No permita que Kanban se convierta en una excusa para ser flojo
12.5 Resumen 285
13 Enseñar kanban a través de juegos 286

13.1 Pase los peniques 288
Qué necesitas para jugar 288 ■ Cómo jugar 288
Preguntas para la discusión 290 ■ Conclusiones principales 291
Consejos y variantes 291
xii CONTENIDO
13.2 El Juego Multitarea de Números 291

Lo que necesitas para jugar 292 ■ Cómo jugar 292
Preguntas para debate 294 ■ Conclusiones principales 294
13.3 El juego de puntos 295
Primera iteración 297 ■ Segunda iteración 299 ■ Tercera (y
final) iteración 300 ■ Conclusiones principales 301
Consejos y variantes 302
13.4 El juego del cuello de botella 302
13.5 getKanban 304
Lo que necesitas para jugar 305 ■ Cómo es el juego
jugado 305 ■ Preguntas para discusión 306 ■ Consejos y
variantes 306 ■ Conclusiones principales 306
13.6 El juego de pizza Kanban 307
13.7 Resumen 309
apéndice A Lecturas recomendadas y otros recursos 311.

apéndice B Herramientas Kanban 316
índice 323
prefacio
Una gran parte de la capacidad de tu cerebro está dedicada a absorber, procesar, actuar sobre algo, y
almacenar información visual. Lo que vemos nos inspira a actuar ahora e infunde patrones para
acción futura. Si no tenemos nada que ver, tenemos poco en qué actuar.
Ver y entender
Los sistemas visuales como kanban obtienen su poder de nuestra preferencia por la información
visual. Eche un vistazo, por ejemplo, en el siguiente mapa simple. Ves el agua, los
edificios, las carreteras y una gran cantidad de información adicional. Usted reconoce esto de
inmediato. En un abrir y cerrar de ojos, comprende el contexto, la forma y la sustancia.
xiii
xiv PREFACIO
Aquí hay una lista de todo lo que me interesó escribir desde ese mapa. Esta es una lista parcial.
Y está en un tamaño de letra necesario para no llenar páginas con texto:
■ Centro marino de Salmon Bay
■ Canal de barco del lago Washington
■ W. Commodore Way
■ 20 th Ave W
■ Gilman Place W
■ W Elmore Street
■ 21 S t Ave W
■ Gilman Ave W
■ Shilshole Ave NW
■ W Fort Street
■ 26 th Ave W
■ 24 th Ave W
Puede ver rápidamente que las listas largas de cosas proporcionan menos contexto y toman más
tiempo para proceso que un mapa.
Nuestro objetivo con sistemas visuales como Kanban es construir un mapa de nuestro
trabajo. Queremos la forma y sustancia de nuestro trabajo. Queremos entender el sistema, de
inmediato e intuitivamente. Queremos que nuestro tablero kanban sea explícito sobre roles,
responsabilidades, trabajo en progreso, tasa de finalización, la estructura de nuestros procesos,
impedimentos y más.
Eso es mucha información.
Lo que hemos encontrado desde el lanzamiento de Kanban como una herramienta de diseño
de software hace casi una década, es esto:
Ver el trabajo y el proceso crea entendimiento.
Una vez que vemos nuestro trabajo, construimos una comprensión compartida de él. Entonces
podemos alejarnos con complicadas convenciones de procesos que han plagado el desarrollo de
software por años. El tablero kanban puede convertirse en un simple punto único que permite que
cualquiera pueda venir y entender el estado actual del proyecto.
¡Esto significa que los equipos de software finalmente pueden hablar el mismo idioma que el
negocio! La división entre ESO y el resto de la compañía puede disolverse. Un traductor ha llegado.
Ver es la mitad de la batalla

En este libro, Marcus y Joakim enumeran tres elementos de un proyecto usando kanban:
■ Visualizar
■ Limitar el trabajo en proceso
■ Administrar flujo
Me gusta esta lista
PREFACIO xv
Para Personal Kanban, usamos los dos primeros (visualice su trabajo y limite el trabajo en proceso)
y vea el tercero de forma natural. Pero me gusta la lista de tres porque lleva este punto al inicio:
El trabajo no encaja — fluye.
Imponer el trabajo en cantidades de tiempo arbitrarias tiene profundos impactos negativos en la tasa
de cumplimiento, defectos de escape y moral. El estrés de plazos innecesarios o conjuntos de
características demasiado entusiastas desaprueban tanto las personas como el producto. El enfoque
se convierte en hacer que el trabajo encaje en el período de tiempo límite, en lugar de completarlo
con calidad.
La finalización del trabajo con calidad solo es posible si el trabajo fluye a un ritmo
verdaderamente sostenible. Encontrar y mantener ese ritmo es posible solo si el WIP “work in
process” (trabajo activo en proceso) es menor que la capacidad de quienes hacen el trabajo. Abordar
cosas antes de las fechas límite casi siempre dará como resultado la interrupción del límite de su
WIP.
Demasiado WIP destruye el flujo

Con un límite de WIP razonable, alentamos el flujo de trabajo. Las tareas se completan de forma
mesurada con la mirada puesta en la calidad. Gastos generales de administrar demasiado WIP
desaparece. Y, como es lógico, la productividad se dispara.
Esta es la forma abreviada de lo que Marcus y Joakim te han dado en este libro.
Proporcionan detalles fantásticos y pacientes. Si este es tu entrada principal en Kanban, bienvenido.
No podrías haber consultado mejor guía.
JIM BENSON
AUTOR DEL 2013 SHINGO AWARD-WINNING
PERSONAL KANBAN
prefacio
El viaje de Marcus
Me presentaron el Agilismo a travéz de Scrum y comencé a usarlo, estilo guerrilla, en una gran
compañía de seguros en Suecia. En poco tiempo, se extendió; y en pocos años la compañía tenía
más de 50 equipos de Scrum. Pero todavía no se sentía bien, porque los procesos de trabajo de
muchos equipos no encajaban bien con la naturaleza arrítmica de Scrum.
Además, la mayoría de los equipos no abarcaron todo el proceso; los equipos consistieron en su
mayoría en desarrolladores que recibieron los requisitos y que luego entregaron a una fase de
prueba por separado. Sentí ganas de intentar incorporar más del proceso completo por el que pasó el
trabajo.
Este hormigueo me llevó a comenzar a investigar otras prácticas en la comunidad ágil. En poco
tiempo, y a través de algunos consejos útiles de Joakim, encontré y comencé a leer kanban. En 2010
y 2011, asistí a capacitaciones en kanban y kanban entrenado por David J. Anderson. Estos
confirmaron aún más mi sensación de que kanban y Lean eran lo que estaba buscando.
El viaje de Joakim
En 2008, fui consultor como Scrum Master en un proyecto de desarrollo de software de tres equipos
en el departamento de TI de una gran compañía sueca. Para profundizar mi comprensión del
desarrollo de software ágil, estaba leyendo sobre el desarrollo de software Lean, lo que me llevó a
la increíble historia de Toyota y a muchas literaturas sobre Lean thinking y el Toyota Way. El
estudio llegó a su clímax cuando realicé un viaje de estudios a Toyota HQ en Japón junto con Mary
y Tom Poppendieck, autores de libros de desarrollo de software Lean, en la primavera de 2009.
xvii
xviii PREFACIO
A fines de 2008, mi cliente llegó a la conclusión de que la mayoría, si no todos, los clientes que
pagan por el desarrollo de software finalmente reclaman—que las cosas se mueven demasiado
despacio. Querían que se desarrollara más rápido, pero sin reducir el alcance o la calidad. Inspirado
por el pensamiento Lean en torno al flujo contiguo de una pieza, sugerí que dejáramos de planear
lotes de trabajo en las reuniones de planificación de sprints de Scrum cada dos o tres semanas (una
cadencia que nos parecía cada vez más arbitraria) y en cambio tratar de enfocarnos en uno o unos
pocos elementos de trabajo y colaborativamente hacerlos lo más rápido posible, en un flujo
continuo de valor. Alrededor de una docena de miembros del equipo acordaron no tener más de dos
elementos de trabajo en desarrollo y dos en pruebas en cualquier momento, y que solo cuando algo
se terminaba, extraíamos nuevos elementos de la pila de productos para entonces planificarlos justo
al momento.
Pronto aprendí sobre algo llamado kanban que parecía similar a lo que estábamos haciendo, primero
a través del blog de Corey Ladas y luego a través del trabajo de David J. Anderson. En 2009, me
conecté con la comunidad a través de la primera conferencia Lean Kanban en el Reino Unido.
Inmediatamente me atrajo el enfoque pragmático de ver qué había funcionado realmente para
diferentes equipos y compañías en sus respectivos contextos, en un momento en que sentía que gran
parte del enfoque ágil de la comunidad estaba en los enfoques basados en la creencia de "¿Cómo
está Scrum diciéndonos cómo resolver esto?"
El siguiente año, participé en la primera tienda de entrenamiento de kanban de David J. Anderson

(ahora llamada Advanced Master Class) en Londres, junto con profesionales experimentados como
Rachel Davies, David P. Joyce y Martine Devos , entre otros. Fui cofundador de Stockholm Lean
Coffee en 2010, donde entusiastas de Kanban se han reunido todas las semanas desde entonces. En
2011, me invitaron a asistir al primer Retiro de Liderazgo Kanban organizado por David J.
Anderson, durante el cual me convertí en uno de los primeros capacitadores de kanban "David J.
Anderson aprobados".
El viaje común
Junto con nuestro colega del Grupo Avega en ese momento, Christophe Achouiantz, comenzamos a
desarrollar una introducción práctica a Kanban en 2010. Fue un éxito inmediato y el punto de
partida para una larga serie de conferencias tanto en Europa como en los EE. UU., Incluyendo
-entrenamientos de clientes, tutoriales y talleres, a veces realizados individualmente, a veces por los
dos juntos. El enfoque práctico de nuestro trabajo resonó bien con muchas personas que asistieron a
nuestras charlas y tutoriales, y recibimos muchos comentarios positivos.
Fue después de un tutorial de conferencia en JFokus (una gran conferencia organizada por Mattias
Karlsson, otro colega del Grupo Avega) que Marcus recibió una llamada de Manning Publications,
preguntándole si estaba interesado en escribir un libro. De inmediato sintió que debería hacerlo
junto con Joakim. Decidimos escribir el libro de la misma manera que la presentación que habíamos
creado, utilizando un enfoque práctico y un estilo desenfadado.
sobre este libro
¿Desea comprender mejor cómo funciona su trabajo y qué está sucediendo en su equipo o en su
lugar de trabajo? ¿Te beneficiarías de poder enfocarte en algunas cosas pequeñas en lugar de tener
que cambiar constantemente entre proyectos múltiples? ¿Sus usuarios y partes interesadas quieren
que se entreguen nuevas características ahora en lugar de otro día? ¿Crees que tú y tus compañeros
de trabajo necesitan seguir mejorando y aprendiendo?
Entonces kanban es para ti.
¿Desea comenzar con kanban lo antes posible, sin dedicar demasiado tiempo a la teoría
abstracta y la historia y separar los pelos sobre diferentes métodos? ¿Quieres saber cómo las
personas de la comunidad kanban han usado kanban en la práctica para enfrentar diferentes
desafíos?
Entonces este libro es para ti.
Este libro es una introducción a kanban, con los pies en la tierra, sin lujos, y que se puede
conocer. Se basa en mucha práctica, muchas observaciones y algunos rumores (!) De dos tipos que
han trabajado y han entrenado a docenas de equipos de kanban. También hemos hablado y enseñado
en conferencias y participado activamente en grupos de usuarios y en la comunidad kanban en los
últimos años.
En este libro, leerás acerca de técnicas simples pero poderosas para visualizar el trabajo:
cómo diseñar un tablero kanban, cómo rastrear el trabajo y su progreso, cómo visualizar colas y
almacenamientos intermedios, e incluso detalles tan esenciales como cómo los colores y otras
mejoras pueden ayudarlo a organizar y rastrear sus elementos de trabajo.
También obtendrás muchos consejos prácticos sobre cómo limitar tu trabajo en proceso a lo
largo del flujo de trabajo, por ejemplo, cómo establecer el límite de diferentes maneras según el
contexto y cómo entender cuándo y cómo cambiarlo.
XIX
xx SOBRE ESTE LIBRO
Con estas dos herramientas a mano, Kanban y este libro, estás listo para ponerte a trabajar y ayudar
a que tu trabajo fluya a través del sistema a medida que aprendes y mejoras tu proceso cada vez
más. Aprenderás sobre cosas como las clases de servicio, cómo se planifican y realizan las
estimaciones en kanbanland, sobre las colas y los buffers y cómo manejarlos, y—bueno, aprenderás
muchas cosas que necesitarás para ayudar a que. el equipo se vuelva un poco mejor todos los días.
Pero espera. hay mas. Aprenderás sobre las métricas y cómo usarlas para mejorar,
y presentaremos varios juegos y ejercicios que puedes utilizar para comprender los principios de
kanban y lograr que nuevas personas se unan a usted en el autobús kanban. Oye, incluso incluimos
una pequeña sección sobre los escollos de kanban y las críticas comunes, solo por si acaso.
Este es un libro práctico, y no pasaremos mucho tiempo en la teoría subyacente
o la historia detrás de Kanban. Ya hay excelentes libros sobre estos temas (pista: recoja algunos
libros sobre Lean, ágil y Toyota), y hacen un trabajo mucho mejor de lo que podríamos soñar. Pero
no te dejaremos en seco; se necesitará alguna teoría para hacer un buen uso de los consejos
prácticos que ofrecemos, y se lo proporcionaremos.
Pero este libro no es solo para principiantes. A juzgar por todas las preguntas que recibimos
sobre kanban, y de todas las bombillas que se encienden durante nuestras charlas orientadas a la
práctica y cursos de capacitación para personas que han estado trabajando con kanban durante algún
tiempo, así como para principiantes, obtendrás mucho de este libro, incluso si estás lejos de ser
nuevo en Kanban.
¡Comencemos y veamos algo de kanban en acción!
La estructura de este libro

Este libro está dividido en cuatro partes, cada una con un propósito diferente, con el objetivo de ser
su compañero mientras aprende kanban:
■ Parte 1, "Aprendiendo Kanban" - Esta es una introducción a Kanban en la forma de un
cuento. La idea es que puedas hojear rápidamente esta parte para tener una idea de lo que es
kanban y aprender lo suficiente para ponerlo en marcha, al igual que el equipo ficticio que
encontrarás en el capítulo 1. Después de esta introducción, tendrás todas las herramientas y
el conocimiento que necesitas para comenzar a usar kanban en la vida real: podrás comenzar
a aprender haciendo kanban. Si las historias no son lo tuyo, o si no te gusta nuestro estilo de
narración de historias, puedes omitir este capítulo y pasar directamente a la siguiente parte.
■ Parte 2, "Comprendiendo kanban": esta parte le brinda un conocimiento más profundo
sobre el por qué (los principios y las ideas detrás de Kanban) y el cómo (muchos consejos
prácticos sobre la aplicación de los principios en su contexto). Echaremos un vistazo más de
cerca a los principios básicos de kanban. Habrá muchas soluciones y variaciones
comúnmente usadas sobre estas, que las personas en la comunidad han aplicado en
diferentes contextos. Nuestras descripciones serán prácticas y les brindarán más
herramientas y consejos para continuar desarrollando sus conocimientos. El equipo del
capítulo 1 aparecerá de vez en cuando para hacer preguntas.
OBRE ESTE LIBRO xxi
■ Parte 3, "Kanban avanzado": OK, ya estás funcionando con su tablero, estás familiarizado
con el funcionamiento de los límites de WIP y estás centrado en ayudar a que el trabajo
fluya. ¿Ahora qué? En los capítulos 8-12, aprenderás cómo usar los principios de kanban
para administrar los riesgos, facilitar la autoorganización, planificar y mejorar. También
hemos incluido un capítulo sobre trampas comunes y cómo evitarlas. No dejes que el
"avanzado" te asuste: no es tan complicado, es solo que estas prácticas no son lo que
comienzas normalmente cuando eres nuevo en kanban.
■ Parte 4, "Enseñar kanban": si comienzas a usar kanban en tu organización, pronto
enseñarás kanban a otros. Hemos encontrado que es beneficioso hacer esto a través de
juegos y simulaciones, porque algunos de los principios parecen contradictorios al principio.
No afirmamos que saldrás de un maestro kanban al final de este libro, pero

será un buen compañero en tu viaje de aprendizaje. Combinado con la experiencia práctica que
obtendrás al probar cosas, esta será una gran combinación de aprendizaje.
Cómo leer este libro

Puedes elegir varias formas de leer este libro:
■ Si desea comenzar lo más rápido posible, dedique una hora a leer la parte 1 ("Aprender
kanban") e implemente algunas de las cosas que aprende de inmediato.
■ Cuando necesite inspiración o se quede atascado, explore la parte 2 ("Comprensión
kanban") y robe ideas o inspírese en cómo otros se han acercado a desafíos similares.
■ Si desea saber por qué las cosas son como están en kanban-land, lea la parte 2 y aprenda
de dónde viene kanban y los principios e ideas en los que se basa. Obtendrá una buena dosis
de consejos prácticos en el camino.
■ Si ya está usando kanban y siente curiosidad por el siguiente paso, eche un vistazo más de
cerca a los temas en la parte 3 ("Kanban avanzado"). Se asegurará de elegir algo nuevo que
se aplique a su situación.
■ Cuando las personas le piden que les enseñe kanban, encuentre juegos divertidos y
educativos en la parte 4 ("Enseñando kanban") para jugar con ellos, y cuénteles acerca de
sus hallazgos y experiencias. ¡Y luego obtén una copia de este libro!
También puede leer todo el libro de principio a fin. Esto te dará una forma gradual
una comprensión más profunda y más amplia de kanban. Creemos que la mejor experiencia de
aprendizaje vendrá al combinar los temas de este libro con la experiencia práctica.
Autor en línea
La compra de Kanban en Acción incluye acceso gratuito a un foro web privado administrado por
Manning Publications donde puede hacer comentarios sobre el libro, hacer preguntas técnicas y
recibir ayuda de los autores y de otros usuarios. Para acceder al foro y suscribirse, vaya a
www.manning.com/KanbaninAction. Esta página proporciona información sobre cómo ingresar al
foro una vez que está registrado, qué tipo de ayuda está disponible y las reglas de conducta en el
foro.
xxii SOBRE ESTE LIBRO
El compromiso de Manning con nuestros lectores es proporcionar un lugar donde pueda

tener lugar un diálogo significativo entre los lectores individuales y entre los lectores y los autores.
No es un compromiso con una cantidad específica de participación por parte de los autores, cuya
contribución al foro sigue siendo voluntaria (y no remunerada). ¡Le sugerimos que intente preguntar
a los autores algunas asuntos desafiantes para que no se desvíe su interés!
Se podrá acceder al foro de Author Online y a los archivos de debates anteriores desde el
sitio web del editor, siempre que el libro esté en impresión.
sobre los autores
Antes de emprender este viaje juntos, podría ser interesante que nos conozcas un poco. Aquí
estamos, claro y simple:
JOAKIM es un pensador, el cerebro de nuestro dúo dinámico. A

menudo deja que una persona hable durante bastante tiempo antes de decidir
qué decir, y luego responde con algo profundo que les hace pensar. Esto
molesta a algunas personas, porque generalmente solo quieren saber qué
"hacer". Tiene sólidos conocimientos teóricos en todas las áreas de Lean,
ágil y sobre el Sistema de Producción de Toyota. Y él tiene mucha
experiencia práctica para acompañarlo también.
En su tiempo libre, Joakim es aficionado a la comida y al cine, y citas de obscenas películas

dogmáticas danesas se cuelan en sus conversaciones de vez en cuando (para gran confusión de
quienes lo rodean).
Joakim tiene cuatro hijos (de cero a nueve años) y una esposa (Anna) y aún se las arregla para
participar en el progreso de la empresa para la que trabaja (Spotify) y las comunidades "Lean" y
ágiles en Suecia y en todo el mundo. Es un orador habitual en conferencias internacionales.
MARCUS es un hacedor y, por lo tanto, el músculo de la pareja, para

continuar con la metáfora del "dúo dinámico". Él prefiere intentar algo y
fracasar en lugar de pensar en hacerlo bien la primera vez. Esto lo lleva a
tener cosas una y otra vez, para su irritación y la diversión de los demás.
Marcus se ha acercado a las comunidades Lean y Kanban desde la
perspectiva de un desarrollador y tiene un gran interés en las prácticas que
hacen que estas ideas funcionen en la naturaleza: desarrollo basado en
pruebas, programación de pares, especificación por ejemplo y mapeo de
impacto, entre otros.
xxiii
xxiv SOBRE LOS AUTORES
Cuando tiene tiempo, puede encontrar blogs o en el Ejército de Salvación o leer las últimas noticias
de la banda. Intentar incorporar gran parte de eso en situaciones relacionadas con el trabajo es
difícil y bastante inútil, como probablemente te puedas imaginar.
Marcus está casado con Elin, y tienen tres hijos (5, 3 y 3 años de edad 1). Para cuando leas esto,
todos se habrán mudado a Indonesia, donde Marcus trabajará para el Ejército de Salvación. Dirigirá
el trabajo en una fundación, para los 6 hospitales del Ejército de Salvación y 13 clínicas en
Indonesia. Esto, por supuesto, se hará de una manera ágil, Lean, inspirándose y usando las técnicas
que se encuentran en este libro.
Marcus también enseñará instrumentos de viento a los jóvenes en los orfanatos del Ejército de
Salvación.
1
Si, los últimos dos son gemelos.
sobre la ilustración de portada
La figura en la portada de Kanban in Action es Tokugawa Ieyasu (1543 - 1616), el fundador y
primer shogun del Tokugawa Shogunate de Japón, que gobernó desde la Batalla de Sekighara en
1600 hasta la Restauración Meji en 1868. Un shogun fue el Líder militar en el Japón feudal, y
debido al poder concentrado en sus manos, él era el líder de facto de Japón, en lugar del jefe de
estado nominal, el mikado o emperador. Ieyasu tomó el poder en 1600, recibió nombramiento como
shogun en 1603, abdicó de su cargo en 1605, pero permaneció en el poder hasta su muerte en 1616.
Afirmó haber participado en más de 90 batallas durante su vida, como guerrero o como general.
Tenía una serie de cualidades que le permitían mantenerse en el poder y ejercer la autoridad, era
cuidadoso y audaz, en los momentos correctos y en los lugares correctos. Cálculo y sutil, cambió de
alianzas cuando pensó que se beneficiaría del cambio.
Nos gustaría compartir una de las citas grabadas de Ieyasu con nuestros lectores, una cita que se
aplica a nuestra vida personal y profesional: "La vida es como un largo viaje con una carga pesada.
Deja que tu paso sea lento y constante, para que no tropieces ... Encuentra fallas contigo mismo en
lugar de con los demás".
XXV
agradecimientos
Si ya has leído una sección de agradecimientos, sabes que siempre comienza agradeciendo a las
familias de los escritores. Ahora sabemos por qué. Son las personas de las que nos hemos tomado el
tiempo: escribir mientras duermen, escribir en lugar de pasar tiempo con ellos, darles respuestas
crípticas cuando estábamos en algún lugar de la página 267 en lugar de en el patio de recreo donde
deberíamos haber estado. Y aún así nos apoyaron a lo largo de este proyecto. Sin ellos y sin su
apoyo, este libro no hubiera sido posible.
Le agradecemos a la comunidad que nos rodea por esta oportunidad, a todas las personas de
las que hemos aprendido y de las que aprendemos todos los días, y que en muchos casos saben esto
mejor que nosotros. Estamos parados sobre los hombros de los gigantes. Gracias por sus hombros y
su aliento durante este proceso.
Hay otras personas que queremos mencionar que han sido particularmente útiles,
inspiradoras y solidarias: Christophe Achouiantz, Torbjörn Gyllebring, David J. Anderson, Jim
Benson, Corey Ladas, David P. Joyce, Benjamin Mitchell, Karl Scotland, Mattias Skarin, Don
Reinertsen, Alan Shalloway, Mary y Tom Poppendieck, Håkan Forss, Måns Sandström, Eric
Willeke, Jabe Bloom, Mike Burrows, Dennis Stevens y toda la gente del Retiro de Liderazgo de
Kanban. Hemos aprendido mucho y lo pasamos muy bien con el grupo Stockholm Lean Coffee, que
incluye a Håkan Forss y todas las otras personas maravillosas que hay allí.
Una serie de personas también nos ayudaron con revisión y retroalimentación, por lo que
estamos muy agradecidos. Un agradecimiento especial a Rasmus Rasmussen y Viktor Cessan por
sus ideas y a los siguientes revisores: Adam Read, Barry Warren Polley, Burk Hufnagel, Chris
Gaschler, Craig Smith, Daniel Bretoi, Dror Helper, Ernesto Cárdenas Cangahuala, Jorge Bo, Karl
Metivier, Marius Butuc, Richard Bogle y Sune Lomholt.
XXVI
AGRADECIMIENTOS VII
Un agradecimiento especial a Jim Benson por proporcionar el prólogo de nuestro libro, a Danny
Vinson por su cuidadosa revisión técnica del manuscrito poco antes de que fuera a producción, y a
Robert Vallmark por producir los avatares de gran-apariencia2—realmente nos ayudaron a mejorar
las imágenes del libro!
Hemos tenido la suerte de trabajar juntos con la gran tripulación en Manning, y
Estamos convencidos de que Manning dejó de lado a sus mejores personas solo para nosotros.
Gracias a Bert Bates por ayudarnos a sobrepasar el aspecto y el sentir de un libro de
Manning. Somos afortunados de haber tenido acceso a su cabeza al comienzo de este proceso. Y,
por supuesto, gracias a la editorial Marjan Bace por permitirnos escribir el libro de esta manera.
Un gran agradecimiento a Beth Lexleigh y Cynthia Kane, nuestras editoras de desarrollo,
por su fácil revisión e impulso cuando las cosas fueron lentas. Usted tomó nuestras divagaciones y
las convirtió en un libro real.
Gracias a todas las otras personas de Manning que nos ayudaron de diferentes maneras, sin
ningún orden en particular: Michael Stephens, Maureen Spencer, Tiffany Taylor, Kevin Sullivan,
Mary Piergies, Janet Vail y Candace Gillhoolley.
MARCUS
Primero quiero y necesito agradecer a Dios, la base de todo lo que soy y hago.
Mi agradecimiento personal a Elin y a los niños (Albert, Arvid y Gustav), quienes
me han apoyado durante este proceso. Incluso recibí alguna ayuda de diseño de Albert de vez en
cuando.
Para mi padre y mi madre que me criaron para ser lo que soy hoy (para mejor o para
peor): "Tack mamma och pappa, för allt ni gjort for mig".
A todas las personas de mi comunidad cercana a quienes he recurrido con preguntas y
preocupaciones de vez en cuando, un mega gracias. No tengo nada más que aplausos y apoyo de
ustedes: Torbjörn Gyllebring, Håkan Forss, Måns Sandström, Anders Löwenborg, Hugo Häggmark,
Tomas Näslund, Per Jansson, Kalle Ljungholm: los amo muchachos.
Para Avega Group y Aptitud (mis empleadores en el momento de escribir): gracias
por dejarme asumir este proyecto. ¡Avega incluso me pagó por ello! Me impactó,
cuando ofreciste eso! ¡Eres genial, los dos!
Y finalmente, a Joakim: este libro habría sido basura sin ti. Puede haber sido terminado
antes, pero nadie lo habría leído. He aprendido más de ti y sigo haciéndolo. ¡Gracias hombre!
2
Caricaturas graciosas y divertidas, aunque no muy favorecedoras para nosotros. El avatar de Joakim recibió el
comentario "Parece una versión italiana de ti después de haber tenido demasiada pizza", y Jim Benson preguntó por qué
Marcus se parecía a Jeff Goldblum.
XXVIII AGRADECIMIENTOS
JOAKIM
Mi participación en este libro no hubiera sido posible sin el apoyo de mi familia. A la familia que
me dio vida y oportunidades increíbles (en orden cronológico): mis abuelos Albin, Ingeborg y
Molly; mis padres Ove y Elisabet y sus hermanos y sus familias; mi hermana Anna y mi hermano
Henrik, gracias por hacerme lo que soy. Estoy extremadamente agradecido con el amor de mi vida,
Anna, y nuestros hijos Alva, Saga, Albin e Iko; su apoyo ha sido fenomenal, como siempre.
Gracias Marcus por involucrarme en este libro; por tu infinita paciencia con mi
contribuciones lentas y dispersas; para constantemente ser soldado y escribir; para hacer frente a
mis críticas, recomendaciones e ideas no siempre muy educadas para que las reescrituras grandes
sean realizadas principalmente por usted; por el gran esfuerzo que ha dedicado a la tediosa tarea de
formatear, empujar píxeles, etc. por empujarme pero nunca apresurarme o hacerme sentir mal por
no contribuir lo suficiente (lo hice yo mismo); por su personalidad alegre y de apoyo; en resumen,
¡por ser Marcus!
Parte 1
Aprendiendo kanban
L a parte 1 es una introducción práctica a Kanban. El objetivo de esta parte es permitirle
comenzar a usar kanban, al mismo tiempo que le proporciona una comprensión básica de los
principios que lo respaldan y le permite profundizar en algunos temas avanzados para abrir su
apetito.
Comenzamos con una historia corta que sigue a un equipo de desarrollo de software típico a medida
que se les presenta y se comienza a usar kanban. Si no te gusta el enfoque de contar historias,
puedes pasar directamente al siguiente capítulo; cubriremos la mayoría de las cosas del capítulo 1
con más detalle en capítulos posteriores.
1 Equipo Kanbaneros
comienza
Marcus y Joakim están en una conferencia presentando una introducción práctica a Kanban. Están
terminando la presentación; unámonos a ellos en acción.
¡ Comenzar mañana !
¡ Deja de comenzar !
¡ Comenzar a
terminar ¡
"Para resumir: kanban es un enfoque para el desarrollo de software basado en los principios de
Lean. Ha sido recogido rápidamente por muchas organizaciones de todo el mundo. ¡Puedes
recogerlo también! A partir de mañana, debe dejar de comenzar y comenzar a terminar". Y con eso,
concluyó Joakim, "nuestra introducción rápida y práctica al kanban termina. Pero recuerda lo que
dijimos antes—podrías comenzar mañana. Comenzar a trabajar con esto no es difícil— los efectos
pueden tener un impacto dramático en su productividad".
3
4 Capítulo 1 El equipo Kanbaneros comienza
"¡Gracias a todos por venir! Estaremos dando vueltas por aquí por un par de minutos si tienen
alguna pregunta ", agregó Marcus, tratando de cerrar la discusión para finalizar la presentación a
tiempo— por una vez.
Cuando Joakim comenzó a limpiar la pizarra blanca y quitar todos los
adhesivos de la pared, Marcus respondió un par de preguntas rápidas,
apuntando a algunas personas a las diapositivas disponibles para
descargar mientras se dirigía hacia la salida. Sin embargo, no llegó muy
lejos. A mitad de camino hacia la salida, una mujer lo detuvo
bruscamente.
"¿Qué es esto? ¿Por qué te vas? ¡¿No me digas que nos lo perdimos
todo ?! "La mujer parecía decepcionada y casi como si la hubieran
engañado.
"¿Te perdiste qué? ¿La presentación? Sí, acaba de terminar, pero
puedes ver el vídeo en línea ", respondió Marcus.
"¡Oh, no!", Gritó. "¡Solo vinimos aquí para esta presentación! Parece que alguien
se perdió la hora de inicio de la presentación. "Ella asintió con la cabeza hacia un hombre que
conducía a un grupo a la habitación.
"Bueno, probablemente hagamos algo en otoño también si quieres ver la presentación en
vivo", dijo Marcus, tratando de suavizar las cosas.
"Eso no servirá de nada: ¡queremos comenzar de inmediato! Todo nuestro equipo está aquí;
incluso los chicos de negocios se unieron a nosotros para este tutorial, por recomendación mía. "Se
veía realmente triste. "Hola, soy Daphne, por cierto".
"OK; ¿Por qué no nos reserva a Marcus o a mí para un día de consultas,
entonces? "sugirió Joakim mientras se unía a ellos, presentándose a
Daphne.
"Bueno, pudimos, pero ha habido bastantes quejas tanto del equipo
como de las personas que trabajan con él. Queríamos hacer algo al
respecto y esperamos poder recoger algo para ayudar hoy". Las palabras
vinieron de un hombre imponente que había alcanzado a Daphne.
"¿De qué tipo de problemas estás hablando?", Le preguntó Joakim al
hombre.
"El equipo se siente abrumado por el trabajo, y las personas que están esperando que entreguen
cosas piensan que se tarda una eternidad", dijo claramente. Daphne intervino: "A pesar de que
tenemos mucho trabajo por hacer, tenemos largas discusiones sobre qué proyecto es más importante
comenzar primero. Sin embargo, todavía no podemos elegir el correcto ".
"Y ... bueno, hay más, pero no queremos tomar tu tiempo. Te estabas yendo, ¿verdad? "Dijo
el hombre, dejando la pregunta colgando.
Introducción 5
"¿A menos que tengas una mejor sugerencia?" Marcus respondió rápidamente. Esto sonó como el
comienzo de un desafío divertido.
"Esto es lo que vamos a hacer. Compraré alguna consulta de ustedes dos aquí y ahora", dijo
el imponente jefe. "Tu diapositiva en la pantalla dice 'comienza mañana'. Te estoy dando la
oportunidad de poner tu dinero donde está tu boca. ¿Cuánto tiempo puedes dedicar? Hizo una pausa
y miró a Marcus y a Joakim.
"Tenemos dos horas hasta que tengamos que ponernos en marcha", dijo Joakim, mirando su
reloj.
"Bueno, en ese caso: ponnos en marcha con Kanban en dos horas", dijo el jefe, extendiendo
la mano.
"No podremos ayudarte a resolver todos tus problemas, solo te pondremos en el camino
correcto", dijo Joakim, mirando a Marcus. Ellos asintieron con la cabeza el uno al otro. "Bien,
tenemos dos horas de sobra. ¡Desafío aceptado!"
Bienvenido a Kanban en acción!

Te has embarcado en un viaje de aprendizaje sobre kanban, y este capítulo introductorio te
enseñará los fundamentos del kanban por medio de una historia. No se necesita conocimiento
previo de kanban. Seguirás a los entrenadores Marcus y Joakim (sí, somos nosotros) mientras
enseñan kanban a un equipo de desarrollo de software y ayudan al equipo a aplicar lo que
aprenden a su forma de trabajar.
Esta historia inventada es una introducción que te lleva fácil y suavemente a lo básico de
Kanban. En este capítulo, aprenderás cómo utilizar técnicas de visualización, como el tablero
kanban y sus elementos de trabajo, para comprender mejor cómo funciona tu trabajo. Aprenderás
cómo limitar la cantidad de trabajo en proceso, y comprenderás cómo hace que tu trabajo fluya
más rápido y ayudar a identificar oportunidades de mejora. También aprenderás un poco sobre el
uso de métricas para mejorar.
En las revisiones que hemos recibido en este capítulo, ha habido dos campos. Muchas
personas adoran este enfoque de narración de historias; otros parecen ... no gustarle tanto. Si no
deseas comenzar con una historia, puedes pasar directamente a los capítulos siguientes. Todo lo
que mencionamos en este capítulo será tratado con mucha más profundidad en capítulos
posteriores. Pero esperamos que leas este capítulo también y obtengas mucho de él. Después de
leer este capítulo, deberías poder comenzar a usar kanban, aplicando los principios que le
enseñamos al equipo en la historia.
En el resto del libro, veremos los detalles: los principios detrás de Kanban y muchas
variantes y prácticas que han evolucionado los equipos de kanban en todo el mundo. Si cree que le
hemos dejado preguntas en la primera parte, seguramente encontrarás las respuestas en las últimas
partes del libro.
Pero primero lo primero; Volvamos a la historia!
1.1 Introducciones
Todo el equipo estaba reunido en la habitación contigua. Se presentaron a Marcus y Joakim
describiéndose unos a otros, una técnica con la que parecían tener bastante experiencia, a juzgar por
las audaces declaraciones hechas.
6 CAPITULO 1 Equipo Kambaneros Comienza
"Adam es un probador. Ha estado presente por bastante tiempo y casi

siempre es escéptico: de cosas nuevas, de las capacidades de los demás,
pero principalmente de la calidad del trabajo que hacen los demás. Él
trata de expresar su crítica de una manera agradable; a veces lo logra".
"A Adam le gusta trabajar a su manera. A él no le gusta el cambio—
cambio significa prueba de regresión".
"Beth es una nueva empleada. Ella es responsable del análisis de

requisitos en el equipo. Eso incluye todo, desde preguntarle al negocio lo
que quiere y escribirlo hasta asegurarse de que los desarrolladores
comprendan lo que deben hacer".
"Beth siempre está buscando nuevas formas de trabajar".
"Cesar es el negocio. Prácticamente construyó la primera versión de la

aplicación en la que está trabajando el equipo, un banco de Internet, todo
él solo cuando camino devuelta".
"Ahora dejó la parte de TI y está a cargo de la parte comercial de la
operación. Todavía le gusta pensar en sí mismo como desarrollador y a
menudo se lo encuentra "metido en el fondo".
"Daphne es una desarrolladora kick-ass. Se sabe que lanzó más

códigos en una hora que la mayoría de los desarrolladores en una
semana ".
"Pero a ella le gusta trabajar sola; otras personas la retrasan. Sentarse
con Cesar y decidir cómo deberían funcionar las cosas—esa es la mejor
manera de trabajar, si le preguntas a Daphne. Las cosas vuelan entonces.
Todas estas otras ceremonias y jerarquías están en su camino ".
"Eric es un desarrollador de día ... porque tiene que serlo. Pero por la
noche es un héroe de la guitarra, tocando en pubs locales y en otros
lugares. Pronto llegará el gran salto. Pronto."
"Escribir código está bien, pero a menudo es difícil ver por qué lo
hacemos".
"A Eric le gusta hacer cosas para que pueda continuar respondiendo
preguntas sobre http://guitar.stackexchange.com".
"Frank es el gerente del lado de TI de la operación. Él tiene 36
personas debajo de él, e intenta reunirse con todos al menos una vez
cada dos meses, pero hay muchas otras reuniones para asistir ".
"Se preocupa por el producto, pero le resulta difícil mantenerse al día
con todas las funciones nuevas. Frank trata de desarrollar a su gente cada
vez que tiene tiempo extra ".
Introducciones 7
"Genial", dijo Marcus. "Encontré una habitación aquí con una pizarra blanca. ¿Tienes tus adhesivos,
Jocke?
"Sí, por supuesto", respondió Joakim, con su cara de preguntas por favor, no estúpidas. Es
un entrenador ágil; naturalmente él tiene adhesivos con él todo el tiempo.
"Genial, vámonos, entonces", dijo Marcus, liderando el camino.
"¿Quién puede decirnos qué hace tu equipo?" Preguntó Joakim cuando se pararon alrededor
del tablero.
"Probablemente soy yo", dijo Cesar, sacando su computadora portátil.
"¡No por favor! ¡Sin diapositivas! Eric gritó de dolor. "Dile, no tenemos tiempo para eso."
"Sí, probablemente tengas razón", respondió Cesar, un tanto perplejo. "Aquí está la versión
corta".
Es un pequeño equipo de desarrollo que consiste en el grupo reunido aquí. Trabajan para una
gran compañía de seguros con responsabilidad por la aplicación del banco móvil recientemente
lanzada. Debido a que su equipo es bastante pequeño, pueden gobernarse a sí mismos en su mayor
parte. Se debe informar a otras partes del negocio, pero pueden tomar sus propias decisiones sobre
el trabajo que realizan, y César tiene la última palabra en cada decisión importante. El equipo está a
cargo de crear nuevas funciones en el banco móvil, así como de apoyar y mantener el software que
está en producción.
"¿Por qué necesitas nuestra ayuda?", Preguntó Marcus. Mientras esperaba una respuesta,
escribió el encabezado Desafíos en un rotafolio.
"Probablemente pueda responder un poco de eso". Frank, el líder del proyecto, dio un paso
adelante. "Hemos estado experimentando dificultades para mantener el ritmo de las entregas
previstas.
Hubo muchas quejas de diferentes partes interesadas en la organización sobre no obtener sus
características a tiempo ".
"Y eso empeora cada minuto", agregó César. "La gente ya no confía en la calidad de nuestro
trabajo, y definitivamente no confían en nuestras estimaciones y fechas de entrega".
"Nosotros, en el equipo, por nuestra parte", agregó Daphne, "nos sentimos totalmente
abrumadas y no sabemos qué hacer primero". Cuando tratamos de complacer a todos, conduce a
cambios repentinos en las prioridades, y todo es 'PRIO 1' ".
Luego, el equipo les dijo a Marcus y a Joakim que era común que los interesados entregaran
tareas directamente a los miembros del equipo. Estas solicitudes a menudo provienen de personas
mayores de la organización, lo que dificulta que los desarrolladores digan que no. Además, esos
elementos eran a veces tareas en las que alguien más ya estaba trabajando. Marcus anotó
pacientemente los desafíos como viñetas en el rotafolio.
8 CAPITULO 1 Equipo Kambaneros Comienza
* A menudo entregamos tarde
* Las estimaciones son a menudo inexactas
* El equipo está inundado de trabajo
* Las prioridades no son claras
* El trabajo viene al equipo desde cualquier lugar
* Incierto quién está trabajando en qué
"Gracias, pero eso es probablemente suficiente", interrumpió Daphne. "El tiempo corre, sabes; solo
te quedaban dos horas, ¿verdad? Seamos prácticos ".
"Sí, volvamos a la tarea que nos ocupa". Frank se impacientó ahora. "¿Donde empezamos?"
"Entendemos que estás ansioso por comenzar", respondió Joakim. "Pero tu

también debe entender que kanban es un poco diferente de otros métodos. Tomar Scrum o Rational
Unified Process (RUP), por ejemplo; prescriben qué roles debes tener, qué reuniones debes ejecutar,
incluso cómo debes ejecutarlas, y así sucesivamente. Kanban, por otro lado, comienza donde estás,
te ayuda a comprender tu situación actual y lo ayuda a identificar el siguiente paso para mejorarlo".
"Sí, es importante para nosotros y para usted, entender dónde se encuentra ahora mismo para
poder ayudarlo", interrumpió Marcus, temeroso de que Joakim pareciera demasiado teórico, "pero
definitivamente podemos comenzar ahora, y entenderás más sobre esto a medida que avanzamos.
Mantendremos esta lista de desafíos aquí como una especie de agenda para nuestro corto tiempo
juntos”.
"¿Cómo se llama tu equipo, por cierto?", Preguntó Joakim.

"De ahora en adelante debería ser: ¡los Kanbaneros!" Dijo Frank, en su mejor acento
mexicano. El resto del grupo se rió, y Marcus lo anotó en el rotafolio.
"Comencemos con un mostrar-y-contar para hacer que nuestro trabajo sea un poco más
visual, ¿de acuerdo?" Joakim comenzó.
1.2 El tablero
"¿Cómo saber en qué está trabajando el equipo y cómo el trabajo entra en el flujo? Si ni siquiera
están seguros de sí mismos, ¿cómo podrían saber las partes interesadas, ¿verdad? Joakim se acercó
a la pizarra y agarró un marcador.
"¿Dónde guardas tus pedidos pendientes hoy?", Preguntó Joakim. "¿Supongo que tienes
algún tipo de lista de lo que necesitas para trabajar?"
El tablero 9
"Por supuesto que sí", Beth respondió rápidamente. Joakim y Marcus podían
sentir que se sentía un poco ofendida por la pregunta. "Me aseguro de
ingresar y categorizar todos los requisitos en JIRA, 1 nuestro sistema de
seguimiento de problemas de proyectos".
"Sí, y voy allí cada vez que tengo la oportunidad y trato de mantener el
orden, con respecto a las prioridades, al día". Frank agregó que sentía que el
sistema de seguimiento del proyecto estaba en buena forma.
"Esto hace que sea fácil ver quién está trabajando en qué y el progreso de
cada elemento", agregó Cesar.
"¿Podemos acceder a su sistema JIRA en este momento?", Preguntó Marcus, señalando la
computadora portátil de Daphne.
"Sí—por supuesto", respondió Daphne, y ella abrió la computadora portátil.
"Bueno. Vamos a anotar en qué están trabajando en este momento", sugirió Joakim.
"Escriban cada elemento en una nota adhesiva por separado y manténgala brevemente; es suficiente
si todos ustedes entienden más o menos a qué se refiere esto. Abrió el paquete de notas adhesivas
con su empuñadura patentada con una mano en menos de un segundo, para gran admiración del
grupo (o al menos eso imaginó). Entregó notas amarillas al equipo.
"Por favor, escriba de forma legible, utilizando los marcadores más gruesos y no los
bolígrafos". Aunque Marcus había dado las mismas instrucciones cientos de veces, siempre se sintió
un poco condescendiente al hacerlo, pero había aprendido de la peor manera que los pequeños
garabatos es mucho más difícil para las personas comprender y sentirse involucrados en ejercicios
como estos. "Cuando hayas terminado, publica los elementos en la pizarra".
Joakim le pidió al equipo que publicara el trabajo en orden de prioridad de arriba a abajo.
Hubo un par de minutos dedicados corriendo de ida y vuelta a la pantalla, pero muy pronto se
publicaron seis elementos en una buena columna en el tablero. Cuando la carrera se calmó, Joakim
se enfrentó al equipo y preguntó: "¿Están de acuerdo, equipo? ¿Es esto en lo que están trabajando
ahora mismo?
"Sí", fue la respuesta, casi instantánea y simultánea de César, Frank y Beth. Adam y los
desarrolladores, Daphne y Frank, miraron hacia el piso y no dijeron nada.
"No está bien o mal aquí", dijo Marcus. "Lo que es importante es que tengamos una idea real
de tu situación actual. ¿Algo más?"
Después de un par de segundos, Adam salió limpio. "Bueno, no es del todo
cierto ... tenemos muchas cosas que hacemos que no se ingresan en JIRA".
"¿Cuáles son esos elementos?", Preguntó Joakim. "¿Puedes darnos
ejemplos?"
Resultó que esos elementos podían variar mucho tanto en tamaño como en lo
que eran: requisitos adicionales, pequeñas tareas de soporte, favores pagados a
otros departamentos y el mantenimiento de los sistemas eran algunos ejemplos.
A menudo, alguien de alto nivel que quería algo hecho se lo entregó a un
miembro del equipo en el pasillo.
1
JIRA es una aplicación electrónica de seguimiento de problemas y tickets de Atlassian:
www.atlassian.com/software/jira/overview/ .
10 CAPÍTULO 1 Equipo Kanbaneros Comienza
"Esas tareas son difíciles de rechazar", dijo Adam. "No sabemos cómo priorizar o a lo que se nos
permite decir que no. Pero creo que podríamos hacer un mejor trabajo contándoles sobre ellos ".
"Bueno, para mí parece que nos estamos perdiendo entradas de JIRA", dijo
Beth.
"Si las personas están trabajando en cosas que no están registradas allí,
entonces no podemos confiar en JIRA".
"¿Hay algo que puedas hacer al respecto?", Continuó Joakim.
"Bueno, supongo que se resolverá solo si nos aseguramos de agregar todo a
JIRA, ¿verdad?", Dijo Beth. "Entonces todo el trabajo estará en un lugar, y es
fácil compartirlo con personas que no se sientan a nuestro lado".
"Así es", dijo Joakim. "¿Algún inconveniente para una herramienta
electrónica?"
"No donde estoy parado, no", Eric fue rápido en decir.
"Hmmm—las cosas a menudo se pierden en JIRA", comentó Beth. "Tenemos, en más
de una ocasión, tenía dobles de trabajo, por ejemplo. Hay una buena cantidad de búsqueda para
encontrar algo allí ".
"¿Cómo podríamos hacer que el trabajo sea más fácil de encontrar y ver?", Preguntó Joakim.
"Bien", comenzó Beth, "tendríamos que verlo todo el tiempo, supongo. Como escribir en la
pared o algo así ".
"¡Bingo!" Marcus no pudo contenerse más. "¡Pon el trabajo en la pared! por
cada elemento de trabajo en el que está trabajando, cree una pequeña nota y colóquela en la pared.
Te sorprendería la gran diferencia que una cosa tan pequeña hará para tu trabajo. "Marcus sabía por
experiencia que era algo muy importante para muchas organizaciones que comenzaban con un
desarrollo ágil.
Para ver esto en la práctica, Marcus sugirió que el equipo creara un adhesivo para cada
elemento de trabajo en el que estaban trabajando en ese momento y luego los publicara en la
pizarra.
"¿Todo el mundo lo hizo?", Preguntó Joakim después de un minuto o dos. "Por favor,
publícalos en el tablero".
Próximo a los seis elementos anteriores de JIRA, se
publicaron otros ocho.
"¡Dios mío!", Gritó Frank. "¿Es esto cierto?"
"¡Te lo dijimos!" Dijo Daphne, extendiendo sus
brazos ampliamente. "Tenemos un montón de cosas por
fuera".
"Lo sé, pero nunca me di cuenta ..." César se rascó
la cabeza. "Has pasado por momentos malos, estresantes,
personas".
"Pero eso es más que el trabajo actual en JIRA",
dijo Beth, mientras contaba los adhesivos.
"Eso es lo que hemos estado diciendo todo el
tiempo", dijo Eric, cambiando el tono de su voz por una
vez.
El tablero 11
El grupo guardó silencio y miró a la pizarra por un momento. Al crear pequeñas notas
que representaban cada elemento de trabajo, habían mostrado, de una manera física, lo que estaban
haciendo. Joakim y Marcus habían presenciado esta revelación para los equipos muchas veces
antes.
"Ahí tienen información que se selecciona de JIRA, la herramienta electrónica—o el
'refrigerador de información', como quieras llamarlo, Joakim," dijo Marcus. Miró a Joakim,
haciendo una pausa para que él le explicara la metáfora.
Joakim tomó la señal y explicó: "Una visualización en un tablero visible
grande se puede llamar un radiador de información; su información es obvia y
evidente para la gente que pasa. Las herramientas electrónicas son, a mi
parecer, a veces más como frigoríficos, ya que tienes que abrirlas y hurgar para
encontrar lo que estás buscando". No estaba muy seguro de que alguien lo
oyera, mientras el equipo miraba la pila de adhesivos enfrente de él.
"Mirando hacia atrás en sus desafíos", intervino Marcus, "al menos hemos comenzado a
abordar la confusión de quién está trabajando en qué y qué trabajo está haciendo realmente el
equipo, y hemos tocado brevemente en la priorización".
* A menudo entregamos tarde

* Las estimaciones son a menudo inexactas
* Las prioridades no son claras *
* El trabajo viene al equipo desde cualquier lugar
* Incierto quién está trabajando en qué *
Beth observó la escena ante ella con las notas adhesivas en el tablero. Después de un minuto, ella
dijo: "¿Qué hacemos con esa pila de adhesivos, entonces?"
"Sí, apilarlos en la pared no nos ayuda a hacer más trabajo y mantener satisfechos a los
interesados, ¿verdad?", Agregó Daphne.
Visualizando el trabajo
* Hace que el trabajo oculto aparezca
- Puede ser tan fácil como un adhesivo para cada elemento de trabajo
* Te ayuda a ver:
- ¿Quién está trabajando en qué
- En qué estás trabajando
- ¿Cuánto está pasando?
* El trabajo visible irradia información a las personas que lo ven
1.3 Mapeo del flujo de trabajo

"Bueno, todas esas notas le muestran que tiene mucho trabajo en progreso", comenzó Joakim. "Pero
hay más cosas que puedes dejar visualizar en tu trabajo, como dejar que todos vean el progreso de
los diferentes elementos de trabajo y cuáles son las prioridades. Esto mejorará aún más la
transparencia y le ayudará a priorizar el trabajo, ya que se trata de ustedes", dijo, señalando la lista
de desafíos. "Tratemos de asignar el flujo de trabajo en el tablero y coloquemos los adhesivos en los
lugares correctos." Joakim retiró la tapa de su marcador de pizarra, listo para ir.
"¿Mapear nuestro qué al qué, ahora?" Preguntó Beth.
"Bueno, los elementos con los que trabajas fluyen a través de tu sistema desde la idea, o la
solicitud del cliente, hasta la función finalizada en la producción, proporcionando valor al cliente,
¿cierto?", Preguntó Joakim.
"Sí ... creo que sí". Hubo murmullos por todas partes.
"¿Dónde comienza el trabajo?", Preguntó Joakim.
"Hmmm-difícil de decir", dijo Frank. "Depende de dónde traces la línea". ¿Es cuando la idea
se concibe por primera vez? ¿O cuando decidimos hacerlo, u obtener la aprobación para hacerlo?
Pero creo que algo concreto es que registramos todo lo que estamos haciendo en JIRA, nuestro
sistema de manejo de requerimientos ".
"Pero Beth", interrumpió César, "tú y yo hemos trabajado mucho antes de eso, ¿verdad?"
"Sí", respondió Beth, "pero eso está un poco desestructurado, porque va y viene mucho antes
de que decidamos qué poner en JIRA. A veces es una gran idea, y a veces es una pequeña solución".
Decidieron comenzar el flujo de trabajo cuando el trabajo estaba registrado en JIRA y
finalizarlo cuando el trabajo estaba en producción.
"No veo por qué no deberíamos rastrear todo el camino", dijo Daphne.
"OK, dibujemos el flujo de trabajo como columnas por las que avanza el trabajo". Joakim
comenzó a dibujar columnas en la pizarra, pero luego se detuvo. Había intentado demasiadas veces
dibujar el tablero para un equipo, y sabía que haría que el tablero fuera suyo y no del equipo.
Afortunadamente, había una solución simple. "Mejor todavía; tú los dibujas. "Joakim tiró el
marcador en el regazo de Beth.
"Para indicar que un trabajo se encuentra en cierta etapa, colocamos el

adhesivo en la columna con el nombre correspondiente", explicó Marcus.
"Pero, ¿cuáles son los nombres o las etapas, entonces?" Beth parecía
confundida, porque Joakim no había escrito ningún nombre.
"Bueno, ahí es donde ustedes entran", dijo Joakim con una sonrisa
irónica. "No podemos hacer todo el trabajo por ti. Las cosas que aún no
has hecho en JIRA, ¿cómo llamas eso?
Marcus "Bueno ... no sé. ¿Deshacerse? "Dijo Frank. Hubo risas por todos lados.
"¿Qué tal Bandeja de entrada?", Sugirió César.

Mapeo del flujo de trabajo 13
"No sé", dijo Eric. "Mi pensamiento va al buzón. Y odio el correo electrónico ¿No podemos
intentar algo más?
"Hacer", sugirió Daphne. "¿O es eso demasiado simple?"
A nadie pareció importarle, y Joakim dijo: "¡Es un gran comienzo! Recuerde, queremos que
sea simple y fácil. Si ve la necesidad de hacerlo más tarde, siempre puede cambiarlo ".
"De hecho", dijo Marcus, levantando un dedo, "le sugerimos que dibuje el tabelro con un
marcador en una pizarra blanca. No lo haga permanente, use cinta adhesiva y otras cosas para las
columnas demasiado pronto, porque eso podría hacer que esté menos inclinado a cambiarlo. Y
tendrás que cambiarlo a medida que aprendas ".
Mientras Marcus hablaba, Beth dibujó una columna en el tablero hacia el extremo izquierdo.
Ella escribió Todo en la parte superior de la columna.
Joakim dijo: "OK, todas las cosas en las que no has comenzado a trabajar todavía, muévelas
a esa columna".
El equipo se acercó al tablero y comenzó a mover elementos.
Hubo algunas discusiones y preguntas sobre qué significaban realmente los
elementos, pero muy pronto se publicaron tres notas adhesivas en la columna
Todo.
"De acuerdo, chicos", Joakim llamó al grupo mientras se acurrucaban
alrededor del tablero. "Hagámoslo más fácil desde el principio, y coloquemos los
elementos en orden de prioridad, de arriba a abajo. Esto será útil más adelante,
porque podrán ver fácilmente qué es más importante en cada columna".
"¿Cómo trabajas con el elemento desde allí?", Preguntó Marcus. "¿Qué es lo
primero que haces?"
"A menudo nos sentamos a conversar sobre el diseño. ¿Cómo debería ser esto
construido? ¿Qué podemos usar de nuestra plataforma existente? ¿Deberíamos
usar los componentes de otros equipos para la nueva solución? Cosas como esa",
dijo Frank.
"También hay documentación de nuestros hallazgos", agregó Beth.
"¿Cómo llamarías eso?", Preguntó Joakim.
"¿Qué tal el diseño como nombre?", Preguntó Cesar.
"Hmmm, no del todo bien. Podría haber muchas cosas diferentes para hacer.
Tal vez Analyze sería una mejor opción? ¿Qué piensas? "Frank le preguntó a
Marcus.
"No tengo ni idea. Es su flujo de trabajo. Pregunte a su equipo en su lugar.
¿Qué piensan todos ustedes? Marcus se encaró al grupo.
"Sí, el análisis es mejor", dijo Daphne, y los otros asintieron y murmuraron de
acuerdo.
"¿Algo que estés analizando ahora?", Preguntó Marcus.
El equipo acordó colocar dos elementos en la columna Analyze.
"Continúe con su flujo de trabajo, siguiendo el flujo hasta 'en producción'".
Joakim pensó que los términos Lean, encadenados, a veces se convertían en
poesía. Una rápida mirada alrededor confirmó que todavía estaba solo en esa creencia. Tosió
levemente y dijo: "OK, ¿qué sucede después de eso?"
El equipo continuó creando columnas para Development y Testing, y agregaron las notas con
el trabajo actual a las columnas. Después de eso, hubo una breve discusión sobre lo que significaba
"hecho". Decidieron agregar un paso en el flujo de trabajo para su aceptación. Se decidieron por
Accept como un nombre de columna. Cuando se le preguntó, Adam también se dio cuenta de que
tres de los elementos en la columna de Testing ya habían sido probados y estaban esperando la
aprobación de César. Decidieron moverlos a la columna Accept también, junto con otro elemento
que ya estaba allí.
Adam subió al tablero y movió las partes adhesivas de Testing a Accept.
"¿Entonces qué?" Dijo Joakim. "Usted tiene su trabajo analizado, desarrollado, probado y aceptado.
¿Qué más hay que hacer?
"Bueno, deberíamos lanzarlo en producción, amigo", dijo Eric.
"Y por 'nosotros', quieres decir ..." Daphne apuntó.
"Ops". Eric se encogió de hombros, suspirando.
"¿Qué es eso?", Dijo Marcus.
"Bueno, eso son operaciones", Frank, siempre el diplomático, explicó.
"La parte de operaciones de nuestra empresa ha sido subcontratada a otra
compañía. Eso ha aumentado el tiempo que lleva implementar una
implementación en producción ".
"Y lo primero que hicieron fue revocar todo nuestro acceso a los
servidores de producción", murmuró Daphne.
"Supongo que tienes que esperar un tiempo antes de que se envíen las cosas, ¿entonces?",
Preguntó Joakim.
"Sí, hacen despliegues seis veces al año. Y no van a cambiar de opinión. Eric estaba
decepcionado.
"Escribe 'Esperando operaciones' o algo así", dijo Adam.
"Sí, vamos con eso", dijo Frank.
"Pero podría llamarse Hecho o Fuera de nuestras manos, si lo desea",

dijo Frank.
"¿Por qué?" Preguntó Marcus.
"Solo queda el trabajo de Ops, y nuestras manos están atadas", dijo
Daphne.
Frank continuó: "Sí, no hacemos mucho después de eso".
Joakim y Marcus intercambiaron un "¿Debería hacerlo o tú?" mira. Era
el turno de Joakim, aparentemente, y él preguntó: "¿Quién es tu cliente?"
"¿Qué quieres decir con ‘cliente’?" Frank preguntó.
"Bueno, ¿a quién le interesa tu trabajo o las características que creas?" Joakim explicó.
"Bueno, las partes interesadas que escribieron los requisitos para el sistema", comenzó
Frank.
"¿De Verdad?" Joakim dijo furtivamente.
"Hmmm ... define ‘cliente’ de nuevo para mí", dijo Beth pensativamente.
Cuando el equipo lo pensó un poco más, pronto acordaron que los usuarios del Internet Bank
eran los clientes importantes a tener en cuenta.
"Listo" para ellos sería cuando puedan usar el producto ", dijo César.
"¿Y qué hay de la columna Esperando operaciones?" Joakim presionó. "¿Eso hará que sus
usuarios finales sean más felices?"
"No, por supuesto que no", dijo Beth. "Pero aparentemente así es como se hacen las cosas,
entonces, ¿qué podemos hacer al respecto?"
"Si tuviéramos que pedirle que publique todos los elementos que estaban esperando a
operaciones, ¿cuántos serían?" Joakim preguntó a todo el grupo.
"Un camión de ellos", respondió Eric antes de que alguien más tuviera tiempo de decir algo.
"Sí, son muchos. El último lanzamiento fue ... Frank se detuvo y pensó un momento. "Creo que
vendrá uno este miércoles. Supongo que quizás de 25 a 40 elementos ".
Marcus se enfrentó a César y le preguntó: "¿De qué sirven los proyectos que hacen sus
clientes allí, en Waiting for Ops?" Señaló hacia la columna.
"Ninguno en absoluto, lo queremos fuera", dijo César. "Pero como dijo Beth, está fuera de
nuestro alcance".
"¿Puedes cambiar eso?" Joakim preguntó.
"No es fácil." César suspiró. "Tienen un presupuesto diferente, en un departamento
diferente, e incluso en un edificio diferente, por el amor de Dios".
Daphne se acercó al pizarrón y dijo: “Pero si tuviéramos una columna de Waiting for Ops
con notas adhesivas, y lo único que impidió que esos elementos se hicieran eran los chicos de Ops.
¿No crees que podemos comenzar una discusión, al menos?"
"Sí, es mucho mejor que decir ‘apestas’", dijo Frank, mirando a Eric, quien a su vez miró
hacia la tabla.
"Incluso podríamos ayudarlos con algunas de las cosas simples nosotros mismos".
Daphne vio su oportunidad de recuperar los derechos de administrador de los servidores.
"Sí, al menos vale la pena intentarlo", admitió César.
"Gran trabajo, equipo", dijo Marcus. "Cuando visualizas tu dolor y recopilas datos
al respecto, es mucho más fácil lograr que los interesados y otros equipos entiendan. No estas
molesto, son datos". Eric asintió de acuerdo y pareció aliviado.
"Aquí hay otro excelente ejemplo de por qué la visualización es tan importante", interrumpió
Marcus.
“Estos problemas existen ahora mismo; simplemente no los viste. Al hacer esta visualización
simple, un elemento adhesivo para cada elemento de trabajo y en qué etapa del flujo de trabajo
se encuentra, puede ver un problema en su proceso".

"Correcto, aunque prefiero llamarlo una ‘oportunidad de mejora no realizada’", dijo Joakim,
sonriendo a Marcus. “Y esto es una gran cosa. Su tablero kanban le dirá todo tipo de cosas. Los
elementos que se mueven lentamente, los elementos que se bloquean o los elementos en los que no
se trabaja son solo algunos ejemplos. Son oportunidades de mejora de las que puedes aprende a
mejorar tu forma de trabajar. Aprovecha estas oportunidades. Llame a Ops y haga algo al respecto,
por ejemplo. ¡Quizás ni siquiera saben que esto es un problema para ti!" Joakim se dio cuenta de
que se estaba dejando llevar y trató de calmarse.
"Seguro", murmuró César, pero también estaba muy contento con el progreso que habían
hecho hasta ahora.
"Está bien, ¿qué pasa después de eso, después de esperar a operaciones?"
"Bueno, entonces se acabó", dijo Adam. "Está en producción. Los errores pueden aparecer,
pero luego se ingresan como entradas de JIRA, con suerte, y eso iría en la columna Todo,
¿supongo?
"Si lo dices, es tu proceso", dijo Joakim. "Eso nos deja con una columna final llamada
Hecho, ¿o algo así?"
"¿Por qué tener una columna Listo?" Preguntó Daphne.
"¿Por qué no?" Eric respondió. "Queremos demostrar que somos increíbles, ¿verdad?"
Marcus estuvo de acuerdo. "Sí, por supuesto". Hizo una pausa breve. "Y también es una
excelente manera de recopilar todo el trabajo en el tablero cuando está terminado".
"Correcto." Adam entendió eso. “¿Pero por qué hecho? Dije que podrían ocurrir errores.
¿Qué tal en producción?
Eso dice más de lo que es, creo. El resto del equipo estuvo de acuerdo, y no había entradas
para poner allí en este momento.
"Mirando esto, ¿diría que es aproximadamente el

flujo por el que pasa su trabajo?" Joakim preguntó.
"¿Puedes ver el estado de cada elemento más * A menudo entregamos tarde
claramente ahora que cuando estaba bloqueado en * Las estimaciones son a menudo inexactas
el sistema electrónico?" Asintió al rotafolio con su * Las prioridades no están claras
lista de desafíos. * El trabajo llega al equipo desde todas partes
“¿Qué tal la priorización? Ese también fue uno * No está claro quién está trabajando en qué
de sus desafíos”, dijo Joakim, y señaló el elemento
en el rotafolio. "¿Es más fácil ver la priorización
ahora, cuando los elementos se enumeran en orden de prioridad en cada columna, por ejemplo?"
El equipo miró el tablero por un momento. Frank mencionó que se sintió un poco
simplificado y que no podían saber si funcionó hasta que lo intentaron.
"Eso está bien por ahora", dijo Marcus. "Dos cosas: primero, esto no es definitivo. Esto es
"lo mejor hasta ahora". Este tablero, y todo lo demás que hemos discutido, probablemente estará
sujeto a cambios más adelante. Deberíamos mejorarlo a medida que avanzamos ”. Hizo una pausa
por un segundo, tratando de evitar entrar en el modo de predicación sobre las virtudes de la
inspección y la adaptación y la mejora continua.
"Segundo, hablemos sobre los diferentes tipos de trabajo que mencionó. O en otras palabras,
¿qué pasa en el tablero?
Asigne su flujo de trabajo al tablero
* Identifica todas las etapas, desde el trabajo que

ingresa hasta el trabajo que sale del equipo
* No luches por la perfección: inspecciona y adapta
* El trabajo no se realiza hasta que está
produciendo valor para el cliente
* Con un flujo de trabajo visualizado puede ver:
- Estado del trabajo
- Problemas potenciales, como el trabajo no
progresa y se acumula en una etapa
1.4 Elementos de trabajo

"Ahora tenemos muchos adhesivos en el tablero, cada uno de ellos simbolizando un elemento de
trabajo", dijo Marcus. "Cada uno tiene un título corto que describe a qué elemento de trabajo se
refieren".
"Y el estado de cada elemento se muestra claramente en la columna en la que se encuentra",
agregó Joakim, pasando la mano por el tablero de derecha a izquierda.
Elementos de trabajo 19
"¿Es esta información suficiente para que todos ustedes y sus partes
interesadas comprendan en qué están trabajando en este momento?"
Preguntó Marcus.
"Bueno, esos títulos pueden ser demasiado breves a veces", dijo
Beth.
"¿A qué te refieres?" Preguntó Marcus.
"Diría que algunos de ellos solo pueden ser entendidos por los
desarrolladores que están trabajando en ellos, incluso si ellos lo
hacen".
“¿Quizás quieres escribir una breve descripción del trabajo que
representa el adhesivo? No es algo largo, pero al mismo tiempo no tan
corto que no recuerdes de qué se trataba esa nota ", Marcus sugirió.
"¿Como una historia de usuario, entonces?" Beth sonrió
"Sí, podrías hacer eso", respondió Joakim, "pero no tienes que hacerlo.
Cualquier descripción breve que te recuerde lo que estás haciendo
será suficiente. Es bueno si es evidente de qué se trata el elemento sin tener que acercarse al tablero
y leer por un momento. Debería ser evidente de un vistazo para que pueda distinguir diferentes
elementos". Joakim dibujó un gran cuadrado en el pizarrón y escribió Descripción en el medio.
"¿Es eso suficiente entonces?" Preguntó Marcus.
"No siempre. A menudo quiero saber el número JIRA". Eric amaba esa herramienta; podías
escucharlo en su voz.
"¿Por qué?" Joakim preguntó, en parte
porque no estaba tan impresionado con
JIRA, en parte porque pensó que Eric
probablemente tenía razón.
"Si vamos a tener una descripción tan
breve, necesitaremos una referencia a
JIRA para que podamos ver el resto de la
información allí. A veces hay un montón
de cosas útiles allí. Largas discusiones,
fotos o lo que tienes ”, explicó Eric.
"¡Excelente!" Joakim escribió JIRA # en la esquina superior izquierda del cuadro que había
dibujado en la pizarra.
"¿Algo más?" preguntó.
"¡Plazos!" Frank se levantó y casi gritó.
"Claro ... ¿eso te parece importante?" Marcus cuestionó. Miró al grupo: no hubo respuesta.
Después de un rato, César rompió el silencio. "Sí, son importantes para nosotros, pero no están
presentes en cada elemento de trabajo que hacemos. ¿Cómo manejamos eso? Dirigió la pregunta a
Joakim.
"¿Qué piensan todos ustedes?" Joakim le preguntó al grupo.
"Vamos a escribirlos en las notas que tienen una fecha límite; es tan simple como eso,
¿verdad? " Eric dijo desde su posición sentada.
"Sí, pero queremos que se destaque, para que no nos lo perdamos". Frank estaba hablando solo
un poco.
"¿Qué tal si usas un color diferente, entonces?"
Beth sugirió.
"¡Gran idea!" Joakim subió al tablero y
agregó una fecha límite en la esquina superior
derecha. “Otra cosa que podría ser útil es
escribirlos siempre en la misma área del
adhesivo. Eso establece que la esquina
superior derecha tiene una fecha límite, si está
presente".
"Gran trabajo, equipo", agregó Marcus.
"Pero hay otra cosa que puede resultar útil agregar al elemento de trabajo", dijo Joakim.
"¿Alguna suposición?" Sin respuestas.
"¿Cómo sabes quién está trabajando en qué?" preguntó.
Ese hecho se observó en cada elemento de JIRA, pero rápidamente se dieron cuenta de que
también necesitaban transferir esa información al tablero. La primera sugerencia era escribir el
nombre, pero eso consumiría espacio en el adhesivo; y a veces más y si agregan más nombres, lo
que dificultaría la lectura del adhesivo.
"Una cosa simple sería tener algún tipo de marcador para
adjuntar al elemento de trabajo. Un imán con tu nombre o algo
así”, dijo Beth.
"Correcto: una solución simple y común es crear lo que se
conoce como avatares de ustedes mismos que ponen en los
elementos de trabajo con los que funcionan”, afirmó Marcus.
“¿Un avatar? ¿Un chico azul montando un caballo volador?
¿Cómo va a ayudar eso? " Daphne parecía bastante sorprendida.
"No, no ese tipo de avatar". Marcus rio. “Una pequeña imagen, o marcador de posición, que
te representa. Como una imagen impresa de nosotros mismos, o una caricatura que se parece a ti, o
lo que sea que sacude a tu bote".
“Dibujos animados? ¡Pero no nos parecemos a nada así! Frank se opuso.
"Usa algo que al menos se parezca a ti mismo, o asegúrate
agregarle su nombre para que sea fácil establecer la conexión
entre la foto y tú”, dijo Joakim. Todavía estaba quemado por
el tiempo que eligió usar adhesivos con perros que eran imposibles
para conectarse con las personas adecuadas. Él comenzó a dibujar un boceto
de un avatar en el tablero. Sus habilidades de dibujo causaron algunas risas.
"¿Sabes lo que sería útil?" Adam dijo cuando terminó el boceto. "Para
saber si algo es un error o no".
"¿Cómo?" Joakim preguntó.
Adam explicó que los errores tenían prioridad sobre otros trabajos y probablemente podrían
omitir pasos como Analyze en el flujo de trabajo. También querían rastrear desde qué ticket JIRA se
originó el error. Después de una discusión, el equipo decidió indicar que algo era un error al usar
Elementos de trabajo 21
un color diferente, escribiéndolo en un adhesivo rojo en lugar de uno amarillo normal (un patrón
común en la comunidad kanban).
"¡Eso es realmente bueno!" Beth, que siempre se consideró una diseñadora disfrazada,
estaba intrigada. "Entonces esos elementos de error serán fáciles de identificar incluso desde la
distancia".
Joakim produjo un adhesivo rojo y escribió la palabra Bug
(Error) en él. En un adhesivo amarillo, escribió Normal.
Los colocó a un lado del tablero.
"Por favor, suba al tablero y cambie los colores de los
elementos que ya están allí", dijo, entregando adhesivos
rojos.
El grupo discutió algunos elementos, pero en su mayor parte decidieron rápidamente el tipo
de trabajo para un elemento de trabajo en particular. Después de un rato, dieron un paso atrás y
miraron el tablero.
"Ahora podemos ver un poco más sobre lo que estamos trabajando", dijo Marcus. “Además, si el
tablero comienza a ser solo adhesivos rojos, debemos sentarnos y tener una charla seria y de
calidad, ¿verdad? El tablero comienza a hablarnos y nos envía información sobre el estado de
nuestro trabajo. ¿Puedes ver lo que queríamos decir con radiador de información antes?
Hubo asentimientos a su alrededor. Era fácil ver el poder de la visualización y cómo las
medidas simples, como cambiar el color de un adhesivo, podrían ser útiles para ayudar a destacar
características importantes, como el tipo de trabajo representado por la nota.
"¡Excelente!" Marcus aplaudió. “Ahora tenemos un tablero con un flujo de trabajo y una plantilla
simple para lo que debe ir en cada elemento de trabajo. Veamos cómo deberían moverse los
elementos de trabajo en todos los ámbitos y qué podemos aprender de eso".
"Recuerda dónde comenzamos este viaje de visualización", interrumpió Joakim. “Queremos que el
tablero y todo lo que contiene contenga información para nosotros. Esa información nos dirá cómo
funciona nuestro trabajo para que podamos aprender de él. La ganancia real no es ver el estado de
cada elemento de trabajo, por muy bueno que sea. El beneficio real es ayudarnos a tomar decisiones
y mejorar nuestro proceso a medida que aprendemos cómo funciona. Esto es solo el comienzo, y
nunca has terminado".
"Este es un principio básico e importante en kanban: hacer visible el trabajo", interrumpió
Marcus.
"Correcto, y el razonamiento básico detrás de eso es que no puedes mejorar lo que no ves.
¿Estás de acuerdo?" Dijo Joakim.
RECUERDA No puedes mejorar lo que no ves.
¿Qué pasa en la tarjeta?

* De la tarjeta debes:
- Ver el estado del elemento de trabajo
- Poder tomar una decisión sobre qué hacer a continuación
* Los atributos comunes son:
- Descripción del elemento de trabajo.
- ID en sistemas electrónicos
- Plazos
- Quién está trabajando en el elemento
- Tipo de trabajo (error o normal, por ejemplo)
La gente asintió con la cabeza, aparentemente de acuerdo. "Totalmente", dijo César, "y ya hemos
visto el valor de esto. ¿Pero qué hacemos después?
1.5 Pase los peniques

"Revisemos sus desafíos nuevamente",
sugirió Marcus. "Veamos si podemos hacer * A menudo entregamos tarde
algo para superar su sensación de ser * Las estimaciones son a menudo inexactas
abrumado por el trabajo, ¿de acuerdo?" * El equipo está inundado de trabajo
"Eso nos llevará a otro importante principio * Las prioridades no están claras
kanban, que nos enseña a limitar el trabajo * El trabajo llega al equipo desde todas partes
en proceso", comenzó Joakim. "Es decir, * No está claro quién está trabajando en qué
esforzarse por trabajar con menos
elementos al mismo tiempo".
Pase los peniques 23
Casi no tuvo tiempo de terminar la frase antes de que Adam, siempre escéptico, dijera: "¿Por qué?
¿No deberíamos hacer todo lo posible? En este momento estamos mostrando el trabajo que estamos
haciendo; No podemos hacer mucho al respecto. Vamos tan rápido como podemos".
"No dudo por un segundo. Pero creo que puedes hacerlo mejor”, dijo Joakim, con una
misteriosa sonrisa en su rostro. Miró a Marcus, le guiñó un ojo y dijo: "Creo que necesitamos unos
peniques por aquí". Sacó una mesa y cuatro sillas.
"Corrrecto." Marcus sacó un pequeño monedero. Lo vació, creando una pequeña pila de 20
peniques en un extremo de la mesa.
Se giró hacia César. "¿Cómo estamos con el tiempo?"
"Tenemos 45 minutos. Una hora y 15 minutos para el final. Por favor, continúa”, dijo César
mecánicamente, preguntándose a sí mismo cómo estos peniques harían avanzar las cosas.
"Cuatro de ustedes por favor tomen asiento alrededor de esta mesa". Joakim invitó al grupo
a las sillas. “El resto de ustedes está detrás de uno de sus colegas y muestra un temporizador en su
teléfono. Marcus y yo llenaremos los dos últimos espacios detrás de ti.
Explicó que el objetivo del juego es que cada estación voltee todas los peniques una vez y luego las
pase. Cuando todos los trabajadores hayan volteado todos los peniques, se recogen y se entregan al
cliente. Todos parecían estar claros con él hasta ahora.
"Las personas que están detrás de un ‘trabajador’, Joakim hizo citas aéreas para enfatizar la
ironía, "son responsables de cronometrar al trabajador frente a ellos para ver cuánto tiempo se
dedica a la tarea. Inicie el temporizador cuando su trabajador comience a trabajar y deténganlo
cuando el trabajador se detenga. ¿Entendido? Estás cronometrando todo el tiempo que tu trabajador
está activo".
"Finalmente, queremos medir el tiempo de entrega total, el tiempo que lleva de principio a fin que
el trabajo fluya a través de nuestro flujo de trabajo", dijo Joakim. "Actuaré como el cliente y
cronometraré toda la cadena. Seguiré dos cosas: el tiempo que lleva hasta que me llegue el primer
penique (al cliente) y el tiempo total, es decir, cuando me han llegado los 20 peniques".
Después de un momento de pensamiento agudo, Daphne habló. "Pero trabajando así,
¿significa que el primer penique y el último penique llegarán al mismo tiempo?"
"Sí, eso es correcto", respondió Marcus. “En esta primera iteración al menos. Veremos
cambios en eso pronto, en las iteraciones a seguir ".
Marcus concluyó la introducción al ejercicio. "Vamos a ejecutar esto tres veces. La primera
vez, cada trabajador lanzará los 20 peniques y luego las enviará al siguiente trabajador en línea.
¿Estás conmigo?"
"¿Estás listo? Temporizadores, cronometra el tiempo efectivo de trabajo de tu trabajador", le
ordenó Joakim por última vez. "¡En sus marcas, listos, fuera!"
Hubo un silencio intenso cuando Adam comenzó a voltear sus peniques como un loco. Pasó
sus peniques a Beth y se volvió hacia su "gerente" Frank a sus espaldas.
"Hecho, ¡para el reloj!"
Beth continuó con igual concentración y envió los peniques a César. César ni siquiera
respiró durante su turno y respiró hondo cuando los peniques fueron enviadas a Daphne en la última
estación. Daphne intentó lanzar dos peniques a la vez, una con cada mano, lo que resultó en un
progreso aún más lento. Los otros gimieron. "Vamos Daphne, ¡no nos decepciones aquí!"
Finalmente ella terminó y envió los
peniques a Joakim, quien detuvo su reloj.
En un rotafolio, Marcus creó una
pequeña tabla y anotó los resultados.
Joakim se acercó a cada uno de los
"gerentes" y les preguntó los tiempos
individuales para cada trabajador.
Después de sumar el total, se volvió hacia
el grupo.
"Como predijo Daphne, el primer y el
último penique llegaron al mismo tiempo".
"Ahora intentemos con lotes de cinco
peniques", indicó Marcus. "Eso significa:
voltear cinco peniques y luego pasarlas al
siguiente trabajador antes de pasar al siguiente lote de cinco, y así sucesivamente. ¿Entendido,
trabajadores?
Los trabajadores asintieron y comenzaron a concentrarse en los peniques nuevamente.
“Y los gerentes, asegúresen de cronometrar todo el tiempo que su respectivo trabajador está
volteando peniques. Comenzando cuando entra el primer penique y se está volteando y termina
cuando se pasa el último penique al siguiente trabajador".
"Hmmm, creo que sé a dónde va esto", se dijo Frank.
"El tiempo no espera a nadie", interrumpió Joakim. "¡En sus marcas, listos, fuera!"
Esta vez hubo más sonidos de los peniques, pero aún así un fuerte enfoque y silencio de
todos en el grupo. Cuando Adam volteó su último penique, animó a los demás. "¡Venga! ¡Métele el
pecho, César!
No pasó mucho tiempo antes de que terminara la
iteración de cinco peniques y se agregaran los
resultados.
"¿Qué? Eso no se ve bien ", gritó César mientras
miraba los números. "¿Estás seguro de que has
cronometrado eso correctamente?" preguntó, mirando
primero a Marcus y luego a Joakim.
"Te aseguro que es correcto. Discutamos esto más
adelante después de la próxima iteración", respondió
Marcus. "Esta vez haremos un solo penique en ese
momento. Voltéalo y pásalo. ¿Entendido, trabajadores?
“Como antes, gerentes, midan todo el tiempo que trabaja su empleado. ¡En sus marcas,
listos, fuera!"
Silencio total, excepto por el sonido continuo de peniques deslizándose alrededor de la
mesa. Después de lo que pareció poco tiempo, terminaron. Joakim recopiló los tiempos para cada
trabajador y los agregó al rotafolio.
"¡No puedo creer eso!" Frank sonó escéptico y casi como si se sintiera engañado.
"¿Cómo puede ser eso cierto?" Los otros también parecían bastante sorprendidos.
"Es correcto, está bien. Discutamos qué podemos aprender de esto ", dijo Joakim.
“Primero, mire la hora en que llega el primer penique al cliente. ¿Qué sucede con eso
cuando cambiamos a lotes más pequeños? Marcus preguntó retóricamente y señaló las filas
resumidas.
“Se cae, muy abajo! Cincuenta contra cuatro; ¡eso es increíble!" Frank sacudió la cabeza con
incredulidad.
"¿Y qué pasa con el tiempo total?"
"Bueno, eso también cayó, por supuesto", dijo Daphne, no tan impresionado.
"Pero no tan dramáticamente como el momento de la primera entrega", Frank todavía no
podía creer ese número. Lo miró una y otra vez.
"Y ahora, eche un vistazo a los tiempos de los trabajadores individuales", dijo Joakim,
dándoles unos segundos para reflexionar.
"¿Cuál es la tendencia común? No señalar con el dedo a nadie en particular. Él tosió y le
guiñó un ojo a Daphne. Ella entendió el chiste y lo rechazó.
“Bueno, por extraño que parezca, esos tiempos suben al mismo tiempo que los otros bajan.
¿Como puede ser?" César miró a Marcus y Joakim en busca de respuestas.
"Lo que le hemos mostrado con este ejercicio simple es que cuando disminuye el número de
elementos de trabajo en curso simultáneos o simultáneos, el tiempo de entrega disminuye". Marcus
explicó. "Tenga en cuenta que estamos haciendo la misma cantidad de trabajo, pero trabajando de
una manera diferente, con lotes más pequeños, con menos trabajo en proceso al mismo tiempo".
"O WIP, como lo oirán referirse en la comunidad kanban", agregó Joakim.
RECUERDA El trabajo en proceso (WIP, “Work in process”) es la cantidad de

elementos de trabajo que tienes al mismo tiempo. Menos trabajo en el proceso
conduce a un flujo más rápido a través de su proceso: menor tiempo de entrega.
"No sería una gran comunidad si no tuviera sus propios acrónimos extraños de tres letras, ¿verdad?"
Marcus dijo, con una gran sonrisa en su rostro.
"Como has visto, esto tiene un efecto dramático en el tiempo total, que en este caso pasó de
50 a 20 segundos". Joakim señaló el tablero. “Pero también sucedió otra cosa. Cuando trabajamos
con grandes lotes de 20 peniques, entregamos la primera y el último penique al mismo tiempo; pero
con elementos más pequeños, obtuvimos el primero después de 4 segundos. Menos de una décima
parte del tiempo para la primera entrega cuando se realizan lotes de 20 peniques".
"Lotes más pequeños", Marcus hizo un movimiento de contracción con los brazos, "con
menos trabajo en proceso, ambos te darán una mejor velocidad total y te permitirán ser más ágil,
porque puedes entregar primero las cosas pequeñas e importantes". ¿Ves por qué esto podría ser una
ventaja? “No solo eso”, continuó Marcus, “¿pero qué pasaría si hubiera algo mal con la forma en
que arrojaste los peniques? ¿Qué pasaría si el cliente esperara que se voltearan para estar al borde,
qué habría sido diferente con diferentes tamaños de lote?
"Debido a que no entregamos hasta que todos terminamos con nuestras contribuciones
individuales, tendríamos que hacerlo de nuevo", dijo Daphne. "En la primera iteración, eso es".
"Finalmente, dejamos de enfocarnos en usar a cada trabajador de la manera más eficiente
posible", dijo Joakim, dirigiendo su comentario a Cesar. “En la primera iteración hubo mucha
espera hasta que el último trabajador hizo algún trabajo, pero cada trabajador fue eficiente y trabajó
en todo el lote antes de entregarlo. Por otro lado, en la última iteración, cuando el tiempo de entrega
fue el más corto, cada trabajador trabajó durante más tiempo, lo que los hizo menos eficientes como
individuos pero más efectivos como equipo ".
RECUERDA Optimizar su proceso para un flujo más rápido puede conducir a una
menor utilización de los recursos.
"Odio llover en tu desfile, pero ..." Adam se echó hacia atrás y

cruzó los brazos sobre su pecho. Soltó un gran suspiro.
"Nuestro trabajo, la ‘realidad’, es un poco más complicado que
esto. ¿Espero que te des cuenta de eso? Adam sonaba cansado.
"¿A qué te refieres? Por favor explique." Marcus intentó
abrir una discusión.
"Para empezar, los elementos no llegan en un flujo continuo
como ese. Van y vienen entre nosotros. Hago un poco de
prueba, luego hay algo más de codificación, más pruebas
nuevamente y tal vez incluso requisitos cambiantes.
“Segundo, los elementos que manejamos varían mucho en tamaño. Los peniques y el trabajo
son exactamente iguales todo el tiempo".
"Buenos puntos", interrumpió Joakim, cuando vio a César mirando su reloj. "Y tienes razón.
Esta es una simplificación, una simulación que tiene como objetivo mostrar un principio único: que
menos trabajo en el proceso conduce a tiempos de entrega más bajos. En realidad, hay muchas otras
fuerzas en juego, y hay que hacer compensaciones, pero el principio básico aún se mantiene”.
"También hay muchas otras ventajas al acortar los plazos de entrega y limitar la cantidad de
trabajo en proceso, pero no tenemos tiempo para eso ahora". Marcus trató de concluir la discusión.
“Este ejercicio se usa como una revelación, y por ahora lo importante es que entiendas el principio.
Volvamos a la práctica nuevamente y reunámonos alrededor del tablero; ¿Cómo puedes aplicar esto
a tu trabajo y a tu tablero?
Limite el trabajo en proceso
* Esforzarse por trabajar con menos elementos al mismo tiempo

* Los lotes más pequeños significan plazos de entrega más cortos
* La eficiencia de los recursos disminuye mientras que la eficiencia
del flujo aumenta
* Guegos/simulaciones como Pase los Peniques pueden ser una
excelente manera de enseñar conceptos abstractos a las personas
1.6 Trabajo en Proceso

Volvieron al tablero.
"¿Dónde están nuestros peniques?" Adam dijo dramáticamente, subrayando el hecho de que todavía
no confiaba completamente en el resultado, al menos no todavía.
¿Cuáles son los peniques en este tablero?" Joakim preguntó al grupo, ignorando el comentario de
Adam.
"Son las tarjetas", dijo Beth.
"¿Que hay de ellos? ¿Qué aprendiste en el juego? Preguntó Marcus.
"Bien, veamos si entiendo esto", comenzó Frank. “Si queremos que el trabajo fluya
rápidamente en todos los ámbitos, deberíamos hacer menos elementos al mismo tiempo. Pasando de
20 peniques a 5, por así decirlo ”. Miró a Joakim y Marcus.
"¿Estás de acuerdo?" Joakim miró al grupo. Parecían de acuerdo.
"¿Pero cómo hacemos esto en la práctica?" Eric quería saberlo. "¿Qué
cambiamos?"
"Bueno, si todos estamos de acuerdo en que es una buena idea", respondió
Daphne, mirando brevemente en dirección a Adam, "eso debería ser suficiente,
¿verdad?
Acordamos trabajar en menos cosas al mismo tiempo ".
"Sí, todos podrían estar de acuerdo en dejar de comenzar y comenzar a
terminar". Joakim reflexionó sobre este llamado a las armas kanban que tanto le
gustaba, pero las miradas en blanco de la audiencia le dijeron que tenía que dar
más detalles. "En lugar de comenzar con un nuevo elemento de trabajo, podría ayudar a alguien en
el equipo a terminar uno que ya está en progreso".
“Y en lugar de permitirte ser bloqueado”, agregó Marcus, “por ejemplo, al esperar
información o una revisión de alguien, debes tratar de resolver la situación o trabajar en cómo
evitarla en el futuro. Estas son las oportunidades de mejora no realizadas de las que hablamos
anteriormente, ¿recuerdas?
"Esto suena muy bien en teoría", acordó Eric, "pero en la práctica no es tan fácil ayudar a
alguien a terminar algo". Quiero decir, no quiero molestar a Daphne pidiéndole que explique lo que
ha estado haciendo y cómo puedo ayudar. ¿No es mejor si ella termina eso ella misma?"
"Eso es lo que se sentirá a veces, especialmente al principio, pero tienes que comenzar en
algún lado y usar tu propio juicio", explicó Joakim. "En nuestra experiencia, el camino de menor
resistencia es a menudo comenzar un nuevo trabajo, por lo que tenemos que hacer un esfuerzo
consciente al diseñar el trabajo para que sea más fácil ayudarnos mutuamente a terminarlo".
"Lo que nos lleva al siguiente paso para limitar el trabajo en proceso", interrumpió Marcus,
preocupado de que Joakim estuviera a punto de irse por la tangente, "que es utilizar la visualización
para hacer que los límites sean explícitos y específicos. Elegimos un número máximo de elementos
de trabajo que podemos tener en progreso al mismo tiempo ".
"Esta limitación nos ayudará a enfocarnos en terminar las cosas y ayudará a que el trabajo
fluya más rápido a través del sistema". Joakim volvió a la normalidad. “Limitar su trabajo en el
proceso lo ayudará con algunos de los desafíos enumerados al principio. Primero, las cosas
comenzarán a avanzar, así que dejarás de tener gente respirando en tu cuello".
Joakim se acercó al tablero y señaló el primer elemento. “Cuando las cosas comiencen a
salir de su sistema de manera regular, la demanda de estimaciones y predicciones precisas
disminuirá, en nuestra experiencia. En segundo lugar, no se sentirá abrumado por el trabajo porque
ahora tiene un límite en cuántas cosas trabajará al mismo tiempo. Si alguien quiere agregar un
Trabajo en Proceso 29
nuevo elemento de trabajo, también tendrá que decidir qué se saca".

Joakim agregó puntos al rotafolio * A menudo entregamos tarde
mientras hablaba.
"Lo que, a su vez", interrumpió * Las estimaciones son a menudo inexactas
Marcus, con una sonrisa feliz en su
rostro, "facilitará la priorización. Menos * El equipo está inundado de trabajo
elementos para empezar, pero ahora
tiene algo para mostrar y razonar. El * Las prioridades no están claras
trabajo que estás haciendo está ahí, en el
tablero". * El trabajo llega al equipo desde todas partes
"¿Pero cómo sabemos cuál debería ser
ese número?" Beth dijo. * No está claro quién está trabajando en qué
"Depende." Marcus abrió con la
respuesta estándar de cada consultor, se
dio cuenta, y rápidamente trató de pasar
a algo un poco más útil. “En general, un límite inferior es mejor, pero un límite demasiado bajo
podría tener malas consecuencias. Imaginen que todos trabajan en un solo elemento. Eso sería
genial para el flujo; en el momento en que está listo para el desarrollo, los desarrolladores pueden
recogerlo y comenzar a trabajar en él. Y Adam se está preparando para comenzar a probarlo cuando
finalice el desarrollo. ¿Algún problema con ese escenario?
Después de un momento, Frank rompió el silencio. "Parece que hay mucha espera en ese
caso, ¿o me estoy perdiendo algo?"
"No, eso es exactamente correcto". Marcus levantó el pulgar a Frank. “Bajo WIP conduce a
una gran holgura. Lo cual es bueno para los plazos de entrega, pero la mayoría de las empresas
probablemente no estén dispuestas a pagar por personas que están inactivas ”.
“Es necesario equilibrar esos dos uno contra el otro: flujo rápido versus personas que tienen
trabajo por hacer. Desea un límite bajo de trabajo en proceso, pero probablemente no un límite de
"uno", concluyó Joakim.
"Pero eso todavía no nos ayuda a determinar cuál debería ser ese
límite para nosotros", dijo Daphne.
"No, y me temo que no podemos decírtelo". Joakim se encogió de
hombros.
"Eso es algo que debes idear y ajustar constantemente para mejorar
cada vez más tu flujo de trabajo".
"Cambiar el límite de la cantidad de elementos concurrentes.
OK, lo tenemos. ¿Pero de qué a qué? Frank estaba perdiendo la
paciencia.
"¡Tienes que darnos algo!"
"Comience simple", dijo Joakim. “Comience con un elemento cada uno en el tablero. Muy pronto
verá algunos problemas acumulados en algún lugar, donde los desarrolladores tienen dificultades
para mantenerse al día, por ejemplo ".
"¿Qué quieres decir con eso?" Daphne dijo en tono de broma, pero también había algo de
picardía allí. Ella era rápida, y lo sabía.
"Algunas tareas tardan más tiempo en completarse que otras", dijo Joakim. "No es tan
importante donde el flujo se ralentiza o se detiene. Lo importante es lo que haces al respecto".
"Tomemos este ejemplo". Marcus borró las notas del tablero. "Digamos que creemos que
dos elementos son una cantidad razonable para desarrollar al mismo tiempo, porque hay dos
desarrolladores, ¿verdad?" lo comprobó con Daphne.
"Claro", respondió un poco a la defensiva, cautelosa a dónde llevaría esto.
Marcus escribió el número 2 sobre la columna Development.
“Tenemos dos elementos allí en progreso. Ahora los analistas están listos con su trabajo y
quieren impulsarlo al desarrollo. Eso romperá nuestro límite de dos elementos, ¿verdad? Marcus
dibujó una flecha y un signo de interrogación en el pizarrón.
"¿Que hacemos ahora?" Joakim preguntó.

Frank rápidamente ofreció su opinión: “Póngalos ahí. Llegarán tarde o temprano de todos
modos".
"¿Quién más piensa que ‘ponerlos allí’ es una buena idea?" Preguntó Marcus.
"¡Claro que no!" Daphne replicó. "¿No era esa la idea completa con todo este pase de
peniques? ¿Mantener el número de elementos al mínimo?
"Correcto, pero ¿qué podríamos hacer en su lugar, entonces?"
"Elimine otras cosas si lo que viene es más importante", sugirió Eric.
"¿Hacer nada? ¿Espere? ¿Trabajar más despacio? Beth imaginó la escena, y no se sentó bien
con ella.
"¿Vez? Una discusión está lista para tener lugar”, dijo Joakim. "Y ese es todo el límite de
trabajo en proceso: un desencadenante para las discusiones. Preferiblemente discusiones sobre
cómo mejorar su proceso para que pueda mantener el WIP bajo y que los elementos de trabajo
fluyan más rápido. Estro podría ser una discusión sobre qué acción específica tomar para evitar traer
más trabajo al proceso. A veces significará que un desarrollador ayuda a otro desarrollador a
terminar algo, a veces significará reemplazar algo que ya está en el tablero, a veces significará que
los desarrolladores dejan de desarrollar para ayudar con las pruebas—”.
"¡Calma! ¡Eso nunca sucederá!" Daphne lloró; Su voz y su cara le dijeron a los demás que estaba
bromeando.
"¡Como si alguna vez te hubiera dejado!" Adam se apresuró a unirse al chiste.
RECUERDA El límite de WIP no es una regla estricta; Es un disparador para las discusiones.
"A menudo terminamos haciendo muchas pruebas antes de un lanzamiento de todos modos",
intervino Eric, "así que supongo que tendría sentido hacerlo todo el tiempo para evitar el efecto de
salsa de tomate. ¿Ya sabes? Nada, nada, nada, y luego, de repente, ¡BLAM! Todo viene a la vez ".
"Incluso podría haber razones válidas para romper el límite de vez en cuando". Marcus
intentó volver a encauzar la discusión. “Pero si lo hace con frecuencia, es posible que tenga que
revisar el límite y ver si un límite más alto ayudaría a que el trabajo fluya mejor. Si, por otro lado,
rara vez o nunca alcanza el límite, nunca tendrán estas discusiones útiles, y no tendrán la tensión
para mejorar. Entonces es hora de bajar el límite".
"Ahora no deberías tener problemas para encontrar números para tus límites, ¿verdad?" Joakim
miró su reloj y se dio cuenta de que tenían que avanzar.
"Bueno, uno es simple, pero ¿es el número correcto?" Frank comenzó.
"Piense en ello como un límite, y no tratando de encontrar el correcto", dijo Marcus, presionando.
"Como dijimos anteriormente, se inspeccionará y se adaptará con el tiempo. Si decidimos ir
con un elemento cada uno, ¿cómo se puede lograr de una manera simple?
"¿Escribir el número de personas que trabajan en cada columna?" Adam sugirió.
“Sí, ¡gran idea! Como se veria eso? ¿Te importaría ayudarnos? Marcus le entregó un marcador a
Adam y dio un paso atrás.
"Bueno, supongo, porque soy el único que está haciendo pruebas en este momento,
terminaremos con un 1 allí". Adam escribió un gran número 1 encima de la columna Test.
"¡Esperen!" Beth se acercó al tablero. “También hago algunas pruebas de vez en cuando.
Es una buena manera de hacer un seguimiento temprano, y el trabajo de análisis rara vez ocupa todo
mi tiempo porque a menudo tengo que esperar a que se lleven a cabo las reuniones. Creo que 2 es
un número mejor ".
"Si eso es verdad. Vamos con 2". Adam cambió el número.
“Bien, ¿qué hay de ustedes, desarrolladores? ¿Qué es adecuado para ti?" Adam arrojó el bolígrafo
sobre el regazo de Eric, quien instantáneamente se lo pasó a Daphne.
“Dos elementos me parecen un poco bajos. A veces tenemos que esperar a la gente, lo que
significaría que terminaríamos sin nada que hacer. Pero cuatro parece mucho también.
¿Qué te parece, Eric?
“Digo cuatro elementos; Hacemos mucho más que eso hoy. ¡Lo lograremos!" Eric dijo con
confianza.
"Hmmm, escribiré 3, y estaremos atentos a los problemas", dijo Daphne mientras borraba el
número que ya estaba allí y escribió 3 en su lugar.
"En cuanto al trabajo de análisis, creo que un límite de dos elementos parece razonable", dijo Beth,
y rápidamente escribió el número 2 sobre su columna. Nadie parecía oponerse a eso.
"¿Y el resto de ellos?" Frank dijo, dándose la vuelta. Se dio cuenta de que Marcus y Joakim no
estaban cerca del tablero en este momento. "¿Qué debemos hacer con ellos?"
"¿Qué quieres decir?" Joakim parecía bastante feliz de quedarse atrás y dejar que el equipo
lo resolviera solo.
“Bueno, las columnas Todo, Accept y Waiting for Ops, y así sucesivamente. ¿No deberían
tener números también?"
"Podrían", respondió Marcus. "¿Pero por qué? ¿Qué ganarías con eso?
"Eeeh... Pensé que todas las columnas deberían tener un número", confesó Frank.
"Como dijimos: pueden tenerlos, pero no hay una regla", explicó Joakim. “Pon límites a las
columnas donde creas que te ayuda a obtener un flujo más rápido. ¿Qué tal esa columna de Accept,
por ejemplo? ¿Qué haría un límite de elementos allí?
"Veamos." César dio un paso adelante y habló lentamente para sí mismo. "Limitar esa
columna a, digamos, cuatro elementos significa que si está llena de cuatro elementos, entonces ..."
Hizo una pausa y escribió el número 4 sobre la columna.
“Cuando el equipo de prueba quiera agregar otro más, serán bloqueados y las cosas retrocederán,
por así decirlo. Porque el flujo se detiene por ese límite ". César dio un paso atrás. "¿Qué significa
eso?" murmuró para sí mismo.
"¿Cómo lo desbloqueas?" Ofreció Marcus. Los demás guardaron silencio mientras César
seguía pensando por sí mismo.
"Bueno, Beth o reviso los elementos y las acepto …"
"Correcto, para que puedas ver ese límite como una señal para que vengas y hagas tu trabajo
de aceptación". Joakim sugirió lo que él pensaba que César estaba pensando, pero traducido a los
términos que habían estado utilizando para presentar kanban.
"Está bien, pero ¿por qué no tener un límite de uno, entonces?" Adam preguntó.
"Porque ..." Marcus no llegó más lejos antes de que César lo interrumpiera.
"Porque entonces tendré que correr allí en el segundo momento en que algo esté listo para
aceptar, o el flujo de trabajo comenzará a retroceder". Se le encendió un bombillo a Cesar. "Veo.
Muy interesante."
"¿Por qué cuatro?" Frank preguntó.
"No sabemos cuál es el límite adecuado. Pero cuatro parece un comienzo que podríamos
usar y ajustar como mejor nos parezca. Un número menor exige nuestra presencia constante, algo
que a menudo no podemos manejar porque estamos viajando o estamos atrapados en reuniones. Un
número mayor significaría que el equipo pasaría demasiado tiempo sin comentarios de nosotros, lo
que podría significar volver a trabajar si algo está mal; y queremos arreglar eso antes de que se
adentren demasiado en otra cosa".
"Pero, ¿por qué debería haber una columna para las cosas que estás esperando hacer?"
Preguntó Daphne. "Quiero decir, estás esperando que esa columna se llene y luego comiences a
aceptar elementos cuando esté llena".
"Buen punto, Daphne", respondió Joakim. "Esto no es raro en absoluto. Es lo que llamamos una
queue (cola) o un buffer (búfer) de trabajo. Por lo general, se coloca delante de una función que está
limitada de alguna manera, como la columna Accept aquí. Beth y Cesar no pueden estar con
nosotros en todo momento, así que cuando lleguen aquí queremos asegurarnos de que haya trabajo
para ellos. Por lo tanto, creamos un pequeño búfer de trabajo para ellos, y solo los llamamos cuando
está lleno".
"No estoy seguro de que te esté siguiendo aquí, Joakim", dijo César.
"Vamos a visualizarlo y ver si se aclara", dijo Marcus, y se acercó a la pizarra.
Dentro de la columna Accept, Marcus dibujó una columna

Ready y una columna Doing, dividiendo la columna en dos.
Se volvió hacia el grupo y dijo: "Ahora es evidente lo que
está esperando y lo que está en progreso. Cuando la columna
Ready comienza a llenarse, llamamos a Beth y Cesar ".
"¿No es así también en Test y Waiting for Ops?" Dijo
Daphne.
"Podría ser. Podría tener colas donde cree que cumplen un
propósito: por ejemplo, donde hay un recurso limitado o si
desea visualizar la diferencia entre Esperar y Trabajar. Si hay
un traspaso involucrado, por ejemplo, de alguien que está
haciendo Development a alguien que está haciendo Testing,
una cola sería una buena forma de indicar que el trabajo está
Ready para pasar a la siguiente etapa " Joakim miró su reloj.
Limite su trabajo en proceso
* Comienza con: deja de comenzar y comienza a terminar

* Limitar WIP presentará oportunidades de mejora
- Actuar sobre ellos conduce a un mejor flujo
* No hay un límite de WIP correcto para un equipo
* Un WIP más bajo es generalmente mejor. Como una regla de oro:
- WIP demasiado alto deja el trabajo inactivo
- El WIP demasiado bajo deja a las personas inactivas
* Los límites de WIP no son reglas, son desencadenantes de discusiones
Frank asintió con la cabeza; parecía que lentamente estaba llegando a un acuerdo con la explicación
de César. Miró el tablero por un momento. "¿Eso es entonces? Este es el tablero, tenemos nuestros
límites y ¿hemos terminado con eso? "
Acelerar los Elementos 35
1.7 Acelerar los Elementos

"Sí ... esa podría ser la tabla para ti". Joakim dio un paso atrás y cruzó los brazos sobre el pecho.
“¿Qué piensan ustedes de esto? ¿Está todo completo ahí? ¿Es así como ustedes trabajan?
Marcus pasó por los desafíos en el rotafolio y * A menudo entregamos tarde

dijo: "Aunque aún no hayamos resuelto todos los * Las estimaciones son a menudo
puntos de esta lista, ahora debería tener inexactas
herramientas para abordar la mayoría de ellos, * El equipo está inundado de
¿de acuerdo?" trabajo
Hubo un momento de silencio, y luego Adam se * Las prioridades no están claras
aclaró la garganta. "Una vez más, todo esto se ve * El trabajo llega al equipo desde
muy bien, pero sigue siendo una simplificación", todas partes
dijo, y suspiró. * No está claro quién está
"No todo son nuevas características y hacer trabajando en qué
avanzar cosas, ya sabes", continuó. "A veces las
cosas salen mal en la producción, y luego no
importa lo que estés haciendo en este momento o cuántas cosas ya tienes en progreso; lo arreglas!
¡Allí y luego!"
"Así es", interrumpió Daphne. "Seguramente no estamos retrasando el trabajo urgente para no
romper el límite de trabajo en proceso, ¿verdad?"
"Bueno, podrías, pero la mayoría de los equipos no, porque eso sería malo para los negocios. Al
final del día, su resultado final triunfa al mantener su proceso perfecto. ¿Cómo se trata el trabajo
urgente hoy? Marcus se volvió hacia el grupo. "Si estás avanzando felizmente con tus nuevas y
geniales funciones, y de repente recibes una alerta de que el servidor de producción está inactivo,
¿qué harás?"
"¡Dejaré todo y ‘run to the hills’! Eric dijo, Iron-Maiden cantando la
última parte. Había risas por todos lados, porque nadie había visto a Eric
moverse rápido, nunca.
"En serio... dejaré de hacer lo que estoy haciendo y comenzaré a atacarlo",
dijo Daphne. “Ah, lo entiendo. Deberíamos visualizarlo en el tablero.
Comencemos donde estamos, visualicémoslo y expliquémoslo, y así
sucesivamente.
¿Cierto?"
"¡Cierto!" Marcus le dio un cursi letrero de disparar una pistola con la
mano derecha.
Joakim puso los ojos en blanco y siguió adelante rápidamente. “Este es un escenario común. Una
solución común es crear un carril especial en el tablero para cosas urgentes, a menudo denominado
un carril acelerado”.
Marcus, que enfundó su pistola imaginaria, agregó un nuevo carril en la parte superior del tablero
mientras Joakim explicaba.
“La política que insinuaste, Daphne, de que debes abandonar tu otro trabajo y ayudar a resolver el
problema, es bastante estándar; pero a menudo es implícito y no todos lo entienden ni lo acuerdan.
No está claro quién debe actuar y hacer algo al respecto o si se supone que todos deben ayudar.
¿Debería contarse el nuevo elemento contra nuestro límite de WIP o no? Y así. Hay muchas
políticas implícitas en juego ”.
"Uh-oh, sé a dónde va esto". Eric levantó los brazos en el aire. "¿Cuál es el punto de
sentarnos aquí discutiendo los límites si vamos a tener esta escapatoria?"
"¿Qué quieres decir?" Frank preguntó, dándole una mirada desagradecida.
"Chicos", Eric asintió con la cabeza hacia Frank, Beth y César a su vez. “Ustedes podrían
llenar este carril con elementos todo el tiempo. Será su camino rápido hacia la columna de
Development, y lo usarán como locos, ¡para que su trabajo se haga primero! Lo que nos hace saltar
de un elemento a otro, de nuevo. Como la primavera pasada con el lanzamiento del gran Banco 2.0,
¿recuerdan?
Hubo un momento de incómodo silencio.
“Está bien, parece que han habido algunas cosas no tan buenas con el trabajo acelerado en el
pasado. ¿Qué podrías hacer para evitar que vuelva a suceder, entonces? Joakim preguntó.
Eric reflexionando y pensando un poco más en el desafío, alimentado por la culpa de haber
causado el silencio incómodo, propuso: "Poner un límite de algún tipo, supongo".
Siguió una breve discusión en la que el equipo acordó algunas políticas simples sobre cómo
manejar el carril Expedite. Joakim resumió la discusión: "Déjame ver si he capturado tu política
correctamente. Un elemento expedito solo debe usarse para casos urgentes y no debe usarse como
una vía rápida para engañar al sistema. Se establecerá un límite para la cantidad de elementos
expeditos permitidas por mes, ¿de acuerdo? "
“Bueno, por mi parte estoy contento con esa configuración. Les prometo a todos que
manejaremos los elementos expeditos con respeto y no engañaremos al sistema", dijo César y se
llevó la mano al corazón durante la última parte. Las risas que siguieron fueron un alivio de la ligera
tensión que se había infiltrado en la habitación.
"Asegurémonos de comprender las implicaciones de esta política. ¿Qué sucedería si pusieras
un elemento expedito en el sistema? Preguntó Marcus.
“Se hace más rápido. Eso es lo que necesitábamos", dijo César, pero se dio cuenta de que
podría estar cayendo en una trampa. Dos pueden jugar ese juego, pensó, y respondieron una
pregunta. "¿Porque lo preguntas?"
Acelerar los Elementos 37
“Bueno, ¿quise decir qué pasará con el resto del trabajo que ya está en su proceso? Adam, si piensas
en el juego de peniques que jugamos, ¿cómo sería un elemento expedito allí?
Adam pensó por un momento y luego comenzó a razonar en voz
alta. "Supongo que eso sería introducir un nuevo penique que tenía que
ser entregado antes que los demás". El pauso. "Y eso no sería bueno
para el flujo, porque tendríamos que dejar de lanzar los otros
peniques ..." De repente, lo entendió. "Eso haría que todos los demás
peniques se muevan más lentamente a través del sistema".
"¡Correcto!" Dijo Marcus. “Use el carril de aceleración con
cuidado. Claro, llevará ese elemento a través del sistema más rápido,
pero también aumentará el trabajo en proceso, y eso a su vez ralentizará
todo el trabajo que ya está allí".
Joakim pensó que eso sonaba un poco siniestro. "Es decir, asegúrate de saber esto y tenerlo
en cuenta cuando juegues la tarjeta de elemento expedito. Hay momentos en que es lo correcto
hacer para que un elemento valioso o importante salga rápidamente. Pero tiene un costo; asegúrese
de saber que lo estás pagando. Como un peaje, si quieres.
"Y nos aseguraremos de que el carril no se use mal". Eric * A menudo entregamos tarde
se veía feliz. * Las estimaciones son a menudo
"Esta también podría ser una forma de manejar el trabajo inexactas
que se le entrega en el corredor", dijo Marcus, y dibujó un * El equipo está inundado de
pequeño punto cerrado cerca de ese punto en el tablero. trabajo
“Claro, podrías hacerlo, pero ¿vale la pena el costo que tienes * Las prioridades no están claras
que pagar? Se puede tener una discusión con algunos datos * El trabajo llega al equipo desde
reales para respaldarla”. todas partes
* No está claro quién está
trabajando en qué
Carril acelerado
* Forma común de manejar casos especiales
- Como el trabajo urgente
* A menudo se visualiza como un carril separado en el tablero
* Las políticas en torno a ese carril podrían ser:
- Solo un elemento puede estar en el carril a la vez
- Máx. Un elemento acelerado por semana
- No cuente el carril de aceleración contra el límite de WIP
1.8 Métricas
César fue al tablero, lo miró y se dio la vuelta. Él era en modo Jefe-
Dando-Discurso ahora; Podrían decirlo."
Creo que hablo por todos cuando quiero agradecerles mucho por esto, y-"
"Ahora espera un minuto", interrumpió Beth. César parecía un poco
sorprendido, pero de nuevo, esta era Beth. Valía la pena escucharla; lo
sabía por experiencia.
"¿Si?" preguntó, animándola a continuar.
"Sé que solo nos quedan 20 minutos, pero hay un área que
no hemos sido tocados", dijo Beth. "¿Cómo podemos mejorar
esto?"
"¿Qué quieres decir?" Frank estaba sorprendido. "Esto nos dará
mejor control sobre nuestro trabajo que nunca antes. ¡Creo que es
un buen comienzo!"
"¡Es! Pero como lo he entendido, esto debería evolucionar,
¿verdad? " Miró a Joakim en busca de apoyo.
"Sí, pero ..." respondió Joakim, "mientras hablábamos cuando
dibujamos el tablero y diseñamos los elementos de trabajo, y así sucesivamente, todo en el tablero
está sujeto a cambios para mejorar a medida que avanzamos ..."
"¡Excelente!" Beth lo detuvo en seco. "¿Cómo sabemos que vamos por el camino correcto?"
Joakim dijo: "¿Cómo sabes que estás mejorando cuando haces un cambio?"
"Bueno, si lo estamos haciendo mejor que antes", dijo Adam.
"¿Pero contra qué?" Frank respondió. Este era su territorio. "¿Qué significa" mejor" ¿medir?
¿Como sabemos? Necesitamos algunas métricas para saber si estamos mejorando".
"Aquí vamos", dijeron Eric y Adam juntos, y otros se unieron con suspiros y voces abatidas.
Joakim y Marcus se miraron, un poco sorprendidos por la fuerte reacción.
Aparentemente, el equipo había sido sometido a un esfuerzo de toda la compañía para
introducir indicadores clave de rendimiento (KPI)2 que no los ayudaron en absoluto. Debido a que
los KPI tenían que cumplirse, la productividad del equipo había estado sufriendo, así como también
la moral. En poco tiempo, los KPI fueron abandonados.
"Bien, ¿qué dices sobre saltarte eso, entonces?" Joakim trató de dirigir la discusión
nuevamente hacia un camino positivo y esperó para llamar su atención. "No estamos hablando de
métricas como esa. Estas son métricas de ustedes, para ustedes, para ayudarlos a encontrar áreas en
las que mejorar".
"Sí, exactamente", dijo Marcus. “Rastrearlos en el tablero y guardarlos para ustedes si lo
desean. O al menos solo muéstraselos a las personas que elijas”.
"Pero es un trabajo pesado capturar y rastrear", gimió Daphne. "¡Quiero hacer un trabajo real!"
2
Los indicadores clave de rendimiento (KPI) Key performance indicators son una forma común de medir el rendimiento.
Métricas 39
"No tiene que ser así", dijo Joakim. "Con el tablero en su lugar, se han configurado para
rastrear fácilmente al menos dos métricas simples y potentes: tiempo de entrega y rendimiento".
Se acercó al tablero y se llevó un par de notas adhesivas. Mientras hablaba, dibujó una gran
abrazadera debajo de todo el tablero. "El tiempo de entrega es el tiempo que tarda un elemento de
trabajo en pasar de principio a fin, desde la primera columna hasta la última".
"¿De Verdad?" Adam intervino. “El tiempo que toma nuestro trabajo varía mucho. ¿Qué podríamos
aprender de eso?
"Tenga paciencia conmigo por un tiempo", suplicó Marcus. “Comenzar a rastrear los plazos de
entrega puede ser tan simple como anotar la fecha del la tarjeta adhesiva cuando ingresa en la
columna ‘Todo’ y luego anotar la fecha en que ingresa In Production. Trace eso en un diagrama
simple y tendrá una idea bastante clara de cuál es su tiempo de entrega promedio".
Marcus rápidamente dibujó una tabla de croquis de ejemplo en la pizarra.
X = Fecha en que se agregó el elemento de trabajo en producción; Y = tiempo de espera;
"Con un gráfico como este, pueden ver fácilmente las diferencias de tiempo para las diferentes
elementos", explicó Marcus. "Como siempre, esto es más algo de qué hablar que la solución a sus
problemas".
"¿Pero con qué nos ayuda ese gráfico?" Adam se rascó la cabeza.
"Veamos", comenzó Joakim. "¿Qué ves que se destaque en ese gráfico?"
Miraron el tablero, y pronto Frank dijo: "Bueno, esos tres". Señaló las tres X que obtuvieron el
puntaje más alto en el tiempo de entrega. “Parecían tomar mucho más tiempo. ¿Porqué es eso?"
"¿Por qué de hecho?" Joakim preguntó. "Eso podría valer la pena investigar".
"Tal vez todos ellos tenían que ver con un cierto subsistema de la aplicación", ofreció Marcus.
"O estaban mal especificados", dijo Adam, mirando a Beth.
"O incluso carecía de la información de los probadores cuando hicimos la especificación",
respondió Beth sin perder el ritmo. Ambos se rieron al respecto.
"¿Ven?" Dijo Joakim. “Comenzó otra discusión. Pero podrían tener una discusión incluso en
torno a las cosas generales. Por ejemplo, ¿qué se necesitaría para reducir el tiempo promedio de
entrega a la mitad?
"¿Mitad?" Frank sonaba como si pensara que era imposible. "No se puede hacer ahora.
Estamos esperando tanto a Ops y otros que ...”
"Exactamente", lo interrumpió Joakim, "pero ¿qué se necesitaría para cambiar eso?" Dejó la
pregunta pendiente.
Joakim miró su reloj y se apresuró.
“Rendimiento, la velocidad a la que completa el
trabajo, es aún más fácil de rastrear. Cuente la
cantidad de elementos que termina por un
período de tiempo determinado: por ejemplo,
cada dos semanas. O cuatro, si eso te queda
mejor.
"Lanzamos el segundo miércoles de cada
mes", dijo Frank, "por lo que sería un buen
momento, si me preguntas".
Marcus dibujó un ejemplo en el tablero.
“Cuenten los elementos en la columna In
Production cada segundo miércoles y luego
retírelos de la columna. Esto le dará una manera
simple de rastrear el rendimiento".
Adam estaba indeciso. "Una vez más, ¿cómo
nos ayudará eso a mejorar?"
"¿Recuerdas antes cuando hablamos de
reducir el trabajo en proceso para obtener un
flujo más rápido a través del workflow?" Joakim preguntó. "¿Cómo puedes saber si no realizas un
seguimiento de los datos? Claro, puedes sentirlo o intuirlo, pero ¿cómo lo sabrás? ¿Y tus
sentimientos serán suficiente para convencer a otros si es necesario?
"Si has realizado un seguimiento de estas métricas durante un tiempo y promediaste el
resultado, incluso podrías comenzar a hacer predicciones y hacer promesas que puedas cumplir con
las fechas de entrega". ¿No fue ese uno de tus desafíos? " Joakim continuó.
La despedida 41
“Con estas métricas simples”, agregó Marcus, “puedes comenzar donde estás y seguir tu proceso
actual. A medida que cambia, puedes ver fácilmente si has mejorado o no".
"¿Pero no es eso un poco simplista?" Adam seguía escéptico.
"Tenemos algunos sistemas sofisticados en el lugar hoy para rastrear y
medir..."
Eric lo interrumpió. "Y no nos gustaron y no las usamos,
¿recuerdas? Prefiero usar algunas métricas simples para nosotros que
funcionan y que usamos que las estúpidas con las que trabajamos
porque alguien en la gerencia pensó que era una buena idea.
Desconfío de la mayoría de las formas de métricas, pero al menos
siento que puedo vivir con ellas”.
Métricas
* Están allí para ayudar al equipo a mejorar
* Deje que el equipo elija sus propias métricas; no
los use para la evaluación del desempeño
* Dos métricas comunes y útiles son:
- Tiempo de entrega: el tiempo para todo el flujo
de trabajo
- Rendimiento: cuánta o cuántos elementos de
trabajo completa durante un período de tiempo
1.9 La despedida
Hubo silencio de nuevo. Esta vez no es tan incómodo, pero no obstante el silencio. De
repente, Daphne se volvió hacia César. "¿La hora?"
"Hay mucho tiempo, no, espera, ahora mismo hemos pasado dos horas completas en esto",
dijo César, mirando su reloj.
"Hay mucho más de lo que podríamos hablar", dijo Joakim, "pero creemos que este es un
gran comienzo que lo pondrá en marcha, pensamos".
"A medida que progresas y quieres saber más, puedes consultar los principios detrás de Lean
e intentar aplicarlos en tu contexto", continuó Marcus. “Eso puede ser complicado, así que toma
pistas de otros equipos y cómo han aplicado Lean en sus contextos. También puede consultar la lista
de correo kanbandev 3, la Limited WIP society4 , y conferencias sobre el tema".
3
http://groups.yahoo.com/neo/groups/kanbandev.
4
http://limitedwipsociety.ning.com/.
"Con lo que tiene ahora, podría comenzar mañana y continuar mejorando desde allí". Joakim trató
de cerrar la discusión.
"No daré un discurso", dijo César y se levantó. Los ánimos inmediatos de
los demás siguieron, y cuando se calmaron, él dijo: "Pero quiero decir: gracias
chicos. Esta fue una inyección de vitaminas que necesitábamos. Y tenías
razón; podríamos ponernos en marcha en menos de dos horas". Él sonrió.
"Cuando llegue a casa, es posible que desee conocer más detalles, algunos
antecedentes y, tarde o temprano, algunas técnicas avanzadas".
Marcus se acercó a su bolso. "Entonces este libro podría ayudarte".
Le entregó a Cesar un borrador de su próximo libro, Kanban in Action.
"Una última pregunta: ¿en qué deberíamos centrarnos ahora?" Frank preguntó.
"Tiempos de entrega", dijeron Marcus y Joakim en armonia; Joakim continuó. "Tenga en
cuenta todo el proceso e intente acortar los plazos de entrega".
"Y aquí hay una pista: intenta encontrar formas de reducir tu trabajo en el proceso para
llegar allí", finalizó Marcus.
"Gracias." César los miró a los dos a los ojos y se volvió apresuradamente.
En la puerta, se detuvo y se dio la vuelta.
"Oh, es cierto , nunca hablamos de su tarifa", dijo, señalando la tabla detrás de Marcus y
Joakim.
Ambos se dieron la vuelta, y al principio no vieron nada.
Se acercaron a la mesa y encontraron un adhesivo con
algún tipo de número garabateado.
"¿Qué es esto?" Marcus volvió a mirar a César hace un
segundo, solo para ver que la puerta se cerraba detrás de él.
"Parece un número de cuenta en un banco", respondió Joakim. "Pero, ¿qué utilidad
podríamos …"
Ambos lo consiguieron al mismo tiempo.
“Nos pagaron. Creo que es mejor que iniciemos sesión en ese banco de Internet, ¿verdad?
Joakim miró a Marcus, sonriendo.
1.10 Resumen
Dejamos a nuestros héroes allí, y el equipo de Kanbaneros está de regreso a casa, listos para
comenzar con Kanban. Todo este capítulo fue una historia ficticia, e incorporó algunas
simplificaciones y ajustes para que la historia fluya mejor, pero también le mostró cómo puede
ponerse en marcha fácilmente.
Quizás su trabajo, equipo y contexto no sean exactamente los mismos que para los Kanbaneros,
pero puede seguir el razonamiento y ajustarlo usted mismo. No necesitas hacer todo lo que hicieron;
recoge y elige lo que mejor se adapte a tus necesidades.
Resumen 43
Este capítulo tuvo como objetivo comenzar con Kanban. En la siguiente sección del libro,
examinaremos todos los elementos descritos y más en mayor detalle, ofreceremos variantes y le
advertiremos sobre las dificultades comunes. También ofreceremos más información sobre dónde se
originaron los conceptos y cómo se han aplicado en otros contextos.
Le invitamos a probar kanban con lo que sabe ahora, o también puede continuar su viaje en
la siguiente parte del libro. En el próximo capítulo, analizaremos brevemente los orígenes de
kanban y profundizaremos en los principios sobre los que se basa.
También le daremos una hoja de trucos para que pueda comenzar a trabajar en poco tiempo.
Parte 2
Entendiendo kanban
D espués de ayudarlo a conocer kanban, esta parte del libro tratará los detalles de
las teorías detrás de kanban. Pero no se preocupe, aún lo mantendremos práctico y
entraremos en la teoría poco a poco. El enfoque de esta parte son los principios en
torno a los cuales se construye kanban y cómo esos principios se pueden aplicar en
su equipo. Los temas abarcarán desde los fundamentos teóricos de Lean hasta cómo
eliminar adecuadamente un adhesivo de su paquete.
2 Principios de Kanban
Este capítulo cubre

■ Introducción de los principios kanban.
■ Comenzar a usar kanban
■ Definir qué es kanban
En el capítulo 1, te presentamos a kanban a través de una historia corta. El propósito de esta historia
era mostrarle, de una manera práctica, cómo se puede usar kanban para ayudarlo a mejorar.
Esperamos que ya sienta que puede usar kanban ahora; pero probablemente también tengas algunas
preguntas, como
■ ¿Cómo surgieron Marcus y Joakim con todas esas ideas? ¿Los sacaron de la nada o hubo
algún método para la locura?
■ Todo eso sonaba bien, pero mi equipo y su situación no se parecen mucho a los
Kanbaneros; ¿Cómo puedo usar kanban en mi equipo? ¿Qué necesito cambiar?
■ ¿Eso fue todo? Parecía un poco simplista, ¿no? ¿Cómo podemos ampliar esto?
Todas estas preguntas y muchas más se abordarán en el resto de este libro. En este capítulo,
queremos mostrarle los principios en los que se basa kanban, recordando lo que hicimos con los
Kanbaneros.
47
48 CAPÍTULO 2 Principios de Kanban
Pero no temas, esta no es una larga reseña teórica sobre todo lo de kanban. Si realmente lo
desea, siempre puede ir directamente a la sección 2.2 y omitir la teoría. Seguiremos manteniendo la
parte de la teoría breve y práctica; Este es un libro práctico que se centra en las necesidades
prácticas. Es por eso que mantendremos la teoría al mínimo y se la serviremos en trozos pequeños,
según lo necesite. También le daremos una receta rápida en este capítulo sobre cómo puede
comenzar a usar kanban rápidamente.
Te acuerdas de los Kanbaneros, ¿no? Volverán al texto a lo largo del libro para hacer
preguntas, desafiarnos y presentar problemas prácticos en su nombre. Aquí están de nuevo:
Si hubiéramos introducido otro proceso, como Scrum, XP o incluso Rational Unified

Process, el primer capítulo se habría visto diferente. Nos hubiéramos centrado en cómo debería
funcionar el proceso, qué hacer y qué no hacer, qué tan largas son las iteraciones o los sprints,
cuáles son las tareas para el rol del Dueño del Producto, etc.
Kanban no es así. No prescribe muchas cosas en absoluto; es más como un metaproceso que
se puede aplicar a cualquier proceso con el que esté trabajando hoy. Esta es una gran noticia, porque
significa que puede comenzar donde está hoy, sin cambiar nada, y mejorar desde allí. No se
necesitan procesos nuevos, roles nuevos ni reorganizaciones problemáticas.
¿Kanban, kanban o sistemas kanban?

Si lees el texto detenidamente, podrías notar que estamos deletreando kanban con una k minúscula
en este libro. La comunidad kanban está mejorando y evolucionando continuamente, por lo que las
cosas cambian mucho. Hemos interpretado el conocimiento actual de la siguiente manera:
■ El método Kanban (K mayúscula): un método para crear un cambio evolutivo en su
organización, formulado por primera vez por David J. Anderson y documentado en su libro
Kanban: Cambio evolutivo exitoso para su negocio tecnológico (Blue Hole Press, 2010,
http://amzn.com/B008H1APT0).
■ Kanban (a veces minúscula k, a veces mayúscula K): a veces se refiere a un "sistema de
gestión de procesos visuales que dice qué producir, cuándo producirlo y cuánto producir"
(la última vez que revisamos Wikipedia de todos modos), a veces a la señal visual real.
■ Sistema kanban: el sistema que está configurado para rastrear el trabajo en proceso. Un
ejemplo de esto podría ser un tablero kanban, las tarjetas y las políticas en torno a su
trabajo. Todo eso es tu sistema kanban.
Los principios de kanban 49
(continuando)
En teoría, estas cosas tienen significados bastante diferentes; pero en la práctica, las personas en la
comunidad a menudo no distinguen entre ellos. Lo que la gente suele llamar "usar kanban" es usar
algún tipo de sistema kanban para gestionar y optimizar los kanbans (las señales visuales) para
mejorar evolutivamente. A eso nos referimos cuando usamos la palabra kanban.
Si eso fue confuso para usted, no se preocupe: puede leer el libro y decidir qué es kanban, y le
prometemos que no habrá una prueba al final.
La conexión Japonesa
Probablemente deberías saber algo sobre la palabra kanban en sí misma, si no por otra razón que
no sea para que puedas impresionar a tus amigos con tu conocimiento del japonés. Kanban son dos
palabras japonesas juntas: kan, que significa visual, y ban, que significa tarjeta.
En conjunto, se convierte en algo así como "tarjeta visual" o "tarjeta de señalización".
Kanban, como concepto, proviene de Toyota, donde se inventó como un sistema de programación
para la fabricación justo a tiempo en el Sistema de producción de Toyota (TPS). Cuando los
investigadores en Occidente estudiaron TPS, lo llamaron Lean Production System, más tarde Lean
Fabricación y Lean Thinking.a Kanban tiene su origen en los principios de TPS y Lean, por lo que
encontrará muchas referencias a estos conceptos en este libro y en la mayoría de los otros textos
sobre kanban para el desarrollo de software.
a. John F. Krafcik, "Triunfo del Sistema de Producción Ajustada", Sloan Management Review 30, no. 1
(1988): 41-52. James P. Womack, Daniel T. Jones y Daniel Roos, La Máquina que Cambió el Mundo
(Scribner, 1990, http://amzn.com/B001D1SRRS).
Aunque kanban no prescribe muchas reglas o prácticas concretas, aún puede mejorar mucho al
usarlo. ¿Como puede ser? En el corazón de kanban hay algunos principios que pueden guiarlo sobre
cómo usar kanban para mejorar. Echemos un vistazo más de cerca a esos principios.
2.1 Los principios de kanban

Kanban se basa en tres principios simples:
Cuando nos pusimos manos a la obra con el Equipo Kanbaneros, comenzamos

visualizando su trabajo. Para comenzar, esto puede ser tan simple como crear
notas adhesivas que representen cada elemento de trabajo y un flujo de trabajo
visualizado en forma de tablero para rastrear el estado actual de cada
elemento.
Esta es una excelente manera de conocer su trabajo, aprender cómo funciona su "trabajo" 1 y
comenzar a ver oportunidades de mejora en su flujo de trabajo.
Para muchos equipos que entrenamos, esto crea un gran impacto de inmediato. Simplemente
haciendo que la información sea visible, eso que antes no lo era, puede ayudarlo a resolver muchos
problemas por sí solo.
También hay otros aspectos subyacentes de la visualización, porque también está
comenzando a hacer explícitas las políticas implícitas en torno al trabajo. Es decir, todos podrían
pensar que saben cómo trabaja con una solicitud de función; pero al mostrar el flujo de trabajo en el
tablero en columnas, el proceso real se hace evidente para todos en el equipo. Al hacer esto, usted
hace más evidente cualquier diferencia que pueda tener en las políticas sobre el trabajo. Esto puede
llevar a una discusión que aclara las políticas con las que trabaja, y puede capturarlas fácilmente en
el tablero visual para que todos los miembros del equipo aborden el trabajo de la misma manera.
Con Team Kanbaneros, pasamos por algunas formas comunes de visualizar el trabajo:
el tablero, los elementos de trabajo y el carril de aceleración, por ejemplo. Hay mucho más que
saber sobre esto, y los capítulos 3 y 4 lo guiarán en mayor detalle.
Continuamos con los Kanbaneros jugando un juego llamado Pass the
Pennies (ver el capítulo 13 para más detalles sobre este y otros juegos).
Esto mostró el principio de limitar el trabajo en proceso.
En pocas palabras, el principio establece que usted declara
deliberadamente un límite para la cantidad de elementos en los que
trabajará al mismo tiempo. La primera ganancia aparente de hacer esto es
que con menos elementos trabajados al mismo tiempo, cada elemento se hará más rápidamente. El
Capítulo 5 explicará en profundidad los efectos del trabajo en proceso.
Pero limitar el trabajo en proceso (WIP) también es importante por otras razones más sutiles.
Al establecer un límite de WIP, creará un poco de tensión en su flujo de trabajo; Esto es bueno
(Good ThingTM), porque expondrá problemas en su sistema o, como lo explicamos a los
Kanbaneros, "oportunidades de mejora no realizadas". Puede leer más sobre la limitación de WIP,
las razones para hacerlo y cómo puede visualizar estos límites en el capítulo 6.
Al limitar WIP comenzarán a surgir oportunidades de mejora. El flujo a través del workflow
se detendrá (las notas adhesivas se mueven lentamente sobre el tablero), comenzará a retroceder
(muchas notas adhesivas en ciertas columnas) o se detendrá por completo (elementos en espera).
Todos estos son indicadores que pueden mejorar su sistema. Lo que haga para solucionar estos
problemas determinará si mejora.
Pero si desea mejorar, debe saber cuál es el objetivo, y aquí es donde entra
en juego el último principio de kanban: administre el flujo rápidamente y sin
interrupciones en el flujo de trabajo.
Este es el comienzo de su viaje para mejorar continuamente el flujo de
trabajo. La mala noticia es que nunca terminarás con esta tarea.
Su flujo de trabajo siempre se puede mejorar; siempre hay un cuello de botella
Ver John Seddon, Libertad de Comando y Control: Una Mejor Manera de Hacer que el Trabajo Funcione (Vanguard
Consulting Ltd, 2003, http://amzn.com/0954618300).
Los principios de kanban 51
que te frena.2 La buena noticia es que los problemas se te revelarán visualmente en el tablero. No
solo eso, sino que a menudo el mayor problema se revelará primero: resuélvalo y habrás realizado
una gran mejora en el flujo a través de tu workflow.
El equipo Kanbaneros descubrió varias oportunidades de mejora, como recordará del
capítulo 1:
■ Se dieron cuenta de que la forma en que se realizaba el despliegue estaba obstaculizando
severamente el flujo. Para los Kanbaneros, podríamos ver esto en el tablero con todos esos
adhesivos en la columna Waiting for Ops. Se podría decir que ya sabían esto, pero ahora
tienen datos constantemente en la cara, exigiendo acciones.
■ Hablaron brevemente sobre los errores, que se manejaron de manera diferente a los
elementos normales. Se podría decir que los errores están en una clase de trabajo diferente a
la de las otros elementos y tal vez se les debe dar prioridad sobre otros elementos en la
priorización.
■ Los Kanbaneros establecieron límites de WIP para ayudar a que su trabajo fluya sin
problemas; por ejemplo, pusieron en cola cuatro elementos para su aceptación para que
Cesar y Beth no tuvieran que correr al equipo varias veces al día. En cambio, ahora tienen
una cantidad razonable de trabajo que hacer, esperándolos cuando vengan por el equipo.
Ayuda a que el trabajo fluya más rápido a través del workflow.. Eso no suena tan duro, ¿verdad?
Siempre puedes encontrar ayuda en el capítulo 7, así que, por supuesto, ¡haz que suceda!
Hay muchas cosas que puedes hacer para lograr esto. Al trabajar con este principio, puede
encontrar inspiración en Pensamiento Lean para ayudar a que su trabajo fluya mejor al eliminar el
desperdicio en sus proceso. También puede echar un vistazo a la Teoría de las Restricciones3 e
identificar, explotar y aliviar los cuellos de botella en su sistema. Las prácticas del movimiento
comunitario de desarrollo de software ágil pueden ayudarlo a mejorar la colaboración y la calidad y,
por lo tanto, mejorar el flujo de su sistema. Depende de usted qué ruta tomar para mejorar su
sistema. Lo importante es que reaccione a las señales que su trabajo lo está enviando y lo mejore.
En realidad, verás mucho los principios combinados entre sí. Por ejemplo, para obtener un
flujo más rápido, limite su WIP, que también se muestra visualmente en el tablero.
Con un flujo de trabajo visualizado, un límite para el WIP y un enfoque en mover el trabajo
a través de su workflow, se ha preparado para detectar fácilmente las oportunidades de mejora. La
forma en que haces eso depende de ti, pero no te dejaremos en alto. Hemos reunido los capítulos 3–
7 con consejos, prácticas, patrones y soluciones comunes para mejorar el flujo en su workflow.
La búsqueda de mejoras pronto lo llevará fuera de los límites de su propio equipo. Para que
pueda obtener un flujo más rápido, es posible que tenga que interactuar con otros equipos o
funciones a su alrededor de una manera diferente. Un primer paso hacia esto es incluir equipos o
funciones antes y después de los suyos en su tablero. O tal vez incluso podría tener un tablero para
2
Bueno, cuando el software, o mejor dicho, las soluciones se materializan instantáneamente cuando las imaginas,
suponemos que no hay más cuellos de botella. Sin embargo, probablemente no sucederá pronto.
3
Visit http://en.wikipedia.org/wiki/Theory_of_constraints para leer sobre the Theory of Constraints (TOC).
todos los equipos en su departamento, agregando el estado de los equipos allí.
Podría ser el comienzo de una transformación que finalmente puede llegar a toda la empresa, de
forma evolutiva. Pronto se encontrará enseñando kanban a otros y participando en la gestión del
cambio a escala de toda la organización. Puedes leer sobre esto en el capítulo 13.
Tres principios? Pensé que eran cinco propiedades. ¿O fueron seis prácticas?
Kanban es bastante joven como metodología utilizada en el negocio del software. Hay una
comunidad vibrante y se descubren nuevas cosas y se ponen en práctica continuamente. Esto es
algo bueno y está muy en línea con los principios de Lean y el pensamiento de mejora continua.
Los tres principios básicos que describimos en esta sección constituyen la base en la que se basa
kanban. Recientemente, David J. Anderson y otros han extendido los tres principios básicos a
cinco propiedades y luego a seis prácticas; ahora se conocen como las prácticas básicas. a Son los
siguientes:
1 Visualizar: descrito anteriormente.
2 Limite el trabajo en proceso: descrito anteriormente.
3 Administrar flujo: descrito anteriormente.
4 Haga explícitas las políticas de proceso: con las políticas explícitas, puede comenzar a
tener discusiones sobre su proceso basado en datos objetivos en lugar de lo que piensa,
siente o tiene evidencia anecdótica.
5 Implemente bucles de retroalimentación: esta práctica se enfoca en obtener
retroalimentación de su proceso: por ejemplo, en lo que se llama una revisión de
operaciones, que es una especie de retrospectiva para el proceso en sí.
6 Mejore en colaboración, evolucione experimentalmente (usando modelos y el método
científico): esta práctica lo alienta a usar modelos como la Theory of Constraints o Lean
para impulsar a su equipo hacia nuevas mejoras.
Esas son tres prácticas más agregadas a los principios de los que hemos hablado hasta ahora. Tenga
en cuenta que esto es válido para el Método Kanban de "cambio progresivo y evolutivo para
organizaciones tecnológicas de desarrollo/operaciones", y en ese contexto las tres últimas prácticas
son importantes.
Como probablemente ya haya notado, adoptamos un enfoque práctico y pragmático, y para
nosotros las últimas tres prácticas encajan perfectamente en los principios básicos:
■ Hacer explícitas las políticas de proceso: hacer de las políticas explícitas es de lo que se
trata gran parte de la visualización del trabajo. En la mayoría de los casos, el paso
importante podría no ser escribirlo en el tablero (aunque eso también es importante), sino
más bien mantener debates que le permitan llegar a un consenso sobre la política que
pretende implementar. Aunque es genial hacer esto ... umm ... explícito, creemos que es
parte del principio de visualización.
a. Ver http://mng.bz/EkgB.
Comience de inmediato 53
(continuando)
■ Implemente bucles de retroalimentación: esto es parte del paso "administrar flujo" para
nosotros. Para ayudar a que el trabajo fluya, los bucles de retroalimentación son esenciales
y deben ser buscados e implementados donde sea necesario.
■ Mejore en colaboración, evolucione experimentalmente (utilizando modelos y el método
científico). Estamos totalmente de acuerdo en la importancia de esto. Pero esta mentalidad
está tan profundamente arraigada en los principios Lean que subyacen a kanban, que no
creemos que sea un principio de kanban per se, sino más bien el medio ambiente y el
ecosistema del que surge kanban.
Para complicar aún más las cosas, David J. Anderson y otros ahora están usando "principios" para
describir algunos otros principios:
■ Comience donde está.
■ Acuerde buscar un cambio evolutivo incremental.
■ Inicialmente, respete los roles, responsabilidades y títulos de trabajo actuales.
Y recientemente se agregó un cuarto principio:
■ Liderazgo en todos los niveles de la organización.
Durante nuestro tiempo como practicantes de kanban, los principios de los que hablamos se han
convertido en prácticas, las prácticas han pasado de tres a cinco y luego a seis, el término
principios ha sido redefinido y se ha agregado otro nuevo principio. Tenemos la esperanza que la
discusión sobre estas prácticas no haya terminado. Pero desde esta barra lateral, ahora comprendes
por qué estamos hablando de tres principios (visualizar, limitar el trabajo en proceso y administrar
el flujo) cuando otros hablan de cinco prácticas. ¿O eran las seis?
2.2 Comience de inmediato

Al igual que los Kanbaneros, puede comenzar fácilmente
empezando a terminar de inmediato, debido a la naturaleza
liviana de kanban. De hecho, ¿por qué no comenzar ahora?
No toma mucho, y puedes comenzar fácilmente justo donde
estás hoy. Simplemente comience a enfocarse en hacer las cosas,
realmente, antes de comenzar a trabajar. Haga que ese sea el
lema para usted y su equipo: ¡deje de comenzar; empieza a
terminar! Esta es una manera simple de limitar el trabajo en
proceso, pero puede ser eficaz.
Si quieres ser un poco más concreto y práctico, también puedes hacer un ejercicio similar al taller
que realizamos con los Kanbaneros en el capítulo 1. Aquí hay una breve descripción de cómo se
puede arrancar:
1 Comience visualizando su trabajo. Le pedimos al equipo que creara un adhesivo para cada
elemento de trabajo en el que trabajaran y lo colocara en cualquier lugar del tablero.
2 Asigne su flujo de trabajo al tablero. Una manera simple de hacer esto es crear una
columna para cada etapa de su flujo de trabajo. Mueva los adhesivos que se encuentran
en las diferentes etapas a las columnas correctas. En esta etapa, los Kanbaneros hablaron
mucho sobre cómo funcionaba el trabajo, y eso es algo bueno que aumenta su conocimiento
del proceso. Pero resista el impulso de optimizar su flujo de trabajo antes de que pueda ver
lo que está sucediendo. Después de este ejercicio, puede terminar con una tabla como esta:
Eric: Dulce nombre para el último,

¿eh?
Buen trabajo, equipo! Y sí, es

simplista. Lea más sobre esto en el
capítulo 3.
¡Bueno, eso no fue tan difícil! Pero ahora es un poco simplista, ¿verdad?
UNA PALABRA DEL ENTRENADOR Asegúrese de dibujar el tablero

juntos como un equipo. No permitas que una persona haga esto sola,
especialmente tú, si eres un entrenador externo. La aceptación del equipo sufrirá
mucho. Confía en nosotros; ya hemos cometido ese error demasiadas veces.
Una manera simple de hacer de este ejercicio un esfuerzo de equipo es pasar el lápiz mientras
dibuja el tablero.
Pero, ¿cómo sabemos si ese límite es el correcto?
3 Realice un par de ejecuciones en seco con
algo de trabajo que haya pasado por su flujo
de trabajo para ver que el workflow
realmente coincida con su forma de trabajar.
Cambiar según sea necesario. No tuvimos
tiempo de hacer esto con los Kanbaneros,
pero creemos que es una buena práctica, y
rápidamente muestra si acertó el flujo de
trabajo. Recuerde, en esta etapa su objetivo
es rastrear cómo trabaja realmente.
¿No sabes? Lee más sobre esto en el capítulo 4, y ajustar según sea necesario
Resumen 55
4 Decida un límite de trabajo en proceso: en cuántos elementos de trabajo usted, como

equipo, debería estar trabajando al mismo tiempo. Pasamos mucho tiempo aquí mientras
ayudamos a los Kanbaneros, pero no lo piensen demasiado. Es mejor conseguir algo allí y
mejorar según sea necesario. Por ahora, vaya con dos elementos de trabajo por persona en el
equipo (seis en nuestro ejemplo), por ejemplo, y distribúyalos de manera uniforme en todas
las columnas. U obtenga algunas buenas ideas en el capítulo 6, que trata sobre los límites de
WIP.
5 Como medida adicional, cree algunos
avatares, pequeñas imágenes de usted
mismo, y adjúntelos a las cosas en las que
está trabajando ahora. Esto lo ayudará a
ver más fácilmente lo que está sucediendo
y a quién recurrir si tiene preguntas sobre
uno de los elementos de trabajo.
Ahí, ahora tienes una tabla kanban simple para
mejorar. Pero incluso esta herramienta simple lo
ayudará a detectar problemas y mejorar ¿Qué quieres decir?
continuamente, en pequeños pasos. El resto del ¿Algunos dibujos animados cojos o algo así?
libro lo ayudará a aprender cómo hacer eso. ¡Crece, ya!
2.3 Resumen
Kanban es un enfoque para el desarrollo de software basado en ideas simples pero
poderosas. Su objetivo es hacer que el trabajo fluya rápidamente a través de toda la cadena de valor,
desde la idea o el concepto hasta el software en producción, deleitando a sus clientes. Las
herramientas que hacen que esto suceda son algunos principios simples pero poderosos: visualizar
su trabajo y políticas, limitar la cantidad de trabajo en progreso y ayudar a que el trabajo fluya
mejor a través del proceso.
Estas herramientas pueden guiarlo a mejorar continuamente su proceso para obtener un flujo
de trabajo aún más rápido y uniforme a través de ese proceso. Esta es una búsqueda interminable
que te ayudará a ti y a tu equipo a mejorar, poco a poco, todos los días.
Ahí, ahora estás listo y corriendo. A medida que avanza su trabajo, mueva los elementos en
consecuencia en el tablero. Tenga cuidado con los problemas que obstaculizan su flujo. Cuando
ocurra un problema, deténgase y hable sobre él; ¡Estas son sus oportunidades de mejora!
No las desperdicies; ¡manéjelas con cuidado!
El resto de este libro está repleto de consejos prácticos sobre visualizaciones, cómo limitar la
WIP y diferentes formas de ayudar a que su trabajo fluya sin problemas y rápidamente a través de
su flujo de trabajo. Nos hemos centrado especialmente en cuestiones prácticas para asegurarnos de
que pueda utilizar las prácticas, los patrones y las herramientas que describimos de inmediato con
su equipo.
Entremos y comencemos a ver la visualización, un tema que hará que tus jugos creativos
funcionen.
3 Visualizando tu trabajo
■ Uso de visualización para transparencia y
el intercambio de información
■ Hacer explícitas las políticas
■ Uso de radiadores de información.
■ El tablero kanban
■ Asignación de su flujo de trabajo al
tablero kanban
Lo primero que te sorprende cuando entras en la planta de ensamblaje de Motomachi Toyota es

cómo Toyota usa visualizaciones y sonidos para rastrear el progreso, mostrar el estado y
comunicarse. La compañía tiene grandes letreros en todas partes que explican para qué son las
diferentes partes de la planta, y grandes tableros Andon que muestran el estado de la producción,
incluso cuándo y dónde se necesita asistencia. Cuando quita una herramienta de su lugar, se revela
una imagen brillante de la herramienta para que todos sepan que la herramienta se ha ido de su lugar
y recuerden volver a colocarla.
Si un trabajador encuentra un problema, tira de un cable, el famoso Andon cord o stop-the-

line cord (cable de parada de línea), y su capataz y compañeros de trabajo son alertados por una
melodía, única en esa estación de trabajo, y por luces intermitentes en el tablero Andon que
56
57
indica qué estación tiene problemas. Al mismo tiempo, se enciende una lámpara amarilla al lado de
la estación; y si el problema no se resuelve hasta que el vehículo en la línea de ensamblaje pase un
marcador para la siguiente estación, la luz se vuelve roja y la línea se detiene.
Otra gran placa en esta planta tiene la
forma de un automóvil visto desde el frente;
uno de sus "faros" es un reloj. Se cuelga del
techo, grande y visible para todos,
mostrando información como el número
planeado de automóviles para ensamblar, el
número real ensamblado, el plan para el
turno actual y el porcentaje del objetivo
alcanzado. Una luz indica si se necesitará un
cuarto o media hora de tiempo extra para
alcanzar el objetivo de hoy.
Estas son solo algunas de las visualizaciones utilizadas para ayudar a los trabajadores a
actuar y tomar decisiones; Hay muchos otros en toda la planta. La visualización es tan importante
para "el estilo Toyota" que uno de sus principios es "Usar el control visual para que no haya
problemas oculto."1 Esto parece estar profundamente arraigado en la cultura japonesa. Si alguna vez
has estado en Japón, es posible que hayas notado que los japoneses usan todo tipo de
visualizaciones ingeniosas para ayudar en la vida cotidiana. Cuando los japoneses usan el término
visualización, o mieruka en japonés ( 見える化 ), a menudo significan no solo presentar las cosas en
una forma visual fácilmente comprensible, sino también el objetivo de una mayor transparencia e
intercambio de información entre los empleados y las partes interesadas para aumentar la
efectividad de la organización. El término también se refiere a una serie de procesos que hacen uso
de los resultados visualizados, reflexionándolos e iniciando acciones de manera adecuada.
Para nosotros, esta es la esencia del principio "Visualizar" en kanban: hacer que toda la
información necesaria sea visible cuando la gente la necesita, permitiendo una colaboración efectiva
y una mejora a través de la comprensión del funcionamiento del trabajo. Para lograr esto con
kanban, debe hacer explícitas las políticas y utilizar radiadores de información.
Si recuerdas del capítulo 1, cuando presentamos kanban al equipo Kanbaneros, comenzamos
visualizando su trabajo. Al principio, crearon una nota adhesiva para cada elemento en el que
estaban trabajando en este momento. Hemos visto muchos equipos experimentar "¡Ajá!" momentos
de visualizar trabajos como ese. Preguntas como "¿Estás trabajando en eso? Yo
también. ¡Quizás deberíamos cooperar! son llevados rápidamente a la superficie.
Este capítulo le mostrará la herramienta de visualización más conocida para los practicantes
de kanban: el tablero de kanban. Después de leer este capítulo, podrá configurar y comenzar a
utilizar un tablero kanban personalizado para su forma de trabajar.
1
Jeffrey Liker, The Toyota Way: 14 principios de gestión del mayor fabricante del mundo (McGraw Hill, 2003,
http://amzn.com/0071392319).
58 CAPÍTULO 3 Visualizando tu trabajo
3.1 Hacer políticas explícitas

A menudo, cuando las personas trabajan juntas, están en juego muchos supuestos y políticas
implícitas. Las personas hacen suposiciones sobre todo, desde cómo se supone que las personas
deben limpiar (o no) los inodoros después de usarlos, hasta lo que significa asumir la
responsabilidad de terminar un trabajo importante. A veces, estos supuestos son inconsistentes o
incluso conflictivos, lo que puede conducir a malentendidos y trabajo en equipo ineficaz,
discusiones emocionales y subjetivas de los problemas, etc.
Si puedes hacer que estas políticas sean explícitas, por ejemplo, visualizando su flujo de
trabajo en un tablero kanban y hablando de lo que significan los diferentes pasos, las inconsistencias
tienen que tratarse y los conflictos pueden resolverse. Una vez que las políticas se aclaran, es mucho
más fácil mantener una discusión racional y empírica sobre cómo mejorarlas. Esto proporciona una
buena base para mejoras de procesos colaborativos.
Recuerde que las políticas son solo eso: políticas, no
reglas que deben seguirse. Pueden y deben romperse de vez ... el código es más lo que
en cuando, pero la decisión de hacerlo debe tomarse llamarías "pautas" que reglas
intencionalmente y, a menudo, con la consideración reales.
cuidadosa de todo el equipo. Capitán Barbossa en
Los Kanbaneros en el capítulo 1 hicieron explícitas Piratas del Caribe
muchas de sus políticas al mapear su flujo de trabajo como
columnas en el tablero. Si recuerdas, tuvieron una larga discusión sobre cómo se comportó su
trabajo en diferentes situaciones. Mucho sucedía en esas discusiones bajo la superficie, porque el
equipo no había formalizado la forma en que trabajaban. En el proceso de hacerlo, obtuvieron una
idea de lo que funcionó y lo que no funcionó.
Otras políticas que los Kanbaneros hicieron explícito se referían a los tipos (colores) de sus
elementos de trabajo y cómo deberían ser manejados, los límites para la cantidad de elementos de
trabajo con los que podrían trabajar en ciertas columnas y el carril expedito (un ejemplo de un
llamado carril de nado).
ADVERTENCIA A veces la transparencia puede amenazar a las

personas. Si te has acostumbrado a hacer las cosas a tu manera; tal vez
priorizaste el trabajo a tu manera, hiciste favores para "tu gente" y
lograste pasar desapercibido durante mucho tiempo; hacer que las
políticas explícitas no parezcan algo bueno para ti. Introducir una forma
DESAFÍOS ADELANTE de trabajo abierta y visual puede parecer amenazante. Maneje este
problema introduciendo la visualización en pequeños pasos y deje que el equipo decida
qué visualizar y cómo.
Para nosotros, visualizar el trabajo y hacer explícitas las políticas son inseparables; pero debido a
que la visualización se puede interpretar más estrictamente, la definición oficial de kanban tiene
Hacer políticas explícitas 59
"Hacer explícitas las políticas de proceso" como una de sus seis prácticas principales, junto con
"Visualizar". Como verá a lo largo del libro, muchas de las prácticas y patrones de kanban tratan de
hacer explícitas las políticas y utilizar visualizaciones para hacerlo; La práctica más importante y
obvia es la del propio tablero kanban, un excelente radiador de información.
3.1.1 Radiador de información
Hola, Eric, te he estado buscando. Realmente necesito saber cómo progresa el trabajo con el proyecto Magneto.
Eh ... buena pregunta, tendré que comprobarlo. Déjame contactarte.
Beth: Daphne, cuál es el estado de

... no importa, puedo verlo por mí mismo.
Los equipos efectivos tienen que responder constantemente a los eventos juntos y coordinar
sus actividades. En un entorno acelerado, las reuniones de estatus tradicionales a menudo se sienten
secas y tristes, y la documentación tradicional del proyecto se siente como una sobrecarga
innecesaria, imprecisa e incompleta. Deseas que la información esté actualizada y fácilmente
disponible para todas las partes interesadas en el momento en que sea necesaria.
Un radiador de información muestra información en un lugar donde los transeúntes pueden

verla. Con los radiadores de información, los transeúntes no necesitan hacer preguntas; la
información simplemente los golpea a medida que pasan.
—Alistair Cockburn 2
Los radiadores de información generalmente toman la forma de pantallas o gráficos grandes y
visibles que puede comprender de un vistazo. Pueden ser grandes carteles con gráficos que
muestran el progreso de un proyecto, paredes de fichas que detallan las acciones de un taller o
pizarras blancas con columnas que muestran un flujo de trabajo, con adhesivos que representan los
elementos de trabajo. Se colocan de modo que el equipo siempre pueda verlos, pero también
deberían ser fácilmente accesibles para las partes interesadas externas al equipo.
El radiador de información debe ser fácil de mantener actualizado, de modo que se actualice
constantemente con la información necesaria y valga la pena visitar. Es por eso que muchos equipos
prefieren gráficos dibujados a mano y equipos de baja tecnología, como pizarras, papeles, adhesivos
y tarjetas de índice. Quizás lo más importante, esto también hace que sea fácil experimentar y
mejorar continuamente el radiador de información para que se ajuste a su contexto particular.
Hay muchas herramientas electrónicas que imitan los tableros y paredes de tarjetas. Estas
herramientas son invaluables para los equipos que pueden no estar juntos o que por otras razones
han optado por usarlas en lugar de una herramienta física. Las herramientas digitales pueden ser
excelentes por muchas razones, pero corre el riesgo de que la herramienta decida y ponga límites a
cómo mejorar su proceso. Especialmente al crear un nuevo radiador de información, desea poder
cambiar sus visualizaciones rápida y fácilmente, porque es poco probable que sea perfecto desde el
principio. Elija una técnica (electrónica o física) que no sea difícil de cambiar.
Los Kanbaneros crearon una gran tablero con todo su trabajo en una secuencia de columnas.
Cada uno de sus elementos de trabajo estaba representado con una nota adhesiva en el tablero. A
partir de estas visualizaciones simples y comunes, su estado actual y carga de trabajo fue fácil de
ver y comprender, incluso para alguien que nunca antes había visto un tablero kanban.
Echemos un vistazo a algunas de las cosas en las que pensar cuando crea su radiador de
información.
NO OCULTES TU INFORMACIÓN EN EL REFRIGERADOR

Las herramientas digitales a veces se convierten en refrigeradores de información en los que la
información está oculta. Debe saber dónde buscarlo, debe poder utilizar la herramienta, debe estar
autorizado, requiere esfuerzo para acceder a la herramienta, etc. Es lo opuesto a irradiar
información; no sabes si la información está ahí, y tienes que abrir la puerta y cavar antes de
encontrarla.
Este es un punto importante si ha elegido una herramienta que, naturalmente, no se convierte
en un radiador de información. Muchos sistemas de seguimiento electrónico de hoy en día ofrecen
un tablero o pantalla que se parece mucho a un tablero de adhesivos. Asegúrese de mostrarlo en un
monitor grande cerca del equipo o incluso en la pared con un proyector. Puede leer más sobre
herramientas para equipos kanban en el apéndice B.
2
Desarrollo de software ágil (Addison-Wesley, 2001, http://amzn.com/0201699699).
Hacer políticas explícitas 61
Tarjeta electrónica o física: pros y contras

Existe un gran debate en los equipos de todo el mundo sobre si se debe usar un tablero físico o
electrónico. Debido a que no hay una respuesta correcta para todos, solo puede sopesar los pros y
los contras entre sí y decidir por sí mismo.
Pros con un tablero electrónico:
■ Universalmente accesible y, por lo tanto, una gran ayuda para los equipos que no están
ubicados.
■ Sin pérdida de datos, mientras que con un tablero físico, los adhesivos pueden caer al
suelo.
■ Cálculo automático de métricas.
■ Puede almacenar información y discusiones sobre cada elemento.
Pros con una tablero físico:
■ Generalmente más grande
■ Atrae a las personas de sus escritorios y se convierte en un lugar natural para reunirse.
■ Generalmente es más fácil de configurar: solo necesita una pizarra o una pared.
■ Más fácil de cambiar y ajustar a sus necesidades particulares.
La razón por la que hablamos más sobre los tableros físicos es que, en general, son fáciles de
comenzar y cambiar en esas primeras fases. Pero de nuevo, ¡tú decides por tu equipo!
¿CO-UBICACIÓN? ¡LUJO!
Tal vez usted y su equipo no puedan darse el lujo de sentarse juntos. Puede intentar usar un área o
pasillo común, un lugar donde puedan reunirse fácilmente alrededor del radiador y donde otros
puedan acceder fácilmente. También puede intentar usar una herramienta digital con un proyector o
una pantalla grande.
Déjalo en manos del equipo.

La decisión de usar una herramienta electrónica o no debe dejarse en manos del equipo. Marcus
tuvo la oportunidad de entrenar como contratista en Spotify, donde trabaja Joakim, y descubrió que
dos de los tres equipos a los que estaba asignado usaban una herramienta electrónica.
Ese hecho en sí mismo no fue tan sorprendente, pero el equipo que no utilizó una herramienta
electrónica no se ubicó junto con un miembro del equipo en Alemania y el resto del equipo en
Suecia. Se ajustaba perfectamente a una herramienta electrónica, pero el equipo sintió que usar un
tablero físico y enviar fotos una vez al día era lo suficientemente bueno para ellos.
Los otros dos equipos se sentaron a no más de 10 metros el uno del otro y todavía optaron por
herramientas electrónicas, pero con grandes monitores visibles que les transmitían la información.
Ese equipo tenía fuertes opiniones sobre el uso de un tablero electrónico, y no había razón para que
Marcus los disuadiera de eso.
No hay correcto o incorrecto, solo lo que cree que se adaptaría mejor a su equipo. Asegúrese de
que su información sea visual para que todos en el equipo la vean; de eso se trata la visualización.
NO.PUEDE.PROCESAR.
Evitar la sobrecarga de información. No intente incluir demasiados gráficos, demasiada información
o demasiados detalles en su radiador de información, ya que esto hará que su radiador sea más
difícil de entender.
VE A LO GRANDE
Esto debería ser evidente, pero la experiencia nos dice que es necesario señalarlo a veces: asegúrese
de que la información sea lo suficientemente grande como para verla fácilmente a unos pocos
metros de distancia, que el texto sea legible, y así sucesivamente, para que las personas puedan leer
sin tener que acercarse demasiado y entrecerrar los ojos.
¡ÚSELO O PIÉRDALO!
No utilice información que no sea valiosa para el equipo o las partes interesadas. Hay pocas cosas
más desmoralizadoras que tener que actualizar información que no ve el punto y que a nadie parece
importarle. Vuelva a evaluar constantemente si debe mantener el radiador como está o si debe
cambiarlo de alguna manera.
1 + 1 IGUAL A 3
Cuando combina el poder de hacer explícitas las políticas con la visualización utilizando radiadores
de información, la política está en su cara y le ayuda a hacer lo correcto. Si esto no es lo
suficientemente útil, los miembros de su equipo probablemente aplicarán cierta presión positiva
cuando puedan ver que lo que está haciendo, o la visualización de lo que está haciendo en el
radiador de información, está divergiendo de la política que usted acordó (ver sección 3.1).
La última combinación kanban de hacer explícitas las políticas y la visualización del trabajo a
través de radiadores de información es el tablero kanban. Echemos un vistazo más de cerca a eso en
la siguiente sección.
Radiadores de información
* Grandes pantallas visibles

* Para usted y otras partes interesadas
* Mantenlo fácil de actualizar
* Mantenlo grande
* Úsalo o piérdelo
El tablero kanban 63
3.2 El tablero kanban

Los tipos de elementos de Las diferentes etapas de
trabajo indican diferentes su flujo de trabajo se
tipos de trabajo, pero muestran como
también se pueden usar columnas en el tablero.
para ayudarlo a decidir Leer más 3.2.2
cómo priorizar y manejar el
trabajo. Lea más en
capítulos 4 y 8.
Las tarjetas de elementos Los carriles de nado se

de trabajo reales pueden pueden usar para dividir
transmitir mucha el tablero para manejar
información por sí mismas. diferentes tipos de
Consulte capítulo 4. trabajo
independientemente en
el mismo tablero. Aquí
hay un ejemplo de un
carril de nado para
elementos
expeditos/urgentes.
Cuando trabajas en un equipo, hay muchas cosas que debes saber para colaborar eficazmente: cosas
como quién está trabajando en qué, si estás enfocando tus esfuerzos en el trabajo de mayor
prioridad, que los elementos bloqueados no se dejen sin resolver, y ese trabajo no haga cola frente a
un cuello de botella. Deseas que el progreso del trabajo continúe. Esto no solo es importante para el
equipo, sino también para otras partes interesadas. ¿Por qué no crear un buen radiador de
información para todo esto?
Los equipos kanban usan muchos radiadores de información, pero uno que se destaca como
el más común y destacado es el tablero en sí.
3.2.1 El tablero
El tablero básico es una pizarra blanca o un espacio vacío en la pared donde se colocan adhesivos o
fichas para visualizar su flujo de trabajo y cómo progresa el trabajo. Actualícela con frecuencia,
para que todos puedan ver y actuar según la información más actualizada.
El uso de un gran tablero no solo lo convierte en un buen radiador de información, sino que
también facilita que un grupo de personas mueva cosas simultáneamente, discuta lo que está
sucediendo, cree nuevos elementos de trabajo, etc. Es aquí donde se reúnen y "cuentan las historias"
de lo que sucedió y podría venir en el futuro, como una fogata que reúne la tribu. El tablero se
convierte en el lugar natural para reunirse y compartir.
Daphne: ... así que creo que

deberíamos investigarlo.
Frank: ... y luego, todo de repente …
Adan: Yo estaba trabajando en …
Eric: ... la respuesta mi amigo está

soplando en el viento. La respuesta está en
el aire.
Para maximizar el alcance de la información en el tablero, debe intentar configurarlo en un lugar

que sea fácilmente accesible para todos y en el que tenga suficiente espacio para reunirse para las
paradas diarias (consulte el capítulo 7) para discutir el trabajo.
A veces es difícil usar una tabla física grande. Si el problema son las políticas mobiliarias o
la falta de espacio, siempre puede usar una tabla plegable, una tabla hecha de cartón que al menos
puede usar durante las paradas. Si esto es demasiado complicado, si el equipo se distribuye en
diferentes ubicaciones físicas, o si algo más lo detiene, hay muchas buenas tablas digitales para
todos (consulte el apéndice B).
ADVERTENCIA
Debería pensarlo dos veces antes de exagerar por completo con las
herramientas electrónicas. Dados los beneficios de un tablero
físico, no debe usar uno o dos miembros del equipo fuera del sitio
como excusa para despojar estos beneficios del resto del equipo;
usar versiones físicas y digitales y hacer un poco de contabilidad
DESAFÍOS doble suele ser mucho menos trabajo de lo que imaginas, y a
ADELANTE menudo vale la pena la inversión.
El tablero kanban 65
Reunirse a menudo: paradas diarias

El tablero es una gran herramienta que irradia tu estado actual al equipo. Otra gran práctica para
combinar con el tablero es reunirse a su alrededor para reuniones cortas pero frecuentes. En estas
reuniones, podrán coordinarse, compartir y aprender unos de otros. Mantenga las reuniones cortas
y al punto; enfóquese en lo que sucedió en el tablero. Este tipo de reunión se conoce comúnmente
como paradas diarias.
Una receta simple para un parada diaria puede ser la siguiente:
■ Decide un tiempo recurrente. El primer momento disponible del día, que no sea doloroso
para nadie, es un buen punto de partida. Para poder hacer la reunión y comenzar el día
juntos.
■ Mantenga la reunión breve: un máximo de 15 minutos. Una manera inteligente de
asegurarse de que la reunión no dure mucho es ponerse de pie durante la reunión, parada
diaria erguida.
■ Las discusiones que no involucran a la mayoría de las personas se postergan y se
trasladan para después de las paradas diarias.
Para muchos equipos que hemos entrenado, estas dos prácticas marcan una gran diferencia:
visualice su trabajo para que pueda ver fácilmente lo que está sucediendo y reúnase todos los días
para dar seguimiento al trabajo y compartir problemas o inquietudes. Puede obtener más
información sobre las paradas diarias efectivas en el capítulo 7, sección 7.3.
OK, entonces tienes un tablero o un pedazo de pared u otro medio para crear un tablero. ¿Qué
deberías hacer con él? ¿Qué constituye un tablero? ¿Cómo lo creas? Se están acumulando muchas
preguntas. En la siguiente sección, encontrará las respuestas.
El tablero
* Use un tablero grande para irradiar información

sobre tu trabajo
* Los tableros físicos y electrónicos pueden servir para

diferentes propósitos; intenta sacar el máximo
provecho de ambos
* Use las paradas diarias de pie frente al tablero para

colaborar y aprender juntos
3.2.2 Mapeando su flujo de trabajo al tablero

Si no tenías idea de cómo era un tablero kanban cuando escogió este libro, al menos debería tener el
presentimiento de que a menudo tiene varias columnas. 3 Las columnas representan los diferentes
pasos por los que fluye el trabajo, pero ¿cuáles son estos pasos? ¿Cómo sabes qué poner en tu
nuevo tablero?
Para empezar, deseas capturar el flujo de trabajo actual y no la versión formal, en papel
estándar de la compañía, que se supone deben usar. Una manera fácil de comenzar es identificar uno
o dos de los elementos de trabajo más típicos y "recorrer la secuencia". Debe averiguar cómo fluye
el trabajo en su contexto particular.
Conseguir que su flujo de trabajo sea correcto puede ser difícil; Como recordará del capítulo
1, los Kanbaneros pasaron mucho tiempo discutiéndolo. Fue un tiempo bien empleado, porque los
obligó a examinar supuestos implícitos y les dio una comprensión más profunda de cómo trabajan
en equipo. Hasta el punto donde mapearon su flujo de trabajo, podrían haber muchas visiones sobre
cómo fluía el trabajo, pero hacerlo visual también lo hizo explícito y al grano.
UNA PALABRA DEL ENTRENADOR No es el gerente, el líder del equipo o

algún tipo de entrenador quien debe diseñar el tablero kanban; los miembros
del equipo que lo van a usar deberían hacerlo. Esto crea un sentido de
propiedad y aumenta la probabilidad de que honren las políticas y los procesos
que acuerdan.
Luego, resista el impulso de mejorar su proceso aquí y ahora. La idea general de la visualización es
comprender el trabajo y hacer que las oportunidades de mejora sean más obvias para usted. Deja
que el tablero te ayude con eso. Por ahora, mapee su flujo de trabajo. Quién sabe, las oportunidades
podrían no estar donde crees que están. Podrían estar en otro lugar.
No todos los tipos de trabajo pasan por el mismo workflow, pero eso está bien. Sin embargo,
deben decidir juntos cómo manejar esto. Quizás un cierto tipo de trabajo omita una columna o dos;
por ejemplo, tal vez los errores no tengan que pasar en el tablero por la columna Analyze, ya que los
Kanbaneros así lo decidieron sobre sus errores en el capítulo 1.
A veces, el nombre de una columna puede ser demasiado específico para todos los tipos de
trabajo, pero cuando considera de qué se trata, un nombre más abstracto hace que el flujo de trabajo
funcione para todos los casos. Un ejemplo es Test, que tiene sentido para el código, pero quizás no
para la documentación o los tipos de trabajo de investigación. Pero cuando cambia el nombre de la
columna a Verify o Reviewed por Alguien, resulta que ambos tienen el mismo flujo de trabajo.
Finalmente, no pongas demasiado esfuerzo en esto por adelantado; más bien, prepárese para
rehacer el tablero cuando vea que su trabajo no fluye como lo pensó por primera vez.
Recomendamos que dibuje su tablero con un marcador de pizarra borrable. De esta manera, puede
cambiar fácilmente el tablero como mejor le parezca. Espere con la herramienta electrónica y la
elegante cinta hasta que sienta que el diseño es algo estable.
3
Para ser sincero, el tablero puede verse como usted lo desee. Hemos visto ejemplos de espirales, escaleras y otras soluciones
creativas. Pero el tablero basado en columnas es, con mucho, el más común y probablemente un buen lugar para comenzar.
Colas 67
Mapeo de flujo de trabajo
* Deje que el tablero refleje su flujo de

trabajo ACTUAL
* Aprenda usando ejemplos reales
* No pienses demasiado; estar preparado para los

cambios
3.3 Colas
Las colas pueden ayudarlo a administrar transferencias, obtener un flujo de trabajo más uniforme y
dar a los miembros del equipo señales visuales de que el trabajo está listo para comenzar. En un
tablero, esto a menudo se manifiesta como una columna de cola separada antes o después de una
columna. Aquí hay un par de ejemplos de colas en un tablero:
■ Todo: la primera columna del tablero
■ Ready for Development: cosas que han sido analizadas y que ahora están listas para ser
recogidas por los desarrolladores.
■ Development Done: elementos que se han desarrollado y ahora están listos para probar
■ To Test: cosas que están listas para ser probadas
Como puede ver en los últimos dos ejemplos, el mismo estado se puede expresar de diferentes
maneras. Development Done y To Test son más o menos lo mismo. Ambos indican que el desarrollo
ha finalizado, y los probadores pueden recoger los elementos y comenzar a probarlos. Cómo
coloque las colas (en nuestro ejemplo Development Done o To Test) es totalmente su elección. Aquí
hay un tablero simple con un ejemplo, para aclarar esto un poco.
Una columna Done ( Development Done por ejemplo) es el caso normal y señala a otros en el flujo
de trabajo que este paso ha finalizado y que alguien más puede comenzar a trabajar en el elemento
de trabajo. La persona que lo traslade a Done no necesita ser consciente de lo que sucederá después.
Para el Development Done, puedes imaginar que un probador y un propietario del producto realicen
algún tipo de "clasificación" rápida juntos para decidir a dónde irá un elemento de trabajo a
continuación: tal vez a Test, tal vez a Stakeholder Verification, tal vez a Ready for Production.
Una columna Ready (como la columna Ready to Test en el tablero que acabamos de
mostrarle, por ejemplo) siempre es para un paso conocido, porque se coloca delante de un paso,
listo para ser procesado por él. Pasos como este se utilizan para transferencias distintas, tal vez
incluso para otros equipos. El trabajo se introduce en ese paso: por ejemplo, una columna de Inbox
donde el trabajo se mueve por un evento o cadencia 4, como la reunión de planificación quincenal o
cuando le quedan tres elementos en la columna Inbox. En nuestro tablero de ejemplo, puede ver que
este equipo ha decidido dividir la columna Test en Ready to Test y Test. Ready to Test es una cola
con trabajo que está listo para ser probado. Debido a que los probadores permiten tres elementos,
usted cuenta los elementos en Ready to Test contra ese límite.
A partir de esto, puede ver que los probadores tienen dos elementos en la cola (elementos en
espera de ser trabajados) y otro elemento en la columna Test (están trabajando en ese elemento).
CRITERIOS DE ENTRADA Y SALIDA

Una excelente manera de erradicar los malentendidos y lograr un consenso sobre lo que significan
las columnas, las colas y el flujo de trabajo en general es responder a la pregunta “¿Qué criterios
deben cumplirse para que pueda mover un elemento de trabajo a la siguiente columna? " Estos
criterios de entrada y salida pueden, una vez que se hacen explícitos, capturarse como viñetas o
como una lista de verificación y visualizarse encima o debajo de la columna a la que se aplican, por
ejemplo, escribiéndolos en una adhesivo o directamente en el tablero.
* Criterios de aceptación definidos * Instalado en entorno de prueba.

* Revisado por P.O. * Cobertura del código > 85%
* Revisado por otro desarrollador
4
El ritmo o los latidos de tu proceso; Lea más en el capítulo 9.
Resumen 69
Estos criterios deben verificarse cada vez que mueva un elemento en el tablero. Cuando se tenga
criterios nuevos o modificados, puede ser bueno usarlos como una lista de verificación para cada
elemento discutido durante la parada diaria, tal vez incluso agregando la política de que al menos
dos personas tienen que estar de acuerdo en que se cumplen los criterios antes de que se le permita
mover el elemento. Las políticas se discuten continuamente y se cambian y mejoran gradualmente.
Al igual que con las columnas, puedes tener criterios de entrada o salida, o ambos, dependiendo de
cómo y qué deseas verificar a medida que cada elemento de trabajo se mueve a través de su flujo de
trabajo.
UNA PALABRA DEL ENTRENADOR A menudo nos resulta útil

volver a visitar los criterios de entrada y salida cuando surge algo
relacionado con el flujo de trabajo: por ejemplo, durante las paradas
diarias, en las retrospectivas del equipo o al hacer un análisis de la raíz
de la causa por un defecto. Usted pregunta: "¿Seguimos los criterios?"
Si lo hizo, ¿hay algo que podría agregar a los criterios que lo ayudarían
a evitar este problema en el futuro? Si no lo hizo, debe examinar por qué
no está siguiendo las políticas que acordaron juntos.
3.4 Resumen
Este capítulo habló sobre visualizar su trabajo haciendo que este y las políticas a su alrededor sean
visibles donde antes no lo estaban:
■ Visualizar su trabajo se trata en última instancia de crear la transparencia y el intercambio
de información necesarios para comprender cómo funciona el trabajo y colaborar de manera
efectiva juntos.
■ El proceso de visualizar el trabajo significa hacer visible la información que antes no lo
era, hacer explícitos los conocimientos y las políticas implícitas y, al hacerlo, resolver las
inconsistencias y conflictos que surgen.
■ El tablero kanban es una excelente forma para visualizar su flujo de trabajo y compartir
información sobre las prioridades, quién está trabajando en qué, el progreso de los elementos
de trabajo individuales, etc.
■ Al usar un tablero grande y visible, la información se irradia a todos los interesados en
lugar de ocultarse en el cerebro de las personas o en herramientas inaccesibles.
■ Crear un tablero kanban es fácil: mapea el flujo de trabajo de sus elementos de trabajo, es
decir, los pasos que suelen seguir para completarse, a las columnas que crea en una pizarra o
pared.
El siguiente paso es crear los elementos de trabajo, que es el tema del próximo capítulo.
4 Elementos de trabajo

■ Tarjetas de elementos de trabajo
■ Principios de diseño para tarjetas de
elementos de trabajo.
■ Qué mantener en las tarjetas de
elementos de trabajo y cómo usar esta
información para obtener un mejor
conocimiento sobre cómo funciona su
trabajo.
El trabajo en el negocio del software a menudo no es visible. La mayor parte del trabajo se lleva a
cabo en nuestras cabezas o dentro de la computadora. Para obtener una mejor visión general de
quién está trabajando en qué y el estado del trabajo, visualiza el trabajo, haciendo visible la
información que antes no era.
Por mucho, la forma más común de rastrear elementos de trabajo es crear una tarjeta
pequeña que represente el trabajo que se está haciendo. Puede ser una tarjeta de índice o una nota
adhesiva1: cualquier cosa con la que sea fácil trabajar y moverse en una tabla, como una pizarra
blanca. Las tarjetas en un tablero son una forma simple pero poderosa de ver el progreso, los cuellos
de botella y las colas que suceden en su flujo de trabajo, y hacer que sea evidente para todos lo que
está sucediendo.
1
Por ejemplo, una nota Post-it®.
70
71
El uso de una tarjeta física le brinda algunas ventajas sobre una representación electrónica. Una
tarjeta física se puede anotar y personalizar fácilmente con avatares, bloqueadores, barras de
progreso, ID de seguimiento y otras cosas que analizaremos en este capítulo. Además, debido a que
las tarjetas son táctiles, son fáciles de usar para colaborar, moverse e incluso llevarlas si es
necesario.
* Fácil de barajar * Se adhiere a todo
sobre una mesa o tipo de superficies.
apilar para el Duh!
transporte
* Pero solo se queda
* No se pega solo atrapado en algunos
… :(
* Generalmente más
grande y más * Generalmente más
duradero que los pequeño que las
adhesivos fichas
Este concepto táctil guarda algunos otros secretos. Al mover las notas adhesivas en un tablero,
involucra más sentidos en el proceso y, por lo tanto, crea una conexión más fuerte entre usted y los
elementos de trabajo. Es más probable que recuerde que asumió la responsabilidad de un elemento
que movió con las manos de una columna a otra.
Este capítulo está dedicado exclusivamente a esas tarjetas. ¿Qué les pasa? ¿Cómo muestra
que un elemento de trabajo está bloqueado? ¿Quién está trabajando en este elemento? Estas
preguntas y más serán respondidas en este capítulo. Como siempre, no se limite solo a nuestras
sugerencias; probablemente no deberías usarlos todos a la vez, y probablemente haya otras cosas
que podrían incluirse en una tarjeta en la que no hemos pensado.
Usa tu imaginación para resolver problemas de flujo de trabajo y utiliza nuestras sugerencias
como inspiración para mejorar. Los temas que discutimos en este capítulo son formas comunes de
visualizar la información básica de un elemento de trabajo. Asegúrese de que su tarjeta contenga
toda la información necesaria para ayudar a su equipo a tomar decisiones con respecto a cada
elemento de trabajo.
* Descripción (ver 4.2.1) * Referencia a sistemas de seguimiento

electrónico externo (ver 4.2.4).
* Roja = tipo de trabajo * Cómo demostrar que estás
defectuoso (ver 4.3) bloqueado (ver 4.2.5) *Asegúrese de no perder esos plazos tan
importantes (ver 4.2.3).
* Tamaño del elemento de trabajo (ver 4.5).

* Formas geniales de indicar qué * Cómo recopilar datos sobre su flujo de
¿Quién estaba trabajando en esto? Usa tan lejos has llegado (ver 4.4). elementos de trabajo (consulte 4.6).
avatares (ver 4.2.2).
72 CAPÍTULO 4 Elementos de trabajo
Cómo quitar una nota adhesiva del paquete Elimina las notas adhesivas del paquete para
que no se enrollen; eso los hará pegar
Sí, esta podría ser la barra lateral más fascinante de la mejor.
historia.
Pero está aquí para protegerlo de una plaga que
atormenta a muchos equipos que usan adhesivos como
rastreadores de elementos de trabajo. Imagina la escena:
entras en la oficina y ves un tablero con muchos
adhesivos tirados en el suelo debajo de él. Felizmente te
das cuenta de que no es tu tablero; tus adhesivos están
unidos de forma segura, gracias a esta barra lateral. Con
una sonrisa irónica en su rostro, visita al pobre equipo a
cuya junta le faltan sus adhesivos para educarlos en el
noble arte de "cómo eliminar un adhesivo ¡Rizado! No se pegará Derecho y agradable!
correctamente". Esto se pegará
El truco es tener cuidado de que la parte adhesiva no se doble. Deslice su dedo debajo de la nota hasta el
área adhesiva, y luego levántelo de derecha a izquierda, lenta pero firmemente. Eso hará que la parte
adhesiva sea recta y agradable, y por lo tanto aumentará el área adhesiva de la nota.
Ahora ya sabes y puedes molestar a todos tus amigos con la forma correcta de eliminar un adhesivo.
No solo es un truco de fiesta fascinante, sino que también, más en serio, te ahorrará problemas con los
elementos de trabajo que se caen de tu tablero.
En lugar de una tarjeta física de elementos de trabajo, puede utilizar sistemas electrónicos que
representan el trabajo. No hay nada de malo en eso, y muchos de los sistemas hoy en día son
excelentes, especialmente para recopilar datos e informar métricas. Pero recuerde que está
renunciando a algunos de los beneficios de una tarjeta física y táctil. En caso de duda, comience
físicamente y luego pase a una versión electrónica más tarde si ve la necesidad. O incluso mejor,
¡usa ambos!
4.1 Principios de diseño para crear tus tarjetas

La tarjeta de elementos de trabajo se puede representar de muchas maneras diferentes, y pronto
profundizaremos en algunos de los patrones comunes para hacerlo. Sin duda, encontrará otras
formas que se adapten mejor a sus necesidades, así que cambie y explique según sea necesario. Pero
hay un par de principios de diseño que debe tener en cuenta cuando decida qué poner en sus tarjetas
y con qué anotarlas. Echemos un vistazo a algunos objetivos de diseño para crear tarjetas de
elementos de trabajo.
4.1.1 Facilitar la toma de decisiones

En primer lugar, desea que el diseño y la información en la tarjeta faciliten la toma de decisiones en
el equipo. Esfuércese por ayudarse a sí mismos a organizarse. Desea evitar situaciones en las que el
equipo no sabe qué hacer a continuación y tiene que preguntarle a alguien para continuar.
Igualmente malo es un equipo en el que las personas responden de manera diferente a la misma
situación debido a la falta de información. Esta es una de las principales razones para tener políticas
explícitas y formas claras de trabajar en primer lugar.
Principios de diseño para crear tus tarjetas 73
Estos objetivos son fáciles de establecer, pero puede pasar algún tiempo antes de que el equipo los
conozca de memoria. Mientras tanto, busque reglas simples y obvias, y haga que sean visualmente
visibles para todos en la tarjeta. Un ejemplo podría ser mostrar con un avatar quien está trabajando
en un elemento, para saber con quién hablar y obtener más información, o qué elementos aún no
tienen a alguien trabajando en ellos.
4.1.2 Ayudar a los miembros del equipo a optimizar los resultados.

El diseño de la tarjeta también debería ayudar a los miembros del equipo a optimizar el resultado
cuando se trata de cuestiones como el riesgo, la satisfacción del cliente y la economía. Si un
elemento de trabajo es de alto riesgo, necesita alguna forma de mostrarlo a los miembros del
equipo, de modo que las acciones riesgosas puedan evitarse fácilmente. Un ejemplo de un elemento
de trabajo de alto riesgo es uno con una fecha límite explícita para cuando una nueva ley entre en
vigencia. Perder este tipo de fecha límite podría estar asociado con una multa de algún tipo. Por lo
tanto, desea asegurarse de que todos sepan acerca de la fecha límite y priorizar en consecuencia.
Lo mismo ocurre con la satisfacción del cliente o la economía; Deje en claro si un (tipo de)
cliente es más importante que otro. Un ejemplo de esto es un elemento de trabajo con una nueva
funcionalidad que beneficia enormemente a los nuevos usuarios. Tal vez desee completar eso antes
de cualquier trabajo de mantenimiento.
La forma de tratar el elemento de trabajo se rige por políticas (explícitamente articuladas o
no) y a menudo se asocia con el tipo (por ejemplo, características normales, defectos y elementos de
trabajo de mantenimiento) y clase (por ejemplo, elementos de trabajo que son particularmente
urgentes o tienen una fecha de entrega fija) del trabajo. Hablaremos más sobre los tipos de
elementos de trabajo en la sección 4.3 y en el capítulo 8. Ayude al equipo a seguir las políticas
mostrando claramente qué tipo y clase de trabajo están recogiendo.
Como puede ver, hay mucho en qué pensar, pero deje que la estrella guía sea la simplicidad.
No sirve de nada agregar demasiado en la nota adhesiva, si corres el riesgo de olvidar de qué se
trata. Comience de manera simple y experimente con más información cuando vea la necesidad.
Desea que la información que irradia el elemento de trabajo sea fácil de ver y comprender. En ese
sentido, también desea que los cambios y los olores (consulte la barra lateral "Procesar olores") sean
evidentes y claros. Desea actuar sobre cosas que están fuera del funcionamiento normal, y debe ser
fácil detectarlas a medida que suceden.
Olores de proceso
Tomamos prestado el concepto de olor de Kent Beck y Martin Fowler, quienes hablan sobre los
olores del código (Refactorización: Mejora del diseño del código existente, Addison-Wesley
Professional, 1999, http://amzn.com/0201485672). Un olor puede significar problemas, pero no es
necesariamente un problema porque huele. Al igual que el olor del pañal de un niño pequeño, si
huele, al menos debería comprobarlo, pero no significa que siempre encontrará algo allí.
UNA PALABRA DEL ENTRENADOR Tenga en cuenta

estos objetivos de diseño a medida que lee los patrones en el
diseño de elementos de trabajo y vea si puede encontrar otras
formas de articular los objetivos en su equipo y en su tablero.
La tarjeta debe
* Facilitar la toma de decisiones

* Ayuda para optimizar la salida
* Mostrar el tipo y clase de trabajo
¿Qué pasa con el tamaño de la tarjeta?

Como pronto verás, puede haber mucha información en una tarjeta de elemento de trabajo.
Asegúrese de elegir un tamaño de tarjeta que le permita ajustar toda la información que necesita en
la tarjeta. Los adhesivos vienen en diferentes tamaños, así que experimente con los tamaños que
más le convengan.
También hemos visto muchos equipos que crean sus propias tarjetas con estructura y forma
personalizadas. Aquí puede ver una tarjeta de elemento de trabajo refinada; a El equipo ha laminado
la tarjeta en plástico para que pueda limpiarse y reutilizarse una y otra vez:
No hay bien o mal. Simplemente elija un tamaño y forma que se adapte a sus necesidades y
cámbielo a medida que cambian sus necesidades.
a
. Uno de los clientes de Marcus, Tradera (sucursal Sueca de eBay), tenía estas tarjetas en un tablero cuando Marcus lo
visitó. Son algunas de las cartas más elaboradas que hemos visto.
Tarjetas de elementos de trabajo 75
4.2 Tarjetas de elementos de trabajo

Muchas cosas pueden estar en una tarjeta, y en las siguientes secciones examinaremos algunos
atributos comunes, comenzando con el más obvio: la descripción del elemento de trabajo.
4.2.1 Descripción del elemento de trabajo
Ok, ¿qué pasa con ese elemento

de trabajo en la parte superior?
Trabajaste en eso, ¿verdad,
Daphne?
¿Qué dice? "Mejorar el

rendimiento"? ¿Era eso el
acceso a los datos? O tal vez
en la página? No, espera ...?
Hmm ... no ...
¿Qué tal si tratas de recordar lo

que fue y escribes una nueva
nota?
Tengo esto. Fue el

controlador ... no ... eso no
está bien. Estoy seguro de que
hice algo ...
Para muchos de ustedes, esto puede parecer obvio; Por supuesto, el elemento de trabajo tiene una
descripción. Pero esta es un área en la que vemos que muchos equipos tienen margen de mejora. No
podemos contar la cantidad de veces que hemos visto a los equipos discutir sobre un elemento
porque la descripción en la tarjeta es inadecuada.
Para poder hablar más fácilmente sobre el elemento y su contenido, la descripción debe ser
concisa, al grano y fácil de entender para todos en el equipo. ¿Qué significa eso en la práctica?
HISTORIA DEL USUARIO

Una historia de usuario es un ejemplo de una descripción que es corta y breve y puede resultar útil. 2
Dice qué, para quién y por qué se está organizando el elemento de trabajo.
2
Tenga cuidado de no confiar demasiado en el formato de plantilla de historia de usuario y sus méritos. Es solo una
forma de estructurar su descripción del trabajo en cuestión y no una bala de plata que siempre funciona. Se sabe que
algunos (incluido Joakim) los llaman antipatrón de vez en cuando.
para hacer un seguimiento No nos detendremos en el tema de la historia de usuario aquí,

de mis ahorros porque no está en el alcance de este libro. 3 Por ahora, simplemente
como cliente del banco podemos decir que es una Tarjeta con un pequeño texto que es un
recordatorio de una Conversación que vas a tener más tarde. En la
Quiero una descripción conversación, desarrollará los detalles y anotará su Confirmación
simple de todas mis como criterio de aceptación. Eso se puede recordar fácilmente con
cuentas de ahorro
el acrónimo CCC: Card, Conversation and Confirmation.
Una plantilla común para una historia de usuario es

Como [rol], quiero [característica], para que [beneficio]
O tal vez
Para [beneficio], como [rol] quiero [función]
Use un formato que le parezca natural, pero asegúrese de incluir el Por qué (beneficio), el Quién (rol) y el
Qué (función) en la descripción.
TITULO
Si la descripción tiende a ser más larga de lo que te gustaría repetir cada vez que hables sobre la tarjeta del
elemento de trabajo, podrías beneficiarte si agregas un título a la tarjeta. Una oración corta que sea fácil de
recordar y de consultar puede ayudarlo a recordar de qué se trata el elemento de trabajo.
"EL LUGAR DONDE …"
Las historias de usuarios son una forma de escribir descripciones, pero a veces no se sientan bien con el
equipo para el elemento en cuestión (como los errores, por ejemplo). Aún debe tener una buena descripción,
y una simple mnemotecnia que hemos utilizado es la convención de nomenclatura de Friends: en su mente,
ponga "El lugar donde" antes de la descripción en la tarjeta. (Todos los títulos de los episodios de Friends
comenzaron de esta manera, como: "El lugar donde Ross y Rachel piensan que vuelven a estar
enamorados").
El uso de este pequeño recordatorio volverá a centrarse en por qué este tema de trabajo está en
primer lugar. Haga que el título sea fácil de consultar en una conversación, como estos elementos de trabajo,
por ejemplo:
■ (El lugar donde) el campo de nombre permitía demasiados caracteres
■ (El lugar donde) le faltaban los derechos de administración, si inició sesión como administrador
UNA PALABRA DEL ENTRENADOR Recuerda que "El donde"

no necesita ir en la tarjeta. Es un pequeño adelanto, para que te
concentres en la verdadera razón detrás del elemento de trabajo.
Vea más en el excelente libro Historias de usuarios aplicadas por Mike Cohn (Addison-Wesley Professional, 2004,
http://amzn.com/0321205685).
Mantener descripciones
* Conciso
* Al punto
* Comprensible para todos en el equipo
Aquí hay algunos ejemplos buenos (y algunos malos) de qué poner en su tarjeta como descripción:
Como administrador, QC87190

quiero el informe de uso del
sitio para poder hacer
predicciones educadas y
priorizar la funcionalidad.
Repare el
ÍNDICE_DE_CUBO de
USO DEL SITIO 74
Si ha iniciado sesión como

administrador, no se puede
hacer clic en la pestaña del
informe de uso del sitio página 6 - ¡hazlo!
Después de saber de qué se trata el elemento de trabajo, el siguiente problema a tratar

probablemente sea quién está trabajando en él ahora. Veamos una solución común a este problema.
4.2.2 Avatares
Desea que la información sobre quién es responsable de un elemento de
trabajo sea tan clara como el día, para saber a dónde ir con sus preguntas,
sugerencias y elogios. Muchos equipos indican quién está trabajando en qué
al adjuntar un avatar a la tarjeta de elementos de trabajo. En este contexto
(vea la barra lateral "¿Qué es un avatar, de todos modos?" Para el significado
real de la palabra), es una clara indicación de quién está trabajando en qué.
La razón por la que muchas personas usan imágenes, dibujos animados o
dibujos de sí mismos es porque es más fácil identificar a una persona que usa la coincidencia de
patrones. Crea una conexión instantánea si compara una imagen con una persona, en lugar de mirar
un nombre garabateado o una firma que podría necesitar alguna traducción para leer y luego
asociarla con la cara correcta.
Esto significa que debe usar avatares que se parezcan a los miembros de su equipo o que
sean caricaturas con características que se reconocen fácilmente. Por supuesto, podría agregar una
clave o leyenda al costado del tablero, pero eso significa que las personas tendrían que buscar qué
avatar pertenece a quién. Con avatares que se parecen a los miembros del equipo, no tiene que hacer
esa búsqueda.
¿Qué es un avatar, de todos modos?

En informática, un avatar es la representación gráfica del usuario o el alter-ego o personaje del usuario.
Puede tomar una forma tridimensional, como en los juegos o mundos virtuales, o una forma bidimensional,
como en un ícono en foros de Internet y otras comunidades en línea. También puede referirse a una
construcción de texto que se encuentra en los primeros sistemas, como los MUD. Es un objeto que
representa al usuario. El término avatar también puede referirse a la personalidad relacionada con el nombre
de usuario o el nombre de usuario de un usuario de Internet, como los iconos de usuario en Facebook,
Twitter y otros sitios de redes sociales.
Algunos equipos usan avatares para limitar el trabajo en proceso para cada persona. Esto puede ser
un auto-control eficaz para los acumuladores4 que tienen la costumbre de participar en cada
elemento del tablero. Por ejemplo, dar a cada persona tres avatares para que jueguen en el tablero es
una forma visual y efectiva de asegurarse de que nadie asuma demasiado trabajo.
UNA PALABRA DEL ENTRENADOR Puede pensar que tener
animales lindos o dibujos animados geniales como avatares es lo que
animará su tablero. Nuestra experiencia nos dice que probablemente
estés equivocado. Un equipo que entrenó Joakim decidió usar
avatares de perros. Esto causó confusión cuando tuvieron que
intentar recordar
quién era el Poodle, por qué el Dálmata aún no había completado esas pruebas y qué demonios
estaba haciendo el Schnauzer con esa tarea de análisis todo ese tiempo. ¡Usa avatares que al menos
se parezcan a la persona en cuestión!
4
Apodo para las personas que a menudo terminan recolectando muchos adhesivos.
Avatares
* Indique quién está haciendo qué
* Debe verse (un poco) como la persona en
cuestión
* Se puede usar para limitar WIP
Al usar avatares, puede ver fácilmente quién está trabajando en el elemento en cuestión. Ahora
dirigimos nuestra atención a los plazos, que le ayudan a saber cuándo debe completarse el elemento
de trabajo.
4.2.3 Plazos
Los plazos pueden existir por varias razones; pueden haber funciones que deben hacerse para una
campaña, una nueva ley que se aplica en una fecha determinada o un nuevo cliente que venga a la
oficina la próxima semana, por ejemplo.
Para mostrar claramente la fecha en que debe realizarse el
trabajo, escríbalo directamente en la tarjeta del elemento de
trabajo, tal vez incluso con otro color que se destaque. Los
plazos son información sobre gestión de riesgos y ayudan al
equipo a priorizar y autoorganizarse; no querrás perderte verlos,
así que asegúrate de que sean claramente visibles.
Algunos equipos incluso usan diferentes colores de adhesivos
para los tipos de elementos de trabajo de fecha fija en
combinación con la fecha límite. Asegúrese de usar la misma
visualización cada vez para crear un patrón o hábito. Por ejemplo, utilice siempre la esquina
superior derecha del adhesivo para plazos.
Plazos
* Indica fechas de vencimiento firme para el elemento de trabajo

* Destaca claramente de otra información
* Se puede utilizar para proporcionar una caja de tiempo para el
elemento de trabajo
Allí, ahora también tienes plazos para el elemento de trabajo. Son otra pieza de información
importante. Continuando por este camino, poniendo toda la información en la tarjeta, pronto se
quedará sin espacio. ¿Qué hacer con la información que no puedes incluir en la tarjeta? Ese es el
tema de la siguiente sección.
4.2.4 ID de Seguimiento
Hemos hablado mucho sobre las cosas buenas que trae un tablero
físico con tarjetas de elementos de trabajo, pero hay algunas cosas que
tal configuración no funciona bien. El espacio limitado5 en un
adhesivo podría no contener toda la información necesaria para
completar una función. Es posible que haya mucha otra
documentación que simplemente no es factible tratar de adjuntar al
adhesivo o mantener cerca del tablero. O es posible que deba realizar
un seguimiento de su trabajo, la cantidad de horas y el progreso en un
sistema electrónico.
En estos casos, y seguramente también hay otros, debe saber fácilmente qué elemento del
sistema electrónico representa el que está en el tablero. Puede considerarlo como un enlace de "más
información aquí".
Una solución simple para esto es anotar el ID de seguimiento electrónico en una esquina del
la nota adhesiva. Similar a la fecha límite, asegúrese de usar la misma esquina en cada nota
adhesiva, lo que crea un buen hábito. O puede prefijar el ID de seguimiento con, por ejemplo,
JIRA :, TFS :, o Git: para asegurarse de que no se confunda con otros números que puedan estar en
la nota.
ADVERTENCIA
Tenga cuidado de caer en la trampa de poner toda la información
sobre la nota adhesiva en el sistema de seguimiento electrónico,
regresando a las tarjetas de elementos de trabajo sin una
descripción fácilmente comprensible (ver sección 4.2.1).
DESAFÍOS
ADELANTE
Los lectores astutos ahora comenzarán a preocuparse por la "doble

Tablero de
contabilidad" que esto hará que usted haga y cómo mantener actualización.
sincronizados el tablero y el sistema electrónico. Para manejar eso, Actualización de JIRA.
primero puede elegir un maestro, preferiblemente el tablero físico, Equipo de actualización
en parada diaria.
porque está "ahí afuera" y en el que su trabajo es más visible. ¿Cuando terminará?
5
El espacio limitado puede ser algo bueno, ya que te obliga a trabajar con elementos más pequeños y dividir los
elementos más grandes en muchos más pequeños. Este es el razonamiento detrás de escribir historias de usuarios en una
tarjeta pequeña, por ejemplo. Si cree que una tarjeta de índice grande es demasiado pequeña para contener su
información, intente con una tarjeta aún más pequeña para obligarse a expresarla brevemente.
En el sistema electrónico, puede hacer una versión simplificada del flujo de trabajo: Not Done y
Done, por ejemplo. Esto hará que la actualización sea mucho más liviana y no creará mucho trabajo
adicional. Además, en el elemento de trabajo en el sistema electrónico ahora puede adjuntar
documentos y enlaces a otros recursos importantes.
Por supuesto, puede dar la vuelta y utilizar el sistema electrónico como maestro; pero luego
le recomendamos que intente obtener un proyector. ¿O por qué no utilizar una pantalla táctil grande
y un complemento similar a un tablero para el sistema en cuestión? 6
IDs de seguimiento
* ID en sistemas electrónicos externos

* Piensa: "más información aquí" -enlace
* ID o similar para buscar en el sistema
electrónico
Hasta ahora, hemos considerado el camino del éxito uniformemente pavimentado. Ese no es el
camino que todos recorremos en realidad. ¿Qué sucede cuando las cosas no funcionan según lo
planeado? Vamos a investigar eso a continuación.
4.2.5 Bloqueadores
Aunque el objetivo es que su trabajo fluya rápida y suavemente a través de su flujo de trabajo, a
veces suceden cosas: tiene que esperar a que alguien más complete su trabajo, alguien está enfermo
o tiene preguntas que impiden que se complete el trabajo.
ELEMENTOS BLOQUEADOS
En estos casos, desea que el elemento se destaque y muestre que está bloqueado para el progreso
posterior. Cuando lo haces, obtienes una señal y una razón para concentrarte en el bloqueador (en tu
parada diaria, por ejemplo). Los ojos se sienten atraídos por los elementos que son diferentes de los
elementos normales, y esto te ayuda a concentrarte en esas desviaciones. Un elemento bloqueado
debe ser un olor visual, para usar la terminología que presentamos anteriormente (ver sección
4.1.2).
Para lograr esto, muchos equipos adjuntan otro adhesivo encima del elemento de trabajo
bloqueado. Esta es una buena idea porque también puede escribir la razón por la cual el elemento
está bloqueado en el adhesivo bloqueador.
6
Hay muchos de estos complementos, pero algunos que nos gustan son Kanban para TFS, JIRA Agile y HuBoard para
GitHub.
De esta manera, obtienes no solo una señal de que el trabajo está bloqueado,
sino también información sobre por qué está bloqueado, lo que a su vez ayuda
al equipo a concentrarse en resolver el bloqueo.
Hay muchas otras alternativas comunes para indicar que un elemento está
bloqueado: imanes colocados encima del elemento de trabajo bloqueado,
girando el elemento de trabajo de lado o moviéndolo a un "estacionamiento" de
bloqueados en en una parte separada del tablero. Si decides mover la tarjeta,
asegúrese de tener alguna forma de recordar su ubicación anterior, de modo que pueda moverla allí
una vez que se haya resuelto el bloqueo.
UNA PALABRA DEL ENTRENADOR Aunque mantener un
"estacionamiento" separado para los elementos bloqueados puede
parecer una buena idea, desaconsejamos su uso. Básicamente es lo
mismo que decir que está bien ser bloqueado: "¡Mira, incluso tenemos
un área dedicada en el tablero para ello!" Mantener el elemento en
su columna lo mantiene en su cara, afecta su cantidad de WIP y lo obliga a tener que
considerarlo constantemente durante sus reuniones de parada diaria.
PROGRESO DE BLOQUEO
Algunos equipos también escriben una forma simple de indicador del progreso
(ver sección 4.4) en el adhesivo bloqueador, para enfocarse más en resolverlo
en lugar de dejar el elemento bloqueado. Por ejemplo, un elemento de trabajo
bloqueado con tres puntos significa que la nota adhesiva ha estado bloqueado
durante tres días, y eso necesita su atención, ¿verdad? Algunos equipos usan
políticas más elaboradas para esto: por ejemplo, después de tres días se
contactan personalmente con el equipo o la persona que los bloquea, y después de cinco días
escalan a la administración u otra función de soporte.
Al elegir qué diseño de bloqueador funciona mejor para su equipo, recuerde que desea que el
elemento se destaque de los elementos de trabajo normales y preferiblemente irradie alguna
información sobre por qué y durante cuánto tiempo se ha bloqueado el elemento.
Llevando los olores al siguiente nivel
Durante la conferencia Lean Kanban North America en Chicago 2013,
aprendimos sobre un equipo que ha llevado las visualizaciones y los olores
al siguiente nivel. En lugar de agregar un pequeño elemento adhesivo al
elemento de trabajo para indicar que estaba bloqueado, este equipo engrapa
una cáscara de plátano real a la tarjeta de índice. a A medida que pasan los
días y no se quita el bloqueador, la cáscara de plátano se vuelve más y más
oscura, y un olor desagradable comienza a extenderse. ¡Eso es un llamado
a la acción para ti!
a. Image courtesy of Gualberto107/FreeDigitalPhotos.net.

Tipos de trabajo 83
(continuado)
Su siguiente idea fue usar errores reales para indicar errores de software. No sabemos acerca de usted, pero sin duda
reforzaríamos la calidad de nuestro código para evitar tener que clavar errores reales en el tablero.
A algunos equipos les encanta ser creativos con estas cosas. Si estás en un equipo así, deberías convertirte en un loco
con las visualizaciones …
Con los bloqueadores, ahora puedes manejar situaciones en las que el trabajo no fluye según lo
planeado.
Bloqueadores
* Indique claramente que el elemento necesita su

atención
* También debe indicar por qué
* Barras de progreso en bloqueo
Hasta ahora hemos usado el término genérico elemento de trabajo, pero los elementos de trabajo
son de diferentes tipos o clases. Veamos cómo puedes visualizar eso.
4.3 Tipos de trabajo

Los elementos de trabajo pueden ser de diferentes tipos, como errores, elementos técnicos o
solicitudes de mantenimiento o características. El trabajo de diferentes tipos a menudo se debe
manejar y priorizar de diferentes maneras. Deseas que el equipo pueda distinguir fácilmente los
diferentes tipos de trabajo entre sí y poder priorizar los elementos de trabajo por su cuenta.
Para ayudar al equipo a autoorganizarse en torno a cómo se debe manejar y priorizar el

trabajo, una práctica común es permitir que cada tipo de trabajo tenga su propio color. De esta
manera, se hace fácil distinguir un defecto de una característica normal, por ejemplo. Estos tipos
también se pueden usar para establecer políticas sobre cómo se debe tratar el trabajo, comúnmente
conocido como clases de servicio (consulte el capítulo 8).
Aquí hay algunos ejemplos comunes de tipos de trabajo. Algunos de los colores utilizados
aquí se han convertido en una convención en la comunidad kanban. Pero, como siempre, asegúrese
de que los colores tengan sentido para usted y su equipo. (Aunque las notas adhesivas son tonos de
gris en el libro impreso, son verdes, amarillas y rojas en el libro electrónico y en el tablero kanban).
Mantenimiento o técnico Característica de historia de usuario estándar Defecto de error
La elección depende de usted, pero debe asegurarse de que no todo en el tablero se vea igual. No
querrás terminar en el mar amarillo de adhesivos, lo que hace difícil saber cómo priorizar entre
diferentes tipos de elementos de trabajo o ver cualquier tipo de patrones.
Hacer evidente el trabajo de diferentes tipos, mediante el uso de adhesivos de diferentes
colores, por ejemplo, puede ayudarlo a ver lo que está sucediendo. Simplemente mirando por
encima del tablero, puede tener una idea del estado general del equipo. Por ejemplo:
■ Si ve muchos adhesivos rojos (errores y defectos), puede ver un problema de calidad en su
sistema. Probablemente deberías hacer un esfuerzo para mejorar la calidad.
■ Cuando observe que no hay elementos ecológicos (mantenimiento, técnicos) en su tablero,
es posible que no esté pagando su deuda técnica según sea necesario, lo que dificulta el
mantenimiento del sistema con el tiempo.
■ Sin elementos amarillos (funciones) significa que no está agregando nuevas funciones a su
sistema. Esto podría ser lo que quieres, o no. El tablero te da una señal visual simple que te
dice cómo es, de cualquier manera.
Si solo usó elementos amarillos, tendría que leer todas y cada una de las notas para conocer el
estado general de todos los elementos en su tablero.
ADVERTENCIA
No caigas en el modo perezoso de agarra cualquier almohadilla de
color que tengas por ahí. Mezclar colores de adhesivos en el
tablero sin ninguna razón causa confusión. Lo mejor es elegir un
número limitado de tipos comunes de trabajo, asignar un color a
cada uno y luego usar ese color todo el tiempo para ese tipo.
DESAFÍOS
ADELANTE
Si tiene dificultades para recordar qué tipo de trabajo significa

cada color, se puede publicar una leyenda en el tablero para
descartar cualquier malentendido. Esto también puede ser útil
para las partes interesadas y otras personas que no trabajan a
diario con la junta.
Indicadores de progreso 85
Tipo de trabajo
* Diferentes colores para diferentes tipos de

trabajo.
* Ayuda a la priorización
* Evita el mar amarillo
* Usa colores por una razón
Ahora volvamos nuestra atención a ver qué tan lejos has llegado. En la siguiente sección, obtendrá
una herramienta simple que lo ayudará a rastrear eso.
4.4 Indicadores de progreso

Una tarjeta en una columna en el tablero es una excelente señal visual y le brinda mucha
información, pero el historial del elemento de trabajo no es tan fácil de rastrear. ¿Cuánto tiempo
lleva aquí esta carta? ¿Es este un plazo de entrega normal para la etapa de desarrollo? Preguntas
como estas no se pueden responder fácilmente mirando la tarjeta donde se encuentra hoy.
Un indicador de progreso es una herramienta simple que lo ayuda a rastrear esta
información y muestra "cuánto se ha hecho" el elemento. Puede ser tan simple
como marcar cada elemento adhesivo en el flujo de trabajo con un punto por
cada día en que se haya trabajado. Si está un poco más avanzado, puede usar
diferentes colores de puntos para diferentes estados en su flujo de trabajo.
En los equipos que hemos entrenado, también hemos visto la línea de
tiempo esperada dibujada como cuadros, que se completan a medida que avanza el trabajo. Esto te
da una pista de cómo te va en comparación con lo que sueles hacer o el resultado esperado.
Progreso por Paso Terminación

paso completado contra
SLA, 3/5 días
Para los elementos que no siguen un flujo lineal, 7 cada estado en el flujo de trabajo podría tener su
propia casilla para marcar cuando se realiza el trabajo, y eso mostrará lo que queda por hacer.
IR A GOOFY: CONTANDO HACIA ABAJO

En lugar de contar la cantidad de días que ha pasado, puede realizar una cuenta regresiva rastreando
la cantidad de días que quedan antes de que el elemento deba completarse, por ejemplo, según su
fecha límite. Luego, en la reunión de parada diaria, puede actualizar esta cifra para reflejar la
cantidad de días que aún quedan. Si ha estado haciendo Scrum, sabe que esta es una forma común
de rastrear el progreso en comparación con la estimación en un gráfico de quemado (burn-down).
Indicador de progreso
* Mostrar "cuánto hecho" el elemento es
* Puntos, cuadros o letras
* Total o por paso
* Base para el acuerdo de nivel de servicio
Al usar indicadores de progreso, ahora ha comenzado a recopilar y rastrear datos sobre cómo está
funcionando su proceso. Para hacerlo con precisión, pronto necesitará saber cuánto esfuerzo
requiere cada elemento de trabajo. Echemos un vistazo a una forma de hacerlo.
4.5 Tamaño del elemento de trabajo

El tamaño de un elemento de trabajo puede proporcionar información valiosa para ayudarlo a
administrar el elemento de trabajo en el tablero. El único problema es que a menudo no se conoce el
tamaño exacto del trabajo en su negocio hasta que haya terminado.
Luego hablaremos más sobre la estimación (vea el capítulo
9), pero brevemente, podemos decir que dar un número de
cuántas horas tomará un determinado elemento es difícil y a
menudo termina siendo incorrecto. Un enfoque mucho más
convincente es comparar ese elemento de trabajo con otros
elementos de trabajo. La pregunta es, entonces, ¿el
elemento de trabajo A requiere más o menos trabajo para
completarse que el elemento de trabajo B?
7
Donde el proceso no sigue una secuencia natural de pasos, de modo que los pasos para completar el trabajo para el
elemento de trabajo se pueden ejecutar en cualquier orden.
Recopilación de datos de flujo de trabajo 87
Al hacer esto para todas sus tareas, puede asignar un número de elementos de trabajo del mismo
tamaño, lo que se conoce como puntos de historia, o incluso tamaños de camisetas (S, M o L).
Estos números solo muestran sus estimaciones relativas de cuánto esfuerzo se necesita para
completar la tarea. Este enfoque no es exacto, pero probablemente sea más útil de todos modos,
porque las mediciones exactas (104 horas, por ejemplo) también son suposiciones.
Tamaño del elemento de trabajo

* ¿Qué tan grande es este elemento de trabajo?
* Número relativo o tallas de camiseta
* Establecer como ingresa al tablero o cuando se conoce
Independientemente de cómo haya presentado su estimación, desea escribirla claramente en la

tarjeta del elemento de trabajo, de modo que sea simple y fácil de ver para todos.
4.6 Recopilación de datos de flujo de trabajo

Las últimas secciones han hablado sobre agregar información al elemento de trabajo que puede
ayudarlo a recopilar buenos datos sobre cómo se comporta su flujo de trabajo. Esta puede ser
información útil para mejorar su proceso en el futuro. Miremos más de cerca.
4.6.1 Recopilación de métricas de flujo de trabajo

Cuando el flujo de trabajo se configura de manera detallada, tiene una excelente oportunidad para
recopilar datos sobre qué tan bien fluye su trabajo y para medir y rastrear las tendencias en su
trabajo. En resumen, puede aprender aún más sobre cómo funciona su trabajo.
Algunas de estas métricas pueden capturarse con bastante facilidad en casi cualquier
momento, y otras deben realizarse a medida que el trabajo avanza a través del flujo porque algunos
de los datos no pueden capturarse en retrospectiva. Muchos equipos realizan un seguimiento de un
par de métricas fáciles de obtener, como el tiempo de entrega de cada elemento de trabajo y el
rendimiento (número de elementos completados por semana, por ejemplo), para aprender sobre su
trabajo. En el capítulo 1, viste a los Kanbaneros configurar tales métricas para su proceso con unos
simples pasos.
Esta sección no trata sobre métricas y cómo usarlas. Puede leer más sobre las métricas en el
capítulo 11. Aquí queremos sugerir un par de formas simples de personalizar sus tarjetas para
capturar las métricas.
En la forma más simple, puede "sellar" la tarjeta con la fecha

en que ingresa al tablero y la fecha en que ingresa a la etapa
final del flujo de trabajo. Esto lo ayudará a rastrear el tiempo
de entrega de ese elemento.
Sellar la fecha de llegada para cada nueva columna (es decir, cada
nuevo paso en su flujo de trabajo) puede ampliar esta idea. Ahora
puede comenzar a ver tendencias en el tiempo del ciclo para cada
paso del flujo de trabajo, dónde están sus cuellos de botella y
dónde suele esperar el trabajo. Necesita datos como este para crear
diagramas más avanzados (consulte el capítulo 11).
En combinación con el tamaño del elemento de trabajo del que
hablamos antes (consulte la sección 4.5), ahora puede comenzar a
hacer algunas predicciones, como estas:
■ "Si coloca un pequeño elemento de trabajo en la bandeja de entrada, saldrá por la puerta en
tres días, como máximo".
■ "Un elemento de trabajo mediano se manejará en cinco u ocho días, en 9 de cada 10 casos.
Tenemos evidencia estadística para respaldar eso".
Recuerde: está recopilando estos datos para que el equipo los apruebe. No te excedas. Comience
con una métrica que sea fácil de rastrear y luego hágala más avanzada a medida que surja la
necesidad. No desea agregar mucho trabajo adicional para capturar y manejar las métricas.
Simplemente anote una fecha simple en la tarjeta, eso es todo. Cámbielo cuando esa métrica simple
ya no sea suficiente.
Recopilar datos de flujo de trabajo

* Métricas sobre cómo fluye el trabajo
* Podría ser tan simple como las fechas de entra/sale
en el tablero
* Más avanzado: fechas/columna
* Mantenlo simple y mejora según sea necesario
Recopilación de datos de flujo de trabajo 89
En esta sección se habló sobre la recopilación de datos concretos sobre cómo se mueven sus
elementos de trabajo a través de su workflow. Terminaremos esta sección con un tono más suave y
acogedor: hablando de emociones.
4.6.2 Recolectando emociones
Algunos equipos usan los elementos de trabajo para realizar un

seguimiento de lo feliz que está el equipo con el trabajo que están
haciendo. Usted también puede; simplemente dibuje un ícono, como
una carita sonriente, una cara enojada, una cara indiferente o algo más
que indique su emoción con respecto al trabajo, en la nota adhesiva
cuando lo termine. Este pequeño ícono indica cómo te sentiste en ese
momento.
Debido a que la tarjeta está a punto de ser retirada del tablero, no

tiene que preocuparse por estropear nota adhesiva. Simplemente
dibuje el icono sobre la información existente como un recordatorio
rápido de cómo se sentía.
Cualquier persona en el equipo puede capturar la "emoción" de la tarjeta a medida que se

mueve fuera del tablero. Una forma de hacerlo es tener una votación rápida en la reunión de la
mañana. También puede decidir si decide el último miembro del equipo que tocó el elemento de
trabajo. En los equipos en los que uno o un par de desarrolladores mueven el elemento de trabajo a
través de toda la cadena, deciden el estado al final.
Prácticas divertidas y quizás útiles.

Hemos escuchado sobre muchas otras prácticas, demasiadas para enumerarlas todas en este libro.
Pero aquí hay dos prácticas que son divertidas y un poco diferentes que pueden resultarle útiles y
que pueden inspirarlo a probar algo diferente:a
■ Divida un elemento en dos partes (literalmente, con tijeras) cuando tenga actividades
concurrentes/carriles paralelos que se fusionen nuevamente. Por ejemplo, un elemento de
trabajo va a la revisión de seguridad y software en paralelo, y cada uno tiene su propio flujo
de trabajo/columna antes de volver a unirse.
■ Use elementos de trabajo de diferentes tamaños para diferentes tamaños de trabajo, de
modo que grande sea un adhesivo realmente grande (los de tamaño aproximadamente A5),
mediano sea un adhesivo rectangular y pequeño sea cuadrado, por ejemplo. Incluso podría
tener límites físicos de WIP (por ancho y alto en el tablero) para estos en lugar de un
número.
a. Si lo haces, cuéntanoslo
4.7 Crear tus propias tarjetas de elementos de trabajo

Ahora has visto muchos consejos sobre lo que podría estar en la tarjeta. Es hora de ponerse práctico
y comenzar a pensar en cómo deberían ser sus elementos de trabajo.
Sugerimos que haga esto como un ejercicio de equipo. Comience pequeño y simple, y
amplíe a medida que surja la necesidad. Aquí hay algunas cosas que su equipo puede discutir:
■ ¿Qué información se necesita para saber qué hacer con los elementos de trabajo? Recuerde
los objetivos de diseño de la sección 4.1.
■ ¿Qué información puede ser interesante para otras personas que no están trabajando con
los elementos de trabajo todos los días?
■ ¿Tienes diferentes tipos de trabajo? ¿Se beneficia de distinguir entre diferentes tipos de
trabajo? ¿Necesitas bloqueadores? Si lo hace, ¿cuáles son sus políticas al respecto? ¿Qué
debería pasar con los elementos que están marcados como bloqueados? ¿Quién es
responsable de desbloquearlos?
Como último ejercicio divertido, crea tus propios avatares personales. Sin embargo, recuerda no
exagerar por completo con creatividad; quieres avatares que al menos se parezcan a ti.
4.8 Resumen
Este capítulo fue todo sobre la tarjeta de elementos de trabajo y la información que irradia
(comunica) mientras se encuentra en el tablero. Un elemento de trabajo debe contener toda la
información que el equipo necesita para saber cómo trabajar con él. Discutimos lo siguiente:
■ Una descripción: para saber de qué se trata el trabajo

■ Un avatar u otro marcador: para saber quién está trabajando en el elemento
■ Plazos y otras fechas importantes: para saber cuándo necesita que se haga el elemento
■ ID de seguimiento u otras referencias a un sistema externo: para que sepa dónde encontrar
más información
■ Bloqueadores: para que pueda recoger los elementos que están bloqueados y, por lo tanto,
obstaculizando un mayor progreso
■ Tipo de trabajo: para saber el tipo de trabajo para cada elemento, lo cual es importante
para que pueda priorizar los elementos de trabajo uno contra el otro si es necesario
■ Indicadores de progreso: para saber cuánto trabajo ha realizado hasta ahora
■ Tamaño: para que pueda ver las diferencias en tamaño y esfuerzo
■ Datos de flujo, emociones y otros datos acumulados durante el flujo a través del tablero:
para que sepa cómo se comportó el trabajo y cómo se sintió el equipo al respecto
Si encuentra esta lista desalentadora, ¡pare! No lo hagas todo; no hemos conocido un solo equipo
que haga todas estas cosas al mismo tiempo. Comience con lo que se ajuste a sus necesidades
actuales y no se exceda. Agregue funciones según sea necesario.
Resumen 91
Si encuentras que falta algo en esta lista, probablemente tengas razón, y así es como debe ser. No
limite sus tarjetas de elementos de trabajo solo a esta lista. Este es un punto de partida. Siéntase
libre de elaborar con su creatividad y crear cosas increíbles.
Aquí hay ejemplos de tarjetas de elementos de trabajo que usan algunas, pero no todas, las
características de las que hemos hablado:
Ahora tiene las herramientas que necesita para crear muchos elementos de trabajo;
pero no deberías. Debes crear pequeñas cantidades de trabajo. Este es el tema del próximo capítulo.
5 Trabajo en proceso
■ Introducción del concepto de trabajo en proceso

(WIP)
■ Los efectos de mucho trabajo en proceso
■ Cómo limitar el trabajo en proceso
El trabajo en proceso (WIP) es una frase que escuchará mucho en la comunidad kanban o al leer
sobre Lean. WIP parece ser algo que no deseas o al menos quieres lo menos posible, por lo que a
menudo escucha a los aficionados kanban hablando de "limitar" WIP.
Este capítulo lo ayudará a comprender qué es WIP, qué podría suceder si permite una gran cantidad
de WIP en su proceso y, finalmente, algunas formas de ayudarlo a limitar el trabajo en proceso.
92
Comprender el trabajo en proceso 93
En serio, Joakim, tú y
Marcus deben dejar
de hablar de whips.
Ese no es el tipo de
gestión que
queremos ver por
aquí. ¿Bien?
Nosotros tampoco,
por supuesto. Pero
estamos hablando de
WIP y no de whips.
Oh no, otra palabra

de moda. Ok, ¿qué es
eso entonces?
WIP: Trabajo en
proceso. Siéntate;
Esto será instructivo,
pienso.
5.1 Comprender el trabajo en proceso

En esta sección, analizaremos el concepto llamado trabajo en proceso. Primero hablemos un poco
sobre la abreviatura WIP y cómo se puede interpretar. WIP tiene al menos dos significados
diferentes:
Trabajo en progreso
Trabajo en proceso
Ambos significados son ampliamente utilizados en la literatura Lean. Nos pasó al recoger "en
proceso" de la literatura que leímos a medida que aprendíamos sobre Lean y kanban. A lo largo de
este libro, estamos utilizando el trabajo en proceso, pero puede intercambiarlo en progreso si lo
desea.
5.1.1 ¿Qué es el trabajo en proceso?

Trabajo en proceso significa todo el trabajo que está haciendo en este momento. Eso incluye el
trabajo en el que está trabajando activamente en este momento, los elementos de trabajo que
esperan ser verificados o implementados, y también el trabajo que se encuentra en su bandeja de
entrada que aún no ha comenzado: todas las cosas pendientes que debe hacer para entregar valor al
cliente final.
94 CAPÍTULO 5 Trabajo en proceso
TRABAJO EN PROCESO Y TIEMPO DE ENTREGA

Limitar WIP es uno de los principios básicos de kanban. No significa que debas hacer menos
trabajo, sino que debes hacer menos trabajo al mismo tiempo. Limitar su WIP lo ayudará a
completar más trabajo en total más rápidamente.
Si recuerda, en la introducción jugamos un pequeño juego con los Kanbaneros: Pase los
Peniques (vea el capítulo 13 para obtener detalles sobre cómo ejecutar el juego). El objetivo de este
juego era mostrar cómo las diferentes cantidades de WIP afectan su tiempo de entrega, el tiempo
que tarda un elemento en completar su proceso completo. Cuando se les pidió a los Kanbaneros que
volcara 20 peniques cada uno antes de continuar, el tiempo de entrega total fue alto; el WIP fue de
20 elementos en esta etapa. Cuando el WIP se redujo, o se limitó, primero a cinco (cada trabajador
volcó cinco peniques y se los pasó) y luego a uno (cada trabajador volcó un penique y se las pasó),
el tiempo de entrega se redujo. El juego simple te mostró que cuanto más grandes sean los lotes,
más WIP tendrás y mayores serán los tiempos de entrega.
UNA PALABRA DEL ENTRENADOR Si desea algunos ejemplos

más concretos de lo que puede significar mucho WIP antes de
continuar, podemos darle uno de cuando estábamos escribiendo este
libro. En un momento nos impacientamos y comenzamos a escribir
muchos capítulos simultáneamente, antes de terminar los que
estábamos trabajando. Teníamos alrededor de ocho capítulos al mismo
tiempo, y algunos de ellos se estaban acercando. Luego decidimos reestructurar la tabla de
contenido y terminamos moviendo muchas cosas. Ese cambio fue considerablemente más
difícil de hacer, tomó más tiempo y causó más dolor con un WIP de ocho capítulos que,
por ejemplo, dos capítulos.
Esta relación entre WIP y el tiempo de entrega se ha expresado como una ley en matemáticas, en
teoría de colas, para ser más precisos. Se llama Little’s law (Ley de poco); Echemos un vistazo más
de cerca.
Todo esto me parece un poco

mágico. ¿La reducción de WIP
siempre tiene ese impacto
positivo en el tiempo de
entrega? ¿Hay alguna manera
de probar algo de esto? ¿Esta
ahí? ¿Esta ahí?
Cálmate ahora ... nos dirigimos

a alguna teoría en la siguiente
sección. Quizás encuentres
respuestas allí.
LITTLE'S LEY
Cuando se habla de limitar WIP, a menudo surge la Ley de poco. La ley de poco es una prueba
matemática de John D.C. que dice que mientras más cosas tengas al mismo tiempo, más tiempo
tomará cada cosa. Es una fórmula que se ve así:
Número de
elementos en los
que trabaja al
Tiempo a través del mismo tiempo
proceso para cada
elemento Tiempo promedio
que lleva
completar cada
elemento
Como siempre, la primera vez que ves algo así, la respuesta correcta es "¿Eh ... qué?" Si eres como
nosotros, no te hizo decir "¡Ajá!" Agreguemos algunos números reales y veamos si eso lo aclara.
Imagine que su equipo toma 12 elementos
durante un mes y trabaja en todos ellos al
mismo tiempo, lo que resulta en una WIP de
12 elementos. También suelen terminar 12
elementos por mes, dándoles un rendimiento
de 12 por mes. Ahora es trivial calcular el
tiempo de ciclo para cada elemento: 1 mes.
Hagamos un experimento y, sin cambiar nada

sobre la forma en que trabajan las personas, la
cantidad de personas en el equipo o los
elementos de trabajo, trabajemos con seis
elementos al mismo tiempo. Eso le da un WIP
de 6, una tasa de rendimiento de 12 por mes y un
tiempo de ciclo de medio mes.
¡Guauu! Es una gran mejora simplemente haciendo menos cosas al mismo tiempo; no estas de
acuerdo?
Para completar, lo contrario también es cierto.
Duplique la cantidad de elementos en los que trabaja, y
el tiempo de ciclo se duplica a dos grandísimos meses.
Esto se debe a que las otras condiciones (forma de
trabajo, tamaño del elemento, personas en el equipo,
etc.) siguen siendo las mismas.
Al manejar menos elementos en el mismo elemento (o limitar su WIP), está reduciendo el
tiempo del ciclo y moviendo las cosas más rápido a través del proceso, ¡sin cambiar nada más!
Probablemente pueda hacerlo ahora y que sus elementos de trabajo fluyan mucho más rápido a
través de su flujo de trabajo. Esto, a su vez, le brinda retroalimentación más rápido y le ayuda a
conocer su proceso más rápido, lo que a su vez le brinda la oportunidad de mejorar su proceso para
avanzar aún más rápido.
ADVERTENCIA
¿Notó el pequeño "probablemente" allí? Si su WIP ya es bastante
bajo, es probable que no pueda bajarlo y esperar que las otras
variables en la ecuación de Little se mantengan estables. Puede
resultar difícil paralelizar el trabajo y hacer que dos personas
trabajen en una tarea con la misma eficiencia. La disminución de
DESAFÍOS WIP puede tener un impacto negativo en la tasa promedio de
ADELANTE finalización.
Esto no es necesariamente algo malo; de hecho, es una de las fortalezas de kanban,
porque representará un desafío de mejora. ¿Qué tiene que cambiar en su forma de
trabajar para mantener su tasa de finalización, aunque reduzca la cantidad de WIP?
Puede leer más sobre esto en la sección 11.1.2.
Ahora sabe un poco sobre el concepto de trabajo en proceso y la teoría de por qué desea limitarlo.
Seamos un poco más concretos y veamos cómo WIP puede manifestarse en la industria del
desarrollo de software.
5.1.2 ¿Qué es el trabajo en proceso para el desarrollo de software?
En el capítulo 1, los entrenadores ayudaron al Equipo Kanbaneros a comprender cuál era su WIP.
WIP en la fabricación ajustada es obvio porque a menudo se manifiesta físicamente: los elementos
se acumulan frente a una máquina en espera de ser procesados o los elementos terminados en el
piso esperando ser trasladados al siguiente paso en la cadena de procesamiento. Una vez que
aprende que puede tener un impacto negativo en su trabajo, es bastante fácil de detectar, porque a
menudo involucra cosas físicas.
WIP en el trabajo de conocimiento no es visual, y esta es la fuerza impulsora detrás de
querer visualizar el trabajo, para hacer que el trabajo sea aparente y obvio donde antes no estaba.
Esta es una de las razones principales para crear tableros y adhesivos que muestren sus elementos
de trabajo y su estado, como se describe en el capítulo 3. El trabajo está ahí incluso si no usa un
tablero; simplemente no lo ves tan claramente.
Pero hay más en WIP que la cantidad de elementos en los que está trabajando al mismo
tiempo. Considerar solo el número de cosas que está haciendo al mismo tiempo es una
simplificación. En esta sección, veremos un par de formas en que WIP puede manifestarse en el
mundo del desarrollo de software.1
LAS ESPECIFICACIONES NO SE IMPLEMENTAN AÚN

Si lo piensa, las especificaciones tienen una fecha de "mejor antes". Se podría decir que se pudren si
se dejan por ahí.
1
Consulte Mary y Tom Poppendieck, Implementación del desarrollo de software Lean (Addison Wesley Professional,
2006, http://amzn.com/0321437381), para obtener más información al respecto.
¿Que es ese
olor?
¿Esta? Son solo las

especificaciones para la
nueva pantalla de inicio
de sesión. Lo escribí hace
unos meses. Debería
estar bien, ¿verdad?
Imagine que hoy escribe una especificación y luego la deja. ¿Cuáles son las probabilidades de que
alguien pueda recogerlo en seis meses y comenzar a codificarlo? Incluso después de solo dos meses,
solo hay una pequeña posibilidad. Las cosas en el entorno empresarial cambian, y el sistema para el
que se escribió la especificación probablemente también ha cambiado durante el tiempo de espera.
Como mínimo, debe volver a revisar la especificación para asegurarse de que siga siendo válida.
Una especificación escrita y tendida a la espera de ser implementada es un trabajo en su
proceso.
CÓDIGO QUE NO ESTÁ INTEGRADO

Continuando con un proceso de Para resumir:
desarrollo estereotípico, lo siguiente simplemente no
que podría aumentar su WIP es el funciona, Eric. ¡Ni

siquiera hay un
código implementado que aún no ha
botón para hacer
ingresado e integrado con el código de
clic!
otras personas. Eso también es WIP,
porque no sabes cuánto trabajo queda
por hacer antes de terminar con el
elemento de trabajo.
Si alguna vez escuchó la frase
¡Eso es tan raro!
"Funciona en mi computadora", ya
Funciona bien en
sabe lo que queremos decir. Si aún no
mi computadora ...
ha integrado el código con el trabajo de
otras personas, todavía no sabe si
funciona en absoluto. Funciona en su
computadora, con su configuración y en su entorno.
Verificar e integrar su código a menudo es una buena manera de no acumular un montón de
trabajo de integración y obtener comentarios rápidos sobre la calidad del trabajo que ha realizado
hasta ahora.
CÓDIGO NO PROBADO
El código no probado es otra forma en que WIP se Entonces, ¿la
manifiesta en el desarrollo de software. Escribir código impresión del
sin tener una forma rápida de averiguar si funciona o no informe ya está
es una excelente manera de acumular un stock de trabajo lista?
inacabado.
Las pruebas automatizadas son una forma de manejar
Sí, claro ... todavía
este problema. Al utilizar las pruebas unitarias
no lo he probado,
automatizadas o el desarrollo basado en pruebas (TDD),
pero está hecho al
obtiene comentarios rápidos de que no está introduciendo
95%.
defectos en el software existente. Al realizar pruebas de
aceptación automatizadas o especificaciones, por ejemplo, obtiene comentarios de que está creando la
aplicación correcta.
UNA PALABRA DEL ENTRENADOR El desarrollo basado en pruebas

(TDD) es una práctica de diseño y desarrollo en la que comienza escribiendo
una pequeña prueba para el código que está a punto de escribir. Es una
microespecificación para el próximo fragmento de código que necesita para
cumplir con su tarea. Como efecto secundario de trabajar de esta manera,
obtienes un conjunto de casos de prueba para todo tu código. ¡TDD se trata de desarrollar las
cosas bien!
OTRA PALABRA DEL ENTRENADOR La especificación por ejemplo

también se conoce como desarrollo basado en el comportamiento (BDD) y es
una forma poderosa de, en esencia, escribir sus especificaciones como casos
de prueba ejecutables. Las especificaciones, por ejemplo, se refieren a la
comunicación y a asegurarse de que todos se entiendan entre sí. Hacer esto
mal, en nuestra experiencia, lleva mucho tiempo, porque luego tienes que ir y venir y anclar la
información en torno a la característica para construir. Al utilizar ejemplos concretos al principio
del proceso, a medida que especifica la funcionalidad, aumenta la probabilidad de que todos digan
lo mismo cuando habla de la función. En esencia, la especificación por ejemplo se trata de
desarrollar lo correcto.
CÓDIGO NO EN PRODUCCIÓN
Finalmente, el código que se ha desarrollado y ¿Has terminado? Genial: iniciaré
sesión y lo probaré ahora mismo.
probado pero que no se ha montado en
¡Fácil, gran amigo! Hemos
producción también es WIP. Todavía tiene
terminado, pero no está en
trabajo por hacer y aún no sabe si la producción. El próximo
funcionalidad lo hace bien o si tendrá un efecto lanzamiento está programado en
negativo en otras partes de su sistema. Sobre tres semanas.
todo, todavía no proporciona ningún valor al

usuario, sigue siendo WIP.
Efectos de demasiado WIP 99
Si lo piensa por un tiempo, el código en producción también podría ser WIP. El trabajo no está
necesariamente "hecho" simplemente porque está en producción. Tener el código en producción,
funcionando, no es lo que importa: es cómo lo reciben los usuarios, si se benefician de él y si su
software logró el impacto (comercial) que usted pretendía. Si el comportamiento del usuario no se
ve afectado, ¿realmente ha terminado?
Ahora hemos examinado qué es WIP y cómo se manifiesta en nuestra industria. Vamos a
sumergirnos y analizar los efectos de demasiado WIP.
5.2 Efectos de demasiado WIP

Ahora podrías pensar, bueno, mucho trabajo en proceso es algo malo, lo sé. ¿Pero qué tan malo
puede ser? ¿Qué pasa si tienes demasiado WIP? Esta sección examina la respuesta en detalle. Es
una lectura desmoralizante, pero mantén la cabeza alta. Ya sabes cómo abordar esto: ¡limita tu WIP!
5.2.1 Cambio de contexto
¡Hola adam!
¿Qué pasa?
Mucho ... Estoy

tratando de probar esta
nueva página, y llego
tarde con las pruebas
automatizadas de esta
semana. Además de eso,
la reunión de diseño
para las características
de la próxima semana
se está acercando.
Tratando de hacer un
poco de todo, para
mantener mis tareas en
marcha. ¿Que
necesitas?
Bueno ... te esperamos

en la reunión de
gestión del proyecto ...
# &! @ ¡Doh! Ya voy.

Voy a poner estas
tareas en espera por
ahora. Espero recordar
lo que hice cuando
regrese ...
Si eras Adam en la caricatura anterior, ¿crees que tendrías que luchar para recordar lo que estabas
haciendo cuando volviste? Probablemente lo harías, ¿verdad? Esto sucede debido a algo que a
menudo se conoce como cambio de contexto.
El cambio de contexto fue originalmente un concepto de

computación que describe cómo la computadora almacena
y recupera el estado de un proceso a medida que cambia a
otro. Esta es la base de la multitarea de varios procesos en
un CPU. La sensación de "tratar de volver a lo que sea que
estaba haciendo" es lo mismo, pero para los humanos. Al
cambiar entre varias tareas, debe configurar en su mente el
"estado" de la tarea que estaba haciendo anteriormente.
Piense en ello como un cambio de contexto humano.
Puede comparar esto con el tiempo de configuración de
una máquina en una fábrica. Si la máquina está preparada
para producir el Modelo A, tomará algún tiempo
reajustarla para producir el Modelo B. Entonces, es fácil
entender que por cada pieza que está alternando entre el Modelo A y el Modelo B, se perderá mucho
tiempo debido a la configuración.
Eso es exactamente lo que experimentas cuando cambias de contexto en el trabajo del
conocimiento. Pierdes tiempo y concentración para cada tarea que intenta mantener en tu cabeza al
mismo tiempo.
Un estudio2 mostró que hasta el 10% de su tiempo de trabajo por proyecto se pierde por el
cambio de contexto. Esto significa que si ejecuta dos cosas a la vez, solo tiene que gastar el 40% de
su tiempo de trabajo disponible por proyecto. Con cinco tareas al mismo tiempo, solo le queda un
5% por proyecto.
X = Número de proyectos simultáneos ■ Tiempo de trabajo disponible por proyecto.

Y = Porcentaje de tiempo de trabajo ■ Pérdida por cambio de contexto
Libro de Gerald Weinberg Quality Software Management: Systems Thinking (Dorset House, 1991,
http://amzn.com/0932633226) a menudo se menciona como la fuente de estos números, aunque no hemos podido para
encontrarlos allí. Pero Weinberg ha confirmado que él es la fuente en correspondencia privada con nosotros.
Curiosamente, otro estudio también mostró que el cambio de contexto representaba una caída de 10
puntos en el coeficiente intelectual. ¡Eso es más del doble del número encontrado en estudios sobre
el impacto de fumar marihuana (!). Entonces, si tiene que elegir entre los dos, ya sabe qué hacer.3
¿Qué puedes hacer entonces? Estos proyectos y tareas son parte de su WIP, el WIP para
usted. Y ahora ya sabe qué hacer con WIP: ¡limítelo! Mantenlo al mínimo. Si tienes que mantener
varias tareas, al menos trate de tener la menor cantidad posible a la vez. Intenta completar una antes
de comenzar otra. Hacer esto lo ayudará a evitar el cambio de contexto y completar cada tarea más
rápidamente (de acuerdo con la ley de Little).
Ahora sabe algo sobre el problema con el cambio de contexto en nuestro tipo de trabajo.
Continuemos y echemos un vistazo a otro de los problemas que causa mucha WIP: más trabajo.
5.2.2 El retraso causa trabajo extra
Eric, ¿recuerdas la
nueva página que
creaste justo antes de
Navidad el año pasado?
Eeeehhh ...
no. ¿Vos si?
¡Pues no funciona! No
he tenido tiempo de
probarlo hasta ahora ...
¿puedes arreglarlo muy
rápido?
Imagine que introduce un error en la aplicación que está escribiendo. Si recibe una notificación al
respecto de inmediato, en cuestión de minutos, es fácil de solucionar y no habrá pasado nada malo.
Ahora considere la misma situación, pero suponga que toma dos meses antes de que alguien
encuentre el error y le notifique. Ahora es mucho más trabajo arreglar el error. Primero debe
recordar cuál es la función, qué hizo al respecto y cómo solucionarla.
3
Queremos dejar claro que la última parte fue una broma. No queremos que nadie piense que estamos haciendo
proselitismo por usar marihuana. Marcus, miembro del Ejército de Salvación, particularmente quiere subrayar esto. Sin
embargo, el estudio no es una broma: "‘Infomania’ peor que la marihuana ", BBC News, http://mng.bz/HjcX.
Entonces es posible que deba configurar el sistema en el estado en que se encontraba en ese
momento para poder reproducir el error. Finalmente, el resto del sistema podría haber cambiado
desde entonces, haciendo que el error sea mucho más difícil y complicado de solucionar. Y eso solo
considerándolo a usted y a su situación. Es posible que tenga que involucrar a otros para poder
reproducir el defecto (probadores, administradores del sistema o DBA para configurar el sistema en
el estado correcto, por ejemplo).4
Todo este trabajo adicional se debe a la demora desde el momento en que introdujo el error
hasta que se le notificó su existencia y podía hacer algo al respecto. Obtiene más trabajo (en
proceso) debido al retraso en sí.
Este problema se reduce a que el ciclo de
retroalimentación es más largo. No solo una gran
cantidad de trabajo al mismo tiempo hace que cada
elemento vaya más despacio, sino que la
retroalimentación sobre cómo cada elemento de trabajo
se recibió y se comporta en la producción también lleva
más tiempo.
Y eso es algo malo.
La retroalimentación es una parte esencial de cada
proceso ágil. La retroalimentación es la creadora del conocimiento.
Le informa sobre la calidad de su trabajo y la calidad de su flujo de trabajo. ¿Que funciona?
¿Qué deberías cambiar? ¿Qué no deberías cambiar?
Cuanto más rápido pueda obtener retroalimentación, más rápido podrá cambiar un mal
proceso por uno ligeramente mejor. Por lo tanto, debe fallar rápidamente si hay algún problema. La
retroalimentación retardada dificulta la conexión del efecto con su causa, lo que hace que el
aprendizaje sea muy difícil o incluso imposible.
Como has visto, una mayor WIP hace que la
retroalimentación se vuelva cada vez más lenta. Y
la retroalimentación lenta en sí misma hace que se
cree aún más trabajo, lo que provoca una WIP aún
mayor, lo que prolonga el ciclo de
retroalimentación, y ... bueno, ya ves hacia dónde
se dirige, ¿no? Al reducir su WIP, puede estar al
tanto de este problema y obtener retroalimentación rápidamente sobre los elementos de trabajo
pequeños que se mueven rápidamente a través del flujo de trabajo completo.
Pero más WIP, tiempos de entrega más largos y ciclos de retroalimentación prolongados:
¿son tales como un gran problema? Sí, y las siguientes secciones le mostrarán ejemplos de cómo
pueden perseguirlo.
4
En un cliente, Marcus tuvo una reunión interrumpida 30 minutos porque la otra persona tuvo que leer sobre un error
que estaban a punto de discutir en la próxima reunión. "Lo archivé hace un año y medio" fue la razón comprensible de
su necesidad de ir a leer lo que escribió en ese momento.
5.2.3 Aumento del riesgo
En resumen: les digo que

en dos meses
codificaremos en un
framework de acceso a
datos sin soporte.
¡¿Estas loco?! ¿Me

estás diciendo esto
ahora? Necesitamos
dos meses para
implementar, y eso ni
siquiera cuenta el
tiempo para cambiar
el código de acceso a
datos.
Sí ... ¿escuchará nuestra

necesidad de acortar los
tiempos de entrega?
Con más trabajo al mismo tiempo, aumenta el riesgo. Esto tiene que ver con no poder cambiar
rápidamente y, por lo tanto, ser más sensible a los cambios en el mundo que te rodea.
Por ejemplo, supongamos que tiene un proceso con largos tiempos de entrega. Si su cliente
solicita un cambio en una función, llevará mucho tiempo construirla y ponerla en producción.
Durante ese tiempo, la función puede quedar obsoleta o un competidor puede recoger esa solicitud e
implementarla primero.
Un ejemplo de tal característica podría ser la integración con plataformas sociales como
Twitter y Facebook. Muchos servicios en línea ahora le permiten iniciar sesión con credenciales de
estas plataformas. Si tiene un tiempo de espera largo, digamos un año, es posible que otra persona
ya haya creado una copia de su servicio con la integración de las redes sociales.
Otros lugares donde la capacidad de cambiar rápidamente es importante son dentro de la
tecnología, así como en el entorno en el que opera su empresa (tendencias, leyes y otras
regulaciones, por ejemplo). Si no puede cambiar rápidamente y obtener nuevas funciones o cambios
para sus clientes rápidamente, corre el riesgo de perder relevancia para sus clientes, que su servicio
se vuelva obsoleto o que alguien más lo supere.
5.2.4 Más gastos generales
Adam, solo estás con

este proyecto dos días
cada dos semanas.
Tenemos problemas para
recordar lo que hiciste
desde la última vez.
Sí yo también. Debido
a que también me
asignaron otros dos
proyectos, tengo que
pasar medio día para
volver a encarrilarme.
Tal vez pueda escribir un

pequeño informe
después de cada sesión
que esté con nosotros,
para ayudarnos a ambos
a recordar.
Una cosa realmente desagradable acerca de mucho WIP es que se creará más trabajo a partir
de la necesidad de coordinar todo ese trabajo. Es un círculo vicioso que rápidamente puede salirse
de control y en el que terminas haciendo coordinación. Esto se asemeja a las situaciones que
describimos en la sección 5.2.2, en la que hablamos sobre los retrasos que crean más trabajo. El
retraso del que hablamos aquí es que tiene tiempos de entrega más largos con una gran cantidad de
WIP.
Imagine que participa en tres proyectos diferentes a la vez. No solo significa mucho cambio
de contexto para usted, sino que aquellos involucrados en los tres proyectos también probablemente
le pedirán que haga informes, seguimiento del tiempo y planificación de los tres proyectos. Debido
a que está entrando y saliendo de los proyectos, es probable que también necesite realizar muchas
entregas y coordinación. Gran parte de este trabajo adicional se crea porque está haciendo varios
proyectos al mismo tiempo. Si solo se le asignó un proyecto, no se le pediría que realice muchas de
las tareas necesarias para coordinar su trabajo entre tres proyectos.
Este tipo de situación a menudo ocurre en organizaciones con un fuerte enfoque en el uso de
"recursos"5 al máximo. Si en cambio, se enfoca en mantener el tiempo de entrega corto para las
cosas que produce y los elementos que fluyen sin problemas hacia el cliente, muchas de estas tareas
adicionales se considerarán un desperdicio y se esforzará por eliminarlas.
5
A menudo, la palabra recurso también significa personas en estas organizaciones.
UNA PALABRA DEL ENTRENADOR Ambos hemos trabajado como

contratistas durante bastante tiempo. En este negocio, el informe de tiempo es
esencial, porque ese es nuestro producto: como contratistas, estamos
facturando al cliente por horas. Sin lugar a dudas, el sistema de informes de
tiempo en las empresas contratantes suele ser un desastre, se quejan y lleva
mucho tiempo usarlo. En la mayoría de los casos, escuchará esto en cualquier empresa contratante:
"Entonces, ¿a quién debemos facturar por el tiempo que me toma hacer el informe de tiempo?"
En el empleador de Marcus, Aptitud, ha tratado de resolver el problema de este tiempo
perdido informando las desviaciones de una norma. Si está asignado a un proyecto el 60% de su
tiempo, y esa es la cantidad de horas que trabajó para ese cliente, no hace nada y Aptitud le
facturará al cliente el 60% de su tiempo. Si él, por alguna razón, tiene dos horas menos del 60%,
informa que esas dos horas son una desviación.
5.2.5 Baja calidad

Si es desarrollador, la calidad de su código puede verse afectada por largos tiempos de entrega. Esto tiene
que ver con el ciclo de retroalimentación prolongado que dura desde el momento en que escribe el código
hasta que sepa cómo se recibió y cómo funciona en la producción.
Imagine una ocasión en que se introduce un error; usted asumió que el cliente tenía un nombre, pero
debería haber un nombre y un apellido. El error pasa desapercibido, porque todos los clientes de su sistema
hasta ese momento eran empresas y usaban un solo campo de nombre.
Entonces, un día, varios meses después, su primer cliente "privado" intenta iniciar sesión y se enoja
porque no puede ingresar su nombre y apellido como solía hacerlo. Corregir este error no es fácil; Ya se ha
escrito una gran cantidad de código que depende de que los clientes tengan una propiedad de nombre único.
Has trabajado alrededor del error sin notarlo.
El sistema es Compensando y trabajando

agradable y ordenado. alrededor del problema.
Se introduce un error.
Scott Bellware6 comparó una vez esta situación con la introducción de una hernia en el sistema, y lo
ilustró con las imágenes anteriores. Al principio, su sistema es agradable y ordenado. Cuando
introduce el error, una línea se distorsiona. Hasta que esté informado sobre el error, solucionará el
problema y creará un código incorrecto que compense el error en el sistema. No es hasta que lo
arregles que puedas retomar el camino y tener un sistema bien alineado nuevamente.
Compare esa situación con una en la que se le notifique de inmediato sobre el error que
introdujo y pueda solucionarlo a las pocas horas de haberlo escrito. Sin hernia, sin problemas:
simple y rápido.
La diferencia entre estas dos situaciones es el tiempo de entrega: el tiempo de entrega desde
que introdujo el error hasta que se le informe. Durante ese tiempo, su código ha sufrido en calidad,
lo que significa que solucionar el error llevará más tiempo y será más difícil.
5.2.6 Disminución de la motivación.
Ahí. ¡Hecho! Hice un

gran esfuerzo para
tener este código listo
para probar hoy, como
usted pidió.
Excelente. Ponga su
adhesivo en la parte
inferior de la columna
"Para probar", si no le
importa.
Muy bien ... pero

espera ... hay otros 24
elementos encima.
¿Está bien?
Sí ... tiempos ocupados.

Llegaré a la tuya en
una o dos semanas. Lo
prometo.
Los largos tiempos de entrega también pueden disminuir la motivación de su equipo. No es difícil
ver por qué, porque las cosas que terminan en otra fila no aumentan la motivación.
6
Consulte Scott Bellware, “Fallas de Diseño, Hernias y Calidad Anémica”, 9 de febrero de 2009, http://mng.bz/f2x1,
para obtener más información.
Resumen 107
Tome Daphne en la caricatura anterior. Ella ha estado esclavizada con esa característica que Adam
le ha pedido que complete hoy. Incluso le tomó parte de la noche, pero sabía que tenía que estar
lista para Adam. Él lo exigió, porque las últimas tres veces tuvo que esperarla. Hacer feliz a Adam
esta vez proporcionó la sensación de urgencia (o motivación) que Daphne necesitaba para hacer un
esfuerzo adicional y terminar el elemento hoy.
Pero cuando Daphne llegó por la mañana, descubrió que el elemento era el último de una
larga pila de elementos de trabajo que debían probarse. Su motivación para entregar a tiempo
recibió un golpe severo.
En este ejemplo, fue Adam quien tenía muchas cosas sucediendo al mismo tiempo. Debido a
eso, no pudo darle a Daphne comentarios sobre su trabajo hasta dos semanas después. Eso a su vez
resultó en la caída de la motivación de Daphne; y cuando Adam finalmente regresó, no podría
haberle importado menos el resultado de la prueba. Él la interrumpía en ese momento, porque ella
se había movido a otro trabajo.
¿Qué deberían hacer al respecto? Bueno, aquí radica la verdadera razón para luchar por una
WIP más baja y, por lo tanto, tiempos de entrega más cortos. Expondrá problemas 7 para usted:
problemas que, si intenta solucionarlos, harán que su flujo sea aún más rápido, incluso más suave.
Lamentablemente, kanban no dice mucho sobre cómo solucionar estos problemas. Debe descubrirlo
usted mismo aprovechando una oportunidad de mejora no realizada a la vez. Hemos dedicado el
capítulo 10 a prácticas que pueden ayudarlo a encontrar e implementar mejoras en los procesos.
5.3 Resumen
Este capítulo habló sobre el trabajo en proceso y discutió específicamente la limitación de WIP para
obtener plazos de entrega más cortos:
■ WIP es una abreviatura común, y tiene al menos dos significados: trabajo en progreso y
trabajo en proceso. Preferimos el trabajo en proceso y lo usamos en todo el libro.
■ La ley de Little nos dice con certeza matemática que cuanto más WIP, más largo será el
tiempo de ciclo para cada elemento de trabajo. Debe limitar el WIP para obtener un flujo
más rápido y tiempos de entrega más cortos.
■ WIP puede tomar muchas formas, y observamos algunas comunes en el desarrollo de
software:
■ Especificaciones que aún no se han implementado
■ Código no integrado que "funciona en mi computadora"
■ Código no probado, que puede o no estar a la altura de sus estándares
■ Código no en producción, que se sienta y espera el próximo lanzamiento
■ Los problemas y las cosas malas pueden derivarse de tener mucho WIP:
■ Más cambio de contexto
■ Bucle de retroalimentación prolongado, que a su vez le causa trabajo adicional
7
Lo sentimos, las "oportunidades de mejora no realizadas" son mucho mejores.
■ Y mencionamos algunas formas en que WIP puede manifestarse:

■ Aumento del riesgo
■ Más gastos generales
■ Baja calidad
■ Menos motivación
Ahora tiene un conocimiento sólido de lo que es el trabajo en proceso y por qué demasiado es malo,
y tiene una comprensión teórica de qué hacer con demasiada WIP. El próximo capítulo será mucho
más práctico y comenzará a establecer límites de WIP para su equipo.
6 Limitando el trabajo en proceso

■ Principios para encontrar los límites adecuados de
WIP
■ Formas comunes en que los equipos limitan WIP
■ Formas comunes de visualizar los límites de WIP
■ Respuestas a algunas preguntas frecuentes con
respecto a los límites de WIP
Desde el capítulo anterior, esperamos haberlo convencido de que muchas cosas buenas provienen de
limitar su trabajo en proceso (WIP). Probablemente ya esté lleno de preguntas: ¿cuál es el límite
adecuado para usted? ¿Cómo haces para encontrar el límite de WIP? ¿Hay algunos buenos puntos
de partida que puedan guiarte?
Por última vez, Beth. El
límite de WIP es cuatro.
Punto final!
¿Pero por qué cuatro?

¿Y cómo sabemos si
cuatro es el límite WIP
correcto para
nosotros?
No puedes. Y no lo es.
Nunca puedes encontrar
el correcto. Es una
búsqueda eterna.
Eeeh ... se siente un

poco zen-monk-ish,
¿ahora no lo hace?
109
110 CAPÍTULO 6 Limitando el trabajo en proceso
Como pronto descubrirá, no hay reglas estrictas aquí. Encontrar un límite WIP adecuado no solo es
contextual y depende de lo que desea lograr, sino que también es como alcanzar un objetivo en
movimiento. Los límites de WIP pueden y deben cambiar. Al comienzo de este capítulo, ya
podemos revelar un secreto: el objetivo no es limitar WIP. Los límites de WIP son solo un medio
para impulsarlo a mejorar. Mejore para lograr un mejor flujo, que es el tema del próximo capítulo.
Es por eso que verá mucho "Depende" y "Puede hacer esto, lo otro" en este capítulo. No es
una señal de que no lo sepamos; es que necesita encontrar lo que funciona mejor para usted y su
equipo.
Sin embargo, no hay que preocuparse; hemos incluido y llenado este capítulo de orientación
y principios para encontrar un límite WIP adecuado, así como formas prácticas en que muchos
equipos se dedican a visualizar y establecer sus límites WIP. Vamos a sumergirnos y ver cómo
puedes razonar tu camino para encontrar un límite WIP para tu equipo.
6.1 La búsqueda de límites de WIP

Buscar un límite WIP adecuado para su equipo puede ser un asunto complicado. ¿Qué es lo correcto
para usted y su equipo en este momento? La respuesta es, la respuesta favorita de los consultores en
todo el mundo: "depende".
Y lo hace. Depende de
■ Cuánta presión hay para mejorar continuamente la organización
■ El número de personas en el equipo y su disponibilidad.
■ La forma y el tamaño de los elementos de trabajo con los que está trabajando
Y la lista continúa.
Para encontrar un límite de WIP para su equipo, aquí hay algunas reglas básicas, pero esté
preparado para cambiar los límites de WIP a medida que aprende más:
■ Más bajo es mejor que más alto.
■ Personas ociosas o trabajo ocioso.
■ Sin límites no es la respuesta.
Examinemos estos enfoques en detalle.
6.1.1 Más bajo es mejor que más alto

Un límite de WIP más bajo es generalmente mejor que uno más alto porque desea limitar la
cantidad de elementos en los que trabaja tanto como sea posible. Esto le dará mejores tiempos de
entrega y comentarios más rápidos y lo obligará a eliminar impedimentos. Estas son todas las cosas
que lo ayudan a mejorar el flujo de elementos de trabajo en su proceso.
Sin embargo, establecer el límite de WIP demasiado bajo, podría hacer que su proceso se
detenga, ya que rápidamente provocará problemas en el proceso. Imagine que todo su equipo está
trabajando en un solo elemento de trabajo, y de repente necesita una respuesta de un cliente para
continuar. Debido a que ese elemento de trabajo es lo único que estaba haciendo, se detuvo por
completo.
Los problemas son síntomas de cosas que tendrán que cambiar en su proceso para mejorar
su flujo. Encontrar muchos problemas puede convertirse rápidamente en una experiencia dolorosa
La búsqueda de límites de WIP 111
para los equipos que no están equipados para manejar muchos problemas como estos a la vez. En lugar de
sentirse alentados a mejorar y resolver sus problemas, una reacción común es darse por vencido y dejar de
preocuparse de que estén rompiendo el límite de WIP de forma regular.
Desea buscar un límite de WIP bajo, pero no demasiado bajo. Hay señales para guiarlo, como verá
en la siguiente sección.
6.1.2 Personas ociosas o trabajo ocioso

Ajustar el límite de WIP puede convertirse fácilmente en algo de lo que se habla para siempre: esforzarse por
encontrar el único límite verdadero puede dar lugar a muchas discusiones en las que nadie puede decidir qué
es lo mejor. Este no es un tiempo bien empleado; es mejor probar algo y luego ajustarlo.
Un método simple para ayudarlo a ajustar el límite de WIP hacia arriba o hacia abajo es el siguiente:
WIP demasiado alto = trabajo ocioso WIP demasiado bajo = gente ociosa
Si su límite de WIP es demasiado alto, el trabajo quedará ocioso. Habrá elementos de trabajo de los cuales
nadie es responsable. Este podría ser un buen momento para reducir el límite de WIP.
Con un límite de WIP demasiado bajo, las personas quedarán ociosas. Todos los elementos están
siendo trabajados, y hay personas sin trabajo. Ahora puede colaborar para hacer elementos o aumentar el
límite de WIP.
6.1.3 Sin límites no es la respuesta

¡Asegúrese de no caer en la trampa de no establecer un límite de WIP! Este es uno de los errores más
comunes que vemos en los equipos que comienzan con kanban. Kanban implica tres principios simples; no
elimines uno de ellos demasiado pronto.
El riesgo es que terminarás con un tablero
inundado de trabajo, como puedes ver en la figura
a la derecha, mostrando tus ineficiencias y tu
incapacidad para mover el trabajo a través de tu
proceso. Eventualmente, el tablero terminará no
siendo usado, porque no puedes ver los elementos
de trabajo para todo el trabajo en el tablero.
Los espacios de oficinas en todo el mundo
tienen tableros no utilizados cubiertos con
adhesivos.
No agregue su tablero a ese grupo triste; en su lugar, haga del tablero una herramienta que lo ayude
a mejorar.
Además, como veremos más adelante en el capítulo 7, eliminar el límite de WIP eliminará
su incentivo para mejorar. Sin límite de WIP, nada empuja a las personas a mejorar. Si permite una
cantidad ilimitada de elementos en su tablero, nada lo obligará a completar los que están allí antes
de comenzar un nuevo trabajo.
Esto se debe a que (si recuerda del capítulo 5 sobre el trabajo en proceso), mientras más
cosas tenga que hacer al mismo tiempo, mayor será el tiempo de espera para todo el trabajo en su
proceso. Desea una restricción que lo empuje hacia terminar el trabajo y hacia mejoras en su
proceso. Nos sumergiremos mucho más en esto en el capítulo 7.
Dirijamos nuestra atención a algunos principios sobre cómo decidir sobre un límite WIP
adecuado.
6.2 Principios para establecer límites

Encontrar su límite de WIP depende de su contexto y situación particular. En esta sección,
veremos algunas formas comunes en que los equipos que hemos entrenado y escuchado han
acordado sus límites.
Recuerde que no se trata tanto de encontrar el límite de WIP, sino de visualizar su límite de
WIP actual; Es el mejor hasta ahora. Debe cambiarlo tan a menudo como sea necesario. Aceptar el
cambio; es bueno para ti.
Como siempre, use los ejemplos aquí como inspiración y amplíelos para satisfacer sus
necesidades. Comencemos con un principio simple, uno que ya podría estar atascado en la cabeza
de capítulos anteriores: dejar de comenzar, comenzar a terminar.
6.2.1 Dejar de comenzar, comenzar a terminar

Un punto de partida simple pero poderoso para limitar su trabajo en proceso es aceptar esforzarse
por completar el trabajo actual antes de comenzar algo nuevo. Esto mantendrá su WIP bajo, porque
solo comienza un nuevo trabajo cuando algo más ha terminado.
Una manera fácil de comenzar a hacer esto es adoptar este eslogan para su equipo:
Deja de empezar
Comienza a terminar
Sí, tienes que pensar mucho cuando lo dices las primeras veces, pero luego se queda. Una buena
idea podría ser poner esta declaración sobre su tablero, donde se reunirá cada mañana; ¿O por qué
no usarlo como la frase inicial o final de sus reuniones de paradas diarias?
Principios para establecer límites 113
Hill Street Blues — pase de lista

Para superar ese sonido en tu cabeza, puedes usar el final de pase de lista de Hill Street Blues.
Cuando la gente abandone la parada diaria, diga:
“Oh, una cosa más. Dejen de comenzar, comiencen a terminar, todos".
Espera un segundo. Y luego agregue el famoso final:
"Y tengamos cuidado ahí afuera".
Al usar una referencia a Hill Street Blues, probablemente nos hemos salido bastante bien. Fue una
serie policial en la década de 1980 que fue un gran éxito en Suecia. Cada persona que lo ha visto
recuerda el final de las llamadas de la mañana en la estación de policía; todos se levantaron y el
sargento gritó: "Una cosa más ... tengamos cuidado ahí afuera".
Hay un gran poder en este simple eslogan, porque lo empuja a un WIP más bajo. También resume
un patrón básico de kanban: preferir terminar el trabajo antes de comenzar algo nuevo. Hacerlo lo
ayudará no solo a limitar la cantidad de elementos de trabajo en los que trabaja al mismo tiempo,
sino también a acortar los tiempos de entrega, llevar el trabajo a través de toda la cadena de valor,
obtener comentarios y mejorar su proceso.
Terminemos esta sección con una cita inspiradora para ayudarlo a recordar lo que es
importante:
No es "cuanto más comienzas, más terminas", es "cuanto más terminas,

más terminas".
—David P. Joyce
Pronto es posible que necesite un poco más de control sobre su límite de WIP, y en ese momento
este principio podría ser demasiado complejo. Pero es un gran comienzo para enfatizar un principio.
6.2.2 Uno no es la respuesta

Es deseable lograr un límite de WIP bajo porque le brinda un mejor flujo (consulte el capítulo 7),
pero establecerlo demasiado bajo probablemente será demasiado perjudicial para su flujo. Por
ejemplo, si tiene un límite WIP de uno, cualquier perturbación en el flujo, como transferencias,
personas fuera de la oficina, etc., hará que todo el trabajo se detenga. La mayoría de las
organizaciones no están listas para manejar todas esas oportunidades de mejora (recuerda que eso es
lo que llamamos problemas, ¿no?) De inmediato, por lo que probablemente debería ir con un límite
de WIP superior a un elemento.
Programación de la mafia
La programación de la mafia es un enfoque interesante y novedoso para el desarrollo del sistema,
promovido por un equipo entrenado por Woody Zuill. El concepto básico de la programación de la
mafia es simple: todo el equipo trabaja en equipo en una tarea a la vez. Eso significa: un equipo,
un teclado (activo), una pantalla (proyector, por supuesto). Es como hacer una programación de
pareja de equipo completo.
Un equipo que realiza programación mafiosa tiene un límite WIP de uno. Eso es muy efectivo
cuando se trata de completar el trabajo en el que se está trabajando lo más rápido posible.
Cualquier pregunta, cualquier problema, se abordará de inmediato; y todas las personas necesarias
para resolver el problema están presentes en la sala y tienen tiempo para resolver cualquier
problema de inmediato.
Pero este enfoque es muy ineficiente cuando se trata de utilizar al máximo a las personas del
equipo. No todas las personas del equipo escriben código activamente.
La pregunta es, ¿estás vendiendo pulsaciones de teclas o funciones completas?
Para muchas organizaciones, la programación de la mafia es demasiado extrema; un límite WIP de
uno probablemente no sea adecuado para todos. Pero para las organizaciones que pueden
manejarlo, el trabajo fluye muy rápido.
Principios para establecer límites de WIP

* Un simple eslogan puede ser suficiente:
- "Deja de empezar, comienza a terminar"
- Se asegura de que no aumentes WIP
* Esforzarse por baja WIP
- Pero probablemente no sea un WIP de uno
- A menos que estés haciendo programación
mafiosa
Resumiendo esta sección sobre orientación para establecer sus límites de WIP, podemos decir que
en la mayoría de los casos, establecer el límite de WIP en uno no es una buena idea. Debes luchar
por un número bajo, pero no necesariamente uno.
Es probable que a estas alturas desees algunos consejos prácticos sobre cómo establecer
límites de WIP utilizando prácticas, visualizaciones y métodos comunes que otros equipos han
encontrado útiles. Bueno, vamos a ello. Comenzará estableciendo un único límite de WIP para todo
el equipo.
Tablero completo, enfoque de equipo completo 115
6.3 Tablero completo, enfoque de equipo completo

En esta sección, veremos un par de formas de limitar el número total de elementos de trabajo en el
tablero para todo el equipo. Esta puede ser una forma sencilla de comenzar y puede ser todo lo que
necesita su equipo.
Recuerde que no se puede encontrar un verdadero límite de WIP. Los límites de WIP son
herramientas que utiliza para mejorar. Puede hacer preguntas como “¿Este límite de WIP ayudará a
que nuestro trabajo fluya mejor o empeore nuestro flujo? ¿Este límite de WIP dejará a muchas
personas inactivas? ¿Mucho trabajo estará inactivo? ¿Es eso un problema y qué podemos hacer para
resolverlo?
6.3.1 ¡Toma uno! ¡Toma dos!

Muchos equipos que hemos entrenado han realizado un viaje similar para alcanzar un límite WIP
adecuado. Su experiencia ilustra el tipo de razonamiento que creemos que es necesario con respecto
a los límites de WIP, y queremos relatar ese razonamiento aquí. Aprende de esto y luego elige un
límite que se adapte a ti.
Supongamos que tienes un equipo de cinco personas. Podrías, por ejemplo, comenzar
audazmente y decidir sobre un límite de WIP de uno por persona, haciendo que el límite total de
WIP sea igual al número de personas en el equipo.
Muy pronto, descubrirás que este enfoque crea algunos problemas; si te bloqueas, no puedes
retomar un nuevo trabajo sin romper el límite de WIP, por ejemplo. Puedes decidir que parece más
razonable permitir un máximo de dos elementos cada uno, por lo que las personas tienen algo que
hacer si un elemento está bloqueado. Eso hace que el límite total de WIP sea igual al tamaño del
equipo multiplicado por dos.
Pero esa configuración podría no ser razonable tampoco, porque permite situaciones en las que cada
persona del equipo puede ser bloqueada en un elemento y seguir trabajando en otro sin romper el
límite de WIP. Esa es una situación perfectamente válida con una configuración de límite WIP
como esa, pero en muchos casos esto no está presionando al equipo lo suficiente. Desea que los
límites de WIP lo empujen a resolver problemas, no permitiéndole trabajar sin notarlo (sin darse
cuenta de ellos).
Para empujar al equipo, puedes retroceder desde un límite de WIP de 10 elementos y decidir
tal vez 8. Si todos los miembros del equipo ahora están bloqueados en un elemento, comenzarán a
romper el límite de WIP si todos recogen otro para trabajar. Obtienes un leve empujón para hacer
algo con respecto al bloqueo, porque excedes el límite de WIP antes con 8 elementos de lo que lo
haría con 10 elementos. Si desea recibir esta advertencia incluso antes, baja el límite de WIP un
poco más.
Tenga en cuenta que los números en nuestros ejemplos no son tan importantes, pero el
razonamiento (lo que sucede si está bloqueado, esto mejorará el flujo, etc.) para encontrar sus
límites de WIP lo es. Recuerde: no hay un límite de WIP correcto que pueda calcularse. Debe
encontrar el que mejor se adapte a su equipo y su situación. Lo más racional es probar un límite
WIP y luego cambiarlo según sea necesario.
Además, piense en qué tipo de comportamiento desea que conduzca el límite de WIP. Es el
mecanismo que impulsa las mejoras.
6.3.2 Vengan juntos

La sección anterior permitía que cada persona tuviera al menos un elemento al mismo tiempo. Si su
equipo está utilizando prácticas de colaboración como la programación de pares, probablemente
debería reducir aún más el límite de WIP. En tales casos, puede establecer el límite de WIP en un
número menor que el número de personas en el equipo. Puede tomar el número de personas en el
equipo dividido por 1.5 (o algún otro número que considere conveniente) para obtener un límite
bajo de WIP.
Para nuestro equipo de cinco personas de ejemplo, esto sumará aproximadamente tres
elementos en total para trabajar.
Con un límite WIP de tres para un equipo de cinco personas, terminarán rápidamente sin nada que
hacer, si todos trabajan solos. Para poder manejar un límite WIP de tres y aún involucrar a las
personas en el proceso, los miembros del equipo tendrán que cooperar en los elementos para
Junta completa, enfoque de equipo completo 117
terminarlos mediante la programación de pares, escribiendo las especificaciones juntas o probando

en pares: exactamente el tipo de colaboración que buscan los equipos ágiles. Como un efecto
secundario agradable, los elementos de trabajo se moverán rápidamente en todos los ámbitos.
Esto podría ser un gran cambio para algunos equipos que no están acostumbrados a
colaborar estrechamente. Como siempre, no establezca el límite de WIP demasiado bajo para
comenzar, sino que baje poco a poco y mejore su proceso al mismo tiempo.
6.3.3 Déjate caer y dame 20

Don Reinertsen1 introdujo una técnica para establecer un límite WIP adecuado. Propuso que
primero observes qué es un nivel normal en un sistema sin restricciones. Eso significa: ¿cuál es la
carga normal de elementos de trabajo en su sistema? Comienza donde estás: visualice los elementos
de trabajo y cuéntelos para saber cuál es su WIP actual.
Luego duplique esa cantidad de
WIP y use ese número como límite, sin WIP 4-5
permitiendo el doble de WIP que
tienes normalmente. Duplicas el
límite de WIP porque se puede WIP doble sin
deducir estadísticamente que con restricciones = 10
una variación normal, casi ningún

Retroceda gradualmente
equipo alcanzará el límite. Es seguro con decrementos del 20%
decir que este límite no tendrá
ningún efecto para empezar, todos
deberían poder lograrlo. A partir de
este nuevo límite, puede disminuir
gradualmente entre un 20 y un 30%
de disminución, por ejemplo, cada mes o cada dos semanas, hasta que comience a experimentar
problemas, se acumulen colas o vea personas inactivas entre las tareas.
Veamos esto en la práctica. Digamos que un equipo generalmente tiene aproximadamente
cuatro o cinco elementos a la vez. Siguiendo el razonamiento del Sr. Reinertsen, debes comenzar
permitiendo 10 elementos en el tablero. Luego retrocede ese número en un 20% a intervalos
regulares. La primera iteración se reduce a 8 elementos, y luego 6, y luego 5, y así sucesivamente.
Al hacer esto, no solo estás disminuyendo el límite de WIP, que hará que los elementos
fluyan más rápido a través de su sistema. También estás comenzando una tendencia de esfuerzo
continuo para mejorar: una mentalidad que caracteriza el pensamiento Lean.
Esta propuesta pone el foco en un aspecto importante de los límites de WIP; son baratos de
implementar. Eliges el número y no trabajas más que eso. Si eso no funciona para usted, si hay
demasiados elementos de trabajo inactivos, puedes volver al nivel que tenía antes. Esto hace que los
límites de WIP sean excelentes para su uso en experimentos.
1
Presentado en una conferencia magistral en la conferencia Lean Kanban de Europa Central 2012. para más
información, ver www.lean-kanban.eu/sessions/reinertsen/.
¿Qué sucede si reduces el límite en un 20%? Pruébalo y verás; Si no funciona, regrese y piense en
lo que sucedió. ¿Qué tendrías que hacer de manera diferente para poder reducir el WIP y mantener
los elementos fluyendo a través de tu sistema?
Este enfoque le enseña al equipo a evaluar continuamente el límite para mejorar el flujo.
Debido a que el límite inicial de WIP es alto, disminuirlo las primeras veces no causará grandes
problemas. Esto ayuda al equipo a acostumbrarse a evaluar y cambiar sus límites regularmente.
Aunque en este ejemplo utilizamos un enfoque de límite de WIP para todo el equipo, tiene
mucho sentido aplicar el mismo pensamiento con un enfoque de límite de WIP basado en columnas
(como se discutió en la sección 6.4). Puede dejar de disminuir los límites para las columnas donde
siente dolor y seguir disminuyendo para otras columnas.
6.3.4 Elige un número y baila

Si no sabe cuál podría ser un límite WIP adecuado, elija un número de la nada. Si, lo lees
correctamente. ¡Elige cualquier número antiguo!
O, más bien, adivine de forma inteligente lo que podría ser inteligente, pero no piense
demasiado. Este número, como hemos dicho muchas veces, podría y debería modificarse a medida
que avanza y lo considera conveniente.
Use los principios para encontrar un buen límite, como se describe en la sección 6.1, para guiarlo
hacia el establecimiento de su límite WIP.
Límites de WIP de todo el equipo

* Un número total para todo el equipo
* Estrategias de ejemplo:
- Toma dos
- Venir juntos
- Duplica y luego cae en incrementos de 20%
- Elige cualquier número
* Cambie su límite según sea necesario
* Baje su WIP para mejorar los plazos de entrega
Limitar WIP basado en columnas 119
Hasta ahora hemos considerado los límites de WIP para toda la tabla y todo el equipo. Al hacer esto,
no se preocupa por cómo se distribuye el trabajo entre los pasos de su workflow (las columnas en su
tablero). Establecer un único límite de WIP, como los ejemplos que hemos considerado hasta ahora,
a veces se conoce como un sistema con un WIP constante (también conocido como CONWIP).
Ahora echemos un vistazo a otros enfoques para limitar WIP. ¿Podría limitar WIP solo para
partes de su flujo de trabajo? ¿Por qué harías eso? ¿Y cómo se puede visualizar eso?
6.4 Limitar WIP basado en columnas

La mayoría de los equipos con los que hemos trabajado establecen límites de WIP por columna en
lugar de para todo el equipo. Esto les da un control un poco más detallado sobre cómo fluye su
trabajo y una oportunidad para manejar cuellos de botella y flujo desigual. Dicho esto, establecer un
WIP para toda la tabla aún podría ser útil y, si no sabe por dónde empezar, proporciona un buen
punto de partida.
En esta sección, profundizaremos en las formas comunes de limitar el WIP por columna,
algunas cosas a tener en cuenta al hacerlo y lo que puede obtener de un enfoque de WIP por
columna.
6.4.1 Comience desde el cuello de botella

Todos los flujos de trabajo siempre tienen un cuello de botella en alguna parte, lo que marca el
ritmo de todo el flujo de trabajo. Aumentar el rendimiento aguas arriba del cuello de botella solo
acumulará trabajo en una cola frente a él, y tratar de aumentar el rendimiento aguas abajo del cuello
de botella es inútil porque no habrá suficiente información para trabajar. Si puede identificar el
cuello de botella en su flujo de trabajo, tiene sentido utilizar los límites de WIP para ayudar a
resolverlo. Para obtener más información sobre los cuellos de botella y cómo descubrirlos y
gestionarlos, consulte la sección 7.5.
Veamos un ejemplo, en el tablero a la derecha.
Aquí tenemos un flujo de trabajo donde los
elementos de trabajo se están acumulando en
una cola frente a un cuello de botella: la
columna Test. Si no hace nada, el trabajo
continuará acumulándose, y aumentará el tiempo
de trabajo y los tiempos de entrega. Si por el
contrario, establece un límite WIP de digamos 3
en toda la columna Development, los
desarrolladores tendrán que dejar de hacer el
trabajo de Desarrollo cuando la cola comience a
construirse. ¿Qué deberían hacer en su lugar?
Podrían ayudar a los probadores a terminar su trabajo. Hagan lo que hagan, no deberían realizar
nuevos trabajos, porque eso solo generará más WIP.
Como puede ver, poner un límite de WIP en el escalón que alimenta el cuello de botella
evitará que el cuello de botella se inunde e impulsará el comportamiento para resolver el cuello de
botella, mejorando así todo el flujo.
Comience desde el cuello de botella

* Un cuello de botella es un paso en su flujo de
trabajo que ralentiza su flujo
* Limitar el paso que alimenta el cuello de botella
para evitar que se inunde
* Y llevar al equipo a resolver el cuello de botella
6.4.2 Recoger una columna que te ayudará a mejorar

¿Por qué compraste este libro? ¿Cuál es la razón por la que crees que kanban te ayudará a mejorar?
La mayoría de los equipos ya tienen una idea bastante buena sobre dónde residen (algunos de) sus
problemas. Un escenario común es usar kanban para colaborar juntos en menos elementos de
trabajo para completarlos más rápido. En un equipo de desarrolladores en su mayoría, podría tener
sentido poner un límite de WIP desafiante en la columna Development, donde se realiza la mayor
parte del trabajo activo, para impulsar la colaboración.
Muchos equipos comienzan con uno de los enfoques de "equipo completo, tablero
completo" descritos en la sección 6.3 y distribuyen los números en diferentes columnas. También
puedes aplicar el total a una sola columna: por ejemplo, poner 1,5 veces el número de
desarrolladores como límite WIP en la columna Development.
6.4.3 Una historia limitada, por favor

Hay tantas formas de limitar WIP como equipos en el mundo, pero mencionaremos una que a veces
surge como una pregunta: ¿puedes limitar tu trabajo en proceso en función del tamaño estimado del
elemento de trabajo, por ejemplo, usando puntos de historia? 2 (Puedes leer más sobre los puntos de
la historia en el capítulo 9.)
Como hemos dicho, probablemente tendrás que experimentar para encontrar un límite de
WIP que sea adecuado para tu equipo. Comienza con tu instinto y ajusta el límite hacia arriba o
hacia abajo, como se describe en la sección 6.1. Esto se aplica al tamaño de esfuerzo estimado de su
elemento de trabajo (por ejemplo, en puntos de historia), así como a los elementos de trabajo.
Muchos equipos que usan Scrum ya lo hacen, porque cuando planean su próxima iteración,
observan cuántos puntos de la historia suelen terminar y llevan esa cantidad de trabajo nuevo a la
iteración.
2
Los puntos de historia son una forma de estimar el esfuerzo de un equipo, utilizando medidas relativas; se usan en
muchos métodos ágiles, como Scrum y Extreme Programming (XP).
Limitar WIP basado en columnas 121
Limitar WIP por el tamaño estimado significa que solo realizas un nuevo trabajo siempre que lo
mantengas por debajo de un límite acordado: por ejemplo, menos de 10 puntos de historia. La
siguiente figura muestra un ejemplo de un tablero simple donde los desarrolladores tienen un límite
WIP de 10 puntos de historia.
(1) Los desarrolladores terminan un

elemento de trabajo estimado en
tamaño en cuatro puntos de historia.
Ahora se pueden agregar cuatro puntos
de historia a su columna Doing.
(2) Los desarrolladores terminaron la historia

de cuatro puntos, por lo que el equipo ahora
saca dos elementos de InBox. Los valores estimados
de esas dos historias suman cuatro puntos,
lo que no rompe el límite de WIP.
Este enfoque de limitación de WIP a menudo es más adecuado para decidir por columna, en lugar
de para un equipo completo, porque el tamaño de un elemento de trabajo puede cambiar cuanto más
trabaje con él. Por ejemplo, cuando comienza a analizar un elemento, puede encontrar que su
implementación requerirá menos esfuerzo del que anticipaba.
Límite por tamaño estimado

* Establezca un límite de WIP para el número de
puntos de historia en una columna
* Probablemente el más adecuado por columna
* El tamaño puede cambiar durante la vida útil de
un elemento de trabajo
6.4.4. Cómo visualizar los límites de WIP
Los límites de WIP basados en columnas a

menudo se visualizan dibujándolos sobre cada
columna del tablero.
Pero las variantes de esto son abundantes.
Algunas cosas que hemos visto al trabajar con equipos son las siguientes:
■ Cajas para cada
elemento de trabajo:
esto se hará evidente
cuando rompa el
límite, ya que debe
colocar su elemento
de trabajo fuera de
un cuadro o encima
de otro elemento de Hmmm...
qué es esto?
trabajo. Se ve extraño.
¡Bien! Espacio
■ Pliegos de plástico para uno más.
u otros marcadores
de posición física
para cada tarjeta de
elemento de trabajo
permitida: Esto es similar a los cuadros dibujados y también es un buen indicador visual que
lo ayuda a realizar un seguimiento de cómo le está yendo contra el límite WIP establecido.
Lo que uses depende de tu imaginación y de lo que se adapte a tu equipo. No tengas miedo de
experimentar. Pruebe algo nuevo y falle, en lugar de contentarse con una configuración sub-óptima.
Como puede ver, hay muchas maneras de usar los límites de WIP en las columnas de su
tablero para ayudarlo a encontrar problemas, cuellos de botella y otras cosas que ralentizan el flujo
en su proceso. Lo que funcionará mejor para usted se deja como un ejercicio empírico:
experimentar. Pruebe algo y cambie para mejorar.
WIP por columna

* Centrarse en el flujo sobre el tablero
* Encuentra colas y bloqueos antes
* Dibuje el número anterior o use límites físicos
(cajas o carpetas)
* Observe el flujo y ajuste según sea necesario
Pasemos ahora nuestra atención a otra forma de limitar WIP: por persona.
Limitar WIP basado en personas 123
6.5 Limitar WIP basado en personas

Algunos equipos pueden tener una situación en la que las personas toman el trabajo de principio a
fin, y no es común ni factible entregar el trabajo a otra persona. El flujo de trabajo puede seguir
siendo una secuencia de pasos por los que pasa el trabajo. De hecho, esto puede ser valioso para
mostrar en qué estado se encuentra el trabajo en este momento, a pesar de que la misma persona
está haciendo el trabajo durante todo el proceso.
Un ejemplo típico de un equipo como este es el soporte de primera línea, en el que obtienes
un caso de un cliente en una situación desesperada y te mantienes en él hasta que se resuelva. Tal
caso podría pasar por las siguientes fases: encontrar una solución para el cliente, presentar un error,
probar una nueva versión del sistema con la corrección del error y finalmente cerrar el caso.
Probablemente todas estas etapas sean manejadas por una sola persona en un equipo de soporte.
Esto requiere otra estrategia: algunos equipos eligen limitar la cantidad de elementos de
trabajo para cada persona. No se enfocan tanto en optimizar el flujo a través del workflow, sino en
asegurarse de que nadie asuma demasiado trabajo y que todos tengan cosas que hacer.
Otra situación en la que es adecuado limitar WIP por persona es luchar contra la multitarea
en todos los niveles del equipo. En este caso, un límite de WIP por persona puede ayudar a
visualizar que algunas personas están involucradas en muchos elementos de trabajo, 3 lo que podría
ser un conductor detrás de todo el equipo que tiene demasiado WIP. Puedes tener conversaciones
sobre cómo prevenir eso, con un límite por persona explícito.
6.5.1 Formas comunes de limitar WIP por persona

Ahora veremos más de cerca algunas formas comunes de visualizar los límites de WIP basados en
personas.
ESTA TABLA NO ES SUFICIENTEMENTE GRANDE PARA TODOS ESTOS AVATARES
Los avatares en uso se

colocan en la tarjeta en la
que están trabajando.
¡Mira! Adam tiene todos sus

avatares en el tablero ...
¿Es demasiado para él?
¿Necesita ayuda en alguno de
esos casos de prueba?
Los avatares que no estén en uso se

pueden colocar en un estacionamiento.
3
Estas personas se conocen como acumuladores (consulte la siguiente barra lateral para ver un ejemplo de la vida real).
Si estás utilizando avatares para indicar quién está trabajando en qué, una medida simple es limitar
el número de avatares que cada persona puede tener "en juego" al mismo tiempo. Podrías, por
ejemplo, imprimir tres avatares para cada persona, estableciendo efectivamente el límite de WIP por
persona en tres. Ahora es fácil ver quién está haciendo qué y con cuántos elementos trabaja cada
persona en este momento.
Pobre Sean, tenía muy pocos avatares.
En un equipo que Marcus entrenó, estaba este tipo: vamos a llamarlo Sean. Sean había estado
involucrado con esta aplicación desde antes de que nacieras. Prácticamente lo construyó él mismo.
Cada decisión fue tomada de una forma u otra a través de él. Probablemente has conocido a Sean
un par de veces, o al menos su tipo de persona.
Esto ralentizó considerablemente al equipo, porque el equipo era bastante grande (ocho personas)
y cada elemento de trabajo tenía que ser enviado a través de Sean para poder completarlo. Cuando
creamos el sistema kanban, imprimimos solo tres avatares por miembro del equipo para señalar
este punto de dolor.
Y, de hecho, la primera reunión de la mañana tomó aproximadamente 35 minutos, la mayoría de
ellos pasaron esperando a que Sean colocara los tres adhesivos ("¿Solo tres? ¿Puedo tener cinco
más? Por favor?") Con lo que debería trabajar durante el día.
Después de dejarlo sudar por un tiempo, tuvimos una discusión sobre los problemas que esta
situación causó al equipo y el flujo de elementos. Para gran sorpresa de Sean, resultó que cuando
estaba de vacaciones o estaba enfermo, el equipo todavía sacaba cosas por la puerta.
¿Quizás hubo elementos de trabajo en los que Sean no tuvo que involucrarse? ¿Quizás no tener a
Sean involucrado en todo podría aumentar la sensación de autonomía y dominio de otras personas
en el equipo? ¿Tal vez eso podría liberar el tiempo de Sean para hacer las cosas complejas que él,
de hecho, era el único en el equipo que sabía?
Todo terminó bien, pero al principio fue un poco impactante para el pobre Sean.
NADAR EN SU PROPIO CARRIL, POR FAVOR!

Otra forma común de limitar el WIP por persona es dar a cada persona un carril para nadar durante
el proceso. Luego puede decidir un límite de WIP para cada carril de natación, permitiendo
efectivamente una cierta cantidad de elementos en cualquier columna del tablero para ese carril de
natación.
Limitar WIP basado en personas 125
Este enfoque también se puede utilizar para limitar el trabajo por equipo en un tablero multiteam
(multi-quipo) o para teamlets (partes de un equipo).
ADVERTENCIA
Recuerde que estas estrategias se centran en asegurarse de que
cada persona tenga suficiente para hacer; no te ayudan mucho para
que el trabajo fluya a un estado final. Podría comenzar así, pero
vale la pena cuestionar la efectividad de este enfoque para limitar
WIP. Después de todo, sus clientes rara vez se preocupan si usted
DESAFÍOS se mantiene ocupado; solo quieren que entregues cosas.
ADELANTE
WIP por persona

* Prevenir la multitarea
* Obstaculizar el acaparamiento
* Visualizaciones comunes:
- Limite la cantidad de avatares para cada usuario
- Un carril de natación por persona, con límites de WIP
por carril.
Ahora le hemos dado muchos principios, ideas y consejos prácticos sobre cómo establecer su límite
de WIP. El punto principal es que esto es contextual y depende de sus necesidades y situación. A
menudo hay muchas preguntas sobre cómo establecer los límites de WIP, y abordaremos algunas de
las más comunes a continuación.
6.6 Preguntas frecuentes

No es extraño que los límites de WIP provoquen algunas preguntas, porque el límite que seleccione
es algo que depende de lo que necesita y su situación. A veces, cuando se describen los límites de
WIP, aparecen como algo definitivo; esto se suma a la confusión, porque los límites de WIP
deberían ser objetivos móviles.
6.6.1 Elementos de trabajo o tareas: ¿qué está limitando?

Muy a menudo, los equipos dividen los elementos de trabajo en tareas para ciertos pasos en su flujo
de trabajo. Para Development, podrían ser tareas como "implementar acceso a datos", "escribir
página HTML" y "lógica empresarial completa". En una columna Tests, podrían ser tareas como
"preparar datos de prueba", "escribir informe" y "realizar pruebas manuales". Las tareas son parte
de un elemento de trabajo y pueden considerarse como todas las cosas que debe hacer para
completar el elemento de trabajo en una columna determinada.
Hasta que no se complete cada tarea en Development, los elementos de trabajo no se
moverán al siguiente paso del flujo de trabajo. Algunos equipos incluso dividen las columnas en
subcolumnas, formando una mini tabla para las tareas.
Aquí puedes ver dos elementos de trabajo en curso (uno en cada fila), y cada elemento de
trabajo se ha dividido en varias tareas. El equipo cuenta el límite de WIP contra el elemento de
trabajo, no las tareas que componen el elemento de trabajo.
Elementos de trabajo Tareas para los

contados contra WIP elementos de trabajo no
contados contra WIP
La mayoría de los equipos parecen trabajar de esta manera, contando sus límites de WIP contra los
elementos de trabajo. Las tareas son solo para rastrear lo que necesita hacer para completar el
elemento de trabajo y, a menudo, no están entregando valor al cliente. Realmente no importa qué
tan rápido fluyan en todos los ámbitos, si los clientes todavía tienen que esperar a que se entreguen
cosas útiles.
Preguntas frecuentes 127
Puede haber ocasiones en las que, en ciertas columnas, es posible que desee limitar el número de
tareas. Por ejemplo, es posible que desee limitar el nivel de multitarea o asegurarse de que siempre
estás cooperando en ciertas tareas.
6.6.2 ¿Debería contar las colas contra el límite de WIP?

Las colas a menudo se visualizan como una columna
dentro de otra columna. Listo para prueba en la
columna Test es un ejemplo que hemos usado antes.
En la figura de la derecha, puede ver un límite de
WIP de 4 para la columna Development. La columna se
divide en dos secciones: Doing y Done. Los
desarrolladores están trabajando en un elemento y
tienen tres elementos completados, lo que los mantiene
en su límite de WIP.
Otra forma de visualizar esta cola podría ser tener
una columna de cola Ready to Test para probar en la
columna Test. Eso entonces contaría contra el límite de
WIP del paso de prueba.
La forma en que visualice esto en su equipo depende de lo que quieran lograr: es decir, sobre
quién debe "poseer" los boletos que esperan ser probados. ¿Ayuda al equipo si los desarrolladores
reciben la señal en su área, o es más útil para los probadores contar los elementos en la cola contra
su límite de WIP? La elección es algo que debe discutirse con el equipo, pero la función práctica de
la columna de la cola es la misma en ambos casos: los elementos atascados allí se detendrán y
dificultarán el flujo, y las personas no pueden incorporar nuevos trabajos en columnas antes de la
cola. Con esta configuración, pueden ver fácilmente qué elementos se realizan y en qué elementos
los desarrolladores todavía están trabajando.
Finalmente, si recuerdan, en la sección 6.4.1
mostramos otra forma de hacerlo, donde la
columna de la cola es una columna en sí
misma con su propio límite WIP, como se
muestra a la derecha. En este caso, la columna
tiene un límite de WIP propio, y no se cuenta
contra el límite de nadie. Quizás esta sea otra
técnica que pueda ayudar a su equipo. El
límite no "roba" la capacidad de "su" columna,
pero, una vez más, la función de la cola es la
misma.
Esa forma de visualizar la cola evita el cuello de botella en el que se ha convertido el
probador único. Se construye un búfer (la cola de pruebas) delante de él para asegurarse de que no
se inunde y, sin embargo, siempre tengan trabajo que hacer, que puede elegir del búfer frente a él.
Hay momentos en que una cola debe contarse contra el límite de WIP o incluso es el límite de WIP
en sí (como en la sección 6.4.1 con la columna de cola independiente, por ejemplo). En otras
ocasiones, la distinción hecha entre una cola y una columna de ejecución es una forma de visualizar
pasos detallados.
La respuesta a la pregunta de esta sección, "¿Deberíamos contar las colas contra el límite de
WIP?" es también, "depende". Por ejemplo, supongamos que han notado que las pruebas son un
cuello de botella.4 Una cola puede ser una excelente manera de garantizar que el probador siempre
tenga un trabajo listo para probar. Un límite de WIP en la cola lo ayuda a asegurarse de que la cola
no sea demasiado larga. Con un límite de WIP establecido, no podrán inundar la cola con trabajo sin
romper el límite de WIP. Cuando vea una cola llena hasta su límite de WIP, es hora de discutir cómo
eliminar el bloqueo que se está acumulando.
6.7 Ejercicio: ese WIP, ese WIP es realmente bueno

Ha llegado el momento de que empieces a discutir los límites de WIP. Nuevamente, esto debería ser
un esfuerzo de equipo. Recuerde que no hay un límite de WIP óptimo para su equipo; es una
herramienta que puede usar para ayudarlo a mejorar su trabajo.
Si no tiene un límite de WIP obvio que se le ocurra, primero analice los puntos en las
secciones 6.3, 6.4 y 6.5. Aquí hay algunas preguntas en las que puede concentrarse:
■ ¿Deberías tener un único límite de WIP para la tabla completa? ¿Por qué sería bueno para
ti?
■ ¿Puedes comenzar limitando el trabajo en algunas columnas? ¿Cuáles? ¿Por qué?
■ Si limitas el trabajo por persona, ¿qué tipo de comportamiento conduciría o le daría eso?
■ ¿Le ayudarían en su situación los carriles de natación con límites de WIP por carril?
Si no sabes cómo responder estas preguntas, debes intentar algo que parezca apropiado, prestar
atención a lo que sucede y aprender de eso. Cuando encuentres una buena estrategia y un número,
comience a discutir cómo debe tratarse esta política en su trabajo diario:
■ ¿Qué tipo de comportamiento fomenta por la forma en que estableció su límite?
■ ¿Qué debe hacer cuando termina en una situación en la que está rompiendo el límite de
WIP?
■ ¿Debería contar los elementos bloqueados/en cola contra el límite?
Como siempre, esfuércese por comenzar de manera simple y hacer que su enfoque sea más
avanzado cuando vea la necesidad.
6.8 Resumen
En este capítulo hablamos sobre encontrar y visualizar buenos límites de WIP:
■ No hay un límite de WIP correcto para usted y su equipo.
■ Limitar WIP no es el objetivo; es mejorar el flujo. Los límites de WIP son simplemente
una herramienta que ayuda a encontrar problemas que impiden un mejor flujo.
4
Descubrir y gestionar cuellos de botella merece un libro completo por sí solo. Pero brevemente, es posible que tenga
un cuello de botella si ve trabajo acumulado antes del cuello de botella y si los pasos posteriores al cuello de botella se
ven privados de trabajo.
Resumen 129
■ Un límite inferior de WIP moverá su trabajo más rápido y también le traerá problemas a su
atención más rápidamente. Desea un límite de WIP bajo, pero no demasiado bajo.
■ Al comenzar a buscar un límite de WIP, comience de manera simple, tal vez tan simple
como el eslogan "Deje de comenzar, comience a terminar".
■ Puede limitar la WIP para todo el equipo/flujo de trabajo:
■ Este enfoque puede ayudarlo a mejorar la colaboración.
■ Le ayuda a concentrarse en terminar los elementos de trabajo antes de asumir otros
nuevos.
■ Puede limitar WIP según la columna:
■ Esto pone el foco en elementos que fluyen a través del flujo de trabajo.
■ Puede ayudar a manejar los cuellos de botella.
■ Tal vez ya tenga un presentimiento sobre lo que necesita mejorar y pueda comenzar
a limitar WIP para esa columna.
■ El trabajo también puede estar limitado por el tamaño estimado (puntos de la
historia, por ejemplo).
■ Puede limitar el WIP en función de las personas:
■ Limitar el número de avatares que pueden estar en juego es una forma de lograrlo
fácilmente.
■ Usar carriles de natación es otra.
■ Esto puede ayudarlo a evitar demasiadas multitareas y que las personas se
involucren en cada elemento del tablero.
■ La mayoría de los equipos tienen un límite de WIP en el nivel del elemento de trabajo, no
en el nivel de la tarea.
Los límites de WIP son formas de mejorar el flujo de su workflow, pero ¿qué es eso? Es uno de los
conceptos principales de Lean del que aún no hemos hablado. Y es el tema del próximo capítulo.
7 Manejo de flujo
■ Qué es el flujo continuo y por qué lo quieres

■ Eliminar el desperdicio para lograr el flujo
■ Gestión del flujo con kanban
■ Uso de paradas diarias para ayudar al flujo de trabajo.
■ Elegir en qué trabajar a continuación
■ Gestión de cuellos de botella mediante la teoría de las
restricciones.
El flujo, o más bien el flujo continuo de una pieza, ha sido la piedra angular en la visión de
producción de Toyota1 durante décadas. Un flujo continuo de una pieza es un sistema en el que cada
parte del trabajo que crea valor para el cliente pasa de un paso de agregar valor en el proceso
directamente al siguiente, y así sucesivamente hasta que llega al cliente, sin ningún tiempo de
espera o procesamiento por lotes entre esos pasos. En lugar de crear inventarios por si acaso, las
cosas se producen solo cuando es necesario, justo a tiempo, en el lugar correcto y en la cantidad
correcta: ni más, ni menos.
1
Toyota es la compañía que fue pionera en el Sistema de Producción de Toyota (TPS), en el que se basa Lean.
130
131
... así que eso es lo que

debes hacer para obtener
un buen flujo ...
Si. O groove si le gusta a

la gente. Sugeriría
escuchar bandas como ...
Eeeh no fluye así ... Estaba

hablando de flujo en su
proceso donde las cosas
se hacen justo a tiempo y
solo se agrega valor.
Probablemente necesites
describirlo más, porque
en este momento estoy
pensando que
probablemente tampoco
esté compilando JIT.
Este flujo continuo convierte cada proceso en una cadena estrechamente vinculada en la que todo
está conectado. No hay ningún lugar para ocultar un problema, no hay inventario de otro trabajo o
productos para trabajar si algo se detiene o se rompe; así que cuando las cosas se rompen,
inmediatamente sabes lo que sucedió y se ven obligados a resolver el problema juntos. Obliga a las
personas a pensar, y a través de esto se convierten en mejores miembros del equipo y personas.
En este capítulo, analizaremos más de cerca los beneficios del enfoque de flujo para
organizar su trabajo. Aprenderá sobre la eliminación de desechos y el tiempo del ciclo, pero también
sobre cómo administrar realmente el flujo manteniendo el trabajo en movimiento y utilizando
modelos como la Teoría de las Restricciones para mejorar su proceso. Echaremos un vistazo a
algunas prácticas comunes que pueden ayudarlo a enfocarse y mejorar el flujo en su proceso, como
reducir el tiempo de espera, eliminar bloqueadores y usar equipos multifuncionales. Existen algunas
prácticas que utilizan muchos equipos que pueden ayudarlo a concentrarse aún más en el flujo,
como los standup (“paradas diarias”) y las políticas sobre qué trabajar a continuación; también los
revisaremos.
Pero comencemos por el principio y veamos por qué el flujo es algo por lo que vale la pena
esforzarse y centrar su atención.
132 CAPÍTULO 7 Manejo de flujo
7.1 ¿Por qué fluir?

¿Todavía
Toyota no es de ninguna manera la única, o
estás incluso la primera, empresa que persigue el
seguro de
que no
ideal del flujo continuo. Las personas y las
estás empresas han estado luchando por esta visión
hablando de
música? durante siglos. ¿Y por qué no lo harían? Si se
Tengo un logra un flujo continuo de una pieza, no tiene
sentimiento
funky. demoras, sin colas, sin lotes, sin inventario, sin
esperas. No tienes sobreproducción; solo
entregas lo que realmente solicitan y necesita el
cliente, y lo entregas de inmediato cuando es
necesario. Usted ha visto en capítulos anteriores que esto le brinda flexibilidad y capacidad de
respuesta, una mejor gestión de riesgos, una retroalimentación más rápida que conduce a una mejor
calidad (construyendo lo correcto y construyéndolo correctamente), una mayor previsibilidad que
conduce a una mayor confianza, menos solicitudes rápidas y entrega continua de valor más rápida.
Como si eso no fuera suficiente, el flujo también expone oportunidades de mejora y le
brinda una visión para sus esfuerzos de mejora: flujo más rápido.
Entonces, ¿qué puedes hacer para obtener un flujo más rápido? Veamos una estrategia que
ha ayudado a Toyota durante mucho tiempo: eliminar el desperdicio.
7.1.1 Eliminando desperdicios

Toyota ha pasado más tiempo perfeccionando y
Finalmente! Tomó
se ha acercado más a la visión del flujo continuo de
algo de tiempo,
una pieza que cualquier otra compañía. Una parte pero ahora
importante de ese viaje se ha centrado en eliminar el estamos hablando
desperdicio. del medio
ambiente.
Todo lo que estamos haciendo es mirar la ¡Hagamos algo al
línea de tiempo desde el momento en que el respecto!
cliente nos da una orden hasta el momento en

que recogemos el efectivo. Y estamos
reduciendo esa línea de tiempo al eliminar los
desechos sin valor agregado.
—Taiichi Ohno2
Otra forma de expresar esto es preguntar: "¿Qué impide que fluya el trabajo?" Aplicando esta
perspectiva, examina sus procesos desde el punto de vista del cliente. ¿Qué quiere el cliente de este
proceso? El cliente puede ser el cliente final o el cliente interno en la siguiente fase de producción.
Lo que el cliente quiere tiene valor. Todo lo demás es desperdicio. Algunos pasos en un proceso
agregan valor, otros no. Esto es cierto para todos los procesos.
2
Taiichi Ohno, Sistema de producción de Toyota: más allá de la producción a gran escala (Productivity Press, 1988,
http://amzn.com/0915299143), pág. ix.
¿Por qué fluir? 133
Al principio, Toyota identificó siete categorías de desechos que se aplicaban a la fabricación; y luego
la compañía aplicó el mismo pensamiento a otras áreas, como el desarrollo de productos. Desde entonces,
diferentes industrias han hecho categorías similares de desechos para sus contextos particulares. Mary y Tom
Poppendieck hicieron esto para el desarrollo de software a través de sus trabajos fundamentales Lean
Software Development: An Agile Toolkit (Addison-Wesley Professional, 2003) e Implementing Lean
Software Development: From Concept to Cash (Addison-Wesley Professional, 2006).
7.1.2 Los siete desechos del desarrollo de software

Echemos un vistazo más de cerca a los siete tipos diferentes de desechos que Mary y Tom Poppendieck han
identificado:
■ Trabajo parcialmente realizado: el trabajo que no se realiza por completo es en realidad
solo trabajo en proceso. Se encuentra esperando que lo completes y se agrega a tu WIP. Vea
el capítulo 5 para más información sobre esto.
■ Características adicionales: Taiichi Ohno dijo: "No hay mayor desperdicio que la
sobreproducción". Gran parte del software que se produce en el mundo no es realmente
utilizado o valorado por el cliente. Según el famoso informe CHAOS realizado por The
Standish Group a principios de la década de 2000, el 45% de las funciones de las
aplicaciones de software nunca se utilizaron. Esto sugiere que se podrían evitar muchos
desperdicios con una mejor comprensión de lo que el cliente necesita: es decir, construir lo
correcto. A nivel individual, si alguna vez pensó "Esto puede ser útil" o "Quizás quieran que
esto sea configurable", ya sabe lo que queremos decir.
■ Reaprendizaje: el desarrollo de software es, en gran medida, aprendizaje. No recordar los
errores que cometiste antes y tener que rehacerlos (y volver a aprender la solución) es un
gran desperdicio. Esto puede suceder tanto en equipos como para individuos.
■ Traspasos: cuando entrega el trabajo de una persona a otra, se crea mucho trabajo
adicional para transmitir la información necesaria a la siguiente persona. Incluso con ese
trabajo extra, se perderá mucha información en la transferencia.
■ Retrasos: los retrasos crean trabajo adicional, ¿recuerdas? ¿No? Vaya a leer la sección
5.2.2, "La demora causa trabajo extra", sin demora.
■ Cambio de tareas: hablamos anteriormente sobre el cambio de contexto (ver capítulo 5) y
el efecto derrochador que puede tener en su enfoque y capacidad.
■ Defectos: los defectos son un trabajo que vuelve a usted porque hizo algo mal la primera
vez. Esto no solo crea trabajo adicional, sino que, por lo general, ese tipo de trabajo llega en
un mal momento, ralentizando las cosas en las que está trabajando en este momento.
Consulte la sección 5.2.5, "Baja Calidad".
UNA PALABRA DEL ENTRENADOR Algunas personas en la comunidad

kanban piensan que ha habido una obsesión poco saludable con el desperdicio
dentro del desarrollo de software Lean y que el desperdicio es una pista falsa.
Según ellos, en su lugar, debería centrarse en reducir el tiempo de entrega y la
gestión de riesgos; los desechos serán identificados y eliminados como parte
de este proceso. No estamos seguros de ver el conflicto, pero, por supuesto
se debe evitar las obsesiones poco saludables y los enfoques basados en la fe
en general. Parte de la confusión se produce cuando las personas miran para ver si
ciertas acciones son inútiles.
Por ejemplo, ¿una reunión diaria para coordinar las actividades del equipo
agrega valor o es un desperdicio? Si es una actividad de valor agregado, ¿por qué no
haces más? ¿Por qué no simplemente reunirse todo el día? La respuesta es que la
actividad en sí misma no es un valor agregado o desperdicio; es el retorno del tiempo
invertido (ROTI) para ayudarlo a mejorar su comprensión y entregar valor al cliente, ya
que es él quien determina si es un desperdicio o no.
Fluir
* Flujo continuo de una pieza significa
- Sin esperas, retrasos, traspasos o sobreproducción
- Solo actividades de valor agregado
* Los desechos son algo que impide que el trabajo fluya
* Ejemplos de residuos:
- Trabajo realizado parcialmente, funciones
adicionales, reaprendizaje y traspasos
* No te obsesiones con eliminar desechos; en cambio
mira el ROTI
Eliminar el desperdicio y limitar la WIP son diferentes formas de lograr el flujo. Pero, ¿cómo aplica
estos principios en la práctica para ayudar a que el trabajo fluya?
7.2 Ayudando a que el trabajo fluya

Una de las prácticas centrales de kanban es administrar el flujo de trabajo a través de cada estado en
el flujo de trabajo. Esto significa monitorear y medir cómo fluye el trabajo, pero también mantener
el trabajo en movimiento. Puedes adoptar varios enfoques diferentes para ayudar a que el trabajo
fluya.
7.2.1 Limitar el trabajo en proceso

Limitar WIP es, por supuesto, una práctica esencial cuando se trata de mantener el trabajo en
movimiento. Cuantas menos cosas estén en proceso, más rápido fluirá el trabajo y más
oportunidades de mejora descubrirá. Quizás recuerde la ley de Little, que establece que cuanto más
WIP tenga, mayor será el tiempo de entrega de cada elemento. Puedes leer mucho más sobre esto en
el capítulo 5.
Ayudando a que el trabajo fluya 135
Flujo vs. utilización de recursos

Limitar su WIP le brinda un mejor flujo. ¿Pero es eso lo que quieres? La optimización para el flujo
es una decisión estratégica. Esa decisión es una compensación; Para lograr un mejor flujo, es
posible que termines con personas sentadas inactivas de vez en cuando. ¿Es eso aceptable para
obtener un mejor flujo a través de su proceso?
Hay tipos de trabajo y situaciones para las que sucede lo contrario: en su lugar, se esfuerza
por utilizar sus recursos de manera óptima. Un ejemplo es un molino para aluminio. Ese tipo de
equipo funciona a temperaturas extremas y tarda mucho tiempo en calentarse. Es costoso apagar el
molino. Desea que el horno de fusión funcione todo el tiempo, y desea tener una gran cantidad de
material listo para que el horno lo maneje (mucho WIP). Es posible que incluso desee que se
ejecute cuando ningún cliente esté esperando el aluminio. Estás optimizando para la utilización de
recursos.
En el otro caso, optimizando el flujo, un ejemplo es el departamento de bomberos. Tienen
mucha holgura (espera, preparación y entrenamiento) para estar listos para salir de inmediato y
apagar un incendio cuando sucede. Nosotros, como sociedad, aceptamos eso y estamos pagando a
los bomberos para que se sienten inactivos, porque no queremos que estén ocupados cuando
llamamos y les pedimos que apaguen un incendio. Para optimizar el flujo, aceptamos el hecho de
que no están ocupados todo el tiempo. Ese tipo de comportamiento generalmente se encuentra en
entornos de alto riesgo.
La optimización para el flujo sobre la utilización de los recursos es una decisión estratégica,
pero al enfocarse en la eficiencia del flujo, puede reducir una gran cantidad de trabajo superfluo y
desperdicio y, de hecho, también mejorar la eficiencia de los recursos. En el libro This Is Lean:
Resolviendo la Paradoja de la Eficiencia (Rheologica, 2012), los investigadores Niklas Modig y
Pär Åhlström definen Lean como una estrategia de operaciones que tiene como objetivo aumentar
la eficiencia de los recursos al centrarse en aumentar la eficiencia del flujo.
7.2.2 Reducción del tiempo de espera

¿Tiene elementos de trabajo sentados en las columnas Done del tablero, esperando que se los lleve
al siguiente estado? ¿Los elementos se encuentran en estados como Waiting to Deploy o Todo? No
es inusual ver que el trabajo pasa más tiempo esperando para ser trabajado que en el que realmente
se está trabajando. ¿Cómo se puede reducir este tiempo de espera?
Si aún no tiene una forma explícita de mostrar que el trabajo se realiza en un estado
particular y listo para el siguiente, este debería ser su primer paso. Esto hace que la espera sea
visible y les indica a los demás que el elemento de trabajo está listo para extraerse. También facilita
el seguimiento y la medición del tiempo de espera. Recopilar estos datos y analizarlos puede darle
una idea de lo que se puede mejorar. Si tiene dificultades para convencer a los demás de que se
pierde el tiempo en la espera, medirlo de esta manera puede servir de revelación.
¿Comienza el trabajo desde cero, o se inicia o se prepara en otro lugar (lo que generalmente
llamamos aguas arriba de la tabla kanban)? Tal vez el trabajo está sentado allí, esperando
que comiences. ¿Eres la última persona en tocar el trabajo antes de que llegue al cliente? Para
reducir el tiempo de espera, a menudo es necesario salir de su propio flujo de trabajo y de su

tablero kanban.
ASEGURAR QUE EL TRABAJO ESTÁ LISTO

Una excelente manera de evitar la espera es tomar medidas para asegurarse de que el trabajo
siempre esté listo para el próximo estado. Esto se puede hacer planificando y desglosando el trabajo
para minimizar las dependencias. Tal vez, tener personas o recursos externos preparados y listos
para que no te bloqueen, diseñando el trabajo para la colaboración. De modo que los miembros del
equipo que hayan terminado algo, puedan incorporarse fácilmente a lo que se está haciendo, en
lugar de esperar o realizar un nuevo trabajo.
Tener claro el resultado esperado y asegurarse de que se comunique claramente a todos antes
de que comience el trabajo, ayuda mucho a evitar malentendidos y confusión que resultan en
demoras y esperas.
Especificación por ejemplo

Una de las mejores maneras de asegurarse de que se entiendan es practicar la especificación con el
ejemplo.a Esto significa que escribe su especificación en forma de criterios de aceptación o
ejemplos concretos (números reales y datos reales utilizados) de cómo se utilizará una
característica. La función estará completa cuando se cumpla el ejemplo: nada más y nada menos.
a. Lea más en Especificación por ejemplo: Cómo los Equipos Exitosos Entregan el Software Adecuado, por Gojko
Adzic (Manning, 2011, www.manning.com/adzic/).
A veces tiene sentido aumentar la cantidad de WIP en una cola, particularmente frente a un
cuello de botella (ver sección 7.5.1), para evitar esperas innecesarias.
HACIENDO LOS ELEMENTOS DE TRABAJO MÁS PEQUEÑOS Y DE TAMAÑO SIMILAR

Otra forma de diseñar y preparar el trabajo para reducir la espera es hacer que los elementos de
trabajo sean más pequeños y de tamaño similar. Los elementos de trabajo más pequeños reducen los
tiempos de entrega y disminuyen la cantidad de WIP. Los elementos de trabajo grandes a menudo
son más difíciles de estimar y, a veces, ocultan problemas que serán visibles una vez que comience
a desglosarlos. En lugar de crear un caso de uso completo (como comprar libros, por ejemplo),
puede probar historias de usuarios (como poner un libro en la canasta, completar la información de
pago y realizar el pago).
Si puedes hacer que los elementos de trabajo sean más similares en tamaño, obtendrás un
flujo más uniforme y una mayor previsibilidad, lo que a su vez puede ayudarlo a generar confianza
y evitar la necesidad de agilizar las "solicitudes especiales". En la práctica, también elimina la parte
del costo de la ecuación porque todo el trabajo ahora es del mismo costo, al menos en cuanto al
tiempo.
Una forma excelente de reducir la espera es, por supuesto, limitar el WIP: cuanto más bajo
sea el WIP, más rápido podrán llevar los elementos de trabajo al siguiente estado. Muchas esperas
son causadas por el bloqueo, un tipo de espera que exige una sección propia.
7.2.3 Eliminar bloqueadores

Los bloqueadores pertenecen a una clase especial de espera. Son cosas que lo bloquean, pero que están fuera
de su control inmediato, como dependencias de terceros, esperando revisiones de código externos o
esperando información. En nuestra experiencia, los bloqueadores como estos a menudo se aceptan como el
orden natural de las cosas como algo "de lo que no podemos hacer nada", pero la mayoría de las veces
resulta ser cierto lo contrario.
Estoy bloqueado. Estoy esperando operaciones.
No hay nada que hacer en este momento.
¿Qué has hecho para resolver eso?
Bueno… les envié un correo

electrónico la semana pasada.
Nunca se bloquee: la directiva principal del desarrollo ágil

Robert C. Martin, también conocido como tío Bob, el tipo que convocó a la reunión que produjo el
Manifiesto Ágil, afirma que nunca ser bloqueado es la principal directiva para cualquier desarrollador ágil: a
Al igual que un buen jugador de billar que siempre se asegura de que el tiro que está tomando
establece el siguiente tiro que espera dar, cada paso que da un buen desarrollador ágil permite el
siguiente paso. Un buen desarrollador ágil nunca da un paso que detenga su progreso o el
progreso de los demás.
La idea principal es que todas las áreas que interactúan con otros sistemas deben manejarse de tal
manera que pueda continuar con su trabajo a pesar de que las otras partes no hayan terminado con el suyo.
Para la codificación, por ejemplo, esto podría significar crear una interfaz para codificar contra sistemas
externos. Si las otras partes no entregan a tiempo, siempre puede proporcionar su propia implementación,
un trozo o algo falso (fake, como se le llama), y continuar trabajando hasta que se complete la
implementación real.
Pero la directiva principal no es solo para el desarrollador individual:
La directiva principal se extiende a todos los niveles del equipo y la organización. Nunca estar
bloqueado significa que configura su entorno de desarrollo de modo que no ocurran bloqueos ... Si
el grupo central está construyendo un marco reutilizable para nosotros, y necesitamos alguna
función que aún no esté lista, la escribiremos nosotros mismos y usar la función del equipo central
más tarde, cuando (y si) llega. Si la arquitectura empresarial respalda nuestras necesidades de una
manera tan enrevesada y obtusa que tendremos que pasar días entendiendo, entonces evitaremos la
arquitectura empresarial y haremos que las característivas trabajen de una manera más simple. No
seremos bloqueados.
Para otros tipos de trabajo, puede asegurarse de hacer todo el trabajo posible para no terminar esperando a
otros.
a
. "La directiva principal del desarrollo ágil", http://mng.bz/NT5s.
Bueno, ese fue mi quinto Que haya presentado un boleto en

elemento bloqueado. En el
el sistema de soporte o que haya
siguiente. Mejor ocupado
que inactivo, supongo.
enviado un correo electrónico a
alguien no significa que haya hecho
lo posible para no ser bloqueado.
¿Podrías llamarlos, o tal vez
incluso acercarte y hablar con
Ahora espera un minuto.
ellos? ¿Explicó cómo esto lo está
Estás aumentando WIP. afectando y cómo ayudaría a su
¿Hay algo con lo que trabajo a avanzar si pudiera obtener
puedas ayudar a otros? asistencia? ¿Hay alguien más que
pueda resolver el problema por ti?
Tal vez hay una solución alternativa con la que puedes vivir por ahora. Intenta ser creativo y
encuentra una manera de no ser bloqueado.
Si ha intentado todo y aún se encuentra bloqueado, evite comenzar un nuevo trabajo.
Recoger un nuevo trabajo aumentará su WIP y dará como resultado una desaceleración de todo su
otro trabajo, como recordará en el capítulo 5. Quizás haya algo que pueda ayudar a terminar
mientras espera a que lo desbloqueen. ¿Hay cuellos de botella u otros problemas en su flujo de
trabajo que pueda ayudar a resolver? Más sobre esto en la sección 7.5.1.
Puedes guardar algunas tareas que son útiles cuando estás bloqueado. Algunos equipos
incluso crean clases especiales de servicios para esto (ver capítulo 8): es decir, un trabajo especial
que usted como equipo considera importante, pero que puede no ser inmediatamente importante
para otras partes interesadas. Podrían ser cosas como actualizar un servidor de compilación o
automatizar algunos trabajos manuales, cosas que mejorarán su calidad y velocidad futuras. Este
tipo de trabajo se puede recoger cuando se bloquea y se suelta rápidamente a medida que se borra el
bloqueador.
Un bloqueador también es una oportunidad para aprender cómo pueden mejorar su trabajo.
¿Qué causó el bloqueador? ¿Hay algo que podría haber hecho para prever y solucionarlo que pueda
aplicar a situaciones futuras? ¿Se pueden evitar por completo los bloqueadores si cambias tu forma
de trabajar? ¿O si alguien más cambia su forma de trabajar? Algunos equipos crean el hábito de
aplicar siempre el análisis de causa raíz a cada bloqueador o problema que detiene el flujo, para
aprender y mejorar la causa raíz del problema (lea más sobre el análisis de causa raíz en el capítulo
10).
EL SEGUIMIENTO DE LOS BLOQUEADORES

El seguimiento de los bloqueadores y cómo te afectan a menudo es un buen comienzo para
reducirlos. Si colocas las fechas de inicio y finalización en los bloqueadores, o pones un punto en
sus adhesivos por cada día que se sientan allí, puedes ver cuánto tiempo de ciclo total de un
elemento de trabajo se está bloqueando, tal como sugerimos con el tiempo de espera en la sección
anterior. Use estos datos para comprender cómo los bloqueadores lo afectan y qué puede hacer al
respecto. Los datos también pueden ser útiles para explicar a las personas que te bloquean cómo te
ayudaría si estuvieras desbloqueado.
El seguimiento de cómo varía el número de bloqueadores y cuál es el tiempo promedio para

eliminarlos también puede mejorar. Para obtener más información sobre los bloqueadores de
seguimiento, consulte la sección 11.1.3.
ENJAMBRE
Un comportamiento que surge en muchos equipos kanban es lo que se ha denominado enjambre. El

enfoque en limitar WIP y ayudar al flujo de trabajo lleva al equipo a actuar en conjunto cuando se
alcanza un límite de WIP, cuando surge un bloqueador difícil o cuando un elemento de trabajo es
demasiado grande, demasiado tarde o demasiado complejo para ser manejado por una solo persona
o algunos miembros del equipo. Las personas enjambran por el problema para resolverlo más
rápidamente3 y volver al flujo normal.
Algunos equipos hacen de esto una política explícita cuando se bloquean, o incluso cuando
encuentran un defecto. Cada vez que encuentran un bloqueador o un defecto, todos enjambran para
quitarlo. El enjambre también puede ser una política asignada a una clase específica de servicio (ver
capítulo 8).
El enjambre también se puede utilizar para describir el comportamiento general de trabajar
fuera de su especialización para ayudar a que el trabajo de alto riesgo o alto valor se realice más
rápido o para reducir la cantidad total de WIP, un comportamiento que muchos equipos kanban
tienen en alta estima.
3
Por supuesto, a veces más manos pueden ralentizarlo en lugar de ayudarlo. La clave aquí es que las personas están
disponibles para ayudarlo, como una situación de "todas las manos en la cubierta". Tal vez no necesite que todos
resuelvan el problema, pero para empezar, todos están allí para ayudar a analizar el problema y proponer una solución.
La implementación de la solución podría involucrar solo a unas pocas personas.
7.2.4 Evitar retrabajo

Daphne, que bueno que
pueda entenderte.
A veces, un defecto escapará de un estado del
¿Recuerdas esa flujo de trabajo, solo para encontrarlo en uno
característica en la que posterior. Esto hace que el elemento de
trabajamos el año pasado?
trabajo retroceda en el flujo de trabajo, lo que
aumenta el tiempo de ciclo tanto para ese
Apenas recuerdo lo que
escribí esta mañana. ¿Qué
elemento como para otros elementos de
hay de eso? trabajo, ya que aumenta la cantidad de WIP.
Evitar el reproceso puede tener un gran efecto
en el flujo y el tiempo del ciclo.
Bueno, el cálculo de
impuestos tiene un error No es coincidencia que uno de los
sutil que tiene que ver con principios clave del desarrollo de software
nuestro manejo de zona
horaria en algunos casos.
Lean4 sea generar calidad desde el principio.
Una buena manera de lograr esto es invertir
en prácticas técnicas como programación de pares, desarrollo basado en pruebas, integración
continua y automatización de pruebas.5
Otra práctica importante para mejorar la calidad es minimizar el tiempo entre la introducción
y la reparación de un defecto. Si el código se prueba tan pronto como se desarrolla, y los defectos se
corrigen inmediatamente después de que se encuentran, ahorrará tiempo registrando defectos y no
tendrá que pasar tanto tiempo para descubrir dónde se introdujeron. Por supuesto, esto es más fácil
cuanto menos trabajes al mismo tiempo y más pequeños sean: es decir, si la cantidad de WIP es
baja.
DEMANDA DE VALOR Y DEMANDA DE FALLA

Los defectos no son las únicas cosas que causan retrabajo. John Seddon ha introducido el concepto
de demanda de falla para describir "la demanda en un sistema causada por la falta de hacer algo o
hacer algo bien, para el cliente".
Algo me dice que tenemos una alta demanda de fallas y que las nuevas características no reciben tanta atención
4
Acuñado por Mary y Tom Poppendieck.
5
Más sobre esto en el excelente par de libros Clean Code: A Handbook of Agile Software Craftsmanship (Prentice
Hall, 2008, http://amzn.com/0132350882) y The Clean Coder: Un Código de Conducta para Programadores
Profesionales (Prentice Hall, 2011, http://amzn.com/0137081073) por Robert C. Martin.
Todas las solicitudes que ingresan a su flujo de trabajo que no son solicitudes de cosas nuevas, sino
solicitudes generadas porque algo no está funcionando como se esperaba, porque algo es demasiado
difícil de entender, porque falta algo, etc., caen en la categoría de demanda de falla. Ejemplos en el
desarrollo de software son el diseño defectuoso que no tiene en cuenta la experiencia del usuario,
los malos requisitos generados sin la participación o retroalimentación real del usuario, y el
reprocesamiento debido a la mala interpretación de las posiciones y la falta de comunicación.
No ganas mucho haciendo que la demanda de falla fluya más rápido; en su lugar, desea
eliminar la mayor demanda de fallas posible para dejar espacio para una mayor demanda de valor,
que es lo que está (¡con suerte!) aquí para producir. Descubrir lo que el cliente necesita y valora y
ofrecer solo eso también genera calidad.
Demanda de falla en el centro de llamadas

En el libro Freedom from Command and Control: A Better Way to Make the Work Work (Vanguard
Consulting Ltd., 2003, http://amzn.com/0954618300), John Seddon cuenta la historia de un centro
de llamadas para el cual aproximadamente el 40% de las llamadas fueron preguntas sobre facturas.
La imposibilidad de crear una factura clara y comprensible provocó una gran demanda en el
sistema que fácilmente podría evitarse. Y, efectivamente, cuando la compañía cambió el diseño y
la estructura de la factura, la demanda por falla disminuyó y el centro de llamadas recibió muchas
menos llamadas en total.
UNA PALABRA DEL ENTRENADOR Una práctica simple y útil es

comenzar a rastrear y visualizar la demanda de falla. Esto se puede
hacer colocando un pequeño punto rojo en cada adhesivo que
representa la demanda de falla cuando ingresa al tablero. Cuando sale
del tablero, puede hacer un análisis de causa raíz (consulte el capítulo
10) sobre cómo evitarlo en el futuro.
7.2.5 Equipos multifuncionales

Un equipo multifuncional es un equipo con diferentes especialidades funcionales o habilidades
multidisciplinarias. Cuando un equipo tiene todas las habilidades y recursos necesarios para cumplir
con las solicitudes que se le formulan, se dice que es verdaderamente multifuncional. Esto significa
que depende menos de las transferencias con otros equipos y es menos probable que esté esperando
a otros o que sea bloqueado. Si, por ejemplo, un propietario de un producto o un analista de
negocios está en el equipo, lo que se puede construir se puede decidir justo a tiempo en lugar de que
el trabajo no esté listo o el trabajo se acumule; Si el equipo es experto tanto en codificación como
en pruebas, el código no tendrá que ser entregado a otra persona para que lo pruebe.
El esfuerzo por hacer que los equipos funcionen de manera cruzada ayuda a reducir la
espera, hace que evitar y eliminar bloqueadores sea más fácil, y puede ayudar a evitar el reproceso.
También es probable que reduzca WIP. En otras palabras, es una excelente manera de hacer que el
trabajo fluya más rápido.
El mejor equipo multifuncional del mundo.

Cuando pensamos en equipos multifuncionales, uno en particular se destaca: ¡El equipo A! Este
tiene que ser el mejor equipo multifuncional jamás reunido. Tienen todas las habilidades para
cualquier trabajo:
■ El líder y el cerebro de cualquier operación: coronel John
"Hannibal" Smith
■ Sr. Apuesto: Teniente Templeton "Face" Peck
■ El músculo: Bosco "B.A." Baracus
■ Y finalmente, lo que todo buen equipo necesita: un piloto
de helicóptero loco, el Capitán "Howlin’ Mad" Murdock
Aunque todos son especialistas en sus propios campos, siempre
terminan trabajando juntos para resolver las tareas en cuestión. Me da pena el tonto con un flujo lento.
EQUIPOS DE CARACTERÍSTICAS VS. EQUIPOS DE COMPONENTES

Una forma común de organizar un equipo multifuncional es hacerlo responsable de una función.
Algunos se refieren a esto como un equipo de características. El equipo se responsabiliza de una
determinada característica de principio a fin. Para completar una función, el equipo puede necesitar
hacer un corte vertical del sistema completo, tocar todas las partes del sistema y, por lo tanto,
necesitar tener una combinación de competencias dentro del equipo para poder completar la
función.
Considere, por el contrario, un equipo de componentes que crea solo la capa de acceso a
datos o solo la capa de interfaz de usuario. Al estructurar equipos como este, corre el riesgo de que
los equipos se esperen entre sí para poder completar las funciones. Una característica completa
puede involucrar a varios equipos: el equipo de UI, el equipo de lógica de negocios y el equipo de la
capa de datos. Si alguno de ellos llega tarde, la función completa se retrasa. Se pierde información y
se produce una falta de comunicación en las transferencias entre equipos. Por lo tanto, es un mayor
riesgo para el calendario general y la calidad del resultado.
UNA PALABRA DEL ENTRENADOR Un mapa de organización de

proyecto gigante que Marcus miró brevemente tenía unas 250 personas
en capas en un gran mapa jerárquico de cinco niveles de profundidad.
Los equipos en el nivel más bajo se llamaron cosas como Integración,
Acceso a datos, UI Móbil, etc. A partir de esto, fue fácil concluir que el
proyecto (que ya se estaba ejecutando hasta el segundo año) se estableció de una manera
que nadie podía hacerlo hasta que todos los equipos hubieran terminado. El equipo más
lento dictaba la velocidad de todo el proyecto, solo en virtud de la organización del
proyecto.
Organizar sus equipos por características se adapta bien a un flujo kanban e incluso se puede
visualizar en una tabla común como carriles de natación separados.
Parada diaria 143
7.2.6 SLA u objetivo de tiempo de entrega

Algunos equipos descubren que sus acuerdos de nivel de servicio (SLA-“service-level
agreements”) les dan un objetivo claro hacia el cual luchar, y a otros equipos les gusta establecer un
objetivo ellos mismos, por ejemplo, el tiempo promedio de entrega (¿o por qué no un poco menos?)
su progreso en contra. Esto ayuda a fomentar una mentalidad de que el tiempo es esencial, para que
el trabajo fluya más rápido. También puede brindarle los beneficios del timeboxing.
La Caja-de-tiempo (Timeboxing) es una técnica simple que se utiliza en muchos métodos de
desarrollo de software ágiles para gestionar el riesgo y centrarse en hacer las cosas que más
importan primero. Estos métodos a menudo usan iteraciones de una duración establecida (por
ejemplo, dos semanas) para planificar y revisar el trabajo. Cuando el tamaño del equipo y el tiempo
asignado son fijos, el alcance debe ser flexible, y primero debe priorizar y construir las cosas más
importantes. Consulte el capítulo 9 para obtener más información sobre el uso de iteraciones con
kanban.
El uso de un timebox también te hace saber cuánto tiempo pasas en una tarea y te ayuda a
evitar el enchapado en oro: continuar trabajando en una tarea más allá del punto donde el esfuerzo
adicional vale el valor que agrega.
Ayudando a que el trabajo fluya

* Limite el trabajo en proceso
* Reduce el tiempo de espera
- Esfuércese por elementos de trabajo más pequeños
y de tamaño similar.
* Eliminar bloqueadores
- "Nunca ser bloqueado"
* Evitar retrabajo
* Use equipos multifuncionales
* Use los SLA o los tiempos objetivo para timebox
y priorice su trabajo
7.3 Parada diaria

Una manera de ayudar a que el trabajo fluya es hablar y hacer algo sobre los problemas que impiden
que el trabajo fluya, a diario o incluso con más frecuencia. La reunión parada diaria (también
conocida como reunión matutina, diaria, llamada matutina o standup) se hizo popular en la
comunidad de desarrollo de software en los primeros años ágiles con métodos como Scrum y XP.
Scrum tiene la parada diaria como una reunión central que se llama Daily Scrum. Creemos que una
reunión diaria de pie es una gran herramienta para poner al día a todos en el equipo con la situación
actual del equipo y el estado de su trabajo.
El hecho de que los métodos ágiles que mencionamos hicieron que esta práctica sea popular
no significa que solo cuando se usan esos métodos una parada diaria pueda ser útil.
Muchos equipos usan algún tipo de parada diaria incluso cuando no usan métodos ágiles. Es una de
esas prácticas que parece tener sentido para todos. Junto con la visualización de su flujo de trabajo
en un tablero, es probable que muchos equipos obtengan el efecto más inmediato cuando comienzan
a usarlo.
7.3.1 Buenas prácticas comunes en torno a paradas

Ejecutar una parada diaria no toma mucho; ejecutar una buena parada diaria es más fuerte. Pero en
una excelente parada, puede ayudar al trabajo a fluir más suavemente y manejar cosas como
bloqueadores y otros problemas que dificultan el flujo. Hay algunos consejos generales sobre cómo
tener éxito con las paradas, y en esta sección veremos algunos de ellos.
UN STANDUP ES CORTO
Te lo digo, mis pies me
están matando. Estos
Mantenga la reunión corta; 5-15 minutos parece
zapatos no están hechos ser la norma. Una breve reunión de tiempo lo
para permanecer en pie empuja a hablar sobre lo que es importante y lo
durante 45 minutos.
hace pensar sobre lo que se puede discutir en
otro lugar. El límite de tiempo exacto no es lo
importante; manteniendo la reunión enfocada y
¡Lo sé! Estoy empezando a
pensar que lo estamos la energía aumenta.
haciendo mal. Por cierto, La "parada" en las reuniones de parada es así
¿por qué no usas Crocs
como el resto de
por este motivo. Se pone de pie para mantener
nosotros? la reunión breve y activa en lugar de otro
informe de estado en la sala de conferencias.
Párese al lado de su flujo de trabajo visualizado (su tablero) para poder ver y hablar sobre sus
elementos (más sobre esto más adelante).
UN PARADA COMIENZA (Y TERMINA) A TIEMPO ¡Allí! Adam está

aquí. Podemos
Mantener la reunión breve también significa que debe comenzar ... ¿Por
comenzar a tiempo. Hay todo tipo de formas para tratar de qué te vas Daphne?
6
que las personas lleguen a tiempo, pero para la mayoría
de los equipos esto no parece ser un problema, siempre y
Llevamos 15 minutos
cuando las cosas que se discuten en la reunión sean esperando. La
importantes y atractivas. parada se acabó.
La manera de hacer que la reunión comience a tiempo

probablemente variará en las diferentes organizaciones.
Para algunos equipos, solo decidir un horario es todo lo que se necesita; pero otros pueden
6
Incluyendo multas, personas que permanecen en silencio para esperar a los recién llegados, y otras cosas que se
sienten bastante incómodas cuando lo piensas. Probablemente estamos tratando con adultos; ¿por qué no hablar sobre
los pros y los contras de llegar a tiempo y elegir un horario que se adapte a todos?
Parada diaria 145
Por última vez…

necesitar una reserva en el sistema de no nombramos nuestras
calendario para asegurarse de que el intervalo variables después de las
de tiempo no se tome para otras reuniones. mascotas.

Hemos pasado por esto un
millón de veces.
UNA PARADA SE ENFOCA
Asegúrese de hablar sobre cosas que son
Pero... para mí eso tiene
importantes para el equipo que asiste a la mucho sentido.
reunión. Si una discusión comienza a Una variable de bucle es
arrastrarse y solo involucra a dos personas, John, mi hámster.

En su rueda. ¿Consíguelo?
solicite amablemente que continúen después
de la parada diaria.
No tiene sentido hacer que una persona esté Hola, chicos, ¿creen que
pueden aclarar eso
parada esperando que otros hablen sobre cosas después de la parada?
que no son interesantes. Asegúrese de que su Nos estamos aburriendo
valioso tiempo juntos esté bien invertido para por aquí ...
todos los que asistan a la reunión.
UNA PARADA ES REGULAR

¿Cuándo es la
parada?
Realiza la parada a la misma hora y en el mismo
lugar todos los días. Esto crea un ritmo para el día y
A ver ... es el pronto será una segunda naturaleza para el equipo.
segundo viernes Muchos equipos comienzan sus días con una
del mes, pero es
una fecha
parada diaria (a menudo se lo conoce como una
extraña ... Creo reunión de la mañana) porque les da un buen
que es en 1320. O
podría ser 1015.
comienzo al día, pero eso no es obligatorio. Ejecute
la parada en un momento que se considere
OK gracias. ¿Pero apropiado para todos los miembros del equipo.
dónde está Creemos que comenzar el día reuniéndonos y
entonces?
comprobar lo que pasa es genial, pero es posible
que no estén de acuerdo. Pregúntale al equipo.
Parada diaria
* Registro diario para el equipo
* Corto
* Comienza y termina a tiempo
* Centrado
* Regular
7.3.2 Kanban practica alrededor de la parada diaria

A medida que los equipos de kanban han comenzado a practicar paradas, han surgido algunas
prácticas o ideas que difieren de cómo se han hecho tradicionalmente las paradas.
ENFOQUE EN LA BATUTA, NO LOS CORREDORES

Lo primero que a menudo diferencia una parada diaria en un equipo kanban de otras reuniones
paradas es que un equipo kanban tiende a centrarse en el trabajo en el tablero en lugar de en las
personas individuales del equipo.
Esto puede contrastarse con enfocarse en cada persona del equipo, como en la práctica de Scrum de
dejar que cada persona responda "las tres preguntas":
■ ¿Qué hiciste ayer?
■ ¿Qué vas a hacer hoy?
■ ¿Tienes algún impedimento que te impida hacer eso?
Están despierto, Esta es una buena práctica que hace que todos hablen
Eric Las tres preguntas.
en la reunión, y obtienen una excelente visión general
del estado de cada persona en el equipo. Pero pueden
Veamos ... ayer no hice
perder la oportunidad de hablar sobre el trabajo en
mucho. Hoy se desperdicia
principalmente en
cuestión. Tal vez hay un elemento que está bloqueado,
reuniones. Sin y podría valer la pena pasar toda la reunión hablando
impedimentos. Próximo. sobre cómo limpiarlo. O tal vez nada está bloqueado
y el trabajo fluye como se esperaba; entonces puede
cerrar la reunión temprano y no arrastrarla más de lo necesario.
Finalmente y quizás lo más importante, el enfoque no está en lo que las personas
individuales han hecho o no han hecho, sino más bien en si hay algún problema en el flujo, en su
proceso o con elementos de trabajo individuales. Le ayuda a comprender que usted es un equipo
cuyos miembros se ayudan mutuamente a realizar el trabajo juntos.
CAMINAR EL TABLERO
Los equipos Kanban a menudo enumeran su trabajo de derecha a izquierda, comenzando desde la
columna Done y avanzando aguas arriba. Esto es para enfatizar el principio de arrastre: están
llevando el trabajo hacia usted, incorporando características a la producción, no llevando el trabajo
al siguiente estado.
Caminar la Tabla
Parada diaria 147
Nos aseguramos de honrar las buenas prácticas en torno a las reuniones de parada y, por lo tanto,
mantenemos nuestra timebox de 15 minutos, por ejemplo. Esto significa que es posible que no
podamos recorrer todos los elementos de trabajo en el tablero. Al enumerar el trabajo en el tablero
de derecha a izquierda, esto significa que podríamos no tener tiempo para hablar sobre la extrema
izquierda. Esto podría estar bien porque ese trabajo también es lo más alejado de hacer.
Para aumentar aún más el enfoque en avanzar el trabajo hacia Done, puede hacer dos
preguntas para cada elemento de trabajo:
1 ¿Qué debemos hacer para mover el elemento de trabajo más cerca de Done?
2 ¿Quién lo va a hacer?
Si terminas perdiendo parte del tablero a menudo (las columnas más a la izquierda cuando trabajas
de derecha a izquierda, por ejemplo), debido al timebox, puedes buscar otra estrategia, como
enfocarte en cosas que no siguen tus políticas, o cosas que huelen, por ejemplo.
ENFOQUE EN OLORES
Muchas de las visualizaciones de las que hemos hablado en el libro lo ayudan a ver cuándo el
trabajo no se comporta como se esperaba, está bloqueado o rompe algunas de sus políticas. Estos
indicadores y visualizaciones pueden ayudarlo a ver los elementos de trabajo que no siguen sus
políticas — los olores (consulte la barra lateral "Procesar olores" en el capítulo 4) — en el tablero.
Aquí está el tablero de Kanbaneros en una parada diaria. Tiene muchas cosas que no siguen
las políticas visuales y explícitas para el equipo. ¿Puedes verlos a todos?
Estas son las cosas que el equipo vio y habló en su parada diaria:
■ Tenemos dos elementos en el carril Urgente. ¿No decía nuestra política que solo podría
haber uno allí? ¿Qué debemos hacer con respecto al segundo elemento? ¿Ese elemento
urgente tiene toda nuestra atención?
■ En la columna Done, Eric todavía está trabajando en el trabajo que se ha completado. A

menos que él todavía esté trabajando en un universo paralelo, probablemente necesitemos
hablar de eso. ¿Ya está hecho ese trabajo? Si no, ¿qué tipo de trabajo se está llevando a cabo,
y se debe mover el adhesivo? Tal vez nos falta una columna como Deploying.
■ En la columna Test, hemos excedido nuestro límite WIP de dos, porque tenemos tres
elementos en la columna. Eso podría estar bien, pero en este caso el equipo no se dio cuenta
de que sucedió. Romper el límite de WIP debería al menos desencadenar una discusión:
¿Podría Adam ayudar en otro lugar en lugar de sacar un nuevo trabajo? ¿Estamos listos para
pagar el peaje de un WIP más alto? ¿Esto sucede a menudo? ¿Necesitamos cambiar la forma
en que trabajamos o tal vez cambiar el límite?
■ En la columna Test, hay un trabajo que ha estado esperando durante mucho tiempo en el
que nadie está trabajando. Esto se indica con puntos, uno para cada día en la columna Test.
¿Por qué Adam prueba otras cosas? ¿Hay un bloqueador que deberíamos escalar?
■ Eche un vistazo a todo ese trabajo que está listo para la prueba, en la columna
Development/Done. Se está acumulando un cuello de botella antes de Test. Tal vez sea mejor
que los desarrolladores dejen de trabajar para poner más cosas en esa cola y empiecen a
ayudar a Adam a probar. Crear una gran pila de trabajo no probado no hace que el trabajo no
probado sea más completo.
■ Daphne está acaparando muchos elementos en la columna Development. Eso esta bien?
¿Por qué está haciendo eso? será eso un problema? ¿Ella necesita ayuda?
■ En la columna Analyze, hay algún tipo de indicador importante en el único elemento de
trabajo en el que nadie está trabajando. ¿Por qué? ¿Es ese elemento importante, entonces?
¿Quién comenzará a investigar eso? ¿Qué pasa con el otro trabajo en esa columna?
Probablemente también hayas encontrado más (hemos dejado algunos para que descubras), pero
esperamos haber demostrado que al centrarse en las cosas que se desvían de su flujo normal, puedes
pasar el tiempo de parada diaria en los elementos de trabajo que necesitan su atención. El uso de
visualizaciones y políticas explícitas le ayuda a encontrar estas cosas con bastante facilidad.
7.3.3 Aproveche al máximo su parada
Aquí hay algunas otras cosas que vale la pena considerar si desea aprovechar al máximo una parada
diaria.
PREGUNTA DE CONCIENCIA
"¿Hay algo en lo que estén
trabajando que no esté en el
tablero?" Esta es una gran pregunta
para hacerse durante una reunión de
parada. Es bastante fácil tener un
"pequeño trabajo al margen" que
necesitan hacer. Esto no solo toma
tiempo de lo que se suponía que
debían hacer, sino que también
Ok, eso es todo entonces. No... no es que se me ocurra. El tablero se ve
tiende a convertirse en un hábito, lo
No pasa nada más, ¿verdad? bonito y ordenado...
Parada diaria 149
que a la larga significa que el tablero se vuelve menos relevante. En poco tiempo, podrías terminar
con personas que tienen retrasos privados y tal vez incluso un tablero privado con sus tareas
paralelas. Trate de hacer que el tablero refleje la realidad lo más lejos posible.
TRABAJANDO EN LO INCORRECTO
“¿Estamos trabajando en las cosas más importantes en este momento? ¿Cómo lo sabemos? ¿Está
clara la priorización? A menudo escuchamos que los equipos trabajan duro en elementos que
podrían no ser las cosas que están dando el mayor valor en este momento. Esto, por supuesto, tiene
que equilibrarse con el trabajo a largo plazo, como pagar la deuda técnica. Una forma de manejar
esto es con diferentes clases de servicio (ver capítulo 8).
Si comienza a escuchar a las personas decir que no saben qué hacer a continuación o sienten
que están trabajando en las cosas incorrectas, es posible que deba revisar las políticas en torno a su
priorización. Esto podría ser un desencadenante para hacerlos más explícitos; ¿Se pueden visualizar
las políticas de priorización o pueden ser más claras?
NO ENTENDER EL TRABAJO
A medida que el tablero evoluciona, se agregan muchas políticas y mejoras al tablero con las
mejores intenciones. Pero después de un tiempo, estas políticas pueden ser difíciles de entender y
ver, incluso para las personas del equipo. Para los extraños, las reglas a las que se adhiere el trabajo
pueden ser difíciles de seguir.
Intente siempre encontrar formas más simples de describir su trabajo. Recuerde que su
visualización también puede informar a otras personas a su alrededor que podrían pasar por su
tablero. ¿Un extraño entendería cómo funciona esto? ¿Usted si?
KAIZEN ESPONTÁNEO
Ok muchachos, Murmurmur?
eso es un envoltorio.
¡Vamonos!
Y si ...? ¡Bla bla bla!

Cómo podría ...?
Hagamos ...!
Centrarse en olores, desviaciones y problemas en el tablero no es útil si no intentan hacer algo al

respecto, por supuesto. Cuando finaliza la parada diaria, a veces verán a algunas personas quedarse
en el tablero, formando grupos y comenzando a hablar sobre el trabajo que mencionaron durante la
reunión. Algunos lo han llamado kaizen espontáneo, como en reuniones de mejora espontánea. El
equipo está comenzando a discutir y mejorar su trabajo.
Se debe alentar este tipo de comportamiento, y puede desencadenar discusiones y
conversaciones como esta posponiendo las discusiones bajo la parada hasta después.
Cuando un par de personas comienzan a salir por la tangente durante la parada, podría, por ejemplo,
decir:
■ "¿Podemos encontrarnos justo después de esta reunión y hablar más?" (Consulte la barra
lateral "Preguntas adhesivas" para ver un ejemplo).
■ "Busquemos una solución para ese elemento de trabajo justo después de esta reunión. Lo
haremos aquí en el tablero".
■ "¿Podrían encontrar una mejor manera de resolver ese problema después de la reunión?"
Ofrezca ayuda y aliéntelos a involucrar a las personas necesarias para aclarar el problema o mejorar
la situación si así lo desean.
Preguntas adhesivas
En Spotify en Nueva York, a un equipo se le ocurrió una excelente manera de visualizar que se debería
hablar más sobre una pregunta después de la parada. El tema se escribió en una pequeña nota adhesiva y se
pegó a la persona que quería hablar al respecto. Ella mantuvo el adhesivo sobre ella hasta que se sostuvo la
discusión, que generalmente tenía lugar directamente después de la reunión.
Otra forma más formalizada de crear un enfoque de mejora constante es usar el Kanban Kata 7 (ver
capítulo 10) en las paradas. Al usar el kata, obtienes ayuda sobre cómo abordar el trabajo de mejora
y una guía que te ayuda a hacer las preguntas correctas.
Cuando el equipo ha adoptado políticas y formas de trabajo y las ha hecho suyas, a menudo
encontrará que las paradas diarias no tienen muchos olores como los descritos en esta sección. Las
paradas diarias pueden pasar bastante rápido, o su enfoque puede cambiar a una mentalidad de
mejora, que puede ver en la sección 10.3.
Prácticas Kanban: parada diaria

* Centrarse en el trabajo en lugar de los trabajadores
* Camina el tablero, de derecha a izquierda
* Centrarse en olores y desviaciones
* "¿Todo tu trabajo está en el tablero?"
* "¿Trabajamos en las cosas correctas?"
* "¿Entendemos nuestro trabajo?"
* Fomentar reuniones espontáneas de Kaizen después de la parada diaria
7
Kanban Kata es una forma de aplicar pasos formales en torno al trabajo de mejora para ayudarlo a realizar pequeños
experimentos que lo guíen hacia un futuro mejor.
Parada diaria 151
7.3.4 Escalado de paradas
La parada diaria es, como escribimos al comienzo de esta sección, una práctica fácil, a menudo muy
apreciada y gratificante. Esta es la razón por la que muchos equipos adquieren esta práctica, a pesar
de que no estén haciendo XP, Scrum o cualquier método nombrado en absoluto.
Una pregunta que hemos encontrado más de una vez es cómo escalar las paradas diarias. Es
decir, “Tenemos más de un equipo trabajando juntos en el mismo producto o proyecto, y también
necesitamos una forma de coordinar el grupo de equipos. ¿Cómo han usado otros equipos kanban
para hacer eso?
¿POR QUÉ?
Es mucho más difícil mantener una gran reunión con muchos participantes cortos, enfocados y
llenos de energía, especialmente si sucede a diario. Es por eso que la primera pregunta que debe
hacerse es: "¿Por qué queremos hacer un parada diario multiteam?" ¿Cuál es la razón para tener
estas reuniones? ¿Qué tipo de problemas resuelves con estas reuniones? ¿De qué no deberías hablar
en estas reuniones?
Gran Diaria ➝ Sincronización Diaria ➝ Sincronización de Lanzamiento

En un cliente, Marcus fue traído mientras dividieron un gran equipo (unas 40 personas) en cinco
equipos más pequeños. El gran equipo se había reunido todas las mañanas y, por lo tanto, era
natural encontrarse no solo en los equipos más pequeños sino también en un "Big Daily" con todos
los equipos. Todos los equipos tenían un carril en el tablero más grande con copias de sus
elementos de trabajo en curso, a menudo en una forma más gruesa que en su propio tablero.
(continuado)
Muy pronto se dieron cuenta de que ya habían hablado sobre el estado en los equipos más
pequeños, por lo que fue extraño recapitular eso en el Big Daily. Mantener sincronizados el tablero
grande y los estados de los tableros del equipo local se convirtió en una molestia. Por lo tanto,
decidieron ajustar el Big Daily en Daily Sync, en el que solo hablaban sobre cosas que debían
sincronizarse en más de un equipo. También eliminaron los carriles de natación para los equipos y
solo les pidieron que informaran oralmente sobre lo que estaban haciendo.
Después de algunas semanas de hacer eso, se dieron cuenta de que en su mayoría hablaban sobre la
implementación y el lanzamiento, y la reunión se convirtió en Release Sync con un solo enfoque:
"¿Qué lanzamos hoy?" Crearon un tablero simple con solo una cola de lanzamiento a la que cada
equipo traía sus elementos para ser lanzados, y de eso hablaron. La mayoría de los días esa reunión
terminó en unos dos o tres minutos.
Siempre terminamos la reunión con la pregunta: "¿Algo más que todos los equipos necesiten
saber?" dejar espacio para otra información. La mayoría de las veces no había nada que informar a
todos, pero cuando era necesario compartir información con todos, esta reunión era una buena
oportunidad para hacerlo.
CONSEJOS PARA HACER PARADAS MULTIEQUIPOS

Aquí hay algunas cosas a tener en cuenta cuando creas un parada diaria para más de un equipo
(digamos que es gran diaria por falta de un término mejor):
■ ¿Se debe ejecutar la gran diaria antes o después de las paradas del equipo? Si ejecutan la
gran diaria antes de las diarias del equipo, puede enviar información a los equipos, pero
puede perderse el último estado de los equipos. Ejecutarlo después te da el estado de los
equipos, pero pierdes la oportunidad de enviar información a las paradas diarias del equipo.
■ ¿Quién asiste a la gran reunión diaria? Probablemente desee al menos una persona de cada
equipo en su grupo para que la reunión sea interesante. Esa persona necesita poder tomar
decisiones si es necesario (por ejemplo, si se debe agregar algún trabajo adicional al trabajo
atrasado del equipo). Sugerimos que permita que cualquier persona interesada asista a la
reunión, pero que requiera al menos una persona de cada equipo.
■ ¿Qué tipo de visualización debería tener esta reunión para respaldar sus decisiones? ¿Vas a
tener una tabla para tu gran diaria? ¿Qué tipo de información quieres mostrar allí? ¿Qué tipo
de preguntas, estados y progreso desea mostrar en el tablero? ¿Para quién estás creando el
tablero?
■ ¿Estás mostrando el estado de cada equipo en el gran tablero diario también? Si tienes un
tablero para todos los equipos, ¿cómo comunicas el estado de cada equipo? Tenga cuidado
de poner demasiados detalles en el tablero grande, porque eso significa duplicar la
información y que los equipos deben mantener su trabajo sincronizado en dos tablas. Un
estatus agregado es probablemente mejor.
Como puedes ver, hay muchas cosas a considerar cuando organizan una gran reunión diaria. Pero si
comienzan a pensar en lo que ustedes, como grupo, quieres sacar de esta reunión, a menudo pueden
Parada diaria 153
comenzar a reducirla y enfocarse en esas preguntas. Una gran parada diaria puede ser un gran
impulso y una oportunidad para compartir información, pero debe equilibrarla cuidadosamente, o
podría encontrarse con algunos de los problemas de los que hemos hablado en esta sección.
¿DE ABAJO HACIA ARRIBA O DE ARRIBA HACIA ABAJO?

El enfoque que acabamos de describir es adecuado cuando tienes equipos que sienten la necesidad
de sincronizar su trabajo con un tablero agregado. Pero lo contrario también puede ser cierto: es
posible que tengan un gran equipo que se divida en equipos más pequeños (o teamlets, como
algunas empresas los llaman) que necesitan sincronizar su trabajo.
Puede usar un tablero grueso-granulado, sin los detalles, y enfocarse en el bastón/trabajo,
utilizando todas las buenas prácticas que hemos descrito en torno a la parada diaria. Si hay equipos
pequeños dentro del equipo que necesitan intercambiar información detallada y coordinarse después
de eso, pueden tener sus propios tableros y/o paradas donde se concentran en una parte más
pequeña del flujo de trabajo y sus tareas más pequeñas.
Un buen tablero kanban y las prácticas descritas aquí hacen posible escalar un kanban
diariamente más allá de un pequeño equipo. Y llevar las prácticas un poco más allá (tablero grueso-
granulado, etc.) hace que escale algo más.
Si logras que todos se reúnan a menudo, también fomentas la colaboración que se necesita
en un grupo más grande. Sabes quién trabaja en qué, con quién hablar, quién te está esperando, etc.
Esto aumenta la probabilidad de resolver bloqueadores, minimizar el tiempo de espera y compartir
información valiosa, porque todos participan en el mismo flujo de trabajo.
Al igual que con casi todas las prácticas, preguntarse constantemente si esta reunión está
proporcionando valor, por el tiempo que invierte en ella, es una forma de asegurarse de no caer en
esas trampas. Si no, encuentre otras formas de mantener a todos sincronizados entre los equipos;
Las grandes visualizaciones de equipo pueden ser de una manera, las demostraciones frecuentes
pueden ser de otra. Haga que la herramienta funcione para usted, no al revés.
Escalar paradas
* Un standup periódico para más de un equipo.
* Comience con ¿POR QUÉ?
- ¿Qué quieres sacar de esta reunión?

- Comparta información de equipo a equipo, no solo
informe el estado nuevamente
* Considere tener una tabla para la gran diaria también

Dejemos la reunión diaria de pie por ahora y, en cambio, nos centremos en una pregunta que a
menudo surge en la reunión: "¿Qué debo hacer ahora?" Varias de las prácticas kanban que hemos
descrito hasta ahora pueden ayudarlo a usted y a su equipo a responder esa pregunta. Vamos a
sumergirnos y ver cómo.
7.4 ¿Qué debo hacer a continuación?

¡Buen trabajo, Adam! El elemento Si deseas un flujo de trabajo rápido y
de trabajo #182 ahora será
sin problemas, no deseas ser bloqueado
probado. ¿Qué harás ahora?
por no saber qué hacer a continuación.
Una pregunta común que surge con
Bien ... veamos ... hay tres
elementos. El primero es un poco
frecuencia en todo el tablero es qué
grande ... el segundo da miedo, y el debería hacer alguien a continuación.
último es aburrido. ¿Algo más en el Es una pregunta justa, por supuesto,
tablero? Hmm, no. No lo sé ... pero también es algo que ustedes como
simplemente no lo sé.
equipo quieren poder contestar. No
desean que su flujo se ralentice al tener
que esperar a que alguien más le diga qué hacer a continuación.
Muchas de las técnicas de visualización y nuestra discusión de políticas explícitas en este libro
intentan llevarlo a ser cada vez más autoorganizado, para lograr un flujo más fluido en el proceso:
por ejemplo, ordenar las columnas para priorizar, usar clases de servicio con diferentes colores,
usando indicadores bloqueados o urgentes, agregando carriles de natación para el trabajo que se
acelerará y con límites de WIP. Todas estas pequeñas cosas te ayudan a responder la pregunta "¿Qué
debo hacer a continuación?"
Veamos un ejemplo concreto de estas prácticas en el trabajo. Aquí hay una situación en la
que Adam, el probador, se encontró hace un par de días:
Para que el trabajo siga fluyendo, ¿cuál es una buena opción para que Adam haga ahora?
¿Qué debería hacer a continuación? 155
Primero debe verificar si hay algún trabajo en curso en la columna Test (su columna) en este
momento. Para lograr un mejor flujo, esto siempre debe estar en su mente: "¿Puedo ayudar a
terminar el trabajo en progreso?" Quizás recuerdes el lema de Kanbaneros: "Deja de empezar,
comienza a terminar". Aquí hay una situación en la que esto se pone en práctica.
Adam puede practicar esta oportunidad de inmediato porque Beth está probando otro elemento. Él
la ayuda a terminar ese elemento y, por lo tanto, limpia la columna Test. Bien por ellos.
¿Ahora que? No hay más trabajo en la columna Test, pero hay dos elementos apilados en la cola
Development/Done. ¿Qué deberían hacer Adán (y Beth) ahora? Podrían llevar ambos elementos a
Test. Hay espacio para eso, de acuerdo con el límite de WIP, por lo que parece una buena idea. O tal
vez quieran tomar primero el elemento de mayor prioridad (en la parte superior de la columna
Development/Done) y trabajar juntos para mantener la WIP baja y terminar más rápido. El elemento
que persiguen depende del equipo y de las políticas que el equipo tiene sobre cómo funcionan. En
este caso, Beth y Adam toman cada uno un elemento y lo terminan.
Luego, considere la situación que ocurre un par de días después. Adam es ahora el único probador, 8
y se encuentra en una situación en la que no hay otro trabajo en su columna. No solo eso, no hay
trabajo nuevo para jalar y comenzar a trabajar. ¿Qué debería hacer Adam ahora?
El primer reflejo instintivo podría ser sugerir que él ayude a uno de los desarrolladores. Eso
garantizaría que sus elementos se completen y se muevan a la columna Development/Done, desde
donde Adam podría recogerlos y comenzar a probarlos. Lamentablemente, Adam carece totalmente
de las habilidades de desarrollo necesarias para este elemento de trabajo en particular, por lo que no
sería útil escribiendo código.9 No todas las personas pueden hacer todas las tareas, sin importar
cuánto queramos que sea así.
Entonces, ¿qué debe hacer Adán? Si
observas las columnas anteriores en el tablero,
puedes ver una pequeña situación que comienza
a acumularse en forma de un paso que está
hambriento de trabajo (un cuello de botella, si lo
desea). Está en Analize; ¿Puedes verlo?
Tanto Frank como Beth están trabajando en
un elemento cada uno, pero nada está terminado.
No solo eso, sino que a medida que los
desarrolladores terminen su trabajo, no tendrán
ningún trabajo nuevo que extraer porque la cola
Analize/Done está vacía. Este es un cuello de
botella que necesita su atención. Quizás Adam
pueda ayudar por ahí. De hecho, la opinión de
un probador puede ser valiosa para analizar las
características. ¡Se está acumulando un cuello de botella!
Digamos, en aras de la discusión, que Adam no pudo (o no se le permitió) ayudar con el

análisis. Tal vez esos elementos de trabajo no eran adecuados para compartir. ¿Qué debería haber
hecho entonces? Debería resistir el impulso de sacar un nuevo trabajo que aumente la WIP y, en su
lugar, tratar de encontrar otro trabajo interesante, algo que se pueda descartar cuando hay un nuevo
trabajo disponible en el tablero: cuando el nuevo trabajo está listo para probar, por ejemplo. Este
tipo de trabajo puede ser una de esas cosas que ha pospuesto durante tanto tiempo: actualizar ese
nuevo servidor de prueba, limpiar las bases de datos en el entorno de ensayo o finalmente actualizar
la documentación de la antigua API. Sin embargo, no debería ser un trabajo que deba pasar por el
flujo de trabajo normal lo que aumentaría la WIP y ralentizaría todo en el proceso.
Esta podría ser una excelente oportunidad para trabajar en mejoras o inventar o aprender
cosas nuevas que lo ayuden a avanzar más rápido en el futuro. Sí, este es un tiempo de inactividad
cuando no está produciendo valor para su cliente, pero eso es necesario para poder mejorar.
8
Beth es ante todo un analista de negocios, ya sabes.
9
Seamos los primeros en objetar esa afirmación. Un probador a menudo es excelente para emparejarse a medida que
escribe el código. Es una excelente manera de producir código de alta calidad. Este es solo un ejemplo en el que nos
permitimos hacer imposible trabajar con Adam en el desarrollo. Raramente es el caso en la vida real.
¿Qué debería hacer a continuación? 157
Sin holgura no puede haber mejoras.

-Dr. Arne Roock (@arneroock)
RESUMEN: ¿EN QUÉ DEBO ESTAR TRABAJANDO A CONTINUACIÓN?

Dejemos el ejemplo que hemos estado siguiendo durante un tiempo e intentemos resumir cómo
podría razonar sobre lo que debería estar trabajando a continuación:10
1 ¿Puedes ayudar a terminar el trabajo que ya está en proceso? Haz eso.
2 ¿No tienes las habilidades necesarias para eso? Busque cuellos de botella u otras cosas que
ralenticen su flujo y ayude a resolverlos.
3 ¿No tienes las habilidades adecuadas para ayudar a resolver un cuello de botella o eliminar
un bloqueador? Realice nuevos trabajos en el sistema, siempre y cuando no exceda su WIP.
4 Si todavía te encuentras sin trabajo, encuentra algo interesante que creas que ayudará al
equipo, y hazlo. 11
UNA PALABRA DEL ENTRENADOR Estas pautas sobre qué
trabajar a continuación son reglas generales que ayudarán a un equipo
nuevo en kanban y un enfoque de flujo para comprender los principios.
No deben usarse como reglas. Es posible que tengas otras políticas
vigentes que tengan prioridad sobre estas pautas. Dependiendo del
contexto, podría tener, por ejemplo, más sentido tratar de resolver un cuello de botella
antes de ayudar a alguien a completar el trabajo.
¿Qué debería hacer a continuación?

* Ayuda a los miembros del equipo a saber qué hacer
a continuación para que el equipo sea más autónomo
* Use políticas y visualizaciones explícitas
* Regla de oro:
1 - Finalizar el trabajo en proceso
2 - Busque cuellos de botella y ayude a resolverlos
3 - Jale nuevo trabajo, si el límite WIP lo permite
4 - Encuentra otro trabajo interesante
* La holgura no es mala: la holgura permite mejoras
10
Esta lista fue sugerida por David Joyce.
11
Ok, no puedes permitirte estar inactivo para siempre, por supuesto. Simplemente hacer "otro trabajo
interesante" no pagará las facturas. Si eso sucede a menudo, tal vez podrías ver si puedes comenzar a cooperar
más o diseñar su trabajo para que pueda dividirse en partes más pequeñas.
7.5 Gestión de cuellos de botella

Las colas y los límites de WIP trabajan juntos para crear un indicador líder de los problemas en su
flujo de trabajo mientras los experimenta. Te dicen dónde están los cuellos de botella y también te
muestran dónde se están acumulando incluso antes de que sucedan. Veamos un ejemplo. Al
comienzo del día, el tablero se ve así. Todos los pasos están llenos de trabajo y la gente está
trabajando lejos.
Después de un tiempo, los desarrolladores quieren realizar nuevos trabajos. Solo hay un elemento
en Development/Doing. Los desarrolladores extraen un nuevo elemento de trabajo de la columna
Analyze/Done; justo está sentado allí esperando.
Pero espera un minuto; la columna Development ya está en su capacidad máxima. Aparentemente,

los elementos no se mueven lo suficientemente rápido desde la columna Development y a través de
Test; Tenemos un cuello de botella en los Test. ¿Qué debemos hacer al respecto?
Gestión de cuellos de botellas 159
Si no hacemos nada y seguimos haciendo nuevos trabajos en Development, es decir, ignorando los
límites de WIP, Test se inundará de trabajo allí sentado esperando. Esto aumentará los tiempos de
entrega de todo en el flujo de trabajo y dará como resultado todas las cosas malas asociadas con un
WIP más alto del que hablamos en el capítulo 5.
Necesitamos liberar a las personas para solucionar el problema, y afortunadamente los
desarrolladores que estaban a punto de comenzar un nuevo trabajo aparentemente tienen capacidad
de sobra. En muchos casos, esto solo será una solución a corto plazo; por ejemplo, las pruebas
pueden requerir habilidades especiales que dificultan que un desarrollador sea tan eficiente como
sea necesario. Si Test es un cuello de botella recurrente, tiene sentido trabajar en una solución a
largo plazo, como contratar más probadores o tal vez automatizar más pruebas.
7.5.1 Teoría de Restricciones: una breve introducción

The Theory of Constraints12 es una filosofía de gestión que se basa en la idea de que el rendimiento
de todos los sistemas está limitado por al menos una restricción: un cuello de botella que ralentiza la
producción. Sin restricciones en un sistema, el rendimiento sería instantáneo e infinito; el automóvil
aparecería en su camino de entrada al mismo tiempo que hacía clic en Comprar, o una nueva
función de software estaría en producción en el momento en que dijera que la quería.
Eso también significa que la restricción ralentiza todo el sistema. Cualquier mejora que haga
para ayudar a que el trabajo fluya mejor a través de la restricción es una mejora para todo el
sistema. Cualquier mejora que realice en otra parte del sistema no es realmente una mejora porque
la restricción del cuello de botella es lo que está marcando el ritmo de todo el flujo de trabajo.
La Teoría de las Restricciones, como una teoría avanzada de gestión de cuellos de botella,
clasificaría estas soluciones como mejoras de elevación porque se centran en elevar o aumentar la
capacidad en el cuello de botella. Esta es la solución que la mayoría de las personas piensan
intuitivamente cuando se enfrentan a un cuello de botella: agregar más personas o máquinas, más
12
Eliyahu M. Goldratt y Jeff Cox formularon la Theory of Constraints en la excelente novela de negocios The Goal:
Excellence in Manufacturing (North River Press, 1984, http://amzn.com/B0006EI69C).
capacitación, mejores herramientas y mejores tecnologías. Estas soluciones a menudo son difíciles
porque requieren una inversión costosa que lleva tiempo producir resultados.
De acuerdo con la Teoría de las Restricciones, a menudo tienes otra opción, más simple y
menos costosa: explotar el cuello de botella. Esto significa que primero deben asegurarse de que el
cuello de botella se utilice a su máxima capacidad. ¿Las personas que trabajan en el cuello de
botella están haciendo otro tipo de trabajo además de la actividad del cuello de botella? ¿Podría
alguien más hacer ese trabajo en lugar de ellos? En nuestro ejemplo anterior, tal vez los
desarrolladores puedan completar los informes de tiempo de los probadores y hacer sus gastos por
ellos. Cualquier tiempo de inactividad en el cuello de botella, en cualquier momento en que no
puedan realizar el trabajo de la actividad de cuello de botella, reduce la salida de todo el sistema.
DESCUBRIENDO UN CUELLO DE BOTELLA

Los cuellos de botella a menudo se revelan al tener el trabajo acumulado frente a ellos y pasos
después de que el cuello de botella se muera de hambre por cosas que hacer. En el tablero a
continuación, puede ver que hay mucho trabajo esperando para ser probado y nada que esté listo
para implementarse.
En este ejemplo, los desarrolladores tienen bloqueado el trabajo nuevo porque eso rompería su
límite de WIP de cuatro. Los cuatro elementos de Development esperan ser probados. El paso de
Test a su vez está en su límite de WIP de dos y tampoco debería hacer más trabajo. Finalmente,
vemos que el paso después de la prueba (Deploy) no tiene nada que hacer porque no fluye trabajo
del paso de Test.
Con la cola que el equipo ha puesto al frente del paso de prueba, obtienes un indicador
principal de un problema: puedes ver cómo se acumula con el tiempo. Esto le brinda la oportunidad
de reaccionar y comenzar a hacer algo sobre el cuello de botella antes de que se convierta en un
problema real.
Gestión de cuellos de botellas 161
EXPLOTANDO UN CUELLO DE BOTELLA: EL PROBADOR
Por supuesto, las pruebas13 solo se usan como ejemplo porque son comunes y fáciles de entender. El
cuello de botella podría estar en cualquier parte: sí, ¡incluso con los desarrolladores!
Los Cinco Pasos de Enfoque

En The Goal, el Sr. Goldratt también enseña los Cinco Pasos de Enfoque como una forma de
mejorar continuamente el rendimiento de su sistema:
1 Identifique la restricción del sistema: por ejemplo, una sola máquina por la que deben
pasar todas las piezas de una fábrica.
2 Explota la restricción para aprovecharla al máximo. Por ejemplo, asegúrese de que la
máquina esté funcionando todo el tiempo.
3 Subordinar todos los demás trabajos para apoyar la explotación de la restricción. Por
ejemplo, asegúrese de no enviar piezas defectuosas a la máquina; eso sería una pérdida de
tiempo para la restricción.
4 Eleve la restricción. Por ejemplo, compre otra máquina para compartir la carga de trabajo.
5 Enjuague y repita. Vuelva a revisar su sistema y vea si la restricción sigue siendo la
mayor restricción del sistema. No desea que la "resistencia al cambio" sea la restricción;
Estamos aprendiendo y mejorando continuamente.
Aquí hay algunas cosas que puede hacer para explotar un cuello de botella:
■ Asegúrese de que las personas/roles que constituyen el recurso de cuello del botella (los
probadores en nuestro ejemplo) siempre tengan trabajo que hacer: por ejemplo, construir una
cola de trabajo frente a ellos.
■ Construir en calidad para minimizar la carga de trabajo.
■ Eliminar o al menos limitar las interrupciones.
■ Eliminar los impedimentos que los obstaculizan en su trabajo o dejarlos en espera.
■ Priorice cuidadosamente el trabajo del cuello de botella para que siempre trabajen en las
tareas más importantes. No quieres que la restricción sea perder el tiempo en tareas sin
importancia, ¿verdad? Recuerde que la restricción está ralentizando la producción para todo
el sistema.
■ Permítales trabajar a un ritmo constante igualando la tasa de llegada del trabajo.
13
Adam es un gran probador, y lo amamos mucho. No siempre es el cuello de botella, sino que se usa como ejemplo en
esta sección. Lo siento Adam.
Hola chicos ... Para asegurarse de que los

no tengo nada probadores siempre tengan
que hacer. trabajo, intente dividir los
Aburriéndome
elementos de trabajo en pequeñas
por aquí.
entregas que puedan probarse
Yaaaaawn!
individualmente para que el
Je je …
trabajo esté listo rápidamente
para ellos y llegue a un ritmo
constante, en lugar de picos.
Haga que los probadores trabajen

OK gracias.
en estrecha colaboración con los
Supongo. Me
desarrolladores y otras personas
callaré ahora.
Y haré algunas
(propietarios de productos,
pruebas.
analistas, diseñadores, etc.) desde
el principio para desarrollar la
calidad y comprender mejor el
trabajo que están probando.
ADVERTENCIA Un antipatrón común que hemos visto es que

los probadores que trabajan en entornos no ágiles esperan realizar
las pruebas en lotes al final de las iteraciones o lanzamientos. Se
dedica mucho tiempo a la preparación, planificación,
administración y actividades similares. Incluso se involucran en
otras actividades como planificar el próximo lanzamiento u otro
DESAFÍOS proyecto. Esto aumenta su WIP y disminuye la cantidad de tiempo
ADELANTE que pueden dedicar a la actividad del cuello de botella.
OTRA ADVERTENCIA A medida que realiza cambios en su

sistema, el cuello de botella puede moverse. Esa es la última parte
de los cinco pasos de enfoque ("Enjuagar y repetir") y debe
evaluarse continuamente; ¿Dónde está el cuello de botella ahora?
¿Estás trabajando en el cuello de botella correcto? Recuerde que en
su proceso, una mejora en un paso sin cuellos de botella no es
DESAFÍOS realmente una mejora.
ADELANTE
Resumen 163
Gestión de cuellos de botella

* Un cuello de botella es un paso en su proceso
que ralentiza la producción
* Theory of Restraints es una teoría de gestión
basada en la gestión de cuellos de botella.
- Identificar la restricción
- Explotar la restricción
- Subordinar otro trabajo a esa decisión
- Elevar la restricción
- Enjuague y repita
Hay mucho más que se puede decir y aprender del estudio de la teoría de las restricciones, y esto ha
sido solo una breve introducción al tema. Lea más sobre la Teoría de las restricciones en Tame the
Flow: Hyper-Productive Knowledge-Work Management por nuestros amigos Steve Tendon y
Wolfram Müller (Leanpub, 2013, https://leanpub.com/tame-the-flow), que se sumerge en el tema y
sus aplicaciones.
7.6 Resumen
En este capítulo hablamos sobre formas de administrar su flujo de trabajo:
■ El flujo (o flujo continuo) es un estado ideal que describe un proceso en el que cada paso
del proceso crea valor, sin interrupciones ni tiempo de espera.
■ Perseguir este estado ideal es una búsqueda interminable que lo ayudará no solo a obtener
un flujo más rápido y uniforme, sino también a encontrar problemas en su proceso.
■ Todo lo que no es de valor a los ojos del cliente es un desperdicio. Eliminar el desperdicio
conduce a un mejor flujo.
■ “Administrar el flujo” es uno de los principios de kanban, y hay muchas cosas que puede
hacer para ayudar al flujo de trabajo:
■ Limitar WIP.
■ Reduzca los tiempos de espera en su proceso: por ejemplo, asegurándose de que el
trabajo esté siempre listo para el siguiente paso o haciendo que los elementos de
trabajo sean más pequeños para que se muevan más rápido en el proceso. Retire los
bloqueadores lo más rápido posible. ¿O por qué no esforzarse por "nunca ser
bloqueado"?
■ Evite el reproceso incorporando calidad en su proceso desde el principio. ¿Cuánto
de la demanda que tiene en su sistema hoy es demanda de falla? ¿Cómo puede tener
menos demanda de falla y más demanda de valor?
■ Crear equipos multifuncionales que puedan minimizar los tiempos de espera.
■ Use metas y objetivos como SLA para obtener cronogramas y objetivos claros
hacia los cuales esforzarse.
■ Muchos equipos usan the daily standup (la parada diaria) para colaborar bien juntos. Aquí
hay algunas prácticas para ayudar a hacer una parada genial:
■ Manténgala corta y llena de energía: nunca más de 15 minutos (es por eso que de
pié).
■ Manténgala regular: la misma hora y lugar todos los días.
■ Manténgala disciplinada: comience y termine a tiempo.
■ Manténgala enfocada: complete las discusiones después.
■ Muchos equipos kanban tienen algunas prácticas que siguen:
■ Centrarse en el trabajo, no en los trabajadores.
■ Camine a través de los elementos del tablero de derecha a izquierda.
■ Concéntrese en las desviaciones: los olores en su proceso.
■ Aquí hay otras cosas en las que pensar para aprovechar al máximo su parada:
■ ¿Se puede ver todo el trabajo en el tablero?
■ ¿Estamos trabajando en lo correcto?
■ ¿Entendemos el trabajo?
■ Fomentar reuniones espontáneas de kaizen después de la parada en el que se
realizan pequeñas mejoras todos los días.
■ Las paradas se pueden escalar a más de un equipo, pero asegúrese de que cada capa
agregue valor y no sea solo otra instancia de informes. Piensa en lo siguiente:
■ ¿Ejecutar antes o después de las paradas de equipos más pequeños?
■ ¿Quién asiste?
■ ¿Qué tipo de visualizaciones son necesarias?
■ ¿Cómo se sincronizarán los estados entre los tableros de los equipos locales y otros
tableros?
■ "¿Qué debería hacer ahora?" es una pregunta común en paradas. Con políticas explícitas
sobre cómo manejar esa pregunta, minimiza el riesgo de obstaculizar el flujo de trabajo.
■ Un cuello de botella es algo que ralentiza la producción. Con las colas, puede obtener
indicadores principales y descubrir los cuellos de botella.
■ La Teoría de las Restricciones es una teoría de gestión construida alrededor de encontrar y
eliminar cuellos de botella en un proceso.
Parte 3
Kanban avanzado
H asta aquí ha leído en el libro sobre la base de kanban, los principios en los que se
basa y muchas técnicas prácticas que lo ayudan a aplicar esos principios en su
contexto.
Ahora dirigimos nuestra atención a las prácticas más avanzadas o periféricas
que muchos equipos que usan kanban están usando o aprendiendo. Estas prácticas y
herramientas pueden ayudarlo en ciertas situaciones, sin que sea necesario usar
kanban. Y no permita que el "Avanzado" en el nombre de esta parte lo asuste; No se
requiere nada avanzado para aplicar estas prácticas, y continuaremos tomándole la
mano de una manera muy práctica. Pero aplicar algunas de estas prácticas puede
llevarlo más allá y ayudarlo a llegar más allá del alcance de su propio equipo, para
que pueda comenzar a transformar su organización.
8 Clases de servicio

■ Qué clase de servicio es
■ Poner clases de servicio a su disposición.
■ Ejemplos
En el capítulo anterior aprendió Ok gente. Escuchen. ¡Cesar tiene

un elemento que quiere que le
diferentes formas de
entreguen ahora mismo!
administrar el flujo de trabajo.
Una cosa que todos esos
¿Y eso que significa? Antes de
diferentes principios, reglas todo lo que estamos haciendo,
generales y buenas prácticas no ¿o deberíamos ponerlo en último
abordaron fue que no todos los lugar en la bandeja de entrada?
elementos de trabajo son de

igual importancia. Algunos Si detuviera mi prueba en este
tipos de trabajo pueden momento, nos retrasaría

bastante.
necesitar fluir más rápido a
través del flujo de trabajo que
Bueno ... realmente no lo sé.
otros. Aquí es donde el
¿Qué hiciste la última vez?
concepto de clases de servicio Deberíamos tener algunas reglas
es útil. Comencemos con un para esto.
ejemplo de un caso bastante
estándar.
167
168 CAPÍTULO 8 Clases de servicio
8.1 El caso urgente

Tenemos un problema; a veces
El caso de un elemento de trabajo César tiene cosas urgentes que
particularmente urgente es bien quiere en el sitio, rápido. Si
conocido por muchos equipos; a seguimos estrictamente nuestros

límites de WIP, no podríamos
menudo es necesario ser flexible cumplir con eso.
con su proceso para permitir
excepciones importantes y valiosas Kanban nos dice que comencemos
donde estamos y mejoremos desde
a sus reglas y políticas normales. allí. ¿Cómo manejaste cosas como
Podría ser un problema de estas antes?
producción, una solución necesaria

para cumplir con un reglamento o Dejamos todo y comenzamos a
trabajar en el nuevo elemento.
un contrato, una oportunidad de ¿Pero no era ese el punto central
negocio en la que tiene que actuar de la tabla y las políticas
explícitas en torno a nuestro flujo
rápidamente, cualquier cosa que de trabajo?
haga razonable abandonar lo que
está haciendo para llevar este Parece que eso fue una excepción.
elemento de trabajo a su En ese caso, es solo otra política
que aún no hemos hecho explícita.
finalización tan rápido como sea
posible. Una forma común de
visualizar esto es agregar un carril
especial en el tablero para dejar en claro que es una clase diferente de elemento con políticas
especiales adjuntas. Sea explícito acerca de cuáles son estas políticas: aquí hay un ejemplo que
hemos visto:
El caso urgente 169
Elementos urgentes:
■ Tienen su propio carril para nadar

■ Están escritos en adhesivos rosas
■ No cuente contra los límites de WIP
■ Se debe priorizar por encima de los elementos regulares; de hecho,
todos deberían dejar lo que están haciendo y ayudar a solucionar este
problema (también llamado enjambre; consulte la sección 7.2.3)
■ Solo se necesita un cálculo aproximado para ver si se pueden entregar a tiempo para una
fecha de vencimiento determinada
■ Debe haber excepciones; por ejemplo, solo un elemento urgente en su carril en un
momento dado, y un máximo de dos por semana
El último punto puede ser de particular importancia en entornos en los que el costo de acelerar el
elemento no es inmediatamente evidente para las personas que empujan los elementos de trabajo
urgentes a través del sistema. Si recuerda la Ley de Little (del capítulo 5), puede recordar que
agregar más trabajo causará tiempos de entrega más largos para todo el trabajo en su proceso. Usar
kanban para visualizar esto puede ayudar a las personas a comprender esto y evitar el trabajo
acelerado innecesariamente.
Kanban le ayuda a señalar que los elementos urgentes son, y tienen que ser, excepciones.
UNA PALABRA DEL ENTRENADOR Para asegurarnos de que la

clase de elementos Urgente no se use en exceso y para ayudarnos a
mejorar y aprender de esta excepción, recientemente hemos comenzado
a introducir una actividad adicional que se realiza después de cada
elemento urgente: un breve análisis retrospectivo o de causa raíz.
Debido a que tales elementos son excepciones, debe tratarlos como si fueran pepitas de
conocimiento que necesita cosechar para mejorar su proceso. Por lo tanto, después de
completar cada elemento urgente, se reúnen para una retrospectiva:
■ ¿Qué hizo que ocurriera este elemento urgente en nuestro proceso?
■ ¿Cómo podemos evitar que esto vuelva a ocurrir?
■ ¿Nuestro manejo de este elemento funcionó según lo planeado?
También descubrimos que algunas partes interesadas reclasifican sus elementos
urgentes cuando se les informa que tenemos la intención de discutir esos elementos en
una reunión retrospectiva después de que hayamos terminado con ellos. ¡Quizás no era
tan urgente después de todo! Y eso era lo que queríamos; Urgente es solo para cosas
urgentes. No es un acceso rápido al equipo para hacer "mis elementos" más rápido.
Urgente, a veces también denominado Expedito, es solo un ejemplo de una clase de elementos de
trabajo con políticas diferentes a los elementos normales. Se podría decir que estos elementos de
trabajo tienen una clase diferente de servicio.
Ejemplo de clase urgente
* Excepciones a su flujo normal

* Priorizado por encima de los elementos normales
* Un carril de nado separado en el tablero
* No cuente contra los límites de WIP
* Podría estar asociado con un análisis de causa
8.2 ¿Qué es una clase de servicio?

Lo que hace con la clase Urgente es establecer explícitamente que una determinada clase de
elementos de trabajo recibe cierto servicio. Como resultado, no todos los elementos de trabajo
tienen necesariamente el mismo nivel de valor o presión de tiempo. Desea que esto se refleje
explícitamente en su tablero y en otras políticas de trabajo. Es por eso que las clases de servicio se
han convertido en un concepto importante en la comunidad kanban.
Asignar diferentes clases de servicio a diferentes elementos de trabajo es una manera fácil de
crear un enfoque simple y transparente para que el equipo se auto-organice en torno al trabajo y
satisfaga las necesidades de la empresa al hacer que el valor del elemento de trabajo, la información
sobre riesgos y las políticas explícitas incluso se visualicen en el tablero. También ayuda a aumentar
la satisfacción del cliente al usar diferentes niveles de servicio para diferentes tipos de trabajo.
Echemos un vistazo a algunos aspectos a tener en cuenta al capturar y visualizar diferentes
clases de servicio.
8.2.1 Aspectos a considerar al crear una clase de servicio

Como puede ver en el ejemplo de la clase de servicio Urgente, hay muchos aspectos del
comportamiento de un elemento de trabajo que puede considerar al capturar o crear una clase de
servicio. Aquí hay algunos ejemplos de aspectos que una clase de servicio puede afectar.
VISUALIZACIÓN
Para ver fácilmente la clase de servicio de un elemento de trabajo, desea que sea visual para todos
los miembros del equipo, así como para otras personas que puedan estar interesadas. Una forma es
usar un carril para nadar, como en el ejemplo Urgente. También puede usar un color especial para el
elemento de trabajo adhesivo o indicar la clase de servicio en la tarjeta del elemento de trabajo de
alguna manera, por ejemplo, con una pegatina o un icono.
IMPACTO EN WIP
¿La clase de servicio tiene un impacto en el límite de WIP o no? ¿La clase de servicio impacta a
WIP en algunas columnas y no impacta WIP en otras? Si la clase de servicio tiene su propio carril,
¿ese carril tiene un límite WIP o un número máximo de elementos? ¿Un mínimo?
¿Qué es una clase de servicio? 171
PRIORIZACIÓN
¿Cómo se prioriza la clase en comparación con otras clases? ¿Se deben extraer los elementos de
trabajo de esta clase antes que otras clases? ¿Tiene una política de enjambre para que otros trabajos
se dejen de lado y todos pululan para llevar esto a través del flujo de trabajo lo más rápido posible?
Tal vez un tipo de cola Primero en entrar, Primero en salir (FIFO) sería una política adecuada para
este tipo de trabajo.
La información sobre riesgos, como el costo de la demora, los requisitos de habilidades
especiales y el impacto técnico son consideraciones típicas para hacer explícitas, para capacitar y
ayudar a los miembros del equipo a tomar buenas decisiones de riesgo justo a tiempo.
DIFERENTE FLUJO DE TRABAJO

¿Debería la clase seguir un flujo de trabajo diferente al de otras clases? Tal vez omita una columna:
por ejemplo, no se necesita análisis para los elementos en la clase de servicio Defect. Tal vez tenga
una política diferente para un paso del flujo de trabajo: para defectos, un desarrollador que no sea de
QA (Control de Calidad) puede hacer el trabajo de QA. Quizás necesita una estimación menos
detallada que otras clases.
Cambie el flujo de trabajo para sus clases de servicio para optimizar el resultado de los
elementos por clase de servicio. Para elementos urgentes, puede optimizar la velocidad, mientras
que los elementos que se clasifican como intangibles pueden tener la calidad del código como
resultado principal.
Clases de servicio
* Políticas explícitas sobre cómo se trata y maneja un trabajo similar
* Ayuda al equipo a autoorganizarse
* Cosas para considerar:
- Visualización
- Priorización
- Impacto en WIP
- Flujo de trabajo
Con estos aspectos en mente, echemos un vistazo más de cerca a una serie de clases de servicio que
se usan comúnmente en la comunidad kanban.
8.2.2 Clases comunes de servicio

Además de la clase Urgente, que ya mencionamos, hay varias otras clases comunes de servicio.
Entre las más extendidas se encuentran las clases de servicio que David J. Anderson describe en su
libro Kanban: Cambio Evolutivo Exitoso para Su Negocio Tecnológico (Blue Hole Press, 2010):
Expedito (lo que llamamos Urgente), Fecha de Entrega Fija, Intangible y Regular (Anderson usa
Estándar, pero preferimos Regular para evitar confundirlo con el concepto Lean de trabajo estándar)
En nuestra descripción de las diferentes clases, también hemos agregado una clase para Defectos
porque es una clase de servicio común en muchas organizaciones.
Esta sección analiza más de cerca estas clases de servicio. Si no los encuentra adecuados
para su situación específica, explíquelos y cámbielos según sea necesario. Use las pautas aquí como
inspiración y haga que se adapten mejor a su situación.
FECHA DE ENTREGA FIJA

Se está está pateando una nueva
ley a comienzos de año. Se trata de
cómo almacenamos la información
del usuario.
He escuchado sobre eso. No es

tan malo, pero hay un par de
cosas que no cumplimos.
He creado elementos de trabajo

para esas funciones, con una fecha
de entrega fija al final del año.
Genial, eso hace que sea más

fácil ayudarnos a priorizar esos
elementos correctamente y
hacer esa fecha.
La clase de servicio Fixed Delivery Date (Fecha de Entrega Fija) se usa cuando algo debe
entregarse en una fecha de vencimiento específica o antes. El elemento de trabajo se debe priorizar
y extraer a través del flujo de trabajo a tiempo para esta fecha, ya que el incumplimiento de esto
generalmente se cumple con mayores costos u oportunidades perdidas. Las obligaciones
contractuales o legales son ejemplos que vienen fácilmente a la mente, pero también puede haber
razones técnicas, como la suspensión del soporte de un servicio de terceros en una fecha
determinada.
Con una clase de Fecha de Entrega Fija, debe programar los elementos a tiempo para la
fecha de vencimiento, pero no demasiado pronto, o los elementos retrasarán otro trabajo más
valioso. Los elementos de fecha de entrega fija podrían tener estas propiedades y políticas:
■ Están escritos en adhesivos morados
■ Tenga la fecha de vencimiento claramente indicada en la tarjeta
■ Se utilizará con preferencia a otras clases menos riesgosas: por
ejemplo, con preferencia a todo excepto Expedite
■ Se debe considerar para la promoción a la clase Expedite/Urgent si la fecha de

vencimiento está amenazada.
ADVERTENCIA No use en exceso esta clase ni convierta sus

elementos de trabajo en tareas en un diagrama de Gantt tradicional
basado en planes.1 Úselo con moderación para fechas de
vencimiento externas y restricciones similares, o desordenará el
flujo de trabajo para los elementos normales.
DESAFÍOS
ADELANTE
Ejemplo de clase de fecha de entrega fija

* Cuando se debe cumplir una fecha de vencimiento
- No muy temprano o muy tarde
* Fecha claramente indicada en adhesivo
* Priorizado sobre otros elementos menos riesgosos
* Puede ser promovido a Urgente
ELEMENTOS REGULARES
Aquí están los últimos
elementos de trabajo de
las nuevas capacidades
de búsqueda. ¿Cómo los
llamamos de nuevo?
Normal, regular, el
mismo de siempre ...
elige tu opción. Los
ordenaremos como de
costumbre, ¿verdad?
La clase de servicio Regular contiene los elementos de trabajo básicos que llenan la semana laboral.
El flujo y el enfoque los moverán lo más rápido posible a través del sistema y con tiempos de
entrega razonablemente predecibles.
1
Un diagrama de Gantt es un tipo de diagrama de barras que ilustra un cronograma del proyecto y las dependencias
entre las diferentes tareas del proyecto. La comunidad ágil rehuye los gráficos de Gantt porque hacen conjeturas y
estimaciones sobre el futuro como si ellos fueran el futuro. Dan North incluso dice: "Los niños recién nacidos solo
temen dos cosas: luces brillantes y diagramas de Gantt".
Otro término del que hemos escuchado2 para esta clase de servicio es Incrementalmente
Urgente. Típicamente estos elementos no son urgentes en este momento, pero a medida que pasa el
tiempo, su urgencia incrementa.
A menudo hemos visto elementos regulares utilizados con las siguientes

políticas simples:
■ Están escritas en las ubicuas notas adhesivas amarillas
■ Se extraen según el orden FIFO: primero en entrar, primero en salir
Ejemplo de clase regular

* Elementos de pan y mantequilla
* Incrementalmente urgente
* Tirado en orden FIFO
ELEMENTOS INTANGIBLES
Los elementos de esta clase son aquellos que no tienen un valor comercial tangible y concreto, o al
menos no uno que sea fácil de estimar, pero que todavía son importantes. Esto incluye cosas como
defectos de baja prioridad, pequeñas mejoras de usabilidad y cambios de diseño.
El módulo de facturación es
horrendo para trabajar. ¡Cada
cambio lleva 10 veces más tiempo
que en otros módulos!
Lo siento, te dije que solo

hacemos cosas que nos dan valor
comercial en este momento.
Pero si no hacemos algo al

respecto, no podremos movernos
tan rápido como usted lo desee.
¿Quizás si pudiéramos dedicar
algo de tiempo a ese módulo de
vez en cuando?
2
Lea más en http://mng.bz/P6M4.
Esta clase también cubre lo que Stephen R. Covey (autor de Los 7 Hábitos de las Personas
Altamente Afectivas) llama tareas importantes pero no urgentes. Es probable que las descuides, pero
debes enfocarte en lograr la efectividad: mejorar el trabajo, eliminar la deuda técnica, aumentar la
capacidad a mediano o largo plazo y otras cosas que te ayudarán a reducir los costos futuros o crear
opciones futuras.
El bajo costo de posponer estas tareas crea la tentación de posponerlas indefinidamente, un
día a la vez. Una forma de evitar eso es asegurarse de que siempre haya cierta capacidad para esta
clase de trabajo. Una ventaja adicional es que hacer esto crea una holgura en el sistema que se
puede usar para hacer fluir otras clases a través del sistema más rápido: por ejemplo, si se necesitan
otras clases antes de esta, si es necesario.
En las organizaciones en las que el propietario de un producto o las partes interesadas
externas seleccionan el trabajo del equipo, no es raro usar la clase Intangible como una forma para
que el equipo seleccione elementos a su propia discreción: por ejemplo, para reducir la deuda
técnica y mejorar el trabajo .
Los elementos en la clase Intangible podrían tener estas propiedades:
■ Están escritos en adhesivos verdes
■ Solo se extraerá si no hay otros elementos de clase disponibles
■ Puede estar limitado de alguna manera por el número de elementos
en el tablero (ver sección 8.2.3). Por ejemplo:
■ Deben siempre ser dos de ellos en el tablero
■ Debe representar el 20% de los puntos de la historia para la
iteración
■ Debe tener una tasa de tres elementos por mes
La clase de servicio intangible también puede tomar otras formas, como el famoso tiempo de
Google que asigna ciertos días para el trabajo intangible. Otras formas que hemos visto son tarjetas
técnicas o de mejora que crea el equipo: por ejemplo, se le puede permitir al equipo una "tarjeta de
mejora" en el tablero en todo momento. Algunas personas llaman a estas tarjetas doradas técnicas,
porque son esas pepitas de oro de mejoras que los desarrolladores a menudo anhelan abordar, pero
nunca tienen tiempo para trabajar.
Ejemplo de clase intangible

* Sin valor comercial directo, pero sigue siendo importante
* Ejemplo: deuda técnica
* Jalar cuando no hay otro trabajo disponible
* Asigna parte de tu capacidad a Intangible para asegurarte
de que no se olvide
DEFECTOS
Recibí una llamada del equipo

de atención al cliente. Las
nuevas formas en que
clasificamos los resultados de
búsqueda está confundiendo a
las personas. No pueden
encontrar lo que están
buscando.
¡Ay! Eso no suena

bien.
No es tan malo, solo uno de

cada cinco tiene problemas.
Pero tenemos que arreglarlo.
Ok, crearé una

tarjeta de
defectos y la
revisaremos
pronto.
Los defectos son la clase de trabajo que no quieres ver. Un defecto es a menudo una señal de falta
de calidad en el trabajo que realizó la primera vez. De esta forma, se vuelve a introducir el trabajo y
se agrega al trabajo que ya está haciendo.
Los defectos también pueden ser otras cosas, como errores de producción o una falla del
servidor que debe manejar de inmediato.
Aquí hay algunas políticas de ejemplo para elementos defectuosos:

■ Están escritos en adhesivos rojos
■ Omita el paso de Analysis y vaya directamente a la columna
Development
■ No tiene que ser estimado
■ Debe someterse a un análisis de causa raíz sobre cómo evitar
defectos similares en el futuro antes de ser jalado a Done
■ Tiene que gestionarse en la herramienta de seguimiento de errores: cerrada y asignada al
QA, etc.
■ Se puede liberar fuera del horario de lanzamiento normal: no tienen que esperar al
próximo lanzamiento normal
Ejemplo de clase de defecto
* No deseado, trabajo innecesario

* Retrabajo y fallas de calidad
* Debe estar sujeto a análisis de causa raíz
* Puede omitir pasos en el tablero, como
análisis o estimación
Por ahora ha visto muchos usos para las clases de servicio y ejemplos de variantes de uso común;
pero ¿por qué pasar por todos estos problemas para clasificar los elementos de trabajo? ¿Qué uso
puede obtener de las clases de servicio?
8.2.3 Poner clases de servicios a utilizar

Las clases de servicios pueden ayudar con muchas decisiones que usted, como equipo, enfrentará.
Se trata de hacer que las políticas, el valor de los elementos de trabajo y la información de riesgos
sean más explícitos (consulte el capítulo 3), ayudando así al equipo a autoorganizarse y jalar los
elementos de trabajo correctos. Esto, a su vez, ayuda a que el trabajo fluya de manera más fluida y
rápida a través del flujo de trabajo, ya que no necesita decisiones o aprobación de otros en cada
pregunta o punto de decisión.
Una forma de usar las clases de servicio es decidir qué cantidad de la capacidad de un
equipo se debe usar para diferentes clases: por ejemplo, al decidir un número (o porcentaje) de
elementos de trabajo por clase que siempre estará en el tablero. Veamos un ejemplo en acción:
En este tablero, a la izquierda, el equipo ha publicado una leyenda y la distribución preferida entre
las clases de servicios. Puedes ver cuatro clases de servicio en acción aquí: Regular, Intangibles,
Defectos y, finalmente, un carril de natación Urgente para elementos de trabajo que deben ser
acelerados a través del flujo de trabajo.
Todavía no te sigo, me
temo. Después de que
terminemos este
amarillo, ¿qué sigue para
nosotros? ¿Pueden
nuestras clases de
servicio guiarnos?
Bueno, contemos y
veamos. ¿Puedes contar
la cantidad de
adhesivos amarillos en
el tablero ahora mismo?
¡No hay razón para ser

grosero! Por supuesto
que puedo contar. Son
cuatro amarillos, como
todos pueden ver.
Lo siento ... pero a

partir de eso, ¿qué
elemento nuevo deben
jalar para mantener la
distribución propuesta
de los tipos de
elementos de trabajo?
Ahh ya veo. Para

mantener la distribución,
necesitamos jalar un ...
¿pegajoso rojo?
¡Exactamente! ¿Notó
que no hubo que pedirle
a nadie que supiera qué
hacer?
Un número de porcentaje y un número concreto se escriben al lado de cada clase de servicio en la

leyenda. Indican cómo se esfuerzan por distribuir el trabajo. Cuando terminen un elemento de
trabajo, pueden mirar fácilmente el tablero y ver qué tarjeta sacar a continuación de la columna
Todo para mantener la distribución según lo acordado por el equipo.
A partir de este ejemplo, pueden ver una política explícita en funcionamiento para ayudar al
equipo a autoorganizarse. Con la ayuda de la distribución preferida (porcentajes de cada clase de
servicio), Beth podría concluir fácilmente qué tipo de trabajo debería realizar a continuación. El uso
de diferentes colores para cada clase de servicio lo hizo fácil de ver; Beth terminó de analizar un
adhesivo amarillo y, para mantener las distribuciones de colores propuestas, pudo contar los
elementos de trabajo y ver que uno rojo era el que debía jalar.
Pero también, y quizás más importante, este sistema se aseguró de que el trabajo fuera priorizado de
manera adecuada. La tarjeta de defectos que estaba esperando en la columna Todo tenía prioridad
sobre las demás, asegurando que el equipo atendiera los defectos, a pesar de que podría ser más
divertido e incluso más importante para las partes interesadas del negocio trabajar en nuevas
características.
Utilizado de esta manera, las clases de servicio también pueden ayudarlo a asegurarse de que
el trabajo de baja prioridad se haga al menos en cierta medida y no se difiera constantemente a "más
adelante". En este ejemplo, se garantiza que el equipo siempre tendrá al menos un intangible en
curso en todo momento. Debido a que lo intangible tiene una prioridad más baja para pasar a la
siguiente columna mientras está en el flujo de trabajo, también crea cierta holgura para que el
trabajo más importante se mueva a Done más rápido.
La distribución de diferentes clases, por supuesto, puede modificarse continuamente para
permitir el cambio de las necesidades del negocio. Por ejemplo, si hay un problema de calidad
percibido con el producto, es posible que desee aumentar la proporción de defectos hasta que se
resuelva. O si el equipo ha tenido que correr para llegar a una fecha límite, tal vez sea hora de
aumentar el número de intangibles y pagar la deuda técnica acumulada.
Todo es misceláneo
En un cliente entrenado por Marcus, una revisión mostró que habían gastado alrededor del 70% de
su presupuesto en trabajos clasificados como misceláneo, a pesar de que reservaron dinero para
tres inversiones principales que debían priorizarse sobre otro trabajo.
¿Cómo puede ser esto? Primero, esto es común y probablemente refleja el estándar de la
industria en el que una gran parte del presupuesto se gasta en parches. Segundo, en el calor del
momento es difícil rechazar "este rapidito que necesitamos para el viernes".
Si se hubiera establecido una clara priorización con una distribución de clases de servicio,
habrían visto más fácil y rápidamente que se estaban desviando.
Su objetivo es obtener un mejor flujo de los elementos de trabajo en el tablero. En muchos equipos,
el flujo puede detenerse por una razón simple, como que las personas no estén presentes cuando sea
necesario para la priorización, por ejemplo. Si alguna vez experimentó la necesidad de que la
propietaria de un producto sepa en qué trabajar a continuación y se detenga porque ella solo está
presente durante media hora cada semana los martes, ya sabe a qué nos referimos.
Costos de transacción y coordinación.

El costo de transacción es un término de la economía que representa el costo incurrido al realizar
un intercambio económico, como los costos de búsqueda e información, el costo de redactar y
hacer cumplir los contratos, etc. Aplicado al mundo del desarrollo de software, los costos de
transacción implican actividades de configuración y limpieza asociadas con la entrega de valor,
como planificación, estimación, presupuesto, integración y despliegue. Todos estos costos son
realmente un desperdicio (consulte la sección 7.1) porque el cliente preferiría obtener el valor que
entrega sin tener que pagar ninguno de estos costos de transacción. Esto no significa que debas
(continuado)
dejar de hacerlo; es solo el costo de hacer negocios. Pero siempre debes tratar de eliminar la mayor
cantidad posible de estos costos.
Los costos de coordinación son los costos específicos incurridos tan pronto como necesite
cooperar con otros para lograr su objetivo. Todas las reuniones, llamadas telefónicas, correos
electrónicos, etc. necesarios para coordinar sus actividades son parte de los costos de coordinación.
Por ejemplo, conseguir a una parte interesada del negocio ausente tiene muchos costos de
coordinación relacionados: la parte interesada necesita ser convocada y tomarse un tiempo fuera de
su agenda; se deben organizar reuniones; y el equipo debe detener lo que están haciendo y reunirse
con la parte interesada para la reunión.
Todo esto puede contrastarse con la posibilidad de acercarse a una parte interesada del negocio que
está presente en la siguiente mesa y preguntarle sobre la prioridad de los elementos de trabajo.
Con políticas explícitas, los costos de coordinación para seleccionar el trabajo son mucho más
bajos. Ya tienes los principios sobre cómo seleccionar el trabajo de la pila de pedidos, a menudo
visualizado en el tablero. El equipo está más autoorganizado y puede hacer la selección justo a
tiempo en lugar de agrupar el trabajo por adelantado, por si acaso, como tendrían que hacer con un
interesado que es difícil de conseguir.
El proceso de selección de lo que se debe hacer, en el orden correcto, en el momento
correcto, se llama scheduling ( programación | planificación ):
Scheduling es el proceso, y es algo continuo y dinámico, de producir resultados
económicamente óptimos a partir de la secuencia de elementos de trabajo. Es una
gran responsabilidad; así que tratemos de hacerlo de una manera sólida y
transparente.3
—Mike Burrows (@asplake on Twitter)
Aprenderá más sobre planning and scheduling of work en el capítulo 9.
¿Por qué clases de servicio?

* Hace explícita tu política de priorización
* Asegura hacer un trabajo bajo prioridad
* Ayuda al equipo a autoorganizarse
* Minimiza el costo de coordinación
3
Lea mas en http://mng.bz/avnN.
Gestión de clases de servicios 181
Si se esfuerza por tener un flujo rápido con pequeños lotes (elementos de trabajo de pequeño
tamaño) a través de su flujo de trabajo, minimizará los costos de transacción y coordinación. Esto
sucederá a través de una selección continua y dinámica de elementos de trabajo para con ellos
trabajar, en lugar de hacer planes para un futuro que podrían cambiar. La herramienta para lograr
esto son políticas transparentes y explícitas, como limitar el número de elementos que pueden estar
en una determinada clase de servicio en el tablero al mismo tiempo.
8.3 Gestión de clases de servicios
Me gusta la idea de
clases de servicio,
pero me temo que
no siempre
funcionará para
nosotros.
Por qué no?
Bueno, tenemos
algunos elementos
que son mezclas de
sus clases de
servicio; parte
defectos y parte
nuevos desarrollos,
por ejemplo.
Hay maneras de
manejar eso ...
Y no se olvide de
BigCo, Inc. Esos
tipos obtienen el
carril expreso para
el próximo mes.
Y probablemente
también se nos ocurra
algo al respecto
Si te encuentras con situaciones como la que los Kanbaneros le preguntan a Joakim, no estás solo.
Aunque las diferentes clases de servicio pueden estar claramente definidas y acordadas por todos, el
trabajo no siempre se ajusta a su clasificación. Por ejemplo, los elementos de trabajo pueden
consistir en varias tareas, cada una de las cuales pertenece a una clase de servicio separada; o puede
manejar elementos de trabajo de manera diferente según su procedencia. Esta sección habla sobre
un par de métodos y prácticas comunes que pueden ayudarlo a manejar estas situaciones.
DIVIDIR Y RECLASIFICAR
Hola Adam, ¿qué opinas
sobre este elemento? No
sé cómo clasificarlo.
¡Es realmente bueno!

Me encanta el color!
¿Qué quieres decir con
"clasificar"?
Bueno, parte de esto es

un error que debe
corregirse, pero hay una
parte que también es el
desarrollo de una nueva
característica.
Hmm, tendremos que

dividir eso uno, ¿eh?
A veces, un solo elemento de trabajo puede ser una mezcla de diferentes clases de servicio,
especialmente si es un gran elemento de trabajo. Esto puede hacer que tenga dificultades para
decidir en qué clase de servicio se encuentra el elemento y, por lo tanto, no esté seguro de cómo
manejarlo. Puede parecer tanto un error como un intangible al mismo tiempo. Intente dividir los
elementos grandes como ese en otros más pequeños, y vea si los nuevos elementos pertenecen a
otras clases y deben tratarse en consecuencia.
Las razones para dividir los elementos de trabajo y reclasificar los nuevos elementos de
trabajo son contextuales y dependen de su forma de trabajar, en el equipo y con sus clientes. Las
siguientes son algunas razones comunes que vemos de vez en cuando.
EL TAMAÑO IMPORTA
A veces no puede desglosar los elementos grandes debido a la naturaleza del elemento de trabajo o
las dependencias en el entorno técnico o la organización. Otras veces, los equipos terminan con
algunos elementos que son de un orden de magnitud más grande o más complejo que otros.
No hace falta decir que los tiempos de entrega para elementos tan grandes serán diferentes, y tal vez
se apliquen otras políticas. Esta puede ser una razón para considerar una clase especial de servicio.
Tal vez pueda permitir que un elemento grande esté en su tablero durante mucho tiempo y durante
este tiempo siempre le asigne una cierta cantidad de trabajo.
ALGUNOS CLIENTES SON MÁS IGUALES QUE OTROS
Diferentes clientes pueden ser más importantes que otros, como lo representa típicamente un
acuerdo de nivel de servicio (SLA) diferente. Es posible que desee favorecer a un determinado
cliente al asegurar el nuevo contrato con ellos, o tal vez un departamento o un producto específico
ha recibido prioridad sobre otros en la empresa.
Si la diferencia implica una política diferente sobre cómo trata el trabajo, una nueva clase de
servicio podría ser la solución.
Gestión de clases de servicios 183
RECORTANDO DIFERENTEMENTE
Otra forma de diferenciar entre las clases de servicio que podrían resultar útiles es clasificar el
trabajo según su origen o la fuente de la demanda. De esta manera, puede terminar con clases como
Marketing, Problemas de Atención al Cliente y Solicitudes de Desarrollador.
Esta es otra forma de clasificar los elementos de trabajo y hacer explícitas las políticas en
torno a cada clase. Las políticas que asocie con cada clase variarán según su contexto. Pero de los
ejemplos anteriores (consulte la sección 8.2.2), puede extraer algunos patrones comunes que se
aplican fácilmente a las clases de servicio que le resultan útiles en su contexto.
ADVERTENCIA No compliques demasiado las cosas. Una regla

general es no usar más de cinco a siete clases de servicio, porque
más que eso hace que sea difícil para todos entenderlos y
recordarlos, y usar las políticas en la toma de decisiones diaria.
Dicho esto, no tengas miedo de ser imaginativo y explorar para
comprender cómo funciona tu trabajo.
DESAFÍOS
ADELANTE
Ejemplos de gestión de clases de servicio

* Clasifica el trabajo en clases de servicio
* Divide el trabajo y reclasifica las partes
* Asignar clase de servicio
- Por tamaño
- Por cliente
* Los clientes importantes obtienen una clase propia
* Asigna una clase dependiendo de dónde vino el elemento
ACERCARSE, EXPLORAR, Y SIMPLIFICAR

Con muchas maneras diferentes de simplificar, dividir y cambiar sus clases de servicio, una
pregunta obvia es, ¿qué tan detallado debe ser? Nos gustaría citar a un amigo nuestro para ayudar a
explicar que:
Acercarse (más columnas/clases), explorar y luego simplificar es un patrón que he
visto funcionar.
—Jabe Bloom (@cyetain en Twitter)
Lo que Jabe Bloom quiere decir en la cita es primero detallar y agregar cosas: más columnas a su
tablero y más clases de servicio, por ejemplo, a sus políticas y flujo de trabajo. Esto lo obliga a
explorar y probar diferentes formas de aplicarlos hasta que sienta que tiene algo que funciona
para el equipo. Ahora intente simplificar lo que ha creado: qué se puede eliminar, qué clases se
pueden agrupar, etc.
8.4 Ejercicio: ¡clasifique esto!

Siéntese con su equipo y comience a pensar en cómo las clases de servicios pueden servirle:
■ ¿Deberías usar un carril de natación urgente? ¿Qué tipo de políticas deberían rodear esa
clase de servicio? ¿Cómo se asegura de que no todo sea urgente? ¿Puede haber solo un
elemento urgente activo en ese momento?
■ Piensa en los diferentes tipos de trabajo que haces; tal vez ya tengas diferentes colores para
algunos de los trabajos (errores, por ejemplo). ¿Existen políticas implícitas que "todos
sepan" de las que podría beneficiarse al discutirlas y escribirlas?
■ ¿Tienes un trabajo que a menudo se olvida o que con frecuencia obtiene baja prioridad?
¿Podría una clase de servicio y una política que lo ayuden a realizar un trabajo de baja
prioridad? ¿Puedes formular esa política en palabras? ¿Qué tipo de visualizaciones pueden
ayudarlo a recordar su política y ayudarlo a "caer en el pozo del éxito"?
■ ¿Qué tipo de políticas tiene implementadas hoy que podría simplificar?
8.5 Resumen
Este capítulo habló sobre formas de asociar políticas explícitas con ciertos tipos de trabajo, un
concepto llamado clases de servicio:
■ Las clases de servicio son una forma poderosa de hacer explícitas sus políticas en torno al
nivel de servicio para cierto tipo de trabajo.
■ La asignación de una clase de servicio a un elemento de trabajo puede influir en el
elemento de trabajo: visualización, priorización, impacto en WIP y flujo de trabajo.
■ Las clases de servicio ayudan al equipo a autoorganizarse alrededor de:
■ Selección y programación de trabajo.
■ Distribución del trabajo.
■ Asegurarse de que la capacidad de trabajo se distribuya según lo decidido.
■ Las clases comunes incluyen:
■ Urgente (o Expedito): priorizado sobre otro trabajo
■ Fecha de Entrega Fija: debe completarse en una fecha determinada o antes.
■ Regular: elementos normales, cada vez más urgentes, extraídos al estilo FIFO.
■ Defectos: retrabajo producido por mala calidad (desea la menor cantidad posible de
estos)
■ Intangible: no hay valor comercial tangible ahora, pero más adelante: pagar la
deuda técnica
■ Debe usar clases que se adapten a sus necesidades y situación, utilizando los ejemplos de
este capítulo como inspiración. No hay una respuesta correcta para todos.
En el próximo capítulo, veremos otro concepto que es importante para cualquier proceso:
planificación y estimación. ¿Cómo va la planificación junto con Kanban? ¿Siguen siendo
importantes las estimaciones? ¿Hay algunas formas comunes de estimar?
9 Planificación y estimación

■ Planificación, programación y formas de
planificar en el momento adecuado.
■ Estimación, puntos de historia y otras técnicas de
estimación relativa.
■ Cadencia: el latido de su proceso
■ ¿Necesita planes en absoluto?
La necesidad de planificar surge de la

necesidad de informar a los que te rodean y a
ti mismo sobre dónde estás y hacia dónde
vas. Debes levantar los ojos y considerar no
solo tu propio tablero, sino también el
contexto en torno a tu equipo. A veces hay
otros equipos o personas que vienen antes
que usted, y desea mantenerlos informados
sobre su proceso y hacerles saber cómo les
va.
Considere un equipo con el tablero a la
derecha.
185
186 CAPÍTULO 9 Planificación y estimación
Solo quedan dos elementos en la columna InBox (Bandeja de Entrada); ¿Cómo se rellenará? ¿Con
quién necesita hablar para saber qué hacer a continuación? ¿Con qué frecuencia puede reunirse con
ellos y hablar sobre lo que quieren hacer a continuación? Este es el tipo de planificación que
necesita realizar para comprender qué hacer a continuación e informar a los Upstream (Procesos
Anteriores) que está listo para aceptar más trabajo. Upstream significa el trabajo que tiene lugar
ante usted; podrían ser otros departamentos u otras personas que realizan el trabajo, o tareas que se
realizan antes que las suyas pero en otra etapa del proceso. Esto podría visualizarse con tablas
separadas, como se muestra aquí:
En el otro extremo de su tablero, es posible que deba planificar e interactuar con procesos
posteriores que lo ayuden a mover su trabajo a la producción, por ejemplo. En ambos extremos,
donde su proceso toca otros procesos (donde se topa con los procesos ascendentes o descendentes),
a menudo se necesita algún tipo de sincronización o planificación.
Otra razón para planificar es que necesita sincronizar su trabajo con otros equipos a su
alrededor. Imagine que tiene dos equipos trabajando en el mismo producto y que tienen los
siguientes tableros para visualizar su trabajo:
Programación de planificación: ¿cuándo debe planificar? 187
El equipo de backend ha realizado un cambio importante en su sistema durante las últimas semanas.
Esto tendrá un impacto en el equipo frontend, por lo que el lanzamiento del servicio de backend
rediseñado debe ser monitoreado y coordinado de cerca a medida que avanza hacia la producción.
Este capítulo le mostrará varias formas de manejar este tipo de necesidades de planificación
y sincronización en kanban. Revisaremos algunas técnicas comunes de visualización y formas de
pensar sobre la planificación.
Para planificar, a menudo es necesario tener un presentimiento sobre el esfuerzo que
requerirá el trabajo por delante: es decir, algún tipo de estimación. Echaremos un vistazo a una serie
de técnicas de estimación que pueden ayudarlo a hacer estimaciones rápidas y obtener material lo
suficientemente bueno como para comenzar a planificar.
Cuando calcula, comienza a profundizar en el trabajo por delante y descubre algo de la
incertidumbre. Por lo tanto, la estimación puede verse como gestión de riesgos; intenta aprender
sobre las cosas que no sabe, que se sienten riesgosas y que pueden causar problemas más tarde, lo
antes posible.
Comencemos desde el principio y veamos cuándo y con qué frecuencia debe planificar.
¿Puede kanban ayudarlo a programar la planificación y visualizar el proceso, a fin de obtener
indicaciones para cuándo se necesita planificación, justo a tiempo, en lugar de hacerlo por
adelantado, por si acaso?
9.1 Programación de planificación: ¿cuándo debe planificar?

¿Vienes? Es la reunión de
planificación.
Pero tengo muchas cosas en

este momento. No puedo
asumir más trabajo.
¡Finalmente! No he tenido
nada que hacer durante
días, incluso semanas.
La planificación es, por definición, una actividad que se realiza con anticipación, pero no
demasiado pronto, porque entonces corres el riesgo de tener que cambiar las cosas que planeaste y
necesitas volver a hacerlo más tarde. Además de eso, planificar para más trabajo es, de hecho, crear
más trabajo en proceso (WIP), porque ha comenzado un trabajo que estará esperando por usted. Por
otro lado, no querrás planificar demasiado tarde, porque entonces la planificación se vuelve inútil.
Si planea demasiado tarde, el futuro ya está sobre usted.
Quizás se pregunte cuándo es el momento adecuado para la planificación y cómo puede
estar informado sobre cuándo ocurre ese momento en su proceso. Idealmente, desea planificar en el
momento exacto, no demasiado temprano ni demasiado tarde, sino justo a tiempo.
9.1.1 Planificación justo a tiempo
Nos resulta difícil

determinar cuántos
elementos planificar por
adelantado. A veces, el
equipo se queda sin
trabajo hasta nuestra
próxima reunión
quincenal de
planificación, y a veces
solo hemos hecho uno o
dos elementos.
¿Por qué no
planificar justo a
tiempo?
¡¿Qué?! ¿Te refieres a

todos los días? Eso
volvería loco a César.
Necesitamos que él haga
la planificación.
Entonces, ¿no
podrías avisarle con
un par de días de
anticipación?
Eso suena muy bien. Y

muy duro. ¿Cómo
podemos saber cuándo
quedan un par de días,
cuando no sabemos
cuánto dura cada
elemento de trabajo?
Cuando planifica, crea un pequeño stock de elementos de trabajo para trabajar. Esto puede ser algo
bueno porque el equipo ahora sabe en qué van a comenzar a trabajar la próxima vez que la
capacidad les permita realizar nuevos trabajos. Pero también puede ser malo. Un stock es más WIP,
y como aprendió en el capítulo 3, más WIP hace que cada elemento vaya más lento en el flujo de
trabajo.
También se vuelve menos ágil con una larga lista de elementos de trabajo acumulados y
comprometidos por el equipo. Si se debe priorizar un nuevo elemento de trabajo urgente, debe
tenerlo en cuenta y priorizarlo en comparación con el resto del trabajo que ha planeado.
En cambio, lo que desea hacer es planificar un nuevo trabajo justo a tiempo para que
comience a trabajar en él, manteniendo al mínimo el stock de trabajo planificado previamente. Pero
eso plantea otro problema, porque a menudo hay costos asociados con la planificación: por ejemplo,
celebrar una reunión de planificación. A menudo, el cliente no puede estar con usted en cualquier
momento. Tal vez haya que realizar una planificación previa considerable antes de saber cuál es el
siguiente elemento de trabajo priorizado. (Consulte la barra lateral "Costos de transacción y
coordinación" en el capítulo 8).
Una forma de equilibrar el costo de la planificación mientras se lucha por un pequeño buffer
de trabajo es utilizar la planificación basada en eventos. Esto significa que los eventos en su proceso
le dicen que tiene la capacidad de asumir más trabajo. La planificación basada en eventos se puede
lograr mediante la creación de un sistema de señalización simple que lo alerta para planificar más
elementos. Tal sistema de señalización puede crearse fácilmente en su flujo de trabajo y visualizarse
en el tablero.
Por el contrario, puede planificar cada mes, ya sea que exista o no una necesidad de
planificación. El riesgo de programar su planificación a intervalos es que puede realizar sesiones de
planificación en un momento en que no se necesita más trabajo porque no ha terminado el trabajo
que está haciendo en este momento. Otro riesgo es la situación opuesta: la próxima sesión de
planificación no es por dos semanas, y no tiene nada más que hacer porque ha completado su
trabajo antes de lo planeado.
Planificación justo a tiempo
* Justo a tiempo = justo cuando se necesita

* Planificar demasiado por adelantado conduce
a un stock de trabajo planificado y, como resultado,
es menos ágil
* Planificar con demasiada frecuencia lleva a convocar
reuniones con demasiada frecuencia
* Cree señales en su proceso que le informan que se
necesita más trabajo
* Los eventos en su proceso pueden impulsar esto
9.1.2 Punto de pedido

Al introducir un punto de pedido, puede obtener un nuevo trabajo de los interesados cuando llegue a
un cierto número de elementos restantes. Es bastante simple en acción. De hecho, ya hablamos de
esto en la sección 6.4.2.
En el tablero a la izquierda, puede ver que la

columna InBox contiene seis elementos de
trabajo, y debajo del tercero se dibuja una línea.
El equipo recoge cosas de la parte superior de la
columna, bajando hacia la línea punteada
dibujada debajo de la tercera carta de elementos
de trabajo. Esta línea es el punto de orden para
el equipo.
Cuando InBox ha alcanzado este nivel, el
equipo contacta a las partes interesadas para una
reunión para obtener más trabajo por hacer.
Saben que llevar a cabo esa reunión llevará
algún tiempo, y que probablemente sea
necesario realizar otro trabajo antes de que el
trabajo esté listo para que puedan trabajar.
Debido a esto, han creado un pequeño stock de
trabajo, en la forma de los tres elementos debajo del punto de pedido. Esto asegurará que tengan
elementos para trabajar mientras la reunión se coordina y se lleva a cabo.
Al introducir esta simple visualización y mecanismo en su flujo de trabajo, el equipo ha
creado un evento que les indica cuándo es necesario planificar más trabajo. También se han
asegurado de que planean justo a tiempo, cuando es inminente la necesidad de más trabajo, en lugar
de crear un gran stock de elementos de trabajo, por si acaso.
Como siempre, debe estar atento y cambiar su proceso según sea necesario para adaptarse
mejor a usted. Si sus grupos de interés son difíciles de reunir, o si necesita hacer mucho trabajo
antes de poder saber en qué va a trabajar a continuación, debe tener un búfer más grande de
elementos de trabajo. Esta es una situación en la que sus costos de coordinación son más altos. Si
sus costos de coordinación son más bajos y puede llamar a sus partes interesadas en cualquier
momento, puede tener un punto de pedido más bajo. Experimenta y mejora.
Punto de pedido
* Señales cuando se necesita más trabajo

* Dibujado como una línea en su bandeja de entrada
* Cuando pasa la línea, convoca una reunión para
planificar más trabajo
* Equilibre el trabajo que queda en la bandeja de entrada
con el tiempo que lleva planificar más trabajo
9.1.3 Filtro de prioridad: visualizar lo que es importante

Pero, ¿cómo sabe qué es importante y cómo priorizar entre los elementos de trabajo? ¿Alguna vez
ha encontrado una lista de características en las que todo es prioridad 1? 1 ¿O su empresa tiene más
de un proyecto que tenga la máxima prioridad? Priorizar sus funciones en el orden correcto es una
tarea difícil, y en muchas organizaciones se dedica un tiempo y esfuerzo considerable a la
priorización.
Corey Ladas2 introdujo una técnica llamada filtro de prioridad que simplifica el proceso de
priorización y lo hace visual. También pone el foco en las cosas correctas; debe esforzarse por
trabajar solo en los elementos con prioridad 1, porque, por definición, son lo más importante en este
momento.
La visualización es simple de configurar y se presenta mejor con un ejemplo:
Este tablero de priorización tiene columnas con prioridades crecientes: La prioridad 3 es la más baja
y prioridad 1 es la más alta. Eso se traduce en: los elementos de Priority 1 deberían trabajarse ahora
(porque tienen la máxima prioridad), o al menos lo antes posible. El número de elementos en esta
columna está limitado por su capacidad actual; Estos elementos son la entrada real a la columna
InBox (o similar) de su tablero kanban. 3 Los elementos de Priority 2 son los siguientes elementos,
listos para pasar a Priority 1 tan pronto como tenga capacidad. Priority 3 son cosas en las que
trabajarás más tarde.
Cada columna tiene un límite de WIP que se suma a su capacidad. En este caso, el equipo ha
decidido trabajar en dos elementos de Priority 1 al mismo tiempo. Los límites de WIP son cada
1
Hemos encontrado clientes que tenían prioridad 1, 2 y 3, pero también sentían la necesidad de agregar prioridad 0,
porque había muchos elementos que eran la "prioridad más alta". Sin embargo, no estamos seguros de que ese tipo de
priorización les haya ayudado.
2
Visite http://mng.bz/8cDm para más información.
3
Puede agregar estas columnas de prioridad a su tablero normal. En la práctica, esto puede ser difícil si el tablero no es
lo suficientemente grande o si las personas encargadas de planificar y priorizar no están en el equipo, sino que están
sentados en otro lugar.
vez más altos a medida que continúa con los elementos de Priority 2 (WIP = cuatro) y Priority 3
(WIP = ocho). Esto refleja el hecho de que tiene una incertidumbre cada vez mayor sobre los
elementos en los que se trabaja pronto, menor es la prioridad que tienen.
También hay una columna de Backlog, o conjunto de ideas, con elementos en los que podría
comenzar a trabajar más tarde, pero en este momento no sabe si ocurrirá o cuándo. Como una
ilustración de esta incertidumbre, los elementos del Backlog ni siquiera se convierten en elementos
Cuando terminamos un
elemento de Priority 1, el
elemento adhesivo se mueve a
la columna Done, y tenemos
espacio para un nuevo
elemento.
Ahora podemos mover

elementos de Priority 2 a
Priority 1.
Esto a su vez crea espacio para

mover elementos desde trabajos
de menor prioridad a Priority 2.
de trabajo hasta que sea lo suficientemente importante (o apremiante); solo cuando un elemento es
promovido a Priority 3 creará un elemento adhesivo para él. Hasta entonces, está escrito en el
tablero. Hemos visto equipos que han visualizado su Backlog como un mapa mental y lo han puesto
al lado del tablero de filtro de prioridad en lugar de crear una lista de Backlog.4
Recuerda que esto es solo un ejemplo. Algunos equipos con los que hemos trabajado solo
usan P1 y P2; y algunos llaman a las columnas otras cosas, más significativas para ellos, como
Upcoming o Next.
Una cosa que destaca el enfoque de filtro de prioridad es que la prioridad está estrechamente
relacionada con el tiempo. Debe preocuparse acerca de cuál es "la próxima cosa más importante en
la que trabajar" cuando hay espacio para más trabajo, es decir, después de que haya terminado un
elemento de Priority 1. De hecho, no necesita tener las columnas de Priority 2 y 3 en orden. No es
importante que un elemento de trabajo tenga prioridad 34 o 35, ¿verdad? Hasta que llegue el
momento de colocar un nuevo elemento en Priority 1, debe dedicar tiempo a la priorización, y
luego solo tiene que considerar qué elemento de cada columna debe promocionar a la siguiente
columna: qué elemento pasa de Priority 2 a Priority 1, qué elemento va de 3 a 2, y qué elemento va
de Backlog a Priority 3. En lugar de perder tiempo priorizando cosas unas contra otras que nunca
terminarán implementando de todos modos, difiere las decisiones hasta que sean requeridas.
Con esta visualización simple, la priorización es fácil de ver y seguir para todos en y
alrededor del equipo. Es otro ejemplo de una política implícita hecha explícita; Debido a que la
priorización parece causar dolores de cabeza y tomar mucho tiempo en muchas organizaciones, este
enfoque puede ser útil.
Filtro de prioridad
* Visualización de sus prioridades.

* Priority 1 = algo en lo que necesita trabajar ahora
* Limitado a su capacidad para mejorar los plazos de
entrega de cada elemento de trabajo
* "¿Qué es lo más importante en lo que necesitamos
trabajar ahora?"
- Preguntado cuando tienes espacio para más elementos
de Prioridad 1
4
Un excelente ejemplo de esto se encuentra en una publicación de blog donde Marcus describe a un cliente que usa un
filtro de prioridad para obtener un mejor enfoque y velocidad. Ver http://mng.bz/32q3.
9.1.4 Tiempos de espera de Disneyland
Imagina que estás en un parque de diversiones. 5 Estás

esperando en la cola para esa increíble montaña rusa
Su tiempo estimado de
que tus hijos te han estado fastidiando durante todo el
espera desde aquí es: 8 min. año. De hecho, estás buscando un lugar para montarlo
tú mismo. Lamentablemente, pero no es sorprendente,
hay una larga cola que ahora ha esperado durante unos
35 minutos. Da un paso más y, a lo lejos, ve un letrero como el de la izquierda.
Usted piensa: "¿Cómo pueden saber eso? Bueno, en cualquier caso, es bueno saberlo. Ahora
tienes algo con qué planificar, una predicción que parece razonable. "Puedo tomar ocho minutos
más", concluyes, y les das a los niños otro dulce de la bolsa en tu bolsillo.
El personal de la montaña rusa puede saber cuánto tiempo les queda porque han rastreado
los datos y medido el flujo del proceso: “x” número de coches de montaña rusa que salen de las
plataformas por minuto, transportando “y” pasajeros en cada automóvil. Entonces se trata de contar
el número de personas en la fila y hacer los cálculos. Mostrar el resultado a los clientes que esperan
es una forma de darles una predicción de cuánto tiempo tomará, en promedio, antes de que sea su
turno de subir a la montaña rusa.
Esta es una métrica que también puede lograr, con bastante facilidad, en su tablero, lo cual
es excelente, porque enviará a sus partes interesadas las mismas olas de comodidad que obtuvo al
saber que solo tenía ocho minutos más de espera. Esto a veces se conoce como los tiempos de
espera de Disneyland, modelados en la forma en que Disneyland (y otros parques de atracciones)
indican los tiempos de espera para sus atracciones populares. Un ejemplo podría verse más o menos
así:
Esto no solo consuela a las partes interesadas que esperan que se implemente su característica
favorita, sino que también genera confianza entre el equipo y las partes interesadas. Usted, como
equipo, ha rastreado estos datos y puede decir con confianza que este es el tiempo de espera
estimado: seis días.
5
El parque podría tener una asociación con una gran compañía cinematográfica. O no. Es tu imaginación; no dejes que
el rumbo te empuje en ninguna dirección.
Finalmente, porque seis días no es tanto tiempo, la parte interesada se sorprende gratamente cuando
agrega su característica en la parte inferior de la columna. "¿¡Seis días!? Solía tener que esperar uno
o dos meses ".
Un metro no es un tren: generar confianza

Cuando hablamos sobre el punto de pedido en la sección 9.1.2, sugerimos que debe esforzarse por
tener pocos elementos debajo de su punto de pedido. Hay algunas ventajas de flujo aparente en
eso, que tienen que ver con una WIP más baja, pero también hay ventajas relacionadas con la
colaboración y la confianza entre el equipo y las partes interesadas a su alrededor. Cuanto más
estrecha sea la colaboración y más regularmente entregue, más confianza tendrán las partes
interesadas en el equipo.
Imagina que vas a viajar durante varias horas en tren. Probablemente desee comprar un boleto en
línea con suficiente anticipación, para asegurarse de que haya asientos disponibles. Para asegurarse
de no perderse el tren, llegue temprano y tal vez incluso consulte los sitios web antes de ir para ver
si el tren se está yendo.a Cuando vaya a la estación, asegúrese de llegar a tiempo. No quieres
perder tu oportunidad.
Ahora considere la situación en la que va a tomar el metro. ¿Cuánta planificación y verificación
haces entonces? Ninguna, probablemente. Bajas allí y te subes al próximo tren.
La diferencia entre estas situaciones tiene que ver con el costo asociado con la pérdida de su tren.
En el caso de un tren de larga distancia, ese costo es bastante alto; Puede que no haya otro tren
hoy, o incluso esta semana. Si se lo pierde, no puede llegar fácilmente a su destino de ninguna otra
manera.
En el caso del metro, si pierde el que pretendía tomar, solo le tomará un par de minutos esperar el
siguiente. Si hay caos en el tráfico, puede salir del metro y caminar, o tomar un taxi en su lugar.
Una parte interesada que deja su trabajo a un equipo que se reúne cada seis meses estará inclinado
a obtener buenas estimaciones y planes precisos. Quiere asegurarse de que sus cosas se entreguen
y quiere saber cuándo y en qué orden. Una parte interesada que tiene un equipo con el que se reúne
todos los lunes y miércoles no está dispuesta a pedir estimaciones y planes detallados. Si un
elemento no se entrega como se esperaba, será pronto, seguro.
Lo que está haciendo aquí es reducir WIP en forma de la cantidad de elementos que está
planeando. Con un WIP más bajo del trabajo planificado, conocerá a los interesados con mayor
frecuencia y, por lo tanto, generará confianza con ellos.
a. En Suecia, hay un largo período del año cuando el alto riesgo de nieve en las vías tiene un gran impacto en la
probabilidad de que los trenes salgan o lleguen.
Una pregunta y objeción obvia es que puede ser difícil encontrar un número confiable de días para
su tiempo de espera en Disneyland. La respuesta es que usted mide su tiempo de entrega para
obtener un buen número objetivo y tu rendimiento de fecha de vencimiento en comparación con
ello: es decir, el porcentaje de sus elemento que logran cumplir con la fecha. A muchos equipos les
resulta difícil hacerlo porque los tiempos de entrega varían mucho. Aquí hay algunas ideas sobre
cómo resolver esto:
■ Use períodos de tiempo para diferentes tamaños. Por ejemplo, en promedio, los elementos
pequeños demoran de 1 a 3 días, los elementos medianos demoran de 2 a 6 días y los
elementos grandes demoran de 5 a 20 días.
■ Utilice el rendimiento de la fecha de vencimiento. Mida sus plazos de entrega a lo largo
del tiempo y diga que, por ejemplo, en el 80% de los casos, termina en “x” días. También
podría estudiar los datos e intentar encontrar las características típicas de los elementos que
no alcanzaron ese rendimiento (trabajo que depende de terceros, ciertos tipos de elementos
de trabajo o ciertas clases de servicio), para aumentar la previsibilidad a su cliente.
Los tiempos de espera de Disneyland son una forma de aumentar la previsibilidad. Le brinda a sus
partes interesadas una forma de saber cuándo se realizará el trabajo. En nuestra experiencia, a
menudo podemos ver que esto es más importante que la velocidad. Entregar a menudo y con
previsibilidad genera confianza, como discutimos en la barra lateral anterior.
Tiempos de espera de Disneyland
* Mostrar el tiempo de espera esperado para el trabajo

* Calcular a partir del tiempo de entrega del trabajo que
fluyó a través de su proceso
* Se puede hacer por tipo de tamaño (S, M o L, por
ejemplo)
* Crear confianza con los interesados
9.2 Estimación del trabajo: relativamente hablando

Estrechamente relacionado con la planificación está la tarea de estimar cuánto esfuerzo dedicará a
completar el trabajo que le espera. Esto es difícil porque está tratando de predecir el futuro, y la
historia a menudo ha demostrado que, como industria, a menudo omitimos nuestras estimaciones,
en muchos casos, en gran medida.
Las estimaciones a menudo son incorrectas, pero la estimación (el proceso de elaboración de
las estimaciones) aún puede resultar útil. La estimación le brinda la oportunidad de comenzar a
manejar la incertidumbre que se avecina. Se puede utilizar como una herramienta de gestión de
riesgos que le permite descubrir conceptos erróneos, inconsistencias y áreas que necesitan más
investigación desde el principio.
Para poder hacer estimaciones, debe comenzar a profundizar en el trabajo que le espera, para
comprenderlo lo suficientemente bien como para saber a qué se enfrenta. Hacerlo en equipo lo
ayuda a crear una comprensión compartida del trabajo. Pero tampoco desea hacer demasiadas
Estimación del trabajo: relativamente hablando 197
estimaciones, de acuerdo con la ley de rendimientos decrecientes. Puede llegar a una estimación
rápida ahora que tiene una baja probabilidad de ser precisa (o cubre un gran lapso: 70-130%, por
ejemplo), o puede dedicar un poco de tiempo a investigarla y obtener una estimación mejor y más
precisa. en su lugar. Pero no es útil que pases días calculando la cantidad exacta de horas. En algún
lugar entre un WAG6 y un sistema completamente especificado es el punto óptimo; encuentra el
tuyo. El resto de esta sección y la siguiente le brindan herramientas para ayudarlo a hacer
estimaciones.
9.2.1 Puntos de historia

Una razón por la que las estimaciones son complicadas es que está tratando de predecir el futuro y
asegurarse de cómo se desarrollará. El futuro es por definición desconocido. Para proporcionar
precisión y estimaciones precisas, debe conocer bastantes detalles sobre el trabajo que está
estimando, y esto se le pide al comienzo de un proyecto: el momento en que sabes menos sobre el
trabajo que estás a punto de hacer.
Además de todo eso, nosotros, como humanos, no somos buenos para estimar en términos
exactos. Puede probar esto fácilmente usted mismo mirando un edificio alto e intentando adivinar
qué altura tiene desde la parte superior de su cabeza. Eso no es fácil.
Es mejor hacer una pregunta más simple, como "De esos dos edificios de allí, ¿cuál es más
alto? En términos relativos, ¿cuánto más alto es uno que el otro? Estas preguntas son mucho más
fáciles de responder para las personas y probablemente son ancestrales de los humanos desde la
edad de piedra, cuando podría ser útil saber cuál de los dos “mamuts” era el más grande.
Esto ha llevado a los equipos ágiles de todo el mundo a hacer sus estimaciones en términos
relativos en lugar de hacerlo con números exactos. La herramienta ágil más conocida para estimar
de esta manera se llama puntos de historia.
Los puntos de historia se introdujeron por primera vez en métodos ágiles como Scrum y
eXtreme Programming. Esta técnica es una forma de indicar tamaños relativos entre elementos de
trabajo. El nombre de los puntos de historia tiene que ver con las cosas que está estimando, que a
menudo son historias de usuarios.7
Probablemente te hayan preguntado: "¿Cuándo se realizará esta característica?" La respuesta
más común sería un número de días u horas, a menudo con un lapso, porque no lo sabe en este
momento. Esto se asemeja a la difícil pregunta de qué tan alto es un edificio (la ilustración está un
par de partes antes, en esta sección).
Los puntos de historia son una respuesta a ese problema, en el que te centras en la relación
entre los elementos de trabajo individuales. Con una medida relativa, no estás indicando qué tan
grande es un punto de historia; usted está diciendo que algo que calculó en cinco puntos de historia
es aproximadamente el doble del tamaño de algo que calculó en dos puntos de historia. Y es
aproximadamente un tercio del tamaño de algo que estimaste en 14 puntos de historia.
6
Wild Ass Guess (WAG) es un término acuñado por Robert C. Martin, también conocido como tío Bob. Lleva el
nombre de las excelentes capacidades de estimación de los burros salvajes, suponemos ...
7
Las historias de usuarios pueden describirse rápidamente como pequeños incrementos de funcionalidad que le dan
valor a un usuario, de ahí su nombre.
Si la parte de la historia de los puntos de la historia se refiere a las historias de los usuarios, la parte
del punto es solo un nombre. La "relativa" entre los números es lo importante, no el número en sí.
UNA PALABRA DEL ENTRENADOR Trate de evitar el uso de
"días" u "horas" en las estimaciones porque podría confundirlo a usted
y a los demás al pensar que se refiere a días reales. Algunos equipos
usan el término días relativos, por ejemplo, que envía ese tipo de señal.
Serie de Fibonacci
La serie Fibonacci es una famosa serie de números descubierta por Leonardo Fibonacci que a
menudo se usa para estimar el tamaño del punto de la historia. La serie comienza con 0 y 1 y luego
se construye sumando los dos números anteriores en la serie, que produce los siguientes números:
0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55 y así.
La razón por la que la serie de Fibonacci se usa a menudo al hacer estimaciones no es solo por
pura frivolidad matemática. La idea es que solo permitiéndonos usar números de Fibonacci para
nuestras estimaciones, la precisión en nuestras estimaciones disminuye automáticamente, cuanto
más grandes son los elementos. Esto refleja el hecho de que nuestra capacidad de estimar
relativamente disminuye cuando un elemento es un orden de magnitud mayor que el otro. Si está
discutiendo si un elemento es un 12 o un 13, probablemente se esté engañando a sí mismo al tener
más información y mejor precisión que usted.
¿CÓMO ES OTRA VEZ ÚTIL?

A estas alturas quizás te estés preguntando cómo puede ser útil. Estimaciones relativas: ¿qué uso
puede alguien tener para ellos?
Primero, transmiten que una estimación no es exacta. No ha dicho: "Tardará 258 horas en
completar esta función". Lo único que ha dicho es que este elemento de trabajo de ocho puntos es
aproximadamente el doble del tamaño de ese elemento de trabajo de cinco puntos que completó la
semana pasada.
En segundo lugar, una estimación relativa puede ser útil porque puede hacer un seguimiento
de las estimaciones en función de su rendimiento real. Digamos que un equipo ha estado trabajando
durante un mes, y durante ese tiempo el equipo ha entregado elementos de trabajo que se estiman en
34 puntos de historia. Luego puede hacer una predicción de que durante el próximo mes, dado el
mismo equipo y el mismo tipo de tareas, el equipo probablemente pueda ofrecer características
estimadas en 30-40 puntos de historia.
LOS PROBLEMAS CON PUNTOS DE HISTORIA

La naturaleza relativa de los puntos de historia es una gran herramienta para hacer estimaciones,
pero aquí se encuentran los problemas con los puntos de historia: son relativos y, por lo tanto, no
exactos. Esto es incómodo para muchas personas, y es fácil caer en la trampa de tratar de convertir
los puntos de historia en días u horas. Un gerente de un equipo que hizo 34 puntos de historia en un
mes podría hacer la generalización de que un punto de historia significa un día de trabajo
Estimación del trabajo: relativamente hablando 199
aproximadamente. Pero se equivocaría. Es un esfuerzo relativo entre las historias que estimaste en
ese momento.
El mismo gerente también podría pensar que debido a que este equipo hizo 34 puntos en un
mes, y tiene otros tres equipos a su disposición, puede contar con 136 puntos entregados por los
cuatro equipos cada mes. Pero de nuevo, estaría equivocado. Las estimaciones solo son válidas para
un determinado equipo: dos equipos a los que se les pide que estimen una serie de elementos de
trabajo pueden obtener resultados diferentes. La misma historia que un equipo decide es cinco
puntos de historia que pueden ser ocho para otro equipo, porque el primer equipo comenzó
haciendo que su historia más pequeña fuera un punto de historia, mientras que el otro equipo eligió
dos, y todo está relacionado con esta historia.
Las estimaciones también pueden verse afectadas por la dinámica del equipo y quién es más
prominente en las discusiones, o por equipos que tienen diferentes fortalezas, debilidades y
experiencias. Las cosas que son difíciles de hacer para un equipo pueden ser muy simples para otro.
En resumen, los puntos de la historia son relativos; estiman el tamaño relativo de las cosas y
son relativas al equipo y al entorno en el que se hicieron. Esta relación es buena porque transmite
que no se puede dar una estimación exacta, pero aún se puede usar una herramienta para razonar
sobre el tamaño del trabajo .
Puntos de la historia
* Estimaciones relativas que comparan el
tamaño de los elementos de trabajo en
lugar de proporcionar estimaciones exactas
por elemento de trabajo.
* Los equipos no se pueden comparar entre sí
* La serie común es la serie de Fibonacci: 1, 2,
3, 5, 8, 13, 21
* Use números que tengan sentido para usted
El hecho de que los puntos de la historia sean números puede ser malo porque los números
transmiten exactitud donde realmente solo quieres mostrar el tamaño relativo del trabajo estimado.
Para resolver eso, veamos el tema de la siguiente forma de hacer una estimación: Talla de camiseta.
9.2.2 T-shirt sizes

Los problemas con los puntos de la historia han llevado a muchos equipos a abandonarlos e ir con
algo que no usa números en absoluto, como el tamaño de las camisetas, por ejemplo. Esto significa
que estima seleccionando uno de los siguientes: S, M, L o XL.
Mantenga el sistema lo más simple posible. Esta es una estimación aproximada del tamaño
de un elemento de trabajo, y lo único que está indicando es que una S es aproximadamente del
mismo tamaño que todos los demás elementos S que ha hecho. Más valores indican una mayor
precisión en sus estimaciones, y la idea es solo indicar los tamaños relativos del trabajo.
Muy a menudo, nos hemos encontrado con equipos que usan S, M y L; algo más grande que eso, se
dividen en elementos de trabajo más pequeños que pueden estimar como S, M o L. Un elemento de
trabajo XL ocuparía demasiado de su capacidad y sería engorroso para el equipo.
Puede agregar tamaños a esta serie si es necesario (como XS y XXL), pero en la mayoría de
los casos no hemos visto la necesidad de hacerlo. Recuerde que un elemento de trabajo estimado
como XL escondería mucha incertidumbre y riesgos. No es raro dividir un elemento XL y terminar
con ... dos o tres nuevos elementos XL, porque el equipo no sabía qué estaba oculto dentro de ese
gran elemento de trabajo.
UNA PALABRA DEL ENTRENADOR Acuerde dividir siempre los

elementos que se estima que son XL hasta que sean L o más pequeños.
Esta es una excelente manera de gestionar la incertidumbre y reducir el
riesgo, así como limitar su WIP.
Al igual que con los puntos de la historia, el beneficio de tener estimaciones relativas como esta es
que puede comenzar a hacer predicciones basadas en datos reales del rendimiento del equipo a lo
largo del tiempo. Si el equipo normalmente usa de dos a cinco días para un elemento de trabajo
pequeño, y lo ha estado haciendo durante los últimos 30 elementos de trabajo estimados en S, lo
más probable es que el próximo elemento de S tome entre dos y cinco días. Con base en ese
conocimiento, puede predecir que los 30 elementos S que ha alineado en su cartera de pedidos
tardarán aproximadamente 100 días en completarse.
Técnicas de estimación 201
Aparte del hecho de que los tamaños de las camisetas usan letras, mientras que los puntos de la
historia son números, no hay una gran diferencia entre los dos en la forma en que están destinados a
ser utilizados.
Estimaciones de talla de camiseta

* Estima el trabajo en grupos como el tamaño de las camisetas
* S, M y L son los más utilizados
* Use XS y XL solo si es necesario
* Estimaciones relativas
* Seguimiento de datos y proyectos basados en datos reales, por ejemplo:
- "S tarda 3-5 días"
Veamos cómo se pueden usar las estimaciones relativas en la práctica con un par de técnicas de
estimación.
9.3 Técnicas de estimación

Hay varias formas comunes en que los Hola Beth, ¿quieres ver
un truco de magia?
equipos ágiles elaboran estimaciones.
Piensa en un número
Lo que todos tienen en común es la entre 1 y 21.
colaboración, y en todas las prácticas
que sugerimos en esta sección, verá Entendido.
otro tema subyacente: se esfuerzan por
ser lo suficientemente buenos. No
¿En cuál pensaste?
desean invertir demasiado tiempo en Díselo a Adam, por
estimar. favor.
Le recomendamos encarecidamente
que realice una estimación en grupos y 11 ... pero ¿para qué
que preferiblemente incluya personas estás usando ese
en el ejercicio con diferentes número?
competencias, conjuntos de habilidades

y roles. La estimación y la planificación Característica de
búsqueda: 11 días.
se pueden ver como un ejercicio de
Gracias Beth
recopilación de conocimientos en el que
se descubre información a medida que
se elimina la incertidumbre.
Veamos algunas técnicas comunes, comenzando con una forma rápida de estimar el esfuerzo para
un proyecto completo o una cartera completa.
9.3.1 Una línea de cartas

Supongamos que tiene 50 elementos de trabajo para los cuales una parte interesada le pide que
calcule el tamaño. Este es lo temido "¿Cuánto tiempo te llevará este proyecto?" pregunta. Hemos
tenido excelentes resultados de este ejercicio simple que se puede ejecutar rápidamente en un grupo.
Para aproximadamente 50 elementos, esto se puede ejecutar en 10-20 minutos.
El ejercicio es así:
1 Escriba las descripciones de los elementos de trabajo en fichas separadas. Deben estar
preparadas antes de comenzar.
2 Pon todas las cartas en una pila sobre la tabla.
3 Elija el primero y colóquelo en el lado de la pila de cartas.
4 Elija otro y pregunte: "¿Es más grande o más pequeño que el primero?" Para poder
responder esto, es posible que deba analizar de qué se trata el elemento de trabajo con las
otras personas en la sala. Tómese el tiempo para hacer eso, pero no demasiado tiempo.
Recuerde, esta es una estimación rápida.
5 Cuando haya decidido si es más grande o más pequeño, colóquelo encima o debajo de la
tarjeta en la tabla para que las tarjetas formen una línea.
6 Repita los pasos 4 y 5 hasta que se quede sin tarjetas.

7 Ahora puede agrupar las tarjetas, que es la etapa 2 deesta técnica. Comience desde la parte
inferior (la más pequeña) de la línea de cartas en la tabla y declare que el primer grupo se
estimará como pequeño.8
8 Continúa hacia arriba y decida dónde las tarjetas se hacen más grandes y cuándo se debe
usar un nuevo valor (medio, por ejemplo). Que el equipo lo diga.
8
Podrías usar puntos de historia en su lugar. Use la escala y las medidas que funcionen para usted.
9 Muy pronto has recorrido toda la línea de cartas. Ahora puede resumir los valores (cinco
tarjetas estimadas como pequeñas, cuatro tarjetas estimadas como medianas, etc.) y obtener
un total para toda la línea de tarjetas. Este es el esfuerzo estimado para los elementos de
trabajo.
UNA PALABRA DEL ENTRENADOR Hemos utilizado esto como

un ejercicio repetido después de cada lanzamiento (cada dos semanas)
para estimar el resto de los elementos de trabajo en la cartera de
pedidos. Nunca gastamos más de 10 minutos en ello.
Una línea de cartas

* Ejercicio simple para estimar rápidamente muchos
elementos de trabajo
* Elija cualquier elemento de trabajo y luego compare el
siguiente con el primero: ¿más pequeño o más grande?
* Cuando todo esté establecido, asigne números: por ejemplo,
puntos de historia o tamaños de camisetas
Una forma más formal y detallada de hacerlo es a través de Planning Poker, que es el próximo
ejercicio que tenemos por delante.
9.3.2 Planificación de Póker

Planning Poker es otra forma de hacer estimaciones en un grupo, utilizando la sabiduría de la
multitud y algo de diversión para producir excelentes discusiones y ayudarlo a estimar los
elementos de trabajo en el proceso. El nombre de Planning Poker fue acuñado por James Grenning
(uno de los firmantes del Manifiesto Ágil9), y la única conexión con el póker es que a menudo se
usan algún tipo de cartas durante el juego. El juego es simple de jugar:
1 Entregue naipes (discutidos más adelante en esta sección) a todos los participantes del
juego.
2 Tire de un elemento de trabajo para estimar y descríbalo brevemente al grupo.
3 Hable y responda cualquier pregunta sobre el elemento de trabajo.
4 Cuando todos se sientan lo suficientemente cómodos sobre cuál es el elemento de trabajo,
vaya a la estimación.
9
Visite http://agilemanifesto.org/.
5 Cada persona elige una tarjeta que representa los puntos que cree que debería estimarse
que es el elemento de trabajo. No se lo muestres a los demás.
6 A la cuenta de tres, todos muestran la tarjeta con su estimación al resto del grupo.
Ahora que hemos discutido esto, en tres ... 1 ... 2 ... 3 ... ¡muéstralo!
Eeeh ... creo que necesitamos hablar un poco más.
7 Cada persona elige una tarjeta que representa los puntos que cree que se debe estimar que
es el elemento de trabajo. No se lo muestres a los demás. A la cuenta de tres, todos muestran
la tarjeta con su estimación al resto del grupo. Este paso es la parte interesante. Si todos
están más o menos de acuerdo, entonces ha encontrado la estimación y puede pasar al
siguiente elemento de trabajo. Si tiene estimaciones muy diferentes (2, 4, 8 y 13, por
ejemplo), debe preguntarse por qué:
■ ¿Qué pensaban las personas que estimaban 2 y 4 puntos de historia que significaba
el elemento?
■ ¿Qué pensaron las personas de 8 y 13 puntos de historia sobre el elemento de
trabajo?
■ Vuelva al paso 5 y obtenga una nueva votación.
8 Repita hasta llegar a un acuerdo sobre el tamaño de la estimación. Se pueden aceptar
algunas variaciones más pequeñas en las estimaciones, pero deben estar bastante cerca una
de la otra.
El punto principal es la discusión, que es evidente para cualquiera que juegue a Planning Poker más
de una vez. Solo hablando entre ellos pueden entender lo que todos piensan sobre el esfuerzo que
tomará completar el elemento de trabajo. Pedirle al grupo que haga las estimaciones es una forma
de provocar que ocurra tal discusión.
Otra forma de hacer Planning Poker

En el libro Agile Adoption Patterns: A Roadmap to Organizational Success (Addison Wesley
Professional, 2008), Amr Elssamadisy describe la planificación de una manera diferente a la
nuestra. Para cada requerimiento:
1 Haga que un experto en dominios explique el requisito en cuestión al equipo, para
asegurarse de que todos entiendan de qué se trata.
2 Realice las siguientes rondas de estimación y solo continúe a la siguiente ronda si no está
de acuerdo con el tamaño de la estimación:
■ Ronda 1: Lleve a cabo una votación silenciosa con tarjetas. Sin discusión, pero
echar votos: en el recuento de tres como se describió anteriormente, por ejemplo.
■ Ronda 2: deje que la gente piense por un minuto o dos antes de hacer una nueva
votación silenciosa, aún sin discusión.
■ Ronda 3: deje que los miembros del equipo expliquen por qué votaron como lo
hicieron y luego voten nuevamente.
■ Si aún no están de acuerdo, estacione esa historia para una sesión separada y
continúe con el siguiente requisito.
Con este abordaje, te enfocas en producir estimaciones suficientemente buenas rápidamente. No
tiene sentido discutir todos y cada uno de los requisitos en detalle cuando ya están de acuerdo.
Para los equipos que no han trabajado juntos antes, este ejercicio puede ser difícil, porque no tiene
una norma sobre cuáles son sus estimaciones relativas. ¿Qué significan para ti dos puntos de la
historia? En casos como estos, debe elegir una pequeña historia y tratar de acordar una estimación
para eso. Todos los demás trabajos ahora se pueden estimar en relación con ese elemento de trabajo.
Otra forma es estimar con la línea de cartas (ver sección 9.3.1) un par de veces antes de que,
como equipo, comience a hacer Planning Poker.
UNA PALABRA DEL ENTRENADOR La discusión es la meta, no
las estimaciones. No podemos enfatizar esto lo suficiente. Asegúrese de
alentar preguntas y discusiones: aquí es donde se lleva a cabo el
aprendizaje, se descubren nuevas ideas y las viejas "verdades" que
podríamos llevar a cabo son desafiadas y tal vez descartadas. Salir sin
respuesta debido a demasiadas incógnitas es un resultado válido y útil. No muchas partes
interesadas comenzarían un proyecto en esas condiciones. Para una sesión buena y
efectiva, asegúrese de tener las personas presentes que sean necesarias para responder las
preguntas que puedan surgir.
¿QUÉ TARJETAS DEBE USAR?
Muchas compañías10 crean sus propios mazos de Planning Poker, y si tienes uno en tus manos,
funcionará bien. Si no tienes una, puede crear fácilmente algunas tarjetas por su cuenta con lápiz y
10
No es que haya nada malo en eso; ambos estábamos ansiosos por crear tarjetas para una consultoría donde ambos
trabajábamos.
papel; te llevará 30 segundos Estas son algunas tarjetas que podría incluir:
■ Números 1, 2, 3, 5, 8, 13.
■ ? —Esto significa: "No tengo ni idea. Dame más información antes de que pueda adivinar.
■ Un símbolo de descanso o taza de café: esto significa: "Mi cerebro está tostado y necesito
un descanso, preferiblemente con café, antes de continuar".
También hay una serie de aplicaciones para teléfonos inteligentes11 que pueden ayudarlo con esto.
No gaste dinero en uno: use sus manos si nada más funciona. La estimación no es lo importante, así
que no hagas grandes esfuerzos para tener una buena manera de mostrar los números.
Planning Poker
* Buen ejercicio para aclarar malentendidos y
provocar discusiones sobre el significado real
* Comenta, elige un número y muéstralo al grupo
- Si no está de acuerdo => continúe la discusión
- Si está de acuerdo => pase al siguiente
* Discusión importante; estimadas no mucho
Los primeros ejercicios que hemos discutido tienen que ver con estimar elementos de trabajo, pero
hay otra forma. ¿Qué pasa si en su lugar modificó los elementos de trabajo en algo que se adapte a
sus estimaciones? Obtengamos ayuda de una figura de cuento de hadas para hacer eso.
9.3.3 Ricitos de Oro

En lugar de estimar el tamaño del elemento de trabajo, puede cambiar el elemento de trabajo dentro
de un tamaño adecuado. Es un poco como el viejo dicho, "Si la montaña no vendrá a Mahoma,
entonces Mahoma debe ir a la montaña."12 Esta técnica13 se inspira en la historia infantil de
Goldilocks (“Ricitos de Oro”) y los tres osos.
En esta historia, la heroína, Goldilocks, camina por el bosque y encuentra la casa de los tres
osos, habitada por Papa Bear, Mama Bear y Baby Bear. Papa Bear es el oso más grande, Mama
Bear
11
Busque "planificación de póker" en su tienda de aplicaciones y encontrará una larga lista de aplicaciones.
12
Ver http://mng.bz/0l2M para más información.
13
Joakim lo recogió por primera vez en un taller dirigido por Johannes Brodwall y Lasse Koskela en la conferencia de
Oredev hace unos años.
es el siguiente en tamaño, y Baby Bear es el más pequeño de los tres osos. Los osos están afuera
cuando Goldilocks entra a la casa. Ella está cansada y quiere descansar. Goldilocks prueba las sillas
de los osos (entre otras cosas ...) para mayor comodidad. La silla de Papa Bear es demasiado
grande, la silla de Baby Bear es demasiado pequeña, pero la silla de Mama Bear es perfecta.
Goldilocks se sienta en esa silla y descansa.
Antes de perdernos totalmente en las historias de los niños: con la técnica de estimación
Goldilocks, usted cambia sus elementos de trabajo para que sean correctos. No demasiado grande,
no demasiado pequeño. En lugar de asignar diferentes valores estimados a cada elemento de trabajo,
divide y fusiona los elementos de trabajo para hacerlos aproximadamente del mismo tamaño y justo
para su conveniencia.
Puede ejecutar esto como un ejercicio
si lo desea, dividiendo una pila de
elementos de trabajo en tres pilas más
pequeñas: demasiado pequeña, demasiado
grande y correcta. Describa cada elemento
de trabajo y haga que el equipo vote por la
ubicación. Después de esto, divide los
elementos de trabajo en la pila
"demasiado grande" en elementos más
pequeños "justo". Viceversa, fusiona los
elementos en la pila "demasiado pequeña"
en elementos de trabajo "justo".
Este simple ejercicio puede ser beneficioso para usted y sus predicciones. Ahora tiene
elementos de igual tamaño que puede comenzar a rastrear y medir. Después de algunas semanas, ya
sabe cuántos elementos de trabajo de “tamaño promedio” (o del tamaño justo) puede manejar el
equipo cada semana, por ejemplo. Debido a que todos los elementos de trabajo son del mismo
tamaño, hace que las predicciones sean fáciles de hacer.
En la sección 7.2.2, hablamos sobre cómo hacer que los elementos de trabajo sean más
pequeños y de tamaño similar para aumentar el flujo. La técnica de estimación Goldilocks es una
aplicación directa de esas ideas que pueden ayudarlo a estimar y mejorar el flujo.
Ricitos de Oro
* No calcule, sino que rebane el trabajo en un
tamaño adecuado
- Fusionar pequeños elementos de trabajo
- Dividir elementos de trabajo grandes
* Le da una acumulación de elementos de
trabajo de "tamaño promedio"
Ahora que hemos investigado un par de técnicas para hacer estimaciones, centraremos nuestra
atención en algo que pueda ayudarlo a dividir el trabajo en piezas manejables.
9.4 Cadencia
Cadencia significa más o menos latido o ritmo, y probablemente te estés preguntando por qué
estamos comenzando a hablar de términos musicales a finales de este libro si queremos presentarte
la teoría de la música. Pero el ritmo que los practicantes de Lean quieren decir cuando hablan de
cadencia es el ritmo del trabajo, como el latido de su proceso.
Esto no es tan extraño como parece; Hoy tienes un ritmo en tu proceso. Un ejemplo simple
son las iteraciones encontradas en muchos procesos. En el corazón de Scrum, por ejemplo, el
trabajo tiene un latido natural en iteraciones llamadas sprints. Cada sprint comienza con una sesión
de planificación, en la que el equipo asume tanto trabajo como creen que lograrán durante el
próximo sprint. Después de dos semanas, el sprint ha terminado y el equipo puede mirar hacia atrás
con una revisión, demostración y retrospectiva.
Una cadencia te da una base para la previsibilidad. Con una cadencia regular, puede
comenzar a medir y predecir cómo le irá frente a una meta. Se podría decir que su meta es entregar
de cuatro a seis elementos de trabajo cada dos semanas. Cuando hayan pasado dos semanas, puede
mirar hacia atrás y ver cómo le fue en contra de su meta. La cadencia de dos semanas que ha
introducido ahora es para propósitos de revisión.
Las iteraciones de timeboxed como las que describimos anteriormente son solo un tipo de
cadencia. Las cadencias pueden tomar muchas formas, y en esta sección examinaremos diferentes
formas en que pueden manifestarse en kanban y la ganancia que puede obtener al usarlas.
ITERACIONES Y KANBAN
Entonces, ¿he entendido

esto correctamente? El
trabajo seguirá llegando a
nosotros, en un flujo
continuo. Simplemente
esclavizaremos lo más
rápido posible …
Nosotros, sí ... no, es

broma. También hay inicios
y paradas naturales en el
flujo de trabajo.
¿Qué quieres decir? En este

momento se siente como un
río de trabajo sin fin.
Vamos a buscar la cadencia

de tu trabajo, y verás que
hay comienzos y paradas
allí.
Cadencia 209
Una iteración generalmente comienza con algún tipo de planificación o evaluación de lo que se está
preparando para hacer; lo haces y luego terminas, preferiblemente terminas mirando hacia atrás en
lo que has hecho durante la última iteración y viendo si puedes mejorar. La cadencia para el sprint
es, por ejemplo, dos semanas, y un nuevo "latido del corazón" en su proceso se inicia cuando
comienza la próxima iteración.
Como puede ver, las iteraciones son como proyectos pequeños de timeboxed, con un inicio
claro y una meta. Como ejemplo, puede ver una iteración en acción en un tablero como este:
En la primera imagen, el equipo ha alineado todo su trabajo para la próxima iteración en la columna
Todo. En la imagen de mitad de iteración, se están trabajando algunos elementos de trabajo, otros se
han terminado y hay uno que aún no se ha iniciado. Al final de la iteración, es de esperar que todos
los elementos de trabajo se hayan movido a la columna Done. El tablero se reinicia y el equipo
comienza de nuevo planificando la próxima iteración.
TRANSICIÓN DE PROCESOS BASADOS EN LA ITERACIÓN

También puede asignar el flujo de iteración más explícitamente en el tablero, como lo sugiere Eric
Willeke,14 con un tablero que se vea así:
Esto le brinda una transición suave de Scrum (u otros métodos basados en iteraciones) a kanban
(que está basado en el flujo) porque nada ha cambiado, aparte de eso, ha comenzado a visualizar
todo su flujo de trabajo. Las cadencias actuales de Scrum (planificación, paradas diarias,
14
Veer “Switching from Scrum to Kanban – Huh?” http://mng.bz/j6UJ.
retrospectivas y demostraciones) pueden dejarse intactas y ejecutarse con la misma frecuencia que
antes.
LA APROXIMACIÓN DE KANBA A LAS CADENCIAS

Kanban no dice mucho sobre cadencias como los ejemplos que has visto hasta ahora. El enfoque
principal son los elementos de trabajo y cómo fluyen individualmente sobre el tablero. Esto le da la
libertad de desacoplar la iteración (como planificación y revisión) del trabajo.
Eso significa que planifica a intervalos regulares, cada semana, por ejemplo, y tal vez tenga
una revisión y una retrospectiva cada tres semanas. O puede usar eventos en su proceso para
indicarle que haga la planificación, la revisión, etc., tal como lo mencionamos anteriormente. Eso
sería como aplicar el principio Lean de arrastre para esos eventos. Esta aproximación garantiza que
planifique justo a tiempo cuando necesite más trabajo, no solo por si crea un stock de trabajo
planificado.
Aunque kanban no dice nada acerca de las iteraciones, aún puede hacer iteraciones en
kanban si lo desea. Recuerde que kanban son tres principios simples (hacer visible el trabajo, limitar
el trabajo en proceso y ayudar a que el trabajo fluya) y no dice nada sobre sus cadencias o
iteraciones. Muchos equipos Scrum adoptan los principios kanban y se alejan lentamente de una
cadencia centrada en la iteración, hacia un proceso más basado en el flujo sin iteraciones. Puede leer
más sobre este enfoque en el libro ScrumBan de Corey Ladas (Modus Cooperandi Press, 2009,
http://amzn.com/0578002140).
Todos los beneficios de los que hemos hablado en este libro con respecto a la visualización,
la limitación de WIP y ayudar a que el trabajo fluya aún se aplicarían a un equipo que usa
iteraciones. La única diferencia sería que el impacto de los principios kanban estaría limitado dentro
del alcance de la iteración.
Iteración o basado en flujo: ¿cuál es mejor? No hay forma de saberlo. Si tiene una pila de
elementos que son las únicas cosas en las que trabaja, entonces una aproximación basado en
iteraciones sería adecuado. Esto le daría un gran enfoque, y podría empujar el trabajo que viene a
usted durante la iteración a un lado hasta la próxima iteración. Si, por otro lado, gestiona los
elementos que podrían llegar a usted en cualquier momento (por ejemplo, haciendo soporte y
mantenimiento de una aplicación que también está desarrollando), podría estar mejor con un
enfoque basado en el flujo, sin el inicio y parada de iteraciones.
NO TE VUELVAS FLOJO SOBRE MI

Finalmente, si pasa de un proceso basado en la iteración, como Scrum, a un enfoque basado en el
flujo, no se vuelva flojo (como veremos en el capítulo 12). Use las prácticas que tengan sentido para
usted; siga teniendo sesiones de planificación para desglosar el trabajo, siga haciendo retrospectivas
para mejorar y siga haciendo demostraciones para sus partes interesadas en las cadencias adecuadas.
9.5 Planificación de la forma kanban: menos dolor, más ganancia

En esta sección, queremos dar un paso atrás y tomar un tiempo para reflexionar sobre por qué está
planeando y estimando, y tal vez pensar en las alternativas. Además de las razones teóricas y
Planificación de la forma kanban: menos dolor, más ganancia 211
lógicas para tratar de planificar y estimar menos, muchos equipos de kanban encuentran que la
necesidad de planificar y estimar disminuye cuanto más usan kanban y los principios que
discutimos en este libro.
UNA PALABRA DEL ENTRENADOR No dejes de planificar (y
otras prácticas que te ayudan a hacer un gran trabajo) porque kanban no
te dice que lo hagas. Demasiados equipos kanban se esconden detrás de
esta "excusa" y dejan de planificar porque "no hay planificación en
kanban". ¡No seas ese equipo! Eres mejor que eso.
En esa nota, tampoco hay una sola palabra sobre la calidad del código en kanban. O
escribir código, para la caso. O sobre hacer pruebas. O que es una buena idea implementar
su código en todo.
9.5.1 La necesidad disminuye
Los equipos que usan kanban gradualmente encuentran la necesidad de planificación y las
estimaciones se desvanecen. La necesidad de estimaciones y planes se basa en la necesidad de
gestionar el riesgo y la incertidumbre. Los planes están ahí para darle una idea de lo que tiene
delante, lo lejos que ha llegado y cómo manejar circunstancias imprevistas. Para hacer planes que
sean confiables, debe tener algunas estimaciones de cuánto esfuerzo se necesita para completar el
trabajo que ha alineado. Mientras más cosas tiene que hacer al mismo tiempo, a menudo se le pide
más planificación (lo que causa más trabajo: más planificación, más estimación, etc.; vea la
discusión del capítulo 3 sobre la ley de Little).
Con kanban, te esfuerzas por minimizar WIP y ayudar a que el trabajo que realizas fluya
más rápido. Esto significa que no hay mucho trabajo para planificar, y debido a que desea que el
trabajo que realice sea pequeño y rápido, la planificación y la estimación deberían pasar bastante
rápido. Calcular y planificar el esfuerzo para una nueva característica es mucho más fácil de hacer
con precisión que si se le pide que calcule 25 características, ¿verdad?
Cuando los equipos realizan nuevos trabajos a menudo, tal vez varias veces al día, estimar
cada elemento de trabajo rápidamente comienza a sentirse engorroso. Muy pronto empiezas a
cuestionar el valor de hacer estas estimaciones en primer lugar. Esta es una señal sobre la que debes
actuar. ¿Por qué no ir y preguntar a los interesados cuál es la verdadera necesidad? No es
improbable que después de algún tiempo usando kanban, la parte interesada también haya visto
disminuir la necesidad de estimaciones y planes detallados, como usted. Al menos podría hacer un
experimento e intentar pasar un mes sin o con una planificación y estimación mucho más livianas:
probando, por ejemplo, las estimaciones del tamaño de una camiseta (ver sección 9.2.2).
Kanban te enseña a visualizar tantos aspectos de tu proceso como sea posible para las
personas del equipo y otras personas a su alrededor. Eso significa que el estado actual es obvio para
cualquiera: justo frente a usted en una tabla, por ejemplo. Si hay algunos datos que faltan de partes
interesadas, debe agregar esos datos y hacerlos también visuales. Los backlogs impresos en los que
tacha los elementos que se han completado, y gráficos simples de la cantidad de elementos que ha
completado cada semana, son ejemplos de formas de visualizar información que podría ayudar a las
partes interesadas a ver lo que está sucediendo y el progreso del trabajo del equipo.
"¡El mejor informe que hemos tenido!"

Marcus ayudó a un cliente a convertir un sistema crítico de una tecnología obsoleta (VB6) en algo
un poco más moderno (VB.NET). El sistema era una gran aplicación monolítica de Windows con
literalmente cientos de formas. Naturalmente, las preguntas inevitables llegaron en la primera
semana: "¿Cuánto tiempo te llevará?" "¿Cuándo terminarás?"
Debido a que el equipo no tenía ni idea, naturalmente (nunca lo habían hecho antes, no sabían el
código, no habían decidido cuál debería ser el resultado final), decidimos usar informes simples
para calmar a la gente abajo.
Listamos todos los archivos de código (formularios VB6) por tamaño en KB, con la simple
suposición de que cuanto más grande sea el archivo, más código se convertirá. Todo menos de 20
KB se clasificó como pequeño, 20–50 KB se denominó medio y 60–100 KB fue grande. Por
encima de 100 KB se llamaba XL.
Arrojamos todo en una hoja de cálculo en la que los desarrolladores informaron la fecha en que
comenzaron y detuvieron el desarrollo en el formulario.
A partir de esto, fue simple hacer un diagrama que indica el estado actual del proyecto. Y con las
fechas, podríamos hacer proyecciones de cuánto tiempo quedaba para el resto de los formularios.
“Hemos hecho tres pequeños que tomaron en promedio cuatro días. Quedan 60 pequeños en la
cartera de pedidos. 60 × 4 días = 240 días restantes hasta que todos los pequeños estén listos ".
Los desarrolladores estaban contentos con este informe ligero. Pero lo que sorprendió a Marcus
fue que el comité directivo de este proyecto de alto riesgo lo llamó "el mejor informe que hemos
visto en la compañía".
Creemos que tiene que ver con dos hechos simples: era transparente y simple de ver para todos, y
se mantenía actualizado diariamente. Eso generó confianza, y las predicciones estaban en un nivel
suficientemente bueno para que todos se sintieran seguros sobre el progreso del proyecto.
9.5.2 Razonamiento lógico: la petición del cliente

Retrocedamos un momento y pensemos por qué estás aquí. El objetivo principal de cualquier
departamento o proyecto de TI es ayudar a la empresa a trabajar de manera más inteligente, fácil o
mejor. Parafraseando a Gojko Adzic,15 genere impacto comercial, no software.
Esto significa que el software es un medio para un fin; el software en sí mismo no es el
punto. Hay alguien por ahí que quiere poder hacer su trabajo mejor, de manera más fluida, de una
manera más divertida, o no tener que hacerlo en absoluto. Llamemos a esa persona el cliente, ¿de
acuerdo?
15
Impact Mapping: Making a Big Impact with Software Products and Projects, por Gojko Adzic (Provoking Thoughts,
2012, http://amzn.com/B009KWDKVA).
Planificación de la forma kanban: menos dolor, más ganancia 213
UNA PALABRA DEL ENTRENADOR Sí, siempre hay un cliente

que necesita tu trabajo, incluso si no lo ves. Hemos trabajado con
equipos que no pudieron nombrar a sus clientes o no pensaron en ellos,
pero siempre están ahí.
Si tiene dificultades para saber quiénes son, siga el dinero. ¿Quién
paga tus facturas? ¿En qué presupuesto trabajas y cómo obtiene esa persona su dinero?
Ese es tu cliente, y debes preocuparte por él.
El cliente es la razón por la que estás aquí. Y a los clientes no les importan los planes o las
estimaciones. Si, lo dijimos. ¿Cuándo fue la última vez que un cliente lo llamó por teléfono y le
dijo: "Gracias por las excelentes y precisas estimaciones y planes que hizo para el último proyecto"?
Exactamente: nunca. Eso nunca sucedió, y tampoco lo hará. El cliente quiere capacidades que
pueda usar para hacer negocios de una manera mejor, más rápida o nueva.
Usted sabe que "necesita" planes y estimaciones para poder hacer su trabajo o seguir
haciéndolo de manera consistente y precisa, pero finalmente no agrega valor a su producto.
Nuevamente, puede ejecutar una prueba de fuego en la forma de esta pregunta: “Si cree que estimar
es agregar valor, haga mucho más de eso. Está agregando valor, ¿verdad? "16
Dicho esto, siempre que vea valor en la planificación y la estimación, siga haciéndolo, pero
lo suficiente para mejorar el flujo de trabajo a través del equipo. Por ejemplo, puede aprender
mucho acerca de un elemento de trabajo cuando realiza una estimación, pero después de un tiempo
más de estimación no está descubriendo nuevos conocimientos, y luego no debe seguir haciéndolo.
Los planes no valen nada, pero la planificación lo es todo.
-Dwight D. Eisenhower
9.5.3 #NoEstimates: ¿podría prescindir de todo esto?

Por Torbjörn Gyllebring
Una forma de ilustrar más los puntos de la última sección proviene del movimiento Sin
estimaciones. Invitamos a nuestro buen amigo Torbjörn Gyllebring 17 a escribir sobre eso, porque
conoce bien el tema. Torbjörn, el escenario es tuyo.
Pocos se detienen para cuestionar la estimación y las estimaciones; más bien, la mayoría los
considera un regalo. Cuestionar esa suposición y encontrar formas de trabajar eficazmente sin ellas
es la pregunta central de #NoEstimates.
¿QUÉ ES #NOESTIMATES?
La idea es que, en muchos contextos, no solo es posible sino también beneficioso renunciar a la
estimación en favor de formas alternativas de gestionar el trabajo. Las siguientes son algunas
estrategias alternativas para resolver diferentes aspectos de los beneficios atribuidos a las
estimaciones.
16
David J. Anderson introdujo esta excelente forma de determinar si una actividad está agregando valor.
17
Conocido como @drunkcod en Twitter.
El estudio de la naturaleza y el tipo de demandas en el sistema permite el uso de pronósticos

probables y simulación para crear planes sólidos basados en datos históricos. Un pionero en este
campo es Troy Magennis, con su trabajo en la simulación de Monte Carlo.18
Otros llegan a un punto en el que no estiman, sino que confían en lo que he denominado The
Law of Average Averages. Esta ley establece que
En promedio, un elemento de trabajo promedio tardará un tiempo promedio en completarse.
La observación es que suponiendo que las solicitudes sean lo suficientemente similares, o que el
equipo haya aprendido a dividir instintivamente el trabajo en fragmentos "del tamaño correcto",
puede omitir la estimación y considerarlos todos como promedio. Algunos elementos tomarán más
tiempo, otros tomarán menos tiempo, pero con el tiempo las cosas se igualarán.
Suponga que trabaja en pequeños pedazos y que un alto grado de participación de los
interesados permite utilizar un modelo de financiación por goteo muy detallado. Empiezas a trabajar
en la dirección de "la próxima cosa más valiosa". Cuando el valor es realizado o descubres que estás
gastando más de lo que valdrá, dejas de invertir.
Esto requiere una habilidad perfeccionada para estar siempre en un estado entregable y
requiere abrazar la incertidumbre a un nivel bajo. La dirección y la visión de alto nivel se gestionan
mediante el rastreo de la inversión general.
También puede revertir la pregunta de estimación. En lugar de preguntar: "¿Cuánto tiempo
llevará completar todas estas cosas?" y esencialmente agregando un conjunto de conjeturas, puede
plantear una pregunta diferente y más poderosa: "Dado que estoy dispuesto a invertir tanto, ¿qué es
posible?"
POR QUÉ #NOESTIMATES
El impulsor de #NoEstimates es que la estimación puede generar un comportamiento disfuncional,
como las estimaciones que se convierten en compromisos, planes o plazos. Al diseñar la necesidad
de estimación, elimina estos problemas y su tiempo y costos de recursos asociados.
La estimación se vuelve problemática no porque las estimaciones sean intrínsecamente
malas, sino porque tienden a usarse para múltiples propósitos, y su propósito se transforma con el
tiempo a medida que los números asumen una vida propia. Trabajar sin estimaciones lo obliga a
pensar profundamente sobre las diferentes funciones que desempeñan las estimaciones en su
proceso, invitándolo a encontrar soluciones más enfocadas. La coordinación, el descubrimiento de
supuestos diferentes, la planificación a largo plazo, las decisiones de ir / no ir, y los costos pueden
resolverse de una manera que no enturbie las aguas. #NoEstimates es difícil y requiere disciplina y
habilidad, pero las oportunidades son excitantes.
FOMENTAR #NOESTIMATES LEYENDO
Te invitamos a unirte a nosotros y explorar el tema. Un buen punto de partida es la siguiente lista:
■ Siga la discusión en Twitter: busque #NoEstimates.
■ Lea la entrada de blog de Neil Killick “#NoEstimates Part 1 – Doing Scrum Without
Estimates,” http://mng.bz/7wvp.
18
http://en.wikipedia.org/wiki/Monte_Carlo_method.
Resumen 215
■ Lea la entrada de blog de Woody Zuill “If You Found Estimates Bring No Value – What
Would You Do?” http://mng.bz/3a85.
Gracias Torbjörn!, #NoEstimates es a la vez inspirador y estimulante. También es una excelente
manera de terminar nuestro capítulo sobre planificación y estimación: mirando hacia adelante y
desafiándonos a nosotros mismos para probar nuevas y mejores formas y nunca dejar de aprender.
9.6 Resumen
En este capítulo, hablamos sobre la planificación y la estimación:
■ Primero hablamos sobre cuándo planificar y diferentes enfoques para encontrar el
momento adecuado para planificar: no demasiado temprano ni demasiado tarde, justo a
tiempo:
■ Echamos un vistazo a la planificación basada en eventos y hablamos sobre los
puntos de pedido, una forma de ejecutar la planificación basada en eventos.
■ La planificación con mayor frecuencia involucra a las partes interesadas a su
alrededor y genera confianza, pero también puede ser costoso. Debe equilibrarlo para
planificar con la frecuencia correcta.
■ Usar los tiempos de espera de Disneyland es una forma de mostrar los tiempos de
entrega esperados.
■ Los planes y las estimaciones a menudo son solicitados por otras personas a su alrededor,
y hablamos brevemente sobre cómo extender el flujo de trabajo hacia arriba y hacia abajo.
■ Estimar en términos exactos es mucho más difícil que dar estimaciones relativas, por lo
que preferimos hacer estimaciones relativas:
■ Los Story points (Puntos de historia) y el T-shirt sizes (Tamaño de las camisetas)
son dos formas comunes de hacer estimaciones relativas.
■ Observamos un par de técnicas de estimación:
■ A line of cards (Una línea de cartas)
■ Planning Poker (Planificación de Póker)
■ Goldilocks (Ricitos de oro)
■ La cadencia es el ritmo o latido natural que se encuentra en su proceso. En los procesos
basados en iteraciones, hay cadencias naturales cuando las iteraciones comienzan y se
detienen.
■ Con kanban puede tener las cadencias que considere adecuadas para las actividades:
revisión, planificación, demostración y retrospectivas. No tiene que vincularlo con el flujo
de su trabajo.
■ Finalmente, retrocedimos y reflexionamos sobre la necesidad de planes y estimaciones:
■ Los equipos que usan kanban ven que la necesidad de planes detallados disminuye
con el endurecimiento de los circuitos de retroalimentación.
■ Los clientes no quieren planes y presupuestos; Quieren capacidades comerciales.
■ Calcular y hacer planes es útil siempre que descubra nueva información.
■ El movimiento #NoEstimates habla de abandonar las estimaciones por completo y
encontrar formas efectivas de trabajar sin estimaciones.
En el próximo capítulo, analizaremos las mejoras del proceso, que es cómo puede utilizar todas las
herramientas que hemos presentado hasta ahora para ayudarlo a mejorar continuamente.
10 La mejora de procesos

■ Mejora continua: el verdadero propósito de
kanban
■ Respeto por las personas: poner a las
personas primero
■ Retrospectivas, análisis de causa raíz y
Kanban Kata.
Como son las personas las que fabrican cosas, la fabricación es imposible a menos que las
personas estén desarrolladas.
—Visualización en el Museo de Tecnología de Toyota en Nagoya
"Desarrollar primero a las personas" es un principio fundamental en la filosofía de Toyota, y sus dos
partes, "respeto a las personas" y "mejora continua" (o kaizen), a menudo se conocen como los dos
pilares del sistema de gestión de The Toyota Way.
Esta filosofía de mejora es una mentalidad que se puede encontrar en todas las
organizaciones Lean como Toyota, desde el CEO y las estrategias generales hasta el personal de
limpieza y cómo las personas colocan sus herramientas en el banco de trabajo en orden para ser más
efectivas. Existe una aspiración profundamente arraigada de mejorar, perfeccionar y ser más
216
217
efectivos en el corazón y el alma de una organización Lean en funcionamiento. Es el respeto a las

personas (respetar, desarrollar y alentar a todos en la organización) lo que hace esto posible.
Con sus raíces en el pensamiento Lean, kanban tiene que ver con la mejora continua y el
respeto por las personas. Visualizar el trabajo es una manera fácil pero efectiva de permitir el
trabajo de mejora autoorganizada. Limitar WIP y ayudar a que el trabajo fluya hace que los cuellos
de botella y las oportunidades de mejora sean visibles para el equipo, permitiendo a los miembros
del equipo encontrar formas de mejorar.
¿Cómo está funcionando
todo ahora?
Genial, en realidad!
Hemos conseguido que
el nuevo límite WIP de
6 elementos funcione
para nosotros. El
trabajo fluye
suavemente, y es
agradable y fácil.
¡Excelente! ¿Por qué no

probar un límite WIP de
5 entonces?
¿Qué? ¿Por qué

deberíamos hacer eso?
Tendremos que
cambiar las cosas y
esforzarnos más para
que esto funcione.
… [Como silencio Zen]
Aah ... Veo. Así es

como mejoramos.
Desafortunadamente, kanban no resuelve los problemas por ti y no mejora las cosas

automáticamente. Kanban expone oportunidades de mejora, pero depende de usted descubrir cómo
mejorar. En este capítulo, veremos algunas prácticas diferentes que lo ayudarán con eso. No hay
mejor manera de comenzar este capítulo y llamar su atención que parafraseando a la exigente
entrenadora de baile Lydia Grant de Fame:
Tienes grandes sueños. Quieres mejorar. Bueno, costos de mejora. Y aquí es donde
empiezas a pagar: con sudor.1
—Lydia Grant, Fame
1
Ver www.imdb.com/title/tt0576603/quotes para ver la cita original.
218 CAPÍTULO 10 La mejora de procesos
10.1 Retrospectivas
La retrospectiva es una práctica importante en la mayoría de las metodologías ágiles. De hecho, uno
de los principios ágiles2 establece: "A intervalos regulares, el equipo reflexiona sobre cómo ser más
eficaz, luego afina y ajusta su comportamiento en consecuencia". En la reunión retrospectiva,
analiza su proceso y progreso durante el último período e intenta encontrar áreas en las que pueda
mejorar.
Las retrospectivas ágiles son un área grande, y ya se han escrito varios libros sobre el tema.
Esta sección no es en modo alguno un intento de proporcionar una cobertura completa del tema;
más bien, le mostrará cómo la práctica de retrospectivas puede ser puesta en acción en un entorno
kanban. Si desea obtener más información sobre muchas formas diferentes de ejecutar
retrospectivas y el pensamiento detrás de ellas, le recomendamos Agile Retrospectives de Esther
Derby and Diana Larsen (Pragmatic Bookshelf, 2006, http://pragprog.com/book/dlret/agile-
retrospectives) y The Retrospective Handbook de Patrick Kua (CreateSpace Independent
Publishing Platform, 2013, https://leanpub.com/the-retrospective-handbook). Ambos son geniales y
tienen un bonito toque práctico y pragmático.
10.1.1 ¿Qué es una retrospectiva?

Se ejecuta una retrospectiva del equipo a intervalos regulares, con la preferencia de hacerlos con
más frecuencia que rara vez. Por lo general, los equipos reservan unas pocas horas cada una o
cuatro semanas para retrospectivas. Esto puede verse como el equipo que invierte tiempo en
mejorar la forma en que trabajan juntos.
El fin de la retrospectiva es proponer algunas acciones de mejora (preferiblemente no más de
tres) que se puedan cambiar antes de la próxima retrospectiva. Esto garantiza que usted, como
equipo, realice la mayor cantidad de trabajo de mejora que pueda manejar. Estás haciendo pequeñas
mejoras a menudo. ("Limite su WIP", ¿recuerda?)
Una retrospectiva generalmente consta de cinco partes distintas: 3
1 Prepara el escenario. Este primer paso es cuando inicias la retrospectiva y preparas el
ambiente para la reunión. Una excelente manera de hacerlo puede ser informar a todos
acerca de la directiva principal retrospectiva (ver el siguiente cuadro) o utilizar algún tipo de
ejercicio para romper el hielo (ver la siguiente Palabra del Entrenador).
Independientemente de lo que descubramos,

entendemos y realmente creemos que todos
hicieron el mejor trabajo que pudieron, dado lo
que sabían en ese momento, sus habilidades y
capacidades, los recursos disponibles y la
situación en cuestión.
2
Verifica los principios en http://agilemanifesto.org/principles.html.
3
Del excelente libro, Agile Retrospectives (http://pragprog.com/book/dlret/agile-retrospectives).
Retrospectiva 219
UNA PALABRA DEL ENTRENADOR Un gran truco es utilizar

algún tipo de ejercicio que garantice que todos digan algo, aunque solo
sea una palabra como "sí" o "no". Por ejemplo, recorra la sala y
pregunte: "¿Está de acuerdo con la directiva principal retrospectiva?"
La investigación ha demostrado que si alguien dice algo al comienzo
de una reunión, existe una probabilidad mucho mayor de que vuelva a hablar más tarde en
la reunión.
2Recopilar datos. En esta etapa, el equipo mira hacia atrás (por lo tanto, de forma
retrospectiva) en el período anterior y recopila datos sobre lo que sucedió. Diferentes
ejercicios retrospectivos se centran en diferentes eventos, en diferentes estados de ánimo o
en el progreso del equipo, pero la idea principal es la misma: recopilar datos para el análisis.
3 Generar ideas. Aquí analiza los datos que recopiló para saber qué conclusiones puede
sacar de ellos. ¿Por qué estos eventos fueron tan mal como lo hicieron? Hay muchas
maneras diferentes de hacer esto: por ejemplo, análisis de causa raíz.
4 Decide qué hacer. El esfuerzo principal a continuación es encontrar un conjunto adecuado
de acciones que sepa que puede completar durante el período hasta la próxima retrospectiva,
que a menudo es un buen cronograma para las mejoras. Por lo general, es mejor elegir
menos acciones que más; más acciones corren el riesgo de terminar no siendo realizadas.
A veces puede que no tengas acciones que salgan de la retrospectiva. Tal vez el
equipo resolvió los problemas durante la retrospectiva, o tal vez tuvieron que sentarse y
hablar un rato. Esto también está bien.
5 Cierra la retrospectiva. Una buena práctica en este punto es hacer una mini-retrospectiva
de la retrospectiva.4 Puede ser tan simple como preguntar a las personas qué piensan acerca
de la forma de la retrospectiva y cómo se puede mejorar.
Para mantenerse enfocado, le sugerimos que fije la hora en la reunión, por ejemplo, una hora y que
también cronometre las diferentes partes de la retrospectiva.
10.1.2 ¿Cómo funciona?

El esquema que acabamos de describir es bastante genérico y no le dice mucho sobre qué hacer
durante una retrospectiva. Hay muchas maneras diferentes de hacer esto, y a menudo mezclamos
diferentes enfoques para mantener al equipo alerta y evitar que las retrospectivas se vuelvan
aburridas. Un buen consejo es invitar a alguien de otro equipo para facilitarle la retrospectiva; eso le
brinda nuevas formas de ejecutar retrospectivas, y alguien que no está involucrado con el equipo
puede ser neutral, enfocándose en la facilitación de la retrospectiva sin sentir la necesidad de
participar.
Puede encontrar muchos buenos ejercicios y planes completos para retrospectivas en línea.
Aquí hay dos sitios que hemos encontrado útiles:
■ Agile Retrospective Resource Wiki, http://retrospectivewiki.org
■ Gamestorming, www.gogamestorm.com
4
Pero no haga una retrospectiva de la mini-retrospectiva en la retrospectiva, porque entonces podría verse atraído a un
ciclo recursivo de retrospectivas que terminan en el inicio del universo.
En las siguientes secciones encontrará una retrospectiva básica que creemos que es una buena
representación de cómo se puede ejecutar una retrospectiva.
PREPARAR EL ESCENARIO
1 Comience mostrando o leyendo la directiva principal retrospectiva, y pregunte a las
personas que asisten a la retrospectiva si pueden adherirse a esto para esta retrospectiva. Si
todos no están de acuerdo, debe subrayar que el objetivo de la retrospectiva es encontrar
mejoras, no terminar en un juego de culpa.
2 Recopilar datos. Pídale al equipo que escriba todas las cosas maravillosas que han
sucedido durante el período desde la última retrospectiva:
■ Indíqueles que escriban cada cosa en una etiqueta adhesiva separada.
■ Permita de tres a cuatro minutos (use un temporizador) para hacer una lluvia de
ideas. Cuando el equipo haya terminado, pídales que publiquen los elementos en
parte de una pizarra en el orden que deseen.
3 Haga lo mismo nuevamente, pero esta vez, escriba las cosas que desea mejorar. Recuerde
al equipo su enfoque: no desea encontrar personas malas, sino más bien oportunidades de
mejora que aún no se han dado cuenta. Siga las mismas instrucciones que antes.
4 A menudo habrá muchas ideas similares; solicite al equipo que los agrupe para identificar
temas comunes. Si lo desea, puede hacer que lo hagan en silencio. 5 Eso pone de manifiesto
un tipo diferente de dinámica en el grupo y, a menudo, es bastante rápido. Esto debe hacerse
en unos minutos.
5 Haga el ejercicio una vez más, pero esta vez concéntrese en un futuro ideal. Tu puedes
decir. "Si tuvieras una varita mágica y pudieras hacer cualquier cosa, ¿cómo sería tu
situación en la próxima retrospectiva?" Use los mismos patrones que para los elementos
buenos y malos.
GENERAR IDEAS
1 Ahora debe tener muchas ideas de cosas buenas que han sucedido y algunas áreas en las
que el equipo puede mejorar o con las que le gustaría experimentar para mejorar. Esta suele
ser una buena base para una discusión.
2 Pídale al equipo que vote por una o dos (tal vez incluso tres) cosas que les gustaría cambiar
durante el próximo período.
3 Decide qué hacer. Durante la discusión, ayude al equipo a centrarse en las cosas que tienen
posibilidades de implementarse durante el próximo período y que tienen un resultado
concreto.
5
Por supuesto, puedes hablar si no puedes leer las notas adhesivas. La parte del silencio hace que todos sean
iguales, ya que cualquiera puede moverse a un adhesivo sin ser interrumpido. Esté atento a las notas adhesivas
que se mueven mucho de un lado a otro, porque esas son cosas que la gente no está de acuerdo sobre cómo
agrupar. Puede ser interesante discutirlos por separado o dividir los adhesivos en dos partes.
Retrospectiva 221
Podría, por ejemplo, preguntarles: "¿Cómo saber cuándo se hace eso?" Usar las metas
SMART6 para sus acciones de mejora es otra buena práctica.
Asegúrese de reservar una buena parte del tiempo retrospectivo para esto, ya que esta
suele ser una discusión importante (y con suerte fructífera). Permita al menos 15 minutos, si
está ejecutando un timebox de una hora (el 25% de su tiempo, en otras palabras).
4 Cierra la retrospectiva. Pídale al equipo que vote con un "puño de cinco" sobre lo que
pensaron acerca de la retrospectiva. A la cuenta de tres, cada persona levanta el número de
dedos correspondiente a su calificación de la retrospectiva: uno es peor, cinco es mejor.
5 Pídales que escriban una cosa que se pueda mejorar antes de la próxima retrospectiva y
publiquen esa etiqueta adhesiva en la puerta al salir.
6 Gracias por su participación.
Estas instrucciones deben verse como un punto de partida. Puede profundizar en esto utilizando
otras formas de retrospectivas cuando vea la necesidad: por ejemplo, abordar un área específica o
mezclarla un poco.
¿CUÁNDO DEBE EJECUTAR LAS RETROSPECTIVAS?

Para los métodos que están enfocados en la iteración (Scrum, por ejemplo), la retrospectiva se
produce naturalmente al final del sprint o iteración. Muchos equipos que usan kanban utilizan un
enfoque basado en el flujo, y no hay un "final de iteración" en su proceso. Nuestra sugerencia es
que elija una cadencia adecuada (consulte el capítulo 9) para su equipo. Una sugerencia podría ser
tener retrospectivas cada dos semanas y mantenerlas en una hora. A medida que comienza a
acostumbrarse a hacer retrospectivas, puede experimentar con la cadencia adecuada para su equipo.
Retrospectivas
* Aprender de su proceso para mejorar el proceso
* Pasos sugeridos
- Preparar el escenario
- Reunir datos
- Generar ideas
- Decide qué hacer
- Cerrar la retrospectiva
* Prefiere pequeñas mejoras concretas a menudo en lugar de grandes rara vez
6
SMART (Specific, Measurable, Attainable, Relevant, and Time-bound) es un acrónimo que significa metas
específicas, medibles, alcanzables, relevantes y con plazos determinados. Esto asegura que termines con una meta muy
claramente expresada, y en las discusiones también aclararás malentendidos y malas interpretaciones de la meta.
Una retrospectiva puede ayudarlo a encontrar un par de puntos de mejora que desea implementar.
Para comprender por qué esto es importante o dónde radica la raíz del problema, puede hacer un
análisis de causa raíz, el tema de la siguiente sección.
10.2 Análisis de causa raíz

... en resumen:
¡necesitamos más
probadores!
¿Estás seguro de que ese

es el verdadero problema?
¿Por qué necesitas más
probadores?
¡Venga! Estoy solo. Hay

dos desarrolladores. Por
supuesto que necesitamos
más probadores.
Sí, pero ¿POR QUÉ los

necesitas? ¿Cuál es el
verdadero problema?
¿Cuántas veces vas a

preguntar por qué?
Imagine que está trabajando en un equipo y que últimamente han aparecido muchos errores. Tiene
métricas establecidas y ve que las tendencias son claras: la cantidad de defectos ha aumentado y el
tiempo total de entrega ha aumentado bastante. El equipo ha decidido hacer algo sobre esta
tendencia. Quieren tener menos defectos y tiempos de entrega más cortos.
¿Qué haces? ¿Dónde deberías comenzar? ¿Cuál es el problema en cuestión? ¿Deberías
decirle a los desarrolladores que deberían actuar juntos? ¿Se ha degenerado la calidad de las
especificaciones? ¿Los probadores no están alerta? ¿Necesita más probadores para mantener la
calidad bajo control? Todos están haciendo lo mejor que pueden, ¿verdad?
El análisis de causa raíz es un enfoque estructurado para razonar en torno a un problema
para que llegue al fondo del asunto: la razón real y subyacente por la que ocurre el problema. La
idea es que no sirve de nada corregir los síntomas sin buscar también la causa raíz, porque eso solo
hará que los mismos síntomas o similares resurjan en otro lugar más adelante. Desea solucionar el
problema real,7 para asegurarse de que no vuelva a suceder y que todos los problemas que siguen
desaparezcan.
7
"El problema, el problema real, y nada más que el problema, así que ayúdame Dios", si quieres.
Análisis de raíz de la causa 223
También es posible que haya oído hablar de los cinco porqués. El análisis de causa raíz se basa en el
mismo pensamiento. Sigues preguntando "¿Por qué?" hasta que llegue a la causa raíz del problema.
Por extraño que parezca, los equipos suelen enfrentar el problema real después de cinco preguntas y
respuestas de "¿Por qué?"; de ahí los cinco en los cinco por qués. Veamos eso en acción.
10.2.1 Cómo funciona

El análisis de causa raíz se puede utilizar para resolver problemas en todos los niveles, tanto
grandes como pequeños. Puede hacer preguntas para encontrar la causa raíz (los cinco porqués) o, si
es un problema más complicado, realizar un taller. Si lleva a cabo un taller, le sugerimos que tenga
todas las personas en la sala que cree que podrían ayudarlo a encontrar la causa raíz. Mantenga el
horario del taller para centrarse en las preguntas y debates importantes, y no se desvíe del tema.
Decida la hora de inicio y finalización del taller, y diga a todos los asistentes que el objetivo del
taller es encontrar la causa raíz del problema en cuestión.
¿POR QUÉ NECESITAMOS ARREGLAR ESTO?

Comience escribiendo el problema que está discutiendo en una nota adhesiva y publíquelo en el
medio de una pizarra. La primera parte del análisis de causa raíz es encontrar las consecuencias de
no solucionar este problema. Esto se hace para obtener una comprensión más profunda de por qué
es importante solucionar el problema:
1 A partir del "adhesivo del problema", pregunte "¿Y qué?" para generar ideas.
2 Publique cada idea nueva en la pizarra y continúe hacia arriba hasta que las preguntas "¿Y
qué?" ya no tengan sentido.
3 Probablemente generará varios caminos o ramas de ideas diferentes. Siga cada rama y siga
preguntando "¿Y qué?" siguiendo el razonamiento en cada rama.
4 Indique cómo se relacionan las notas adhesivas entre sí dibujando líneas y flechas entre
ellas.
Aquí hay un ejemplo de diálogo:

Marcus: Tenemos muchos errores; ¿Y qué?
Daphne: Bueno, eso le quita tiempo al
desarrollo de nuevas funciones.
Beth: Sí, y también hará que nuestro
producto se vea mal.
Marcus: Ok, nuestro producto se ve mal; ¿a

quien le importa?
Beth: ¿Estás loco? Podemos perder usuarios.
Adam: Y el puntaje neto del promotor, NPS,
baja.
Marcus: ¿Qué pasa con el NPS? ¿Por qué es

tan malo?
Beth: Bueno, eso es lo que están mirando
nuestros inversores. De hecho, también se
preocupan por la cantidad de usuarios.
Marcus: ¿Por qué es malo molestar a los

inversores?
Beth: pueden recortar las inversiones y, en
última instancia, detener el desarrollo del
producto. Es por eso.
Marcus: ¿Y qué? A quién le importa ...
Daphne: Marcus, vamos ... creo que hemos
llegado al final del camino para este. Es
malo. Terminamos desempleados, ¿de
acuerdo?
Marcus: tienes razón. Volvamos al

hecho de que los errores le quitan
tiempo al desarrollo de nuevas
funciones. ¿Por qué es tan malo,
entonces?
Daphne: Significa que no podemos
crear nuevas funciones. No hay cosas
nuevas agregadas a nuestro producto.
Marcus: ¿Y qué?
Daphne: Bueno, eso también nos
haría perder usuarios.
Beth: Pero eso también significa que

hay una oportunidad para que nuestra
competencia se ponga al día.
Como puede ver, el equipo rápidamente descubrió las razones por las cuales es importante observar
este tema y aprendió mucho sobre el problema en el proceso. Utilizando el enfoque descrito aquí,
ahora han alcanzado uno o más nodos superiores del árbol. Ahora saben el impacto de no hacer
nada sobre este problema. Trabajemos ahora hacia la raíz del mal para descubrir cuál es la
verdadera razón del problema.
ENCONTRANDO LA CAUSA RAÍZ DEL PROBLEMA

La segunda parte es profundizar en la causa raíz haciendo preguntas de los "¿Por qué?". Al igual
que con las preguntas "¿Y qué?", comienza a partir del enunciado del problema y crea notas
adhesivas para cada respuesta a las preguntas "¿Por qué?".
Aquí también terminarás con muchas ramas, pero sigue

cavando profundamente. Recuerde dibujar flechas y líneas
que muestren cómo se relacionan los adhesivos entre sí.
Puede encontrar que crea un círculo de referencias, de
modo que se crea un bucle. Estos son lugares especiales que
requieren su atención: se denominan bucles autoejecutables.
Estas son cosas que presentan el riesgo de crear un círculo
vicioso de cosas que se siguen alimentando mutuamente. 8
Haga un círculo alrededor de esos bucles o haga que se
destaquen de alguna manera, para que recuerde hacer algo al
respecto.
Aquí hay un ejemplo del equipo que busca la causa raíz:
Joakim: Tenemos muchos errores; ¿por qué?

Adam: Hemos estado bajo mucha presión de tiempo. Es
entregar, entregar, entregar.
Daphne: Ya no hacemos ningún trabajo técnico.
Eric: Hemos detenido la programación de pares.
Joakim: Ok, ¿por qué no hacemos ningún trabajo

técnico?
Adam: Debido a la presión del tiempo.
Eric: Y lo mismo ocurre con la programación en pareja.
La gente piensa que lleva más tiempo.
Joakim: Eso es lo que llamamos un bucle autoejecutable.
Indiquemos aquellos con flechas rojas.
Joakim: Entonces, ¿por qué ha estado presionando el

tiempo?
Adam: Bueno, es el lanzamiento de mayo que viene ...
Joakim: ¿Por qué tenemos una presión de tiempo para
entregar eso?
8
Por ejemplo, estamos estresados, por lo que tomamos atajos y, por lo tanto, comenzamos a reducir la calidad, lo que
nos estresa más, obligándonos a tomar más atajos, reduciendo la calidad. Eso a su vez nos estresa y nos obliga a ...
¿Qué? Ah, lo tienes. OK. Me detendré ahora. Es un círculo, es difícil saber si ya estás allí.
Adam: No pudimos decidir qué entró en la

cartera de pedidos de lanzamiento de mayo.
Eso creó una cartera de pedidos mucho más
grande de lo que pudimos manejar.
Joakim: ¿Por qué no teníamos nada que decir al

respecto, entonces? "
Eric: ¿Porque a Ventas no le importó
preguntarnos?
Daphne: No, eso no es cierto. Nos preguntaron,
pero no se nos permitió tomar tiempo fuera del
desarrollo en el lanzamiento de febrero,
recuerden ...
Joakim: OK, entonces esa es otra forma en que
la presión sobre la entrega nos está
obstaculizando. Otro bucle autoejecutable.
Como probablemente verá en ese diálogo, el análisis de la causa raíz es una herramienta afilada que
corta rápidamente la raíz del problema y el impacto comercial. Esto podría plantear algunas
preguntas importantes, así que asegúrese de tener una atmósfera de resolución de problemas en
lugar de culpar a la sala. Recordar a las personas sobre la meta del taller antes de comenzar y que
desea encontrar "oportunidades de mejora no realizadas" en su proceso y no personas que han
fallado podría ser una forma.
Análisis de raíz de la causa

* Los cinco por qués
* Encontrar la verdadera razón para resolver
el problema real
* Encuentra el impacto de un problema
* Encuentre la verdadera causa del problema
* Ejercicios visuales y cooperativos.
10.3 Kanban Kata

Creo que deberíamos fijar
ese paso de compilación que
sigue fallando. En este
momento no podemos lanzar
nada a ninguno de nuestros
entornos.
Ahora espera un minuto

aquí ... Tenemos una
retrospectiva en una
semana. Recuerda
mencionarlo en ese
momento y veremos si es
allí donde enfocaremos
nuestros esfuerzos de
mejora.
Las retrospectivas son excelentes porque permiten un tiempo fuera de su flujo normal para mejorar
su proceso. En su trabajo normal, también puede trabajar en mejoras, como pequeñas cosas que
puede arreglar de inmediato (arreglando ese paso en el proceso de compilación que a menudo falla)
o pasos hacia una meta más grande (reducir el tiempo promedio de entrega de sus elementos de
trabajo).
Kanban Kata es otra forma de implementar mejoras de procesos. Kanban Kata es una serie
de preguntas y formularios que lo ayudan a mejorar en pequeños pasos, en un flujo continuo, para
que el trabajo de mejora y el trabajo ordinario se mezclen. Es una excelente manera de obtener un
proceso en torno a las mejoras continuas en su equipo, promovido por nuestro buen amigo Håkan
Forss.9 Nos gusta Kanban Kata porque está en la línea de la mejora continua, inspirada en la forma
9
Visítelo en @hakanforss en Twitter y en http://hakanforss.wordpress.com.
en que Toyota lo hace, haciendo que las mejoras del proceso sean una parte integral del trabajo
normal. También complementa las retrospectivas normales de una manera agradable para los
equipos kanban.
Kata? Toyota Kata?

La extraña palabra kata se usa comúnmente en artes marciales. Se refiere a la práctica de hacer un
conjunto de movimientos predefinidos para crear una memoria muscular de los movimientos.
Intenta hacer que los movimientos sean lo más exactos y precisos posibles, y practicarlos una y
otra vez, luchando por la perfección. La idea es que cuando finalmente te encuentres en una
situación de combate real, estos movimientos básicos estén en la memoria muscular para que no
tengas que pensar en cómo hacerlos.
El paso de las artes marciales a las mejoras de procesos puede parecer grande y empinado, pero
todo tiene que ver con un libro llamado Toyota Kata de Mike Rother (McGraw-Hill, 2009,
http://amzn.com/0071635238). En este libro, el autor describe cómo Toyota ha implementado las
ideas de mejora continua en la práctica. Toyota Kata no es nada de lo que Toyota habla acerca de si
mismo, sino que es la forma en que el autor describe las prácticas que ha observado en su
investigación y estudios de Toyota.
Håkan Forss aplicó las ideas del libro Toyota Kata a kanban para el desarrollo de software y lo
llamó Kanban Kata.
Un kata, una serie de preguntas precisas que sigue hasta cierto punto, puede parecer artificial al
principio, pero recuerde que un kata es una serie de pasos predefinidos que debe seguir para que se
conviertan en memoria muscular. Un kata está escrito de cierta manera para que finalmente te
entrene a hacer lo correcto sin pensar. En este caso, el kata te entrena en la mejora del proceso.
10.3.1 ¿Qué es Kanban Kata?

La forma más fácil de presentar Kanban Kata, ahora que conoce el origen, es a través de un
ejemplo. En esta sección, presentaremos los tres katas, o diálogos de mejora, que componen Kanban
Kata:
■ Daily Kata: una forma de comenzar a incluir el trabajo de mejora en sus reuniones diarias
■ Improvement Kata: una manera formal de mejorar su proceso
■ Coaching Kata: se enfoca en mejorar a los alumnos (las personas en el equipo): una
técnica de entrenamiento
En el mundo imaginario donde residen los Kanbaneros, hemos enviado a Håkan al equipo durante
un par de días, y verás cómo han cambiado su forma de atajar las mejoras y el trabajo diario. Håkan
ha introducido a todo el equipo a Kanban Kata y le ha dado a Frank (el líder del equipo) algunas
horas adicionales de introducción.
KATA DIARIO
Te unes al equipo y a Håkan10 en el tablero para una reunión matutina que Frank ha comenzado:
"Muy bien chicos, ¿qué estamos tratando de lograr?" Frank preguntó, mirando al equipo.
"Nuestro objetivo es tener el código listo para su lanzamiento todos los miércoles; eso es
mañana ", dijo Daphne.
Frank bajó la mirada hacia una pequeña tarjeta que sostenía
en la mano. Levantó la vista de nuevo y continuó: "¿Dónde
5 preguntas para reuniones diarias
estamos ahora?"
"Existe el riesgo de que no podamos lanzar mañana", dijo
1. ¿Qué estamos tratando de lograr?
Adam, un poco decepcionado. 2. ¿Dónde estamos ahora?
"¿Qué obstáculos hay en nuestro camino ahora?" Frank 3. ¿Qué obstáculos hay en nuestro
preguntó. camino ahora?
"Tenemos los elementos de trabajo 22 y 33 registrados sin 4. ¿Cuál es nuestro próximo paso y qué
problemas", dijo Eric. "Hay un par de problemas que ponen esperamos?
en peligro el lanzamiento", dijo Adam. 5. ¿Cuándo podemos ver lo que hemos
"¿Qué son?" Frank preguntó. aprendido al dar ese paso?
10
Utilizamos un avatar de LEGO ® para representar a Håkan. Esto nos parece muy apropiado porque Håkan no solo es
un gran fanático de LEGO®, sino que también ha utilizado elementos de LEGO® en sus presentaciones de una manera
muy efectiva y entretenida. Y podemos desmontarlo si comienza a quejarse de cómo describimos a Kanban Kata.
"En este momento no podemos construir la rama maestra. Hay algunos problemas de fusión desagradables
que deben resolverse", dijo Daphne, cerrando el puño en un movimiento de retorceré- ese-problema-en-un-
segundo.
"¿Cuál es nuestro próximo paso y qué esperamos?" Frank continuó.
"Estoy investigando los errores de compilación de la rama maestra en este momento", dijo Daphne.
"Con la ayuda de Eric, esperamos encontrar el problema pronto". "¿Cuál es nuestro próximo paso y qué
esperamos?" Frank continuó.
"¿Cuándo podemos ver lo que hemos aprendido al dar ese paso?" Frank preguntó.
"Probablemente encontraremos una solución en una o dos horas". Daphne miró a Eric, quien asintió
con la cabeza.
"Muy bien, reunámonos aquí antes del almuerzo". Frank miró su reloj. Él continuó: "¿Hay algo que
impida el flujo en este momento?"
"Sí", comenzó Adam, mientras señalaba el adhesivo rojo para la historia 46, "tenemos algunas
preguntas con respecto a las reglas de negocios. Nos impiden terminar las especificaciones y las
especificaciones de prueba, y el desarrollo también estará esperando”.
"Muy bien, ¿cuál es nuestro próximo paso y qué esperamos?" Frank preguntó.
“Tenemos una reunión reservada con César y Beth para las 2:00 PM de hoy. Esperamos que esa
reunión lo aclare ”, dijo Adam.
"¿Cuándo podemos ver lo que hemos aprendido al dar ese paso?" Frank preguntó de nuevo.
"Podemos compartir lo que aprendimos en la reunión de mañana por la mañana", respondió Adam.
"Excelente. Asegúrese de agregar la fecha de resuelto al adhesivo bloquedor cuando se resuelva".
"¿Algo más que impide el flujo en este momento?" Frank los instó a seguir.
Hubo algunos murmullos en el grupo, pero nadie tuvo nada más que los detuviera. Frank cerró la reunión
con un alegre: "Muy bien, gente, dejen de comenzar y comiencen a terminar". Todos miraron a Joakim, que
estaba parado en la parte de atrás, y luego se echaron a reír de Frank usando esa declaración de una manera
tan alegre.
MEJORA Y ENTRENAMIENTO KATA

Cuando el grupo se disolvió, Frank se acercó a Håkan y le preguntó: "¿Lo hice bien?"
“Sí, eso fue genial. ¿Cuál fue la mayor diferencia con tus paradas diarias normales? Håkan
preguntó.
“Bueno, probablemente el enfoque en el aprendizaje y eso lo subrayé dando pequeños pasos.
También creo que la parte de "qué esperas" nos hizo pensar en lo que hicimos antes de comenzar, en el buen
sentido", dijo Frank.
“Sí, eso fue lo que escuché también. ¡Buen trabajo!" Håkan dijo. "¿Deberíamos pasar al siguiente
kata, entonces?"
"Por supuesto, sensei", dijo Frank y guiñó un ojo. Volvieron al tablero y Håkan comenzó
preguntando: "¿Cuál es la condición target?"
"Todavía estamos trabajando con nuestra meta a largo plazo de reducir los tiempos de entrega de
todos nuestros elementos de trabajo, como decidimos hace un mes. Nuestra hipótesis es que se puede lograr
con la misma cantidad de personas que tenemos hoy en el equipo". Frank continuó: "Estamos reduciendo el
tiempo de espera en el tablero a cinco días, para los elementos clasificados como medios".
"¿Cuál es la condición ahora?" Håkan preguntó.
"Estamos llegando allí; al menos, se siente mucho más cerca ahora ”, dijo Frank.
¿En qué basas eso? ¿Me puede mostrar algunos datos? Håkan preguntó.
"Claro, aquí está nuestro gráfico de ejecución de
elementos de trabajo para los tiempos de entrega".
Frank señaló un cuadro al lado del tablero.
"¿Puedes explicarme lo que ves?" Håkan
preguntó.
“Sí: en este diagrama hemos rastreado los
tiempos de entrega de los elementos de trabajo de
tamaño mediano. Podemos ver que para los últimos
elementos estamos cerca de cinco días, nuestra
condición target", dijo Frank.
"¿Cuál fue tu último paso?" Håkan preguntó,
después de entregar la tarjeta de cinco preguntas de
entrenamiento (que se muestra más adelante en esta sección).
Frank agarró un formulario de registro de ciclos Plan-Do-Check-Act (PDCA) 11 y señaló la
fila de la última sesión de entrenamiento.12
11
Se puede utilizar un formulario de registro de ciclos PDCA para realizar un seguimiento de sus decisiones y progresar
a través del trabajo de mejora.
12
Los formularios y tarjetas de esta sección están tomados de The Improvement Kata Handbook, Copyright © 2013 de
Mike Rother, todos los derechos reservados. Emitido bajo la licencia Creative Commons. Puede descargar el suyo aquí:
http://mng.bz/Kweb.
"Para documentar el proceso de configuración de prueba".

"¿Que pasó?" Håkan le preguntó.
"Bueno ... pasamos por una configuración de prueba normal y documentamos todo lo que
hicimos", dijo Frank, un poco inseguro.
Håkan asintió con la cabeza antes de preguntar: "¿Qué aprendiste?"
"Fue bastante fácil ver una serie de pasos en el proceso de configuración de la prueba que
podrían automatizarse, si no todos", dijo Frank.
"¿Qué obstáculos te impiden ahora alcanzar la condición target?" Håkan preguntó.
"Hay una serie de problemas, y en este momento ...", dijo Frank, y luego enumeró los
obstáculos para Håkan.
"¿A cuál te diriges ahora?" Håkan preguntó.
"El tiempo de configuración de la prueba", dijo Frank.
"¿Cual es tu siguiente paso?"
"Hoy comenzamos a automatizar la configuración de prueba completa", dijo Frank con
orgullo.
"¿Esperas terminar con eso la próxima vez que nos veamos?" Håkan preguntó a escondidas.
Frank sonrió al recordarlo. "Se prefieren los pasos más pequeños que podemos terminar en
poco tiempo ... ¿verdad, sensei?"
"Si." Håkan sonrió.
“Bueno, probablemente podríamos comenzar a automatizar la carga de los datos de prueba.
Esa es bastante fácil ".
"Suena razonable. ¿Qué esperas al dar ese paso?
"Bueno, al menos el 80% del tiempo dedicado a configurar la base de datos debe reducirse",
respondió Frank.
"¿Y qué tiempo sería?" Håkan preguntó.
Frank hizo algunos cálculos en su cabeza y luego dijo: "Eso sería de cuatro a cinco minutos,
al menos".
"Bueno. Queremos ser lo más precisos posible ”, explicó Håkan. "Cuando somos más
precisos, está claro si hemos alcanzado el resultado esperado o no. La parte importante no es
alcanzar el resultado esperado, sino que podemos aprender comparando el resultado con lo que
esperábamos lograr. El kata se trata de aprender para que podamos mejorar en pequeños pasos una y
otra vez. Volviendo al kata", dijo Håkan," ¿cuándo podemos ir a ver qué hemos aprendido al dar ese
paso?"
"Esperamos hacerlo al final de la semana".
"Excelente. Volvamos a encontrarnos aquí el viernes a las 10:00", dijo Håkan, mientras
terminaban la sesión de entrenamiento.
Håkan y Frank se dirigieron a la máquina de café y siguieron hablando sobre la configuración de la
prueba. El trabajo de mejora estaba en marcha y parecía que tenían un buen control sobre el
proceso. ¡Eso requiere café!
10.3.2 ¿Qué pasó?

En este ejemplo, viste tres katas en uso: el Daily Kata, el Improvement Kata y el Coaching Kata. Se
podía ver la forma bastante estricta en la que tanto Frank (en el Daily Kata) como Håkan (en el Kata
Coaching) usaban un conjunto de preguntas predefinidas, conocidas como las Cinco Preguntas.13
Si cree que la forma en que se formulan estos katas (preguntas y formularios) no es
adecuada para usted y su equipo, entonces puede formular la suya propia. Pero las preguntas deben
seguirse al pie de la letra, como lo habría hecho con las sugeridas aquí. La repetición es la clave
para hacerlo perfecto.
La repetición es la madre de todo conocimiento. Ahora haz la tarea de nuevo.
—Lennart Wistedt, maestra de matemáticas de cuarto a octavo grado de Marcus
¿También notó el enfoque en aprender y dar pequeños pasos? Por cada pequeño paso que dio el
equipo, primero se les pidió el resultado esperado. Luego se les preguntó qué aprendieron de lo que
sucedió. Ese es el método científico en juego: desarrollar una hipótesis, hacer una predicción de lo
que sucederá, realizar un experimento, observar los datos y reflexionar sobre la diferencia entre la
predicción y lo que sucedió.
10.3.3 ¿Por qué funciona esto?

Kanban Kata pone un fuerte enfoque en el aprendizaje de manera estructurada. Consiste en tres
katas, o rutinas, si lo desea, que se basan en el método científico. Lo bueno de usar el método
científico es que ningún resultado es malo; es solo un resultado. Utilizará el resultado para aprender
y mejorar su próxima hipótesis.
No existe un experimento fallido, solo experimentos con resultados inesperados.
—R. Buckminster Fuller
13
Usado bajo Creative Commons; ver http://mng.bz/Kweb.
El siguiente secreto de por qué

funciona Kanban Kata es que da
pequeños pasos. Estás intentando
mejorar tu condición actual hacia
una condición target mejorada. El
camino hacia el target es
desconocido, y la mejor manera de
navegarlo es en pequeños pasos.
Estos pasos son los experimentos
que está realizando en función de
su hipótesis.
Eso nos devuelve a los resultados de los experimentos y al hecho de que solo son eso:
resultados. Incluso cometer errores o tomar turnos incorrectos está bien, siempre y cuando aprenda
y mejore desde allí. Pasar de su condición actual al target que se ha establecido significa atravesar
un territorio poco claro. Es probable que tome algunos giros incorrectos, pero está bien, siempre que
sean pequeños pasos y pueda corregir su orientación en el camino hacia el challenge (desafío) para
cumplir su visión.
En Kanban Kata, estás usando rutinas (mira las preguntas que Håkan estaba usando
anteriormente) que te guían a través de los diferentes katas. Le ayudan a crear nuevos hábitos, una
nueva mentalidad de aprendizaje continuo y mejora. Ahí es donde el beneficio real es usar Kanban
Kata: crear hábitos, una mentalidad, en toda la organización, de hacer pequeñas, pequeñas mejoras,
todos los días.
Kanban Kata
* Mejora continua a través de un conjunto de preguntas predefinidas
* Basado en el método científico.
* Apunte a su visión y dé pequeños pasos para acercarse
* Hablamos de tres katas:
- Kata Diario: concéntrate en tus actividades diarias
- Kata de Mejora: concéntrese en las mejoras en su proceso
- Kata de Entrenador: mejora de los alumnos
10.4 Resumen
Este capítulo habló sobre la mejora de procesos y las prácticas comunes de mejora:
■ La mejora continua y el respeto por las personas son fundamentales para Kanban.
■ Kanban te ayuda a descubrir oportunidades de mejora.
Luego dirigimos nuestra atención a un par de prácticas comunes para mejorar:
■ Una retrospectiva es una forma para que un equipo mire hacia atrás en su proceso y vea
cómo puede mejorarlo.
■ El análisis de causa raíz es una herramienta que lo ayuda a encontrar el problema raíz para
que no solo corrija el síntoma.
■ El análisis de causa raíz también lo guía para ver por qué vale la pena resolver el
problema. Kanban Kata es una herramienta de mejora continua que se basa en cómo Toyota
realiza mejoras.
■ Hay tres katas dentro de Kanban Kata:
■ Kata Diario: incluye el trabajo de mejora en su trabajo diario
■ Kata de Mejora: una forma formal de mejorar su proceso
■ Kata de Entrenador: mejora de los alumnos
■ El "kata" en Kanban Kata indica que usted sigue una forma establecida de trabajar hacia
una meta, hasta que la rutina se convierte en una segunda naturaleza y las mejoras se
convierten en la forma en que normalmente trabaja.
En el próximo capítulo, veremos cómo las métricas pueden ayudarlo a saber si está mejorando o no.
11 Uso de métricas para guiar
mejoras

■ Métricas y cómo pueden ayudarlo a mejorar
■ Algunas métricas y visualizaciones comunes
utilizadas por los equipos kanban
■ Cómo encontrar buenas métricas para tu equipo
El Capítulo 10 habló mucho sobre las mejoras y comenzó a hacer cambios en su proceso para
intentar mejorar. Nos gusta pensar que se trata de experimentos que aún no ha validado, porque
realmente no puede saber de antemano si está mejorando o no. Al realizar estos experimentos,
necesita alguna forma de saber si mejoran su proceso. Para saber eso, debe medir cómo funciona su
trabajo. Existe una comunidad sólida en torno a las métricas para los equipos que usan kanban y
Lean. En este capítulo, le mostraremos un par de métricas de uso común y discutiremos lo que
puede aprender y mejorar al usarlas.
Como con la mayoría de las cosas en kanban, desea visualizar las métricas para saber qué está
sucediendo. Le presentaremos un par de visualizaciones y diagramas comunes. Y le mostraremos
cómo crear los diagramas a partir de los datos de su flujo de trabajo y cómo interpretarlos para ver
qué sucede en su proceso.
237
238 CAPÍTULO 11 Uso de métricas para guiar mejoras
¡Esto se siente genial!

Hemos redirigido
algunos de los
trabajos no probados
de Adam. Pensamos
que la prueba era el
cuello de botella, por
lo que ahora tenemos
un mejor flujo.
Suena impresionante.
Pero, ¿cómo sabes
que has mejorado el
flujo?
Eeeh ... se siente más

rápido?
Vamos a reunir
algunas métricas y
visualizarlas.
Entonces lo
sabremos.
Vamos a sumergirnos y hablar sobre algunas métricas comunes que los equipos que usan kanban y
Lean a menudo encuentran útiles.
11.1 Métricas comunes

Esta sección analiza algunas métricas comunes que puede capturar fácilmente mediante el uso de un
flujo de trabajo visualizado en un tablero, como las que hemos utilizado hasta ahora en el libro. Esto
le dará una buena indicación de cómo está funcionando su proceso para usted, qué tan rápido está
moviendo las cosas de la idea a la producción, y más.
UNA PALABRA DEL ENTRENADOR Recuerde incluir siempre al
equipo en el proceso de decidir sobre una métrica para que puedan
opinar sobre cuál es una buena métrica para ellos. Estas son meras
sugerencias para iniciar su discusión. También recuerde mezclar estas
métricas relacionadas con el "proceso" con métricas que muestren que
sus esfuerzos están teniendo un impacto comercial.
Comencemos con una métrica que es fácil de capturar: Ciclo (y tiempo) de entrega.
11.1.1 Ciclo y tiempo de entrega
¿QUÉ SON? Mida qué tan rápido se mueve el trabajo a través de su proceso y dónde se ralentiza.
Métricas comunes 239
¿QUÉ PUEDES APRENDER DE ESTA MÉTRICA? Al medir el tiempo de entrega, puede ver
la mejora real en el tiempo-de-entrega/mercado y la previsibilidad. También puede ver el
rendimiento de la fecha de vencimiento, si un determinado elemento está en el target frente a lo
que creía que debería ser. Con el tiempo de espera capturado, también puede analizar dónde ha
gastado su tiempo el elemento de trabajo y comenzar a rastrear la eficiencia del tiempo de espera
para ver si el elemento de trabajo está esperando, bloqueado, reelaborado o realmente trabajando.
El tiempo de ciclo se refiere al tiempo que tarda un elemento de trabajo en pasar por una parte del
proceso, por ejemplo, haciendo desarrollo y pruebas. El tiempo de entrega, por otro lado, se refiere
al tiempo necesario para finalizar el proceso completo, desde la idea hasta la función final en la
producción.
No lo entiendo. Estamos
trabajando como locos y
vamos más rápido que
nunca en lo que
respecta al desarrollo.
Tiene un gran tiempo

de ciclo para eso, en
otras palabras.
¡Excelente!
Tiempos de ciclo ...? No,

camino al trabajo ... en
cualquier caso, lo
extraño es que todavía
se siente lento. Las
cosas tardan mucho en
completarse.
Ok, comencemos a
rastrear los tiempos
de entrega para cada
elemento de trabajo y
veamos la tendencia.
El tiempo de entrega generalmente es más interesante de rastrear porque le muestra todo el proceso.
El tiempo del ciclo reduce el enfoque a solo una parte, lo que podría perder otra parte del proceso
que podría brindarle información valiosa. Si está mejorando solo durante una parte del proceso,
puede perderse algún otro cuello de botella que ralentice el tiempo de entrega.
La siguiente tabla de ejemplo muestra los tiempos de ciclo que un equipo rastrea para el
desarrollo y las pruebas. También se indica el tiempo de entrega completo, como puede ver en el
flujo de trabajo completo.
El tiempo de entrega para el proceso completo a menudo es un poco más difícil de conseguir, ya
que es posible que no lo tenga bajo su control o visualizado en su tablero. Esfuércese por hacer un
seguimiento del tiempo de los elementos de trabajo durante la mayor parte del proceso posible para
obtener la imagen completa.
Tiempo de ciclo versus tiempo de entrega

Para comprender mejor la diferencia entre los tiempos de entrega y de ciclo, considere el primer
proyecto Scrum en el que participó Marcus. El equipo constaba de seis desarrolladores felices, y
creamos software de trabajo cada tres semanas. El tiempo de ciclo de nuestro desarrollo fue, por lo
tanto, de tres semanas. ¿Pero fue útil para el negocio?
No mucho. Cuando "terminamos" después de seis sprints, supimos que una fase de prueba de tres
meses estaba esperando todo el trabajo que habíamos hecho. Y después de eso, perdimos el ciclo
de lanzamiento trimestral una semana y tuvimos que esperar otros tres meses antes de lanzar
nuestro software a los usuarios.
Lamentablemente, eso no importó mucho para
nuestro tiempo total de entrega, porque
entendimos que los requisitos para la aplicación
se habían redactado un año y medio antes de
que empezáramos.
El tiempo de ciclo (considerando solo el
desarrollo) para una sola característica fue de
tres semanas, pero el tiempo de entrega para esa
misma característica fue de dos años y cuatro
meses.
Esa es la diferencia entre el ciclo y el tiempo de entrega. Aunque reducir el tiempo del ciclo de
desarrollo puede ser útil, las grandes oportunidades de mejora se pueden encontrar en otros
lugares.
El tiempo de entrega debe ser lo más corto posible para que el trabajo fluya rápidamente a través del
proceso completo. Tenga en cuenta que centrarse en acortar los tiempos del ciclo a veces puede ser
malo para el tiempo de entrega general. Esto se conoce como optimización local. Digamos que ha
optimizado el tiempo de desarrollo, y ahora son un par de días. Esto tiene consecuencias para otros
en torno al desarrollo; ¿Se pueden escribir los requisitos en pequeños fragmentos para mantener
ocupados a los desarrolladores? ¿Pueden los probadores manejar recibir nuevos elementos cada dos
días? Incluso puede ser conveniente ralentizar a los desarrolladores para que el trabajo fluya más
suavemente a través del proceso. Al medir los tiempos de espera y de ciclo, esto es fácil de detectar.
(Lea más sobre eso en el capítulo 7.)
CAPTURANDO LA MÉTRICA
El ciclo y los tiempos de entrega son métricas fáciles de capturar y rastrear. Con un flujo de trabajo
visualizado en un tablero, puede comenzar hoy. Anote la fecha en cada tarjeta de elemento de
trabajo cuando la ponga en el tablero. Cuando el elemento de trabajo llegue a la última columna de
su tablero (Done o In Production, por ejemplo), anote esa fecha. La diferencia entre estas dos fechas
es el tiempo de ciclo para su proceso. Es el tiempo total de entrega si tiene todo el proceso en su
tablero, desde la idea hasta la producción.
En este ejemplo, verá un elemento de trabajo que ingresó al tablero (en la columna InBox) el 2 de
febrero de 2013. Llegó a la columna Done el 18 de marzo de 2013. Restar esas fechas entre sí da un
tiempo de entrega total de 44 días (31 días hábiles en Suecia ese año).
Capturar el tiempo del ciclo es
igualmente simple. Hágalo "estampando"
el elemento de trabajo con la fecha en
que ingresa a la columna que le interesa:
por ejemplo, cuando ingresa a la columna
Dev. y luego nuevamente cuando llegue a
la columna Ready to Deploy.
Puede ver que este elemento de trabajo ingresó a la columna Dev. el 1 de marzo y llegó a la
columna Ready to Deploy el 12 de marzo. Eso da un tiempo de ciclo de 11 días (8 días hábiles).
ANALIZANDO LA MÉTRICA
Con estas dos métricas disponibles (tiempo de entrega de 44 días y un tiempo de ciclo para
desarrollo y prueba de 8 días), el equipo ahora puede comenzar a hacer un análisis y hacer
preguntas sobre cómo se comporta su trabajo. Ocho días es solo alrededor del 20% del tiempo total.
¿Ha aumentado o disminuido este número (ocho días)? ¿Que debería ser? ¿Dónde pasa el resto del
tiempo? ¿Deberían comenzar a rastrear el tiempo del ciclo para que otras partes del proceso sepan
más?
Al hacer preguntas como esa, pronto se dará cuenta de que el ciclo individual y los tiempos
de entrega no son tan interesantes. Las tendencias a lo largo del tiempo son mucho más interesantes.
Puede ser que el primer elemento que rastreó fuera excepcionalmente rápido o lento. Necesita una
muestra más grande para ver si está mejorando con el tiempo. Puede hacerlo con análisis
estadísticos (consulte la sección 11.2.1 para ver un ejemplo de esto) o visualizando sus tendencias.
Cuando ha realizado un seguimiento del tiempo de entrega, también puede comenzar a
analizarlo:
■ ¿El tiempo medido es normal para un elemento de trabajo de este tamaño y tipo? Con una
muestra lo suficientemente grande, puede comenzar a hacer predicciones para los elementos
de trabajo a medida que ingresan al tablero (consulte la sección 9.1.4 sobre los tiempos de
espera de Disneyland).
■ Puede usar la fecha del tiempo de entrega para establecer prioridades. Digamos, por
ejemplo, que un elemento de trabajo mediano generalmente tarda de cinco a ocho días en
completarse, y tiene uno con una fecha de vencimiento en seis días. Con esa información en
la mano, puede comenzar a priorizarla sobre otro trabajo si nota que comienza a retrasarse
en su horario previsto.
■ Un ejercicio interesante es reducir el tiempo de espera y ver dónde se gasta el tiempo real.
Por un tiempo total de 30 días, ¿dónde se dedica más tiempo? ¿Cuánto se gasta esperando o
bloqueado? ¿Cuánto cuesta el retrabajo? Un análisis que puede ayudarlo a encontrar cuellos
de botella y hacer grandes mejoras.
VISUALIZANDO LA MÉTRICA
El equipo rastrea las tendencias de los tiempos de espera y de ciclo en dos diagramas simples que
han dibujado en la pizarra junto a su flujo de trabajo. Esto se puede hacer como un diagrama de
dispersión simple, como el que se muestra a continuación. ( Podría usar una herramienta como
Microsoft Excel para dibujar el diagrama, pero hemos descubierto que es más sencillo comenzar
trazándolo en la pizarra).
El diagrama no tiene que ser correcto al punto decimal. Lo importante es visualizar el
diagrama y ponerlo en la pared para que todos lo vean. ¡Hazlo grande! Desea que todos lo vean y
puedan reflexionar y hacer preguntas.
Puede realizar un seguimiento tanto del tiempo de ciclo para las diferentes partes del proceso
como del tiempo de entrega total. Puede mostrar eso en un gráfico de columnas apiladas que
muestra la distribución del tiempo en las diferentes etapas del proceso, como se muestra en este
diagrama.
La Sección 11.2 analiza cómo usar estos datos en diagramas más avanzados, como un diagrama de
control y un diagrama de flujo acumulativo. Pero no subestimes diagramas simples como estos
como un buen comienzo.
Aunque centrarse en acortar los tiempos de entrega es una buena cosa, ya que conduce a un
mejor flujo, como mencionamos en el capítulo 7, es posible que pierda otra información si se
concentra únicamente en esa métrica. Por ejemplo, si se concentra en el tiempo de entrega, es
posible que no note que ha pasado una semana desde que puso algo en producción. Es por eso que
puede complementar su métrica de tiempo de entrega con un enfoque en el rendimiento de su
proceso.
11.1.2 Rendimiento
¿QUÉ ES? Mide la velocidad a la que el proceso produce elementos de trabajo completos.
¿QUÉ PUEDES APRENDER DE ESTA MÉTRICA? Puede saber si sus esfuerzos para mejorar
el flujo reduciendo WIP, cortando historias e invirtiendo en automatización, como la entrega
continua, etc., están dando sus frutos. ¿Realmente está mejorando la frecuencia de entrega y, por lo
tanto, acortando los bucles de retroalimentación?
El rendimiento se define como el movimiento de entradas y salidas en un proceso de producción 1 y

se traduce aproximadamente como "cuánto completamos por unidad de tiempo". Otra forma de
decirlo (que nos gusta más) se puede encontrar en la comunidad de Theory of Restraints: “El
rendimiento es la velocidad a la que un sistema logra su meta”.
¡Guauu! Los tiempos de ciclo

para las implementaciones
realmente han mejorado las
últimas dos semanas.
Despliegue ...
Sí, supongo.
Espera un minuto ...

no hemos implementado
nada en 2 semanas.
El seguimiento del rendimiento lo ayuda a enfocarse en mover cosas a través de su proceso y

garantizar que el trabajo se realice y no simplemente se trabaje. Es mejor luchar por un mayor
rendimiento (más elementos completados por período), pero no a costa de la calidad.
Al igual que con el tiempo de entrega, el rendimiento es bastante simple de capturar: cuente la
cantidad de elementos de trabajo completados por semana (o mes, o lo que se adapte a sus
necesidades de granularidad). En un tablero visualizado, puede contar la cantidad de elementos de
trabajo en la columna Done cada viernes y luego borrar la columna.
1
Verr http://en.wikipedia.org/wiki/Throughput_(business).
El rendimiento es fácil de visualizar como un diagrama de dispersión o un gráfico de columnas
apiladas que muestra cuántos elementos completa cada semana, por ejemplo. Aquí hay un ejemplo
de cómo se puede visualizar eso:
Una vez más, podría usar herramientas sofisticadas para crear este diagrama si quisiera, pero no es
necesario. Lo único importante es que se visualice para el equipo y otras personas interesadas.
Analizar el rendimiento puede ayudarlo a concentrarse en hacer las cosas. Hemos visto equipos en
los que "todo funciona bien", pero no entregaron nada durante un mes. Al agregar una pequeña
visualización que mostraba cuánto salían por la puerta cada semana, comenzaron a concentrarse en
entregar nuevamente.
El rendimiento también puede ser una métrica de equilibrio para mejoras en el tiempo de
entrega. Si está reduciendo el tiempo de entrega y el rendimiento disminuye, podría ser que haya
reducido demasiado el WIP. Por ejemplo, supongamos que realmente intenta optimizar para obtener
un excelente tiempo de entrega y establecer su límite de WIP en un solo elemento de trabajo. Ese
elemento de trabajo no puede moverse más rápido, porque cada persona disponible en el equipo
trabaja solo con ese elemento. En el momento en que necesita que alguien le ayude o responda una
pregunta, tiene tiempo para hacerlo. Pero eso puede ser malo para el rendimiento porque nada más
que ese único elemento se está trabajando. Tal vez (y probablemente) el WIP es demasiado bajo.
11.1.3 Problemas y elementos de trabajo bloqueados
¿QUÉ SON? Mida los elementos que obstaculizan el flujo.

¿QUÉ PUEDES APRENDER DE ESTA MÉTRICA? Cómo los elementos de trabajo
bloqueados están afectando su tiempo de entrega/eficiencia del tiempo de entrega. ¿Qué tan
bueno/rápido eres para desbloquear/resolver problemas? ¿Estás mejorando?
Los problemas y los elementos bloqueados son cosas que obstaculizan el flujo de trabajo. Los
problemas o defectos le indican que no está produciendo con la calidad adecuada y que
definitivamente son cosas sobre las que desea recibir notificaciones. Los bloqueadores evitan que su
trabajo fluya sin problemas. Desea borrarlos y asegurarse de tener el menor número posible de
ellos.
¿Que es esto? ¿Ocho elementos bloqueados Siempre es así cuando nos integramos con Snail-Web
esta semana? Esto no es aceptable. Inc. Como siempre pensamos. Ahora tenemos los datos
para confirmar nuestras corazonadas.
Los problemas de seguimiento pueden ser la métrica de equilibrio que garantiza que no ejecute su
proceso demasiado rápido. Imagine que solo se enfoca en reducir los tiempos de entrega, por
ejemplo, y que alguien desea mejorar esa métrica. Una forma de lograr eso es ser descuidado: eso
seguramente haría que las cosas vayan más rápido.2 Con una métrica centrada en la calidad, que
rastrea el número de defectos, por ejemplo, se asegura de que la métrica del tiempo de entrega no se
centre en lo absurdo. Puede leer más sobre las métricas de calidad en la sección 11.1.5.
Los bloqueadores a menudo ocurren cuando te obligan a esperar a que otros se hagan cargo
de tu trabajo o te den su opinión antes de que puedas seguir trabajando. Los debates sobre cómo
resolver problemas como estos son más fáciles y más precisos si se respaldan con datos.
Por ejemplo: "Hemos rastreado la cantidad de elementos que estamos esperando de usted, y
aumentó en un 30% en el último mes, y aquí están los datos que le muestran esa tendencia" es un
argumento mucho mejor que "Siento que estamos esperando muchas de sus cosas. Con datos
concretos en la mano, puede discutir qué hacer al respecto. O suponga que ha hecho algo para
eliminar los bloqueos. ¿Cómo puede saber si esa medida tuvo algún efecto? Necesita algún tipo de
métrica, antes y después.
Con un flujo de trabajo visualizado, estas dos métricas (defectos y bloqueadores) se capturan
fácilmente contando el número de elementos en el tablero:
2
Al menos por un tiempo. El código descuidado tiende a ser difícil de mantener y se vuelve más y más lento para
moverse.
■ Número de defectos = Número de adhesivos rosados en un momento dado, o por semana,

por ejemplo
■ Número de bloqueadores = Número de adhesivos con un marcador bloqueado adjunto a
ellos
Esto se dibuja fácilmente como un gráfico de
columnas dispersas o apiladas que muestra las
tendencias. ¿Tienes más elementos bloqueados ahora?
Desde que hiciste esa semana de corrección de errores,
¿se ha mantenido el número de nuevos errores en el
mínimo o está aumentando de nuevo? ¿Cuál fue la
razón de tener tantos errores en la última semana?
Puede realizar un rastreo de otras cosas que son
importantes para su proceso (asegurándose de que
siempre esté haciendo un cierto número de funciones
de mantenimiento nuevas o técnicas, por ejemplo). Puede realizar un seguimiento y visualizarlos de
la misma manera que hemos descrito aquí.
El número de bloqueadores es interesante de analizar porque estas son las cosas que lo retrasan y
reducen su eficiencia en el tiempo de espera. Para los bloqueadores que ocurren, asegúrese de
resolverlos rápidamente. Algunos equipos registran cada día que un elemento de trabajo está
bloqueado con un indicador de progreso en el bloqueador adhesivo (ver sección 4.4). Esos datos
pueden conducir a discusiones interesantes y oportunidades de mejora en torno a la resolución de
bloqueadores y cómo priorizar ese trabajo—o alrededor del flujo, porque realmente no desea ser
bloqueado en absoluto.
11.1.4 Desempeño de la fecha de vencimiento
¿QUÉ ES? Mide qué tan bien se cumplen las promesas y los plazos.
¿QUÉ PUEDES APRENDER DE ESTA MÉTRICA? Puede ver si es probable que se cumpla
una fecha de vencimiento en el tiempo de entrega previsto y crear un historial que lo haga
fidedigno y seguro. Esto a su vez lo ayuda a generar confianza con sus partes interesadas.
Si un elemento tiene una fecha de vencimiento adjunta, debe asegurarse de alcanzar esa fecha de
vencimiento. Esa fecha a menudo está allí porque existe una oportunidad de negocio en la fecha o
se debe pagar una multa si se pierde. Algunas personas hablan sobre las fechas de vencimiento
como parte de su acuerdo de nivel de servicio (SLA) con los departamentos y las partes interesadas
de los alrededores.
13.32.05 …
13.32.10 ... 13.32.15 ...
fuera de tiempo! Uno más
que es tarde.
¡¿Seriamente?! No puedes
decir que la compilación se
está ejecutando ahora.
Seguro, te digo. ¡Seguro!
¡Fuera! - ¡Fuera!
Seguro - Seguro
Cuando fechas como estas son importantes para su equipo, debe realizar un seguimiento. No es
difícil hacerlo desde su tablero porque puede anotar la fecha en que se completó el elemento de
trabajo y compararlo con la fecha de vencimiento.
Para métricas como estas, un gráfico de torta o circular probablemente sea el más adecuado. Esto le
proporciona una visión general rápida de cuántas fechas de vencimiento de elementos de trabajo se
cumplen y se pierden.
El rendimiento de la fecha de vencimiento puede ser algo que usted usa para comunicarse con otros
equipos y partes interesadas, pero también lo ayuda a priorizar y motivar a su propio equipo. Si un
elemento se está quedando atrás, de acuerdo con la fecha de vencimiento prevista, puede priorizarlo
más que otro trabajo: "¡No queremos arruinar nuestro excelente historial!"
Con un largo y sólido historial de estar a tiempo, a menudo construye confianza con los
equipos que lo rodean y sus partes interesadas. Pero esto también puede conducir a discusiones de
mejora: "Llegamos al 95% de nuestras fechas de vencimiento, excepto para los elementos que
tienen que ver con el Vendedor B. ¿Qué podemos hacer al respecto?"
11.1.5 Calidad
¿QUÉ ES? Mide la calidad del trabajo y si se están entregando características que dan valor a las
partes interesadas y los clientes.
¿QUÉ PUEDES APRENDER DE ESTA MÉTRICA? La calidad es excelente para usar como
métrica de equilibrio para otras mejoras, como la mejora del tiempo de entrega. También puede ser
una medida para ver si sus esfuerzos de mejora de la calidad (pruebas automatizadas, pago de
deudas técnicas, etc.) están dando resultado.
La calidad es un concepto complicado, y un tratamiento minucioso está más allá del alcance de este
libro. Se puede interpretar de muchas maneras diferentes. No queremos detenernos en ese gran tema
aquí. Adoptaremos la definición de Gerald Weinberg: "La calidad es valor para alguna persona".3
Esta definición es, por supuesto, vaga y abierta a la interpretación, pero también lo es la
calidad. Un amigo nuestro estaba muy decepcionado de encontrar muchos errores ortográficos y
gramaticales en un libro que había escrito. Pero fue votado como el libro ágil número 1 de ese año,
con más de 20 reseñas de cinco estrellas en Amazon. ¿Cuál es la calidad para ese libro? Un
producto impecable que nadie usa no es de calidad.
Hay muchas métricas atractivas en torno a la calidad que puede capturar con bastante facilidad:
■ El número de defectos/errores por compilación o versión del producto. Probablemente,
esto se capte mejor como una tendencia que muestra cómo cambia el número con el tiempo.
■ El número de elementos de trabajo defectuosos en el tablero por unidad de tiempo. Esto
muestra cuánto de sus recursos se gastan en corregir errores.
■ Puede realizar un seguimiento de la mayoría de las métricas que hemos mencionado hasta
ahora (tiempo de entrega, rendimiento, etc.) por separado para los elementos de trabajo
defectuosos.
A estas alturas deberías sentir un gran pero próximo ... y aquí viene: pero solo porque estas cosas
son fáciles de rastrear no significa que haya un valor en rastrearlas.
La calidad, explico pacientemente, no es la ausencia de algo en los ojos de la gerencia,
es decir, defectos, sino la presencia de algo en los ojos del consumidor, es decir, el valor.
—Alan Weiss 4
Y sí, esa idea de calidad es mucho más difícil de capturar y rastrear, pero también es más valioso
rastrear por el impacto comercial que está tratando de lograr. En palabras de Gojko Adzic: "No se
3
De Quality Software Management: Systems Thinking (Dorset House, 1991, http://amzn.com/0932633226).
4
Million Dollar Consulting (McGraw-Hill, 2009, http://amzn.com/0071622101).
aferre a las herramientas de seguimiento de defectos como si fueran una manta de seguridad; define
lo que significa calidad en tu contexto".5
¿Cómo sabes si has creado valor para alguna persona? Esa es una métrica más difícil de
capturar y solo se puede responder preguntando a aquellos para quienes desea crear valor. Hay
muchas maneras diferentes de hacerlo: encuestas y entrevistas, puntajes netos del promotor (NPS:
”net promoter scores”) y número de me gusta en Facebook son algunos de los que hemos
escuchado.
Ahora se ha aventurado fuera de su propio proceso y necesita aprovechar el producto que
está creando para obtener datos para capturar la métrica. Tal vez sea necesario incorporar una nueva
funcionalidad en el producto para ver y saber qué piensan los usuarios y cómo lo están utilizando.
Google Analytics, Optimizely y Google Tag Manager son herramientas comunes del sitio
web que monitorean el tráfico y pueden seguir la forma en que los usuarios interactúan con sus
páginas. Pueden brindarle mucha información sobre la calidad del producto y las características que
está creando.
Las métricas de calidad pueden tomar muchas formas, por lo que no podemos darle un buen consejo
sobre una forma de visualizar las suyas. Podemos decir esto: hazlo grande, hazlo visual y ponlo en
la pared. Un panel de Google Analytics en una pantalla al lado del equipo atraerá mucha atención y
generará elogios, preguntas y discusiones, exactamente lo que desea para mejorar aún más.
Si logra capturar el valor que está creando para sus usuarios, está en una excelente posición para
algunos análisis realmente interesantes. Luego, puede hacer pequeños cambios en su producto
(algunos6 los llaman experimentos) y ver cómo cambian las métricas que está capturando en función
de ellos. Esto incluso puede prestarse a lo que se conoce como prueba A/B, es decir, lanzar dos
versiones de la misma funcionalidad y ver cuál funciona mejor.
Para tomar un ejemplo real en el que Marcus estuvo involucrado, supongamos que desea
tener tantos usuarios como sea posible registrados en su sitio. En este momento ves una gran caída
en el módulo de registro. Cree que tiene que ver con el módulo CAPTCHA 7 que tiene personas que
leen símbolos difíciles de leer y los ingresan en otro cuadro. Entonces, crea un experimento y lanza
una versión del formulario de registro con CAPTCHA activado y una versión desactivada. Ahora
puede medir la diferencia en la conversión (de usuarios no registrados a usuarios registrados) y ver
si debe usar el algoritmo CAPTCHA o no.8
Estos son datos valiosos que pueden ayudarlo a mejorar el impacto comercial que crea con
su producto. Este es también un tema que es mucho más grande de lo que tenemos espacio en este
5
Vea su entrada de blog “Bug statistics are a waste of time” en http://mng.bz/kKIT.
6
Ver http://theleanstartup.com/.
7
Ver http://en.wikipedia.org/wiki/CAPTCHA.
8
¿Puedes adivinar el "ganador" de las alternativas? Ritmo de CAPTCHA activado CAPTCHA desactivado en un 5%
durante una semana de experimentación. Nadie en toda la empresa lo adivinó. Tampoco tú, suponemos. El resultado del
experimento contradecía nuestra hipótesis. Ahora, ¿cómo actuarías con esa información?
libro. Para obtener más información, pruebe el increíble libro Impact Mapping de Gojko Adzic
(Provok-ing Thoughts, 2012, http://mng.bz/12J0) como punto de partida.9
11.1.6 Demanda de valor y demanda de falla
¿QUÉ SON? Mida cuánto trabajo es causado por fallas sistémicas, trabajo que debe rehacerse, por
ejemplo.
¿QUÉ PUEDES APRENDER DE LAS MÉTRICAS? Cómo aumentar la capacidad de entrega de
valor mediante la reducción sistemática de la demanda de fallas.
La demanda por falla es un concepto inventado por el profesor John Seddon (I Want You to Cheat!
Vanguard Consulting Ltd, 1992, http://amzn.com/095197310X). Puede entenderse como "demanda
en un sistema causada por la falta de hacer algo o hacer algo correcto para el cliente". Lo opuesto a
la demanda de falla es la demanda de valor, que es la verdadera razón por la que existe el sistema.
La demanda de valor significa cosas que desea que haga el sistema. No hace falta decir que desea
minimizar la demanda de fallas siempre que sea posible.
¡Oh hombre! Otra

corrección de errores. ¡Lo
juro, es lo único que
hacemos por aquí! ¡Y todo
tiene que ver con las malas
especificaciones!
¿Cómo sabes que es "lo único que

haces"? Hagamos un rastreo de la
demanda de falla y descubramos
con seguridad.
Lamentablemente, abundan los ejemplos de demanda de fallas, pero pueden variar desde tener que
rehacer el trabajo debido a malas especificaciones, hasta no entenderse y, por lo tanto, producir
cosas incorrectas, errores y defectos, sobrecargar las funciones de soporte debido a la mala calidad o
las instrucciones. La demanda de fallas incluye cualquier cosa que lo aleje de hacer las cosas que
desea hacer: ofrecer funciones que tengan un impacto comercial.
Medir la demanda de falla versus la demanda de valor puede ser difícil porque a veces se
reduce a lo que crees que es un elemento. Implementar un nuevo aspecto de una función de
búsqueda, por ejemplo, ¿es esa demanda de valor (nueva función, por favor) o es una demanda de
falla (debería haber incluido la función la primera vez)?
9
Ver también http://impactmapping.org/.
Se deduce naturalmente que, debido a que a veces es difícil clasificar los elementos de trabajo,
también puede ser difícil capturar la métrica. Nuestra sugerencia es no exagerar, sino encontrar una
manera fácil de clasificar el elemento de trabajo. Por ejemplo, vote al final de la vida útil de un
elemento de trabajo: ¿se trataba principalmente de una demanda de falla o una demanda de valor?
Algunos elementos de trabajo (como los defectos) se incluyen naturalmente en una categoría que es
difícil de clasificar como algo más que la demanda por falla.
Una vez que tenga una manera de clasificar la demanda de valor frente a la demanda de falla, puede
visualizar las tendencias como dos gráficos y ver cómo se están comparando entre sí. O puede
escribir un gran porcentaje en el tablero: "La semana pasada tuvimos una demanda de falla del 25%,
10% menos que la semana anterior".
Esta métrica puede ser reveladora para muchos equipos, y para las partes interesadas a su alrededor,
con respecto a dónde se dedica realmente el tiempo del equipo. Cuando tenga esos números frente a
usted, puede comenzar a ver qué puede hacer sobre la situación. ¿Por qué se produjo la demanda de
falla y cuál fue la causa raíz de la misma (ver sección 10.2)?
11.1.7 Ideas abandonadas y descartadas
¿QUÉ SON? Mida cuántos elementos en una cartera de pedidos particular (o columna de bandeja
de entrada) se descartan en lugar de entrar en el flujo de trabajo de desarrollo y cuántos elementos
en el flujo de trabajo de desarrollo se descartan.
¿QUÉ PUEDES APRENDER DE LAS MÉTRICAS? Demasiadas ideas descartadas significa
que no tiene muchas opciones, por lo que tal vez no esté innovando o tomando suficiente riesgo.
Si se descartan demasiados elementos en la columna Development, significa que está comenzando
trabajo que no debería.
Esta es una métrica que es fácil de pasar por alto porque, en métodos ágiles, fomentamos los
cambios. Incluso está en la palabra ágil: poder cambiar rápidamente. Pero, ¿cuántos equipos has
visto contar las ideas o los elementos de trabajo extraídos del tablero? A menudo se descartan y no
se piensa hasta que resurgen.
Una manera fácil de rastrear los elementos que retira del tablero es tener un basurero o una canasta
donde mueva los elementos de trabajo que descarte. Luego puede tomar nota de esos elementos e
incluso contar el número de ideas descartadas por unidad de tiempo (por semana o mes, por
ejemplo). Estos datos pueden ser el contexto para una discusión fructífera más adelante.
Puede leer algunos datos interesantes de esos elementos descartados. Aunque la primera reacción
natural es pensar que es malo seguir moviendo elementos fuera del tablero, aún desea descartar
algunos elementos. Si no descarta nada que haya subido en el tablero, podría argumentar que no
está innovando lo suficiente. La lujuria por el descubrimiento es eliminada por su constante trabajo
atrasado que no debe cambiarse.
Por otro lado, si descarta demasiados elementos, puede ser difícil mantener la meta clara.
Esto es aún peor si comienza a trabajar en elementos y luego los descarta. Eso se puede medir por la
cantidad de elementos en desarrollo que luego descartas. Si ese número es alto, significa que
comienza mucho trabajo que no debería haber comenzado. Eso a su vez puede generar la pregunta
de si debería invertir más tiempo investigando o descubriendo en las fases anteriores, aguas arriba
de su equipo.
Esta sección echó un vistazo a algunas métricas comunes que hemos visto que los equipos
kanban usan y obtienen valor. La visualización de las métricas es una parte importante para hacer
que la métrica sea conocida e importante para todos en el equipo y las personas de todo el equipo.
Aunque los diagramas simples en esta sección son un gran comienzo, la siguiente sección se
sumerge profundamente en dos diagramas conocidos y poderosos: diagramas de control de procesos
y diagramas de flujo acumulativo.
Métricas comunes
* Tiempo de ciclo = tiempo empleado en parte del proceso
* Tiempo de entrega = tiempo empleado en el proceso completo
* Rendimiento = número de elementos completados
* Rendimiento de la fecha de vencimiento = cumple sus promesas
* Calidad = entregas con calidad
* Demanda de Valor/Falla = haces lo correcto
* Ideas descartadas = ¿innova lo suficiente o demasiado?
Ya tiene todos los datos que necesita para producir estos nuevos y potentes diagramas con un flujo
de trabajo visualizado. Se trata de dibujarlos. Veamos cómo se hace.
UNA PALABRA DEL ENTRENADOR Probablemente ningún

equipo debería capturar y rastrear todas las métricas que sugerimos en
esta sección. Pero para los que está rastreando, asegúrese de tener
políticas explícitas y visuales para ayudarlo a recordar qué rastrear
cuando se completa un elemento. Puede ser tan simple como una lista
de verificación, los llamados criterios de salida, en la columna Done: "Esto es lo que hay
que hacer antes de que el elemento se pueda sacar del tablero".
11.2 Dos visualizaciones poderosas

Las secciones anteriores le presentaron un par de métricas comunes y le dieron pistas sobre cómo
visualizarlas. La mayoría de los diagramas sugeridos son simples de dibujar y comprender, pero
también tienen un uso limitado. A menudo muestran un aspecto de su proceso, y necesita hacer una
referencia cruzada de varios diagramas para obtener una visión más integral de cómo van las cosas.
En esta sección, echamos un vistazo a dos diagramas de uso común. Son un poco más
avanzados para producir que los simples gráficos de dispersión, pastel y columnas apiladas que has
visto hasta ahora, pero también te dan más información como recompensa por tus esfuerzos para
dibujarlos. Le mostramos qué tipo de datos necesita rastrear y cómo dibujar los diagramas, y
finalmente qué tipo de información puede obtener de ellos.
Esta sección no trata sobre cómo usar Excel (o cualquier otra herramienta, para el caso).
Solo le mostramos el tipo de cálculos que necesita para dibujar una versión simple del diagrama.
11.2.1 Control estadístico de procesos (SPC)

Statistical process control (SPC) es un enfoque para el control de calidad que implica mucho más
que simplemente dibujar un diagrama. Cubrir SPC está fuera del alcance de este libro, pero
queremos presentarle un diagrama que hemos encontrado útil llamado el gráfico de control de
proceso estadístico. Existe una teoría subyacente que creemos que usted también debe conocer para
poder interpretar y comprender la tabla SPC correctamente. Se llama la teoría de la variación.
TEORÍA DE VARIACIÓN
Una cosa que es fácil de pasar por alto es la variación natural que se encuentra en cada sistema.
Asumimos que podemos alcanzar el resultado promedio cada vez. Pero ese no es el caso, debido a
la variación natural. John Seddon ha formulado una teoría de la variación 10 que, a través de cuatro
principios simples, dice que no puede esperar que el trabajo y los trabajadores se desempeñen en el
resultado promedio que rastrea y mide.
Principio # 1: Debe esperar que las cosas varíen, siempre lo hacen.

Existe una variación natural en cada sistema, por lo que no debe sorprenderse que obtenga
resultados diferentes de diferentes personas o de las mismas personas en diferentes días.
Con una pequeña muestra, realmente no se puede saber si es bueno o malo, y si está dentro o
fuera de la variación normal para ese tipo de trabajo. Usando un gráfico SPC, puede ver si la
variación es predecible (dentro de los límites de control) o impredecible (fuera de los límites de
control).
Por ejemplo, el desempeño de un trabajador puede verse excelente. Sin embargo, cuando
obtiene una muestra más grande, ve que era exactamente lo que se esperaba dada la variación
natural.
10
Ver “There Is a Better Way” en www.systemsthinking.co.uk/variation.asp.
Dos visualizaciones poderosas 255
Principio # 2: Comprender la variación le dirá qué esperar.

Supongamos que tiene un equipo que ha seguido el tiempo de entrega de su trabajo en las últimas
semanas, como se muestra en este gráfico:
Tener límites de control superior e inferior establecidos le indica que el resultado del equipo a veces
será tan bajo como el límite inferior (en este caso, 15) y a veces tan alto como el límite superior (en
este caso, 38), pero más a menudo alrededor el promedio (en este caso, 26.5).
Por extraño que parezca, los equipos a menudo esperan ser promedio (o mejores) cada vez.
Pero eso no va a suceder, porque somos seres humanos que laboramos en el trabajo del
conocimiento en un contexto que naturalmente tiene variaciones.
Considere el ejemplo de establecer metas para el tiempo de entrega en el equipo que se
acaba de mencionar. Si lo establece en el promedio, el equipo a veces lo superará (y se irá a casa
triste) y a veces estará por debajo (y se irá a casa feliz). Sabes que esto sucederá porque hay una
variación natural en el proceso. Si establece la meta hacia el límite de control superior, el equipo a
menudo se irá a casa triste, porque lo extrañarán mucho. En realidad, muchos equipos comenzarán a
hacerlo mejor, porque están tratando de alcanzar esa meta. ¿Pero a qué precio? No es raro que los
equipos comiencen a hacer trampa11 o jueguen con el sistema para alcanzar la meta.
Las metas en procesos con variaciones no motivan a las personas, pero si pueden
desmotivarlas. Si lees el trabajo de Dan Pink (Drive, Riverhead Books, 2001, http://mng.bz/yM3h),
sabrás que lo que realmente motiva a las personas no son las metas sino la autonomía, la maestría y
el propósito.
Si le das a un gerente un objetivo numérico, lo logrará, incluso si tiene que destruir
la compañía en el proceso.
—W. Edwards Deming
Principio # 3: Trabajar en las causas de las variaciones, que siempre se encuentran en el

sistema.
Un mal sistema derrotará a una buena persona en cualquier momento.
—Atribuido a W. Edwards Deming
11
Por ejemplo, comenzar a hacer un trabajo descuidado que sea más rápido pero que volverá y los ralentizará más tarde.
La mayoría de las variaciones de rendimiento se encuentran en el sistema en sí, fuera del control de
las personas que trabajan en él. Considere todas las cosas que afectan sus situaciones actuales:
políticas, roles, estructura organizativa, procedimientos, requisitos, financiación e información, por
mencionar algunos. Todos estos son ejemplos de cosas que (normalmente) están fuera del control
del equipo. Cosas como estas también causan la variación natural en el sistema. Nuevamente: las
cosas que causan la variación natural están fuera del control del equipo.
Los gerentes deben tratar de minimizar la variación trabajando en las cosas en el sistema que
causan variación.
Principio # 4: Entender la variación te dice cuando algo ha sucedido.

En un gráfico SPC, puede ver si un solo valor es una causa especial (se encuentra fuera de los
límites de control; vea el punto marcado en el gráfico) o si es una causa común (dentro de los
límites de control y, por lo tanto, un efecto de variación natural) . Debe ser consciente de la
diferencia para no actuar como si cada variación fuera una causa especial.
Por ejemplo, normalmente a Joakim le toma entre 20 y 40 minutos conducir hasta el trabajo. Pero
un día tuvo un pinchazo y el viaje le llevó 1 hora y 25 minutos. ¿Debería ese incidente único
cambiar la forma en que conduce? ¿O debería comprar un auto nuevo? Si es muy importante que
nunca llegue tarde, tal vez debería invertir en una Vespa y guardarla en su maletero en caso de
llantas pinchadas en el futuro. Pero lo más probable es que debería tratar ese incidente como algo
único que no afectará tanto su conducción. Si comienza a tener llantas pinchadas con frecuencia,
puede verificar sus hábitos de manejo o la calidad de las llantas que compra.
EL GRÁFICO SPC
Un gráfico de control de proceso estadístico (o gráfico de control, o gráfico de ejecución, o gráfico
SPC para abreviar12) muestra tendencias sobre cómo va el proceso con el tiempo. Por lo general,
realiza un seguimiento de los tiempos de adelanto o ciclo (consulte la sección 11.1.1), pero también
puede usar un gráfico de ejecución para realizar un rastreo de otras métricas.
La parte estadística del nombre implica que está aplicando un análisis estadístico con el
gráfico, y eso es completamente correcto. Con el análisis estadístico, obtienes una mejor visión de
12
"El niño amado tiene muchos nombres" es un dicho sueco, por lo que es seguro decir que los SPC son amados,
suponemos.
la tendencia real al excluir los altibajos ocasionales (también conocidos como valores atípicos) y
mantienes tu enfoque en la tendencia de los datos.
¿QUÉ DATOS NECESITAS PARA DIBUJAR UNO?

No necesita muchos datos para poder dibujar un gráfico de control; de hecho, solo necesita el
tiempo de entrega para cada elemento de trabajo. Dicho esto, puede hacer que el gráfico sea más
interesante si tiene algunos valores más, todos los cuales obtiene de su flujo de trabajo visualizado:
■ Identificador o título del elemento de trabajo, para que sepa a qué elemento de trabajo se
refiere un determinado punto del diagrama.
■ Fechas de inicio y finalización, que se utilizan para calcular el tiempo de entrega (o ciclo)
para el elemento de trabajo. Puede seguir el tiempo de entrega como un solo número, 13 pero
tener las fechas de Start y Done puede resultar útil para reducir el alcance del diagrama, por
ejemplo.
■ Tipo de elemento de trabajo, que permite un filtrado y alcance interesante (por ejemplo:
¿cuál fue el tiempo de espera para defectos en mayo?).
Como puede ver, todos esos datos están en su tablero, esperándolo. Es fácil de capturar.
¿CÓMO DIBUJAR UNO?

La versión más simple se dibuja calculando el tiempo de entrega (fecha de finalización menos fecha
de inicio) en días y creando un diagrama de dispersión que muestra estos datos. Ya has visto
diagramas simples como este en este capítulo. Agregar una línea de tendencia facilita el análisis de
los datos.
13
Por ejemplo, al anotar la fecha en que colocó el adhesivo en su tablero y luego cuenta los días hasta que lo movió a la
columna Done.
Puede incluir el identificador o el título del elemento de trabajo si desea una forma de referirse a él,
pero el gráfico puede saturarse fácilmente y puede quitarle el foco a la tendencia.
Un método un poco más avanzado sería trazar diferentes líneas o incluso diferentes diagramas en
función del tipo de elemento de trabajo. Puede hacerlo fácilmente utilizando filtros para sus datos
antes de crear el diagrama.
Finalmente, desea poner la estadística en gráficos de control de proceso estadístico, y para hacerlo
necesita algunas fórmulas para el tiempo de entrega promedio, la sigma única y los límites de
control superior e inferior. Considere los siguientes datos:
■ El tiempo de entrega promedio es fácil: tome todos los tiempos de entrega y divídalos por
la cantidad de elementos que ha rastreado. Para este ejemplo, eso sería (31 + 23 + 19 + 24 +
22 + 21) / 6 = 24 días.
■ Una sigma es un poco difícil de entender y calcular. Un sigma es un valor que ayuda a
igualar los efectos de los valores atípicos. Una regla estadística llamada 68-95-99.714
establece que el 68% de todos los valores se encuentran a una desviación estándar (llamada
una sigma) de la media. Con dos sigmas de la media, cubre el 95% de todos los valores.
Finalmente, con tres sigmas, cubres el 99.7%. Calcular un sigma 15 a partir de una muestra es
una matemática bastante avanzada, pero afortunadamente casi todos los programas de hojas
de cálculo tienen fórmulas para eso en su arsenal.16 Con este ejemplo, obtienes STDEVP
(31,23,19,24,22,21) ~ 3.4.
■ El límite de control superior ahora es (después de hacer el alucinante llenado de sigmas)
fácil de calcular. Utiliza un límite de control superior de una sigma por encima del
promedio, por lo tanto, de acuerdo con la regla 68-95-99.7, teniendo en cuenta el 68% de la
población. En este ejemplo, esto agrega una sigma al promedio: 24 (tiempo de entrega
promedio) + 3.4 (una sigma) = 27.1 días.
■ El límite de control inferior es igualmente fácil de calcular. Resta un sigma del promedio.
En este caso, eso sería: 24 (promedio) - 3.4 (una sigma) = 20.2 días.
14
Ver http://en.wikipedia.org/wiki/68-95-99.7_rule.
15
Ver http://en.wikipedia.org/wiki/Standard_deviation.
16
En Excel se llama DSTDEVP, y para las hojas de cálculo de Google se llama STDEVP.
¿CÓMO LO LEES?
Este cálculo producirá un diagrama que se ve así:
Con este diagrama en su lugar, puede obtener mucha información:17
■ No tiene que preocuparse demasiado por el primer elemento de trabajo porque es un valor
atípico (según los datos que tiene en este momento). Puede verlo fácilmente porque se
encuentra fuera del límite superior de control.
■ La diferencia dentro de los límites de control no es demasiado grande, lo que significa que
tiene una precisión bastante elevada para el tiempo de entrega de sus elementos. Pero espera
un minuto. Esta muestra es mínima (y está compuesta), por lo que no puede decir cómo le
está yendo con una muestra más grande. Lo que debe tener en cuenta es si la propagación
(la distancia entre los límites de control superior e inferior) es grande, lo que significa que
los elementos son diferentes en tamaño y las predicciones son más difíciles de hacer. ¿Podría
ser algo en lo que puedas mejorar? ¿Cómo lo harías tú?
■ Aquí se muestra una buena tendencia porque los tiempos de entrega disminuyen. ¿Porqué
es eso? ¿Son estos elementos de trabajo especiales o ha cambiado su forma de trabajar?
¿Cómo puedes reforzar esta tendencia? Si la tendencia está yendo para otro lado, ¿qué tienes
que hacer para detenerla?
Recuerde la teoría de la variación (tratada anteriormente) y que cada sistema (y proceso) tiene una
variación natural. Tenga en cuenta ese conocimiento al leer un gráfico SPC.
17
Sí, este es un ejemplo, con solo un par de puntos de datos. El análisis que está haciendo puede ser anulado a medida
que se completen nuevos puntos de datos, nuevos elementos de trabajo.
Un gráfico de control de proceso estadístico es una buena herramienta y no es difícil de leer.

También es fácil capturar los datos necesarios para dibujar uno. Ahora volvamos nuestra atención a
un diagrama que es un poco más avanzado a primera vista. Después de acostumbrarse, pronto verá
que no es difícil de leer y que puede obtener mucha información: el diagrama de flujo acumulativo.
11.2.2 Cumulative flow diagram (CFD)

Un diagrama de flujo acumulativo está lleno de información que puede ser útil como material de
fondo para una discusión sobre la mejora del proceso. Después de una introducción inicial, es fácil
de leer y las métricas también son fáciles de capturar desde su flujo de trabajo visualizado. Dibujar
el diagrama es simple después de la disciplina involucrada en la recopilación de datos.
El CFD está creciendo en popularidad en la comunidad ágil y ha sido llamado el sucesor del
gráfico de Scrum burn-down.18 Vamos a sumergirnos y ver cómo puedes dibujar uno tú mismo.
¿QUÉ DATOS NECESITAS PARA DIBUJAR UNO?

Para dibujar un CFD, necesita saber el número de elementos de trabajo que tiene en cada paso de su
tablero por día.19 Puede rastrearlo fácilmente contándolos. El único truco es que no puede capturar
estos datos después de haber quitado las notas adhesivas del tablero. 20 Aquí hay un ejemplo de
tablero, como apareció en una fecha determinada (10/01/2013, para ser exactos):
18
Los equipos Scrum suelen utilizar un gráfico burn-down para realizar un seguimiento de su proceso durante un sprint,
mostrando cuánto trabajo (a menudo en los puntos de la historia) queda por hacer.
19
Teóricamente podría ser cualquier intervalo regular, pero un intervalo diario no solo es el más utilizado sino que
también parece apropiado para la mayoría de los equipos.
20
Si no eres Sheldon Cooper o tienes excelente memoria, o si has tomado una foto de la tabla todos los días.
Con el tiempo, el equipo ha contado la cantidad de elementos en cada paso y ha reunido los datos en
una tabla como esta:
En la tabla puede ver el número de elementos en cada etapa del proceso en una fecha determinada.
La última columna se acumula (por lo tanto, diagrama de flujo acumulativo) a medida que seguimos
desplegando más y más elementos en producción. Por ejemplo, el 09/01/2013 tuvimos tres
elementos de trabajo en Testing, y el número acumulado de elementos desplegados fue hasta cuatro.
Aquí se muestran muchos números, pero no se desanime. Es simple rastrear los datos en una
hoja de cálculo. Recuerde hacerlo diariamente, después de cada parada diaria (standup) o en otro
evento recurrente que ocurra a intervalos regulares.
¿CÓMO DIBUJAR UNO?

Dibujar un diagrama de flujo acumulativo es fácil. Si está utilizando un software de hoja de cálculo,
el tipo de diagrama que está buscando se llama algo así como Diagrama de Área Apilada (Stacked
Area Diagram). Puede crear ese diagrama seleccionando los datos y haciendo que el software cree
el diagrama por usted.
Recuerde que debe diseñar las áreas en el orden de las columnas en su proceso. En este
ejemplo, eso le brinda lo siguiente: el área de la InBox debe estar en la parte superior del diagrama,
seguido de Analysis, Development, Testing, etc. Algún software de hoja de cálculo21 los ordena
alfabéticamente por defecto y, por lo tanto, desordena el diagrama. Asegúrese de que los datos estén
en orden cronológico del tablero.
Si dibuja este diagrama manualmente, se trata de trazar elementos de cada columna para
cada día. Comience desde abajo y observe cuántos elementos Done hay. Para la siguiente posición,
agregue el número de elementos en la siguiente columna a la columna Done.
Por ejemplo, en la columna Ready for Deploy el 10/01/2013, teníamos dos elementos. En la
columna Done, teníamos un valor acumulado de cinco. Agregarlos juntos (2 + 5) significa que el
valor “Y” debe agregarse a 7 por Ready for Deploy.
21
*cough* Excel *cough*
Aquí hay un ejemplo de cómo se ven los datos en un diagrama de área apilada, cuando es dibujado
por Microsoft Excel:
¿CÓMO LO LEES?
Una de las principales razones de la popularidad del CFD es que le muestra mucha información.
Aquí hay algunas cosas que puede elegir del diagrama (indicado con los mismos números en el
diagrama anterior):
1 El tiempo de entrega se puede ver en el diagrama como la longitud horizontal total del área
coloreada en el diagrama, en cualquier fecha dada.
2 Los tiempos de ciclo para partes del proceso también se pueden ver como el inicio del área
de interés. Hemos medido el tiempo de desarrollo aquí.
3 El tamaño del trabajo acumulado se muestra como la altura del área de nivel superior. Esa
es la cantidad de elementos en la Inbox. Se puede realizar la misma medición en cualquier
área en un momento dado para ver la WIP de esa columna.
4 También puede medir su WIP total en cualquier fecha dada midiendo la altura de todas las
áreas hasta Deployed (el paso Done).
Otras cosas de interés se muestran en un CFD:
■ También puede ver la relación entre WIP y el tiempo de entrega. Cuanto más trabajo tenga
en proceso (número 4 en el diagrama anterior, la altura total de todas las áreas), mayor será
su tiempo de entrega (número 1 en el diagrama). Esto puede ser revelador y un gran punto
de discusión para que el equipo vea cómo un WIP más bajo hace que los elementos de
trabajo fluyan más rápido a través de su proceso.
■ De las áreas, puede obtener mucha información. Por ejemplo, la creciente área Deployed
(el área inferior) muestra la cantidad de características entregadas a lo largo del tiempo. Y el
área Development muestra cuántos elementos se están desarrollando en un momento dado.
■ El área Inbox (el área superior) muestra cuántos elementos aún no se están trabajando. En
el diagrama de ejemplo, Inbox se mueve con las otras áreas, lo que significa que de vez en
cuando se agregan cosas nuevas a Inbox. Si un proyecto ya tenía una cartera de pedidos
establecida, el área de Inbox se reduciría con el tiempo.
Como puede ver, hay muchos datos que puede obtener de este diagrama y mirar hacia atrás para
analizarlos. Por ejemplo, ¿qué sucedió cuando comenzó a programar en pareja? ¿Subió o bajó el
WIP? Al mismo tiempo, ¿qué tipo de efecto tuvo eso en el tiempo del ciclo para el Development?
¿Eso también afectó el tiempo de entrega?
Todas estas preguntas y más pueden responderse utilizando el CFD, que es una gran
herramienta para que los equipos de kanban les ayuden a analizar su progreso. Debe ser diligente
cuando se trata de capturar los datos, pero también es gratificante porque el CFD muestra mucha
información de una manera agradable.
Diagramas comunes
* El gráfico de control de proceso estadístico (SPC) o el gráfico de ejecución muestra

los tiempos de entrega y/o ciclo
- Se puede dibujar a mano de manera simple
- La parte "estadística" agrega datos que muestran valores atípicos claramente
- Fechas de inicio y finalización necesarias para dibujar uno
* El diagrama de flujo acumulativo muestra la cantidad de trabajo por paso en su proceso
- Estado diario necesario para dibujar uno
- Contiene mucha información, trabajo en proceso por paso, tiempo de entrega/ciclo
11.3 Métricas como guías de mejora

Ahora hemos hablado mucho sobre diferentes métricas y diagramas y otras visualizaciones, y puede
pensar que será difícil elegir la correcta para usted y su equipo. Recuerde que una métrica (a
menudo) no es importante en sí misma, sino que es más bien una guía para su trabajo de mejora.
Las métricas lo ayudan a saber si está mejorando o no. Con las métricas establecidas, puede adoptar
un enfoque más experimental para aprender y mejorar, porque realmente no puede saber antes de
comenzar si va a mejorar.
Esta sección cubre algunas cosas para pensar en sus métricas y cómo las usa. Kanban se
basa en tres principios simples, uno de los cuales es visualizar el trabajo. Visualiza el trabajo para
ver y conocer información que de otro modo se habría perdido. Esta información lo ayuda a tomar
decisiones informadas sobre su proceso, el estado de su trabajo y cómo puede mejorar.
Las métricas son como la visualización de mejoras. Las métricas están ahí para ayudarlo a
determinar si los cambios que realiza, para mejorar, conducen a una mejora o si debe intentar algo
más. Con una buena métrica visualizada, puede comenzar a tener discusiones basadas en datos en
lugar de en corazonadas o creencias (evidencia anecdótica).
Cuando mide cómo se comporta su trabajo, también puede comenzar a ver cómo los
cambios que realiza para mejorar afectan esas métricas. Puede hacer pequeños experimentos y ver
cómo afectan la métrica que está tratando de mejorar.
HAZLO VISUAL
Una forma de visualizar las métricas es a través de diagramas como el siguiente. Visualizar sus
métricas no mejora su proceso, pero sí inicia discusiones basadas en los datos en lugar de en una
intuición. Se plantean preguntas, se pueden probar los experimentos y se puede rastrear el efecto de
ellos de una manera más controlada porque puede ver cómo el experimento ha cambiado su
tendencia.
Las métricas como guías de mejora 265
Si aún no está convencido, intente lo más simple posible de este capítulo: por ejemplo, el
seguimiento de los tiempos de entrega. Haga que la métrica sea visual y grande, y coloque los datos
en el tablero. Involucre la métrica en sus discusiones; consúltelo mientras habla de su trabajo. Muy
pronto la gente comenzará a hablar, preguntar y discutir. En estas discusiones, el equipo hablará
sobre las mejoras al proceso.
¿ESTÁS HACIENDO UN IMPACTO EMPRESARIAL O NO?

Cuando busque métricas, debe comenzar con lo que es importante para usted y su negocio. ¿Qué
metas estás tratando de alcanzar? ¿Cómo sabes si te diriges en esa dirección? A veces, estas no son
preguntas fáciles de responder y sobre rastrear métricas tampoco, pero aún debe esforzarse por
encontrar datos que muestren si está teniendo un impacto comercial.
Supongamos que su empresa está tratando de atraer más usuarios a su sitio. Si rastrea y
visualiza eso cerca de su tablero, puede mirar ese número y ver si sus esfuerzos están impactando
ese número, razonar sobre el trabajo que está haciendo a continuación, pensar en el efecto que
tendrá en la meta, y así. En resumen, usted hace evidente la meta comercial e intenta conectarlo más
cerca del trabajo que está haciendo.
USTED OBTIENE LO QUE MIDE
¿Qué ha pasado en la
Tierra con la calidad del
código? Tenemos varios
errores que se informan
cada día ahora ...
No hemos prestado
demasiada atención a la
calidad del código
últimamente. Nos dijiste
que nos centráramos en
sacar las cosas por la
puerta.
Obtienes lo que mides. Mide lo incorrecto y obtienes los comportamientos incorrectos.

—John H. Lingle
Establezca una meta o métrica, y pronto comenzará a ver a las personas cambiar su comportamiento
para alcanzar esa meta. Eso, al principio, puede parecer obvio y ser algo que desearías; pero cuando
lo piensas, también es un poco peligroso. Si comienza a medir el tiempo que tarda cada llamada de
soporte en un centro de llamadas, verá que las personas comienzan a cerrar las llamadas antes de
tiempo en lugar de centrarse en ayudar al cliente. Los trabajadores del centro de atención telefónica
preferirán las llamadas cortas a las más largas, incluso si eso significa que sus clientes no recibirán
la ayuda que necesitan. Las métricas pueden conducir a los empleados del centro de llamadas hacia
el comportamiento incorrecto.
El conocimiento de que “obtienes lo que mides”

también podría usarse para tu ventaja. Una de esas
técnicas es poner un límite a la cantidad de trabajo en
la columna Done, a veces denominado límite de
pastel (ver capítulo 12). Cuando se alcanza el límite,
el propietario del producto entra con el pastel y lo
distribuye al equipo. ¿Qué tipo de comportamiento
podría conducir esto? El equipo podría comenzar a
hacer historias más pequeñas que se hacen más
rápidamente y, por lo tanto, llenar la columna Done
con elementos de trabajo más rápidamente. Y eso es
bueno: historias más pequeñas que se mueven más
rápido a través del tablero, sí, por favor.
BALANCEE SUS MÉTRICAS

En su búsqueda de una buena métrica, también debe asegurarse de no concentrar toda su energía en
una métrica. Esto podría hacerle olvidar otros aspectos importantes de su proceso. Imagine que
tiene una métrica de rendimiento (número de elementos completados por semana, por ejemplo).
Con un fuerte enfoque solo en esta métrica, su equipo podría quemarse fácilmente, haciendo que la
gente odie el trabajo e incluso eventualmente irse. O pueden cortar esquinas con la calidad del
código que solo resultará en una deuda más técnica y finalmente ralentizará su proceso.22
Para solucionar este problema, le sugerimos que intente encontrar varias métricas que se
equilibren entre sí. Un ejemplo podría ser enfocarse tanto en el tiempo de entrega (tiempo que lleva
el trabajo durante todo el proceso) como en la calidad (número de errores en la producción, por
ejemplo). Con estos dos valores, intenta asegurarse de no caer en la trampa de comenzar a tomar
atajos para obtener un menor tiempo de entrega.
HÁGALOS FÁCILES DE CAPTURAR

El seguimiento de una métrica requiere que la recopile de alguna manera y luego la visualice o la
muestre a las personas que se preocupan por ella. Asegúrese de que la reunión no requiera mucho
esfuerzo. Si la métrica es difícil de recopilar, terminará en una situación en la que tendrá que
priorizar la recopilación de datos del proceso en lugar de "hacer el trabajo", arriesgándose a que no
se rastree en absoluto. Además, desea que la métrica pueda cambiar a medida que cambia su
proceso. Si utiliza métricas para las que ha invertido mucho en la recopilación de datos, corre el
riesgo de no querer cambiar, o incluso puede dejar de preocuparse por ellas. Eso podría dificultar la
introducción de nuevas métricas porque ahora está rastreando varias métricas, lo que podría
brindarle resultados contradictorios.
22
De hecho, hemos escuchado un par de historias de desarrolladores despedidos porque se preocuparon "demasiado"
por la calidad del código. Agregaron pruebas en torno a una base de código no probada cuando "deberían haber puesto
nuevas características en producción", un comportamiento que podría derivarse de centrarse demasiado en una cosa,
una métrica.
Las métricas como guías de mejora 267
PREFIERE DATOS REALES SOBRE DATOS ESTIMADOS

Intente utilizar datos reales en lugar de valores estimados. Los datos reales son datos que puede
obtener midiendo la forma en que funciona su trabajo, la calidad de su trabajo, cómo se utiliza el
producto, etc.
A diferencia de los datos estimados, no se puede discutir con datos reales. Siempre puede
cuestionar la forma en que se realizó una estimación y cómo se obtuvieron los números, pero con
datos reales se enfrenta directamente a los hechos. Todavía puede tener discusiones sobre el
número, por qué es así y qué hacer al respecto, lo que creemos que es algo bueno. Desea mejorar
continuamente la calidad de los datos y las formas en que los recopila.
Tenga en cuenta que los datos reales no significan automáticamente precisión. Los datos
reales pueden, por ejemplo, pedirle a la gente que vote con un puño de cinco 23 a la pregunta "¿Nos
estamos divirtiendo en este momento?" Esto también es información.
Rastreando dónde pasamos nuestro tiempo

Hay un escuadrón de apaga fuegos en Spotify. Su responsabilidad principal es manejar las
emergencias que ocurren en los sistemas de back-end y mantenerlos en funcionamiento.
Naturalmente, el equipo experimentó mucho trabajo reactivo. Pero pronto se dieron cuenta de que
tenían que comenzar a hacer un trabajo proactivo para mantener el sistema en forma y manejar los
problemas antes de que se convirtieran en emergencias.
Decidimos intentar rastrear dónde pasaban su tiempo: en el trabajo proactivo o reactivo. Esta
es una métrica que podría resultar difícil de rastrear: ¿deberíamos usar hojas de tiempo, rastrear
horas en papel o estimar?
Al equipo se le ocurrió un enfoque simple pero revelador. Después de cada día, publicaron un
adhesivo en un tablero que indicaba dónde habían pasado su tiempo ese día (principalmente).
Recopilamos los datos durante una semana y luego los resumimos para obtener una imagen más
amplia. Muy pronto vimos tendencias y pudimos comenzar a hacer algo al respecto. Esa
información no era perfecta, pero era lo suficientemente buena para nuestras necesidades.
23
Levantando uno a cinco dedos en respuesta a una pregunta.
USE MEDIDAS PARA MEJORAR, NO PARA CASTIGAR

Las métricas son motivadores poderosos que pueden ayudarlo a ver y seguir su progreso hacia un
mejor resultado. Pero, como con todas las herramientas poderosas, pueden ser mal utilizadas. Un
mal uso común que hemos visto es establecer metas para los equipos y luego responsabilizarlos por
el resultado de esas metas. En lugar de motivar al equipo, la métrica es usada para castigar al equipo
por los malos resultados.
No se ha completado una
sola característica este mes.
Aquí ... mira las
estadísticas.
Estamos pagando la
deuda técnica, como le
dijimos. Tomará algunas
semanas.
Esto no está bien. Recuerde

que se supone que debemos
sacar al menos cuatro
funciones nuevas cada mes.
No nos malinterpreten aquí; desea que el equipo se esfuerce por alcanzar la meta y que rinda
cuentas por el resultado, pero hay una sutil diferencia de intención. Esa diferencia se puede
encontrar en quién establece la meta. ¿Es una meta que el equipo ha establecido y comprometido?
¿O es una métrica asignada al equipo por una persona externa, como un gerente o una parte
interesada?
Asegúrese de incluir al equipo en el desarrollo de la métrica. Hacerlo genera compromiso y
la sensación de que la métrica es "nuestra" en lugar de "suya".
Las métricas como guías de mejora
* Las métricas no son mejoras: te ayudan a saber si estás mejorando

* No puedes mejorar lo que no puedes medir
* Usa métricas que conducen el buen comportamiento
* Use métricas balanceadas
* Use métricas que sean fáciles y baratas de atrapar
* Prefiera datos reales sobre estimaciones
* Use las métricas para mejorar, no para castigar
Resumen 269
11.4 Ejercicio: ¡mídelo!

Ahora tiene otra oportunidad de probar esto de verdad en su equipo. Siéntese y analice las métricas
que lo ayudarían a conocer el estado de su proceso:
■ ¿Ya tiene alguna métrica? ¿Están ellos bien? ¿Te ayudan a saber lo que está pasando?
■ ¿Se puede probar y experimentar alguna de las métricas sugeridas? ¿Cómo te ayudaría
eso?
■ ¿Hay alguna otra métrica que quiera presentar?
■ ¿Qué tipo de comportamiento desea fomentar? ¿La métrica ayudará a eso?
Comience simple y fácil. Recuerde que las métricas a menudo son difíciles de dejar de medir una
vez que comienza. Asegúrese de que todos conozcan el propósito de la métrica y que no envíes
métricas al equipo. Deberían provenir del equipo. "Sin métricas en este momento" es un resultado
válido de la discusión. Pregunte nuevamente más tarde si usted o alguien más ve la necesidad.
11.5 Resumen
En este capítulo, aprendió sobre las métricas y cómo pueden ayudarlo a rastrear su proceso:
■ Para saber si está mejorando o no, mide el comportamiento de su proceso y analiza estas
métricas.
■ Las métricas son como una visualización de la salud de su proceso.
■ Las siguientes son métricas comunes que usan los equipos kanban:
■ Tiempo de ciclo: tiempo necesario para completar parte del proceso.
■ Tiempo de entrega: tiempo necesario para completar todo el proceso.
■ Rendimiento: cuántos elementos se realizan por semana (o mes o lo que sea)
■ Número de problemas y bloqueadores en el tablero
■ Rendimiento de fecha de entrega
■ Demanda de valor versus demanda de falla: demanda en un sistema causada por la
falla en hacer algo o hacer algo correcto para el cliente
■ Estos son diagramas comunes que usan los equipos kanban:
■ Statistical process control (SPC) chart: una visualización de los tiempos de avance
y ciclo
■ Cumulative flow diagram (CFD): muestra mucha información sobre su proceso en
función de la cantidad de elementos por etapa en su proceso por día
■ Encontrar una buena métrica puede ser difícil. Recuerda lo siguiente:
■ Obtienes lo que mides.
■ No se centre en una sola métrica: utilice métricas balanceadas.
■ Use métricas que sean fáciles de capturar o hágalos así.
■ Prefiera datos reales sobre estimaciones.
■ Use las métricas para mejorar, no para castigar.
12 Trampas de kanban

■ Cómo evitar las trampas y críticas comunes de
kanban
■ El error número uno al comenzar a usar kanban
■ El hecho de que kanban no es un proceso en
absoluto, al menos no como podría pensar
A estas alturas debería tener muchas razones para usar kanban en su proceso. Puede mostrar a las
personas interesadas que kanban ha mejorado y continúa mejorando su proceso. Debido al enfoque
que adopta kanban para cambiar la gestión ("Comience donde está y mejore desde allí"), la mayoría
de los equipos y organizaciones no se oponen demasiado a kanban y los principios en los que se
basa.
Dicho esto, algunas críticas surgen de vez en cuando. No sería justo si al menos no
tocáramos los problemas más comunes y cómo tratarlos. En su mayor parte, la crítica se centra en
las trampas en las que es fácil caer si no se tiene en cuenta. Escribimos este capítulo para que sepa
qué evitar.
270
Todo trabajo y nada de juego hacen de Jack un chico aburrido 271
El objetivo de este capítulo es doble: presentarle algunas objeciones comúnmente planteadas y

luego ayudarlo a evitar las trampas identificadas por esta crítica. Aprender acerca de las formas en
que las personas critican es una excelente manera de mejorar: ayuda a asegurarse de mantenerse
alejado de las cosas malas.
Ok, lo entiendo, Beth, realmente

te gusta kanban. ¿Puedes decirme
algo que sea malo? O al menos
arriesgado?
¡Nada! Son todos unicornios y

zapatillas cómodas con orejas
de conejo.
Eeeh ... para ser justos, hay

algunas cosas a tener en cuenta y
las críticas que se han planteado.
Tomemos el toro por los cuernos y comencemos con las críticas que surgieron en los primeros años
de kanban, dirigidas por uno de los fundadores de Scrum.
12.1 Todo trabajo y nada de juego convierte a Jack en un niño aburrido
TRAMPA Kanban puede llegar a ser aburrido, con solo un elemento de trabajo tras otro, y sin
interrupciones, celebraciones o cadencias naturales.
SOLUCIÓN En comparación con Scrum, kanban le da la libertad de separar las diferentes
ceremonias, tales como planificación, revisión y retrospectiva, entre sí, dependiendo de cómo fluya
realmente el trabajo a través de su proceso.
272 CAPÍTULO 12 Trampas de kanban
(Todos los que revisaron la puerta para ver si Jack Nicholson estaba listo para entrar con un hacha,
levanten la mano.) El título de esta sección es una cita de la famosa película de terror The Shining,
en la que un autor con exceso de trabajo1 sigue escribiendo la frase "Todo el trabajo y nada de juego
convierte a Jack en un niño aburrido" en su máquina de escribir. También es lo que pensamos que
escuchamos decir a2 Ken Schwaber cuando criticó a la comunidad kanban temprana. La cita real es
esta:
Dios ayúdanos. La gente encontró formas de relajarse en la cascada, descansar y ser

creativo. Con Lean y Kanban, esos escondites se eliminan. Ahora tenemos una marcha de la
muerte progresiva sin pausa.
—Ken Schwaber 3
Ken Schwaber es, junto con Jeff Sutherland, el padre de Scrum. Estaba comentando la falta de
iteraciones en kanban. Para él, kanban era solo una larga lista de trabajos alineados, sin un final a la
vista: solo trabajo, trabajo, trabajo.
Día-0 ... díaaaa-0. ¡Llega la luz del día y queremos ir a casa!
Eso no suena demasiado bien, ¿verdad? Lamentablemente, tenía razón, especialmente teniendo en
cuenta muchas de las implementaciones de kanban que hemos visto en nuestros diferentes clientes y
lugares de trabajo.
1
Ni Marcus ni Joakim habían llegado a ese punto al momento de escribir. Nuestras familias están a salvo. Pero Marcus
no se ha atrevido a dar triciclos a sus gemelos.
2
Es un poco exagerado pero hizo un gran encabezado, ¿no estás de acuerdo?
3
"Cascada, Lean / Kanban y Scrum", http://mng.bz/OrXd.
Todo trabajo y nada de juego hacen de Jack un chico aburrido 273
Kanban es muy liviano y es fácil de poner en funcionamiento. Como ya hemos mencionado mucho,
son solo algunos principios simples. Si ya está haciendo Scrum o algún otro método basado en
iteraciones, incluso puede eliminar cosas como iteraciones, si lo desea. En poco tiempo, terminas
con un flujo continuo de trabajo y "sin holgura ... para descansar y ser creativo".
Pero no es así como debe ser, y no es cómo se pretende que sea kanban. ¡Todo lo contrario! Kanban
nunca dijo que eliminara las iteraciones. Pero sí le da la libertad de destacar las ceremonias de otros
métodos, como la planificación, las revisiones y las retrospectivas, entre sí.
Kanban no dice nada acerca de tener la misma cadencia para diferentes ceremonias o no. Si
lo encuentra útil, siga adelante y hágalo, pero no se vea obligado innecesariamente por ello.
Aproveche la oportunidad de diferir las decisiones hasta el "último momento responsable" 4 , cuando
tenga la mayor cantidad de información en sus manos. Usando kanban, también puede beneficiarse
enormemente al mostrar a sus partes interesadas lo que ha hecho y cómo está progresando, con
demostraciones y revisiones.
Volviendo a las críticas de Ken Schwaber con las que comenzamos esta sección. Podría
tener razón, pero no tiene por qué ser así. Asegúrese de dedicar tiempo a las revisiones,
retrospectivas y otras buenas prácticas. Pero hágalos cuando sea el momento adecuado, no porque
haya pasado una cierta cantidad de tiempo o cuando finalice la iteración. Hágalo cuando sea
necesario, justo a tiempo y no por si acaso. Hablamos de esto en el capítulo sobre planificación
(capítulo 9), donde describimos las cadencias.
Finalmente, el uso de los límites de WIP lo llevará a la colaboración, y también podría
terminar con "holgura ... para descansar y ser creativo" de vez en cuando.
La crítica del "trabajo, trabajo, trabajo"
* Kanban no prescribe cadencias para iteraciones, revisiones y demostraciones

* Puedes terminar en una inundación interminable de trabajo
* Pero no tienes que hacerlo, en su lugar
- Haz las ceremonias que consideres útiles, pero no las acople a tu flujo de trabajo
- Ejecútelos según sea necesario en lugar de según lo dicte un proceso
4
Mary y Tom Poppendieck, Lean Software Development, Addison-Wesley Professional, 2003,
http://amzn.com/0321150783.
12.1.1 Crear cadencias para la celebración

Para combatir el riesgo de que su proceso sea simplemente "trabajar, trabajar, trabajar", podría y
debería tener una cadencia de celebración. Es tan importante como otros eventos de los que hemos
hablado, y es una excelente manera de aumentar la moral y el disfrute del equipo. Las cadencias
para la celebración pueden tomar muchas formas, y a menudo no hay escasez de creatividad a la
hora de inventar nuevas formas de celebrar. En esta sección, le presentaremos dos formas de tener
cadencias de celebración como parte de su proceso.
MILLAS DE VIAJERO FRECUENTE

Con millas de viajero frecuente, el equipo puede acumular puntos por el trabajo que están haciendo.
Luego pueden usar puntos para hacer algo divertido juntos. Los puntos funcionan de manera muy
similar a las millas de viajero frecuente de una aerolínea: después de viajar un cierto número de
millas, la aerolínea le brinda algunos puntos para gastar en viajes gratis, habitaciones de hotel
mejoradas u otros beneficios.
El equipo y la parte interesada encuentran alguna forma de rastrear los puntos ganados por el
equipo y decidir qué hacer cuando el equipo alcanza un cierto umbral de puntos. Por ejemplo,
cuando haya completado 50 puntos de historia o 20 elementos de trabajo, tendrá una noche de pizza
y juegos en la oficina.
También hemos visto equipos trabajando en capas, lo que le permite ahorrar puntos para
obtener recompensas aún mayores. Por ejemplo, puede tener la noche de pizza y juegos en la
oficina con 50 puntos, o puede ahorrar puntos para el siguiente nivel, 100 puntos. Ahí es cuando la
parte interesada lleva al equipo a la ciudad para la etiqueta láser, la cena en un buen restaurante, etc.
ADVERTENCIA Probablemente deberíamos mencionar aquí que

es posible exagerar con las recompensas. Dan Pink habla de esto
en su libro Drive: The Surprising Truth about What Motivates Us
(Riverhead Books, 2011, www.danpink.com/books/drive). Pink
cita varios estudios que indican que, para el trabajo de
conocimiento, el resultado tiende a empeorar si paga más, otorga
DESAFÍOS bonificaciones más altas, etc. Utiliza las ventajas y celebraciones
ADELANTE que sugerimos aquí para pasar un buen rato con tu equipo. No
dejes que sean la única razón por la que la gente está trabajando para ti. Lea más sobre
eso en Drive.5
TRABAJANDO AL LÍMITE DE LA TORTA

Otra forma de crear una cadencia para la celebración es tener un límite de WIP en la columna final
del tablero. Al principio nos confundió cuando vimos eso en un tablero en Spotify, pero cuando el
equipo6 explicó el concepto, tenía mucho sentido. También es una buena manera de extender el uso
de los mecanismos en kanban a esta área.
5
Alerta de Spoiler: la autonomía, el dominio y el propósito nos impulsan, no más dinero, ni pizza y cervezas.
6
El equipo de Spotify comprendió rápidamente la mecánica de kanban y lo usó para introducir un mecanismo de
atracción para la celebración. Creativo y divertido!
Time Boxing es bueno para ti 275
El límite de WIP en Done limita la cantidad de

elementos que puede colocar en esa columna.
Supongamos que establece el límite en 15
elementos. Eso significa que después de
completar la columna Done con 15 elementos,
no puede terminar más elementos. Está a la
altura de su límite de WIP para Done. No solo
eso, sino que el trabajo también comienza a
retroceder en el flujo de trabajo (porque nada
puede avanzar), creando una urgencia creciente
para borrar la columna Done.
La única forma de borrar la columna Done
es que la parte interesada traiga el pastel 7 y
agradezca al equipo por el trabajo bien hecho.
Es brillante y divertido, y muestra los principios de colas y cuellos de botella de una manera
agradable.
Continuemos con otra crítica sobre el flujo que es el corazón de kanban. En resumen: no hay
timeboxes en kanban, pero puede agregarlos si lo necesita.
12.2 Timeboxing es bueno para ti
TRAMPA Kanban no tiene timeboxing incorporado. Desea cajas de tiempo porque le ayudan a
priorizar y hacer las compensaciones necesarias en alcance, tiempo y costo.
SOLUCIÓN Puedes tener cajas de tiempo donde sean beneficiosas. En procesos basados en flujo,
sin iteraciones, timeboxing puede implementarse con SLAs y plazos por elemento de trabajo, por
ejemplo.
Kanban es genial y todo, ¡pero seguro

que echo de menos las
demostraciones de fin de iteración!
Sí, esa caja de tiempo nos hizo

centrarnos en las cosas más importantes
y eliminar las cosas menos importantes.
Oh bueno, tengo que prescindir de
ellos ...
¡No tienes que hacerlo! Todavía

puedes tener timeboxes mientras
haces kanban.
7
O algo más que el equipo disfruta y se le permite comer y beber durante las horas de trabajo.
Timeboxing es una técnica poderosa que le ayuda a mantener el enfoque y tomar las decisiones
necesarias para entregar las cosas correctas a tiempo. El siguiente triángulo es una forma de mostrar
de qué se trata el timeboxing. Ilustra las compensaciones que debe realizar en cualquier proyecto,
pero en particular para proyectos de software (a veces llamados triángulo de hierro o restricciones
triples).
Este triángulo equilibra el alcance, el tiempo y el costo entre sí. Scope se refiere al alcance de las
características que alguien quiere. Cost es cuánto dinero costará, por ejemplo, cuántas personas hay
en el equipo y qué hardware/software se necesita para construirlo, y otros costos. Time representa
cuánto tiempo llevará el esfuerzo, o la fecha de vencimiento cuando el proyecto debe realizarse.
En el medio del triángulo hay un cuarto aspecto 8: Quality. Puede tener en cuenta la calidad y
hacer concesiones con ella. Más a menudo que no, eso crea problemas después en forma de deuda
técnica que debe pagarse. A menudo no recomendamos comerciar con calidad, sino que sugerimos
tratar de hacer que la calidad sea lo mejor posible, teniendo en cuenta los otros aspectos.
Deuda técnica
La deuda técnica es una metáfora que Ward Cunningham acuñó. Le ayuda a pensar en las cosas
que debería haber hecho a su código, que no tenía prisa para hacer o que era demasiado descuidado
para introducir. Al igual que con la deuda financiera, la deuda técnica implica intereses. Si no hace
nada acerca de la deuda técnica, el interés aumenta con el tiempo (en forma de esfuerzo adicional
necesario para mantener el código en condiciones de funcionamiento), y pronto se encuentra
pagando el interés. Esto crea una situación en la que no puede desarrollar nuevas funciones porque
todos sus recursos se gastan para mantener el sistema en funcionamiento.
8
Sí, cuarto. En un triangulo. Quédate con nosotros.
Time Boxing es bueno para ti 277
De vuelta al triángulo. El meollo de la cuestión es que no

puedes solucionar estos tres aspectos. En realidad, podrías,
pero verás más tarde por qué eso se consideraría malo. En aras
de la discusión, digamos que acepta que no puede fijar el
tiempo, el alcance y el costo.
¿Cuáles son tus opciones, entonces?
■ Puede fijar el tiempo y el alcance y dejar que el
costo varíe. "Habremos terminado con esta función
exacta a las 0900 del 14 de mayo, pero nos va a costar". A la mayoría de las empresas y
partes interesadas no les gusta esa configuración. Y en su mayor parte, es muy difícil hacer
que los proyectos de desarrollo de software sean más rápidos al atraer a más personas 9 al
equipo. Escribir código no es la mayor restricción en el desarrollo de software; son
aprendizaje y comprensión.10
■ Vamos a fijar el alcance y el costo en su lugar y dejar que el tiempo varíe. "Tendremos
esta lista exacta de características listas, y costará $ 47,343, pero no sabemos cuándo
terminaremos". Esto también es algo de lo que la mayoría de las empresas evitan: a menudo
es peor que dejar que el costo varíe. Las empresas quieren algún tipo de previsibilidad, y
decir: "No sabemos cuándo terminaremos" es más incertidumbre de lo que la mayoría de las
organizaciones pueden hacer frente. Otro problema (posiblemente mayor) con este enfoque
es que supone que puede conocer el alcance antes de comenzar algo y que no habrá nuevos
descubrimientos. Por estas razones, el "alcance fijo" rara vez es realmente fijo de todos
modos.
■ Que dejes fijar el costo y el tiempo y dejar que el alcance varíe. "Terminaremos a las 0900
el 12 de mayo, y eso le costará el salario de estos seis tipos durante ese tiempo. Pero no
sabemos qué se hará para entonces". Aunque eso suena aterrador al principio, en realidad es
una oportunidad de negocio. Le da la oportunidad de ordenar la lista de elementos que desea
que el equipo haga en orden de valor comercial, haciendo primero los más valiosos. O si los
valores comerciales son difíciles de ver o conocer, puede ordenar la lista de elementos para
hacer en orden de cuánto puede aprender o cuánto riesgo puede reducir. Con una estimación
rápida, el equipo probablemente podría adivinar qué tan lejos llegarían.
El último enfoque se conoce como timeboxing: fijar el tiempo (y el costo) para cuándo se deben
hacer las cosas y ajustar el alcance en consecuencia.
9
"Nueve mujeres no dan a luz a un niño en un mes" es algo que un colega ingenioso a menudo le ha dicho a Marcus
para transmitir el mensaje.
10
Si necesita más evidencia para eso, pregúntele a cualquier persona involucrada en un proyecto si continuaría más
rápidamente si tuviera la oportunidad de hacerlo de nuevo. Lo más probable es que digan: "Sí, por supuesto". Luego
pregúntales por qué. ¿Qué te hizo ir más lento la primera vez?
¡Fija todos los aspectos! ¡Hazlo! ¡Hazlo ahora!

Dijimos que no puede fijar las tres variables (alcance, costo y tiempo) en el triángulo. Eso no es
del todo cierto. Podría, pero ese enfoque crea otros problemas.
Si se fijan todos los aspectos, algo tiene que ceder cuando llegas tarde o necesitas hacer
compensaciones. Debido a que los tres aspectos son fijos, lo único que queda por compensar es la
calidad. Eso significa que estás empezando a descuidarte o a hacer las cosas más rápido de lo que
puedes manejar. Eso eventualmente regresará y lo morderá en forma de deuda técnica. Cuando nos
vemos obligados a fijar el alcance, el tiempo y el costo, a menudo aumentamos nuestras
estimaciones para tener en cuenta el riesgo.
Nunca ha sido tan evidente que en una reunión de revisión en la que Marcus estuvo una vez.
El proyecto había quedado por debajo del presupuesto (!), Y el negocio estaba muy satisfecho pero
quería saber por qué. El gerente de proyectos de TI estaba un poco incómodo con esa pregunta,
pero finalmente dijo: “Bueno, siempre agregamos un 30% a nuestras estimaciones antes de
enviárselas. Solo para manejar el riesgo de que nos equivoquemos.
Eso hizo que la gente de negocios se echara a reír. Cuando se calmaron, lograron decir:
“Cuando recibimos sus estimaciones, siempre agregamos un 30%. Solo para manejar el riesgo de
que sus estimaciones estén equivocadas.
Fijar los tres aspectos es malo en más formas de lo que parece, porque significa que está
retrasando los comentarios y posponiendo las decisiones hasta que sea demasiado tarde para hacer
algo al respecto. Por ejemplo, si proporciona la estimación (por ejemplo, 10 semanas) y se da
cuenta a mitad de camino de que no le llevará 10 semanas, probablemente necesite aumentar su
estimación. Si ha "amortiguado" la estimación en un 30%, probablemente esperará un poco más
antes de plantear el problema, y se perderá más tiempo y dinero.
Disculpe, señores, pero dijeron

Volvamos a la crítica sobre kanban y algo sobre algunas críticas
timeboxes. Ahora puedes ver las cosas sobre timeboxing y kanban.
buenas que traen los timeboxes. Lo ¿Llegaremos a eso pronto?
principal es que proporcionan una

restricción que debes asumir que te
asegura que priorizas y haces las cosas
más importantes primero.
En procesos basados en iteraciones como Scrum y XP, los timeboxes naturales están
integrados en el proceso. En Scrum, se denominan sprints: iteraciones de timeboxed para las cuales
el equipo toma las características principales en la backlog o cartera de productos. El tiempo y el
costo se establecen de antemano, y el alcance que asume el equipo se ordena en valor comercial. Si
el equipo falla, las características menos valiosas son las que no se realizan durante el sprint.
Un proceso basado en flujo como kanban no tiene cajas de tiempo integradas. Es solo un
flujo, ¿verdad? Es un río de trabajo largo e interminable que viene hacia ti. Bueno, no tiene que ser
así. Puede crear cuadros de tiempo propios, por ejemplo, para elementos de trabajo individuales,
conjuntos de elementos de trabajo o columnas en su proceso.
La revolución necesaria 279
El uso de fechas límite en sus tarjetas de elementos de trabajo, SLA y diferentes clases de servicio
(consulte el capítulo 8) es una forma de asegurarse de obtener algunas restricciones en su sistema.
Eso, a su vez, te ayuda a concentrarte en hacer lo correcto primero.
Las iteraciones y los timeboxes lo alientan a recortar la cola de cuánto trabajo puede
exprimir en la iteración. Esto puede ser útil y beneficioso porque puede empujarlo a dividir grandes
elementos de trabajo en dos y llevar la segunda parte a la siguiente iteración. Cuando haya
terminado con la primera parte del elemento de trabajo, es posible que la segunda parte no sea
realmente necesaria.
Cuando, en un proceso basado en el flujo, se concentra en elementos individuales, en su
lugar, está recortando la cola de cada historia de la misma manera. Puede mover una función
avanzada (como un buen cuadro desplegable para la selección, por ejemplo) a un elemento de
trabajo propio y utilizar un cuadro de texto con el valor numérico. Y he aquí, tal vez sus usuarios
sean lo suficientemente avanzados como para que les guste ingresar el valor numérico mejor, y
resulta que es aún más rápido para ellos.
La crítica " timeboxing es bueno"
* Timeboxing es una gran técnica que te ayuda a concentrarte

en lo que es importante
* Kanban no dice nada sobre el uso de timeboxes
* Pero puedes tener timeboxes en kanban:
- Fechas de vencimiento para los elementos de trabajo
según el tamaño
- SLA para diferentes tipos de trabajo o clases de servicio
* Recorte de trabajo para iteraciones o para elementos de
trabajo individuales
Ahora hemos abordado dos críticas que a menudo surgen en torno al comportamiento de los
procesos basados en el flujo. Otro se relaciona con la forma sutil y no intrusiva de introducir
kanban. ¿Puede eso ser realmente criticado? Sí, como descubrirá en la siguiente sección.
12.3 La revolución necesaria

TRAMPA
Kanban adopta un enfoque evolutivo para la gestión del cambio y lo insta a comenzar donde está, a
aceptar el cambio incremental y respetar el proceso y los roles actuales. Pero, ¿y si necesitas una
revolución? ¿Qué pasa si la organización o el equipo necesita ser sacudido y agitado un poco?
SOLUCIÓN Tienes el control del tempo en el que quieres mejorar. Utilice un límite inferior de
WIP para provocar más oportunidades de mejora, por ejemplo. O comience a utilizar nuevas
prácticas, como el desarrollo basado en pruebas (TDD) y la programación de pares a un ritmo
adecuado para su organización.
Kanban es genial porque comienza donde estás. Puede comenzar a usar kanban sin cambiar nada.
Simplemente visualice su forma de trabajar y limite la cantidad de elementos que ocurren al mismo
tiempo. A partir de eso, puede mejorar y evolucionar su proceso a medida que aprende más.
Esta es una buena noticia porque significa que puede introducir kanban fácilmente en casi cualquier
entorno, independientemente del proceso con el que esté trabajando hoy. No hay big bang, no hay
cambios de títulos y roles, puedes seguir trabajando como solías hacerlo. La parte de visualización
es algo con lo que incluso los oponentes más ávidos de las nuevas formas de trabajar a menudo
pueden vivir, siempre y cuando se mantenga alineado con las formas en que trabaja ahora.
En resumen, kanban se puede introducir como una evolución, evitando cambios
revolucionarios dolorosos. A estas alturas, puede que se pregunte cómo demonios esto puede ser
una crítica de kanban. Es fácil de ver, de hecho: resulta que a veces necesitas una revolución. A
veces necesitas sacudir las cosas y hacer que tu organización se despierte. Para sobrevivir o
aprovechar las nuevas oportunidades comerciales, es posible que tenga que cambiar mucho y
cambiar rápidamente. Si ese es el caso, entonces probablemente debería usar un método probado
(como Scrum o XP) y luego agregar los principios kanban además de eso para impulsar la mejora.
Puede pensarlo en términos de evaluación de riesgos: un equipo pequeño y maleable, con la
voluntad de probar algo nuevo y un gran entrenador cercano, probablemente pueda cambiar mucho
sin arriesgar demasiado. Por otro lado, si usted es un equipo de Cobol en una organización bancaria
grande y conservadora, el riesgo de cambio es mayor.
No permitas que kanban se convierta en una excusa para ser perezos@ 281
La buena noticia aquí es que tienes el control del tempo con el que mejoras con kanban. Con límites
de WIP más agresivos y más bajos, por ejemplo, se presentarán más oportunidades de mejora. Poner
las cosas en producción antes y con mayor frecuencia proporcionará comentarios más rápido y, por
lo tanto, le dará aún más razones para cambiar y mejorar. Si terminas con demasiados problemas
para mejorar al mismo tiempo, siempre puedes retroceder de tus límites de WIP nuevamente y
manejar el problema más grande primero, como es normal. (Lea más sobre cómo controlar los
límites de WIP en el capítulo 6.)
Puede agregar prácticas de otros métodos para sus necesidades, como mejor le parezca. Por
ejemplo, elija algunas prácticas de XP, como la programación de pares o el desarrollo basado en
pruebas, para controlar la calidad de su código. O puede comenzar a buscar en el mapeo de impacto
y las especificaciones, por ejemplo, para controlar las primeras etapas de la vida de su funcionalidad
y asegurarse de que está construyendo lo correcto. En los últimos años, la entrega continua y las
ideas detrás de Lean startup se han vuelto populares. Estos métodos se centran en acortar los ciclos
de retroalimentación en su proceso para que pueda obtener retroalimentación sobre sus nuevas
funcionalidades más rápidamente. Los principios de kanban pueden ser de gran utilidad aquí para
ayudarlo a visualizar y rastrear el flujo rápido de sus funcionalidades.
En resumen, usted tiene el control de la velocidad y el alcance de la mejora de sus procesos.
Asegúrese de mejorar a la velocidad que usted y su organización pueden manejar. Pero no vayas
muy despacio: a veces necesitas una revolución.
La crítica de "a veces necesitas una revolución"
* Kanban se puede presentar como evolutivo

* Pero a veces necesitas una revolución para sacudir las cosas
* Usted tiene el control de la velocidad a la que mejora
* Puede usar otros métodos (o prácticas a partir de ellos)
y agregar los principios kanban para impulsar mejoras
Hablando demasiado lento: para algunos equipos, kanban puede convertirse en una excusa para
dejar de hacer las buenas prácticas que ya estaban en su lugar. Ese es el tema de la próxima sección.
12.4 No permita que kanban se convierta en una excusa para ser perezos@
TRAMPA Debido a que son solo tres principios simples, kanban no dicta mucho en absoluto. Esto
a veces puede convertirse en una excusa para dejar de hacer cosas que lo están ayudando hoy.
Puede volverse perezos@.
SOLUCIÓN Siga haciendo las prácticas que haya encontrado útiles hasta que vea una buena
razón para dejar de usarlas. Cuando obstaculizan su flujo, puede comenzar a preguntarse cómo o si
debe hacer la planificación, la estimación, las iteraciones, etc.
¡Amo kanban!
Desde que
comenzamos a
hacer kanban,
no tenemos
plazos ni
demos. Kanban
no dijo nada al
respecto. ¡Así
que dejamos de
hacer eso!
Eeeh ... Tampoco

estamos
entregando nada.
¿Estás seguro de
que lo estamos
haciendo bien?
Algunos equipos que comienzan a "hacer" kanban dejan de hacer las buenas prácticas que les ha
dado algún otro método, como paradas, retrospectivas y revisiones. A menudo escuchamos cosas
como "Solíamos planificar nuestro trabajo, pero ahora, con kanban, lo hemos detenido". Otros
equipos son lo contrario y, en primer lugar, no comienzan con prácticas ágiles. "Scrum no funciona
para nosotros! Intentamos una reunión de planificación ayer, y fue aburrido. En cambio, haremos lo
nuevo llamado kanban. Es simplemente un parada diaria (podríamos eliminarlo más tarde) y
algunos adhesivos en una pared. Eso es suficiente para nosotros".
Estos equipos se pierden un aspecto importante. Te dejaremos entrar en secreto, tan tarde en
el libro.11 Apóyate muy cerca de la página. Allí. Aquí vamos: no puedes hacer kanban. Una vez más,
un poco más fuerte: no puedes hacer kanban.
Sí, lo leíste bien. No puede "ejecutar kanban" en su empresa. Ni siquiera puedes "cambiar de
Scrum a kanban". Lo que puede hacer y sacar mucho provecho es aplicar los principios kanban a su
proceso. Se puede decir que kanban es un metaproceso, un proceso de mejora para los procesos.
11
Bueno, ya dijimos esto, en realidad. En el capítulo 2, dijimos que kanban no es un proceso como otros, sino un
metaproceso que puede aplicar a otros procesos que ya está ejecutando.
No permitas que kanban se convierta en una excusa para ser perezos@ 283
Si su cabeza le da vueltas debido a esa oración, no se sienta mal. Es así para todos nosotros, 12 al
menos al principio. Pero esta es realmente una gran noticia, porque significa que puede aplicar
kanban a cualquier método con el que esté trabajando hoy y mejorar desde allí.
Volvamos a los equipos que dejan de hacer otras cosas porque han "comenzado a hacer
kanban": kanban no dice nada acerca de detener las prácticas que ayudan a mover el trabajo a través
de su flujo de trabajo o que mejoran la calidad del proceso en el que está trabajando. Después de
hacer kanban por un tiempo, puede terminar cuestionando sus prácticas actuales y comenzar a
preguntarse si realmente proporcionan valor. Pero hasta entonces, sigue haciéndolos como si nada
hubiera cambiado. Porque no lo ha hecho. Acaba de comenzar su viaje de mejora con kanban.
Hasta que encuentre una buena razón para detenerse, siga haciendo lo siguiente:
retrospectivas, revisiones y sprints (con una sesión de planificación al principio y una revisión al
final). Siga escribiendo largos documentos de especificaciones y entregándolos en la siguiente fase
de su proceso.
Kanban pronto le mostrará lo que está ralentizando su flujo. En su flujo de trabajo
visualizado (en el tablero, por ejemplo), puede ver cuándo se acumulan los elementos de trabajo.
Sus métricas y diagramas pueden ayudarlo a ver dónde se ralentiza el proceso. Estas cosas
eventualmente pueden llevarlo a comenzar a cuestionar la forma en que escribe especificaciones,
reajustes, sprints, etc.
Una de las cosas con las que hemos visto que se enfrentan muchos equipos kanban es no
usar los límites de WIP. Uno pensaría que la mayoría de los equipos creerían en eso (porque es uno
de los tres principios), pero sucede mucho. Aquí hay un escenario muy común con el que muchos
equipos terminan al introducir kanban en su proceso:
Vamos a introducir
kanban con mucho
cuidado. Simplemente
escribiremos el proceso
tal como está.
¿No deberíamos tener

algunos límites de WIP?
Recuerdo que eran
importantes ...
Fácil allí ... un paso a la

vez. No hay límites de
WIP en este momento.
Eso viene más tarde,
cuando, y si, vemos la
necesidad de ello.
12
Excepto por Torbjörn Gyllebring (@drunkcod), quien se ha hecho un nombre dando explicaciones de que "kanban no
es tu proceso" a la comunidad kanban.
Muchos equipos comienzan a usar los principios kanban sin ningún límite de WIP. Esto es un error,
en nuestra opinión. Sin límites de WIP, no hay tensión para impulsarlo a mejorar su proceso. Puede
seguir agregando trabajo en proceso cuando surjan problemas. A menudo, esto se manifiesta como
una gran cantidad de elementos de trabajo bloqueados o en espera en el tablero.
Puede comparar esto con una iteración que se puede extender indefinidamente. No hay
ningún incentivo para completar el alcance de la iteración a tiempo; siempre puede ampliar el
alcance.
Recuerde la verdadera naturaleza de un límite WIP: no es una regla, sino una guía y un
desencadenante de discusión. Sin ella, no hay razón para tener la discusión. Simplemente sigue
agregando trabajo a su proceso, y no existe un mecanismo para preguntar si debe hacer esto o no.
Una razón común por la que los límites de WIP nunca se introducen es que puede parecer
desalentador encontrar el número "correcto" para el límite de WIP. El Capítulo 6 contiene una serie
de sugerencias para esto. Uno que es realmente fácil de comenzar se llama "Déjate caer y dame 20"
(ver sección 6.3.3). Básicamente, elige un número grande y luego cae el límite de WIP (número
permitido de elementos de trabajo) gradualmente hasta que comience a tener problemas. Luego,
retroceda un poco en el límite de WIP y comience a hacer algo sobre sus problemas.
Finalmente, recuerde que no hay un límite de WIP correcto. El límite de WIP es solo una
herramienta que controlas que te ayuda a impulsar mejoras. Sin ella, no hay razón para mejorar.
Primera retrospectiva de la historia

Para un cliente, Marcus facilitó la primera retrospectiva para un equipo que había estado
trabajando juntos durante unos 15 años. Solo recientemente comenzaron a visualizar su trabajo y
se les presentaron los principios de kanban.
Al igual que muchos equipos en su situación, todavía no habían agregado ningún límite de WIP.
Efectivamente, durante la retrospectiva, algo superior para mejorar fue cómo manejar y
administrar tareas que se agregaron inesperadamente a su carga de trabajo. El equipo se había dado
cuenta de que estos elementos eran perjudiciales para su flujo, ralentizando el trabajo que hicieron.
Se dieron cuenta de que un simple límite de WIP haría que se llevara a cabo una discusión cuando
se iba a presentar un nuevo elemento. El propietario del producto estaba satisfecho con tres niveles
de escalamiento:
■ Póngalo al final del backlog: "Lo tomaremos cuando lleguemos allí".
■ Póngalo en la parte superior del backlog: "Tomaremos eso a continuación, después de
terminar las cosas que estamos haciendo ahora".
■ Empújelo a la columna Doing a costa de otro trabajo: "Dejaremos lo que estamos haciendo
ahora y haremos esto en su lugar".
Lo interesante es que antes de que se estableciera el límite de WIP, no había ninguna razón real
para tener una conversación de este tipo. Los elementos simplemente se introdujeron en la carga de
trabajo actual, y todos intentaron hacer frente a la nueva carga.
Resumen 285
La crítica de "kanban te hace floj@"
* Kanban no prescribe muchas prácticas, solo un par de principios

* Esto puede hacerte perezoso sin restricciones que te empujen a
mejorar
* Use las prácticas que le resulten útiles
* Kanban es un proceso para mejorar procesos
* El error #1 al comenzar a usar kanban es no tener ningún límite
de WIP
No dejes que kanban se convierta en una excusa para detener tus buenas prácticas. Kanban debería
ayudarlo a mejorar su proceso, no empeorarlo.
12.5 Resumen
En este capítulo, analizamos algunas trampas y las críticas que se han planteado sobre kanban.
También mostramos cómo puede evitar caer en esas trampas:
■ Kanban puede terminar siendo un largo flujo de trabajo que parece no tener fin: es solo
trabajo, trabajo, trabajo. Asegúrese de que eso no le suceda agregando cadencias para
revisiones, retrospectivas y planificación según sea necesario.
■ No se sugiere un timeboxing cuando se usa kanban, lo que puede eliminar la restricción
que necesita para terminar las cosas y hacer compensaciones para hacerlo. Para abordar esto,
agregue cajas de tiempo a elementos individuales; use fechas límite/fechas de vencimiento o
SLAs.
■ Kanban es genial porque comienza donde estás: no tienes que cambiar nada sobre cómo
trabajas para comenzar a usar Kanban. Pero a veces necesitas una revolución:
■ Nada le impide asumir nuevos roles o formas de trabajar.
■ También puede controlar el tempo al que mejora limitando WIP, más o menos.
Menos WIP significa más oportunidades para mejorar.
■ Kanban es un metaproceso, un proceso de mejora para un proceso ya existente. No elimine
las cosas que funcionan hoy simplemente porque kanban no dice nada sobre ellas.
■ El error número uno al comenzar con kanban es comenzar sin ningún límite de WIP. Esto
significa que no hay ninguna restricción que lo empuje a mejorar.
13 Enseñar kanban
a través de juegos
■ Uso de juegos y simulaciones para enseñar los
principios de kanban.
■ Dirigir debates que ayuden a los equipos a aplicar
estos principios en su trabajo diario.
■ Uso de la simulación getKanban como una
introducción independiente a kanban
Este capítulo presenta algunos juegos que hemos realizado y utilizado para presentar a los equipos a
kanban. No los inventamos, por lo que intentaremos atribuirlos correctamente. Algunos de los
juegos en la comunidad ágil son casi míticos y parecen haber existido desde siempre. La verdadera
fuente o creador puede ocultarse en todas las variantes y cambios realizados en el juego a lo largo
de los años. Hemos revisado nuestra red de colegas para tratar de encontrar las fuentes de los juegos
que presentamos, ojalá hayamos encontrado los correctos. Si no lo hemos hecho, lo sentimos;
ayúdenos a corregir esto enviándonos un mensaje a través del enlace del Autor Online en
www.manning.com/kanbaninaction.
A medida que comience a usar kanban con su equipo y en su lugar de trabajo, pronto
encontrará a otras personas a su alrededor que estén interesadas en lo que está haciendo. Incluso
286
287
podría ser el caso de que hayas comenzado a presentar a los demás los conceptos. Si eres como
nosotros, pronto estarás enseñando conceptos y prácticas kanban.
Podrías darle a tus colegas este libro y decirles: "¡Háblame otra vez cuando hayas leído
esto!" 1 Pero hemos descubierto que realizar un ejercicio concreto y práctico hace que los conceptos
se adhieran mucho mejor. Esta idea se basa libremente en el pensamiento detrás del aprendizaje
basado en la experiencia definido por David Kolb (Experiential Learning, Prentice Hall, 1984,
http://amzn.com/0132952610).2 A menudo comenzamos nuestra presentación con un juego o
ejercicio que muestra un principio en acción y luego nos referimos a lo aprendido al presentar los
conceptos teóricos en kanban. En la introducción, jugamos a Pase los Peniques con el equipo para
mostrarles por qué quieren limitar WIP.
Para cada juego cubierto aquí, agregamos algunos consejos, comentarios y preguntas para
iniciar una discusión y ayudar al proceso de aprendizaje. La siguiente tabla muestra un breve
resumen de los juegos y los conceptos de los que hablaremos.
Sección Juego Conceptos enseñados
13.1 Pass the Pennies Limitar WIP conduce a tiempos de entrega más cortos.
13.2 The Number Multitasking Limitar WIP conduce a tiempos de entrega más cortos.
La multitarea conduce a la pérdida de tiempo y a un
enfoque y calidad deficientes.
13.3 The Dot Game Limitando WIP, ajustando el proceso hacia un flujo aún
más rápido, colaboración. La ley de Little y la inserción
de más elementos en el sistema aumentan la WIP, lo que
a su vez ralentiza el flujo.
13.4 The Bottleneck Game Mejore el flujo en un sistema utilizando la Teoría de las
Restricciones.
13.5 getKanban Mejore su proceso utilizando los principios kanban en la

práctica.
13.6 The Kanban Pizza Game Mejore su proceso aplicando los principios kanban,
limitando WIP y haciendo retrospectivas en incrementos
cortos.
Son bastantes juegos, así que comencemos de inmediato con un juego rápido y práctico que muestra
por qué limitar WIP es una gran idea.
1
¡Y por supuesto hazlo!
2
Véase también "¿Qué es el aprendizaje basado en la experiencia?" en http://mng.bz/9Ik1.
288 CAPÍTULO 13 Enseñar kanban a través de juegos
13.1 Pass the Pennies

Pasar los Peniques (a veces llamado Voltear el Chip “Flip the Chip”, ) fue mencionado en el
capítulo 1, cuando Marcus y Joakim jugaron este juego con los Kanbaneros. El juego es una forma
rápida y atractiva de introducir el concepto de WIP y mostrar por qué limitar WIP es una buena
idea. Como recordará del capítulo 5, limitar WIP hará que su trabajo fluya más rápido a través de su
proceso. Después de haberlo jugado, puedes tener una discusión sobre cómo limitar el WIP. ¿Cuáles
son los "peniques" que está pasando en su proceso? ¿Cómo se limita la cantidad de trabajo? ¿Qué
pasaría si lo hicieras?
Hemos visto muchos "¡Ajá!" Reveladores momentos cuando jugamos este juego con
equipos, y hemos escuchado a personas mencionar el juego años después de haberlo jugado. Pasar
los peniques tarda unos 15 minutos en jugar, y debes dejar al menos 15 minutos más para discutir lo
que aprendiste.
13.1.1 Lo que necesitas para jugar

Necesitas lo siguiente para jugar (incluidos nueve jugadores, preferiblemente):
■ 4 trabajadores que lanzan los peniques
■ 4 gerentes que cronometran a su trabajador
■ 1 cliente o gerente de proyecto (puede ser jugado por usted, el facilitador, si es necesario)
■ 20 peniques (monedas) de igual tamaño
■ Una mesa para jugar
■ 5 cronómetros (o teléfonos con aplicaciones de cronómetro)
■ Una pizarra o rotafolio para escribir resultados
Asegúrate de haber leído y entendido el juego y de haberlo jugado tú mismo antes de intentar
facilitarlo. Esto se aplica a cada juego y ejercicio que corres y enseñas a otros.
13.1.2 Cómo jugar

El objetivo para cada rol es el siguiente:
■ Trabajadores: voltee todas los peniques y páselas al siguiente trabajador en línea.
■ Gerentes: midan el tiempo efectivo que cada trabajador voltea peniques.
■ Un cliente: determina el tiempo total en dos aspectos: el tiempo que lleva entregar el
primer penique y el tiempo total (hasta que se entrega el último penique).
El juego se hace en tres iteraciones: lotes de 20, 5 y 1 peniques. En cada iteración, el juego se hace
exactamente igual, excepto que se baja el WIP (tamaño del lote). La meta, el proceso y el orden de
los ejercicios son los mismos.
Siente a los trabajadores alrededor de la mesa con un gerente detrás de cada trabajador. Indique a
los gerentes que usen el cronómetro para rastrear el tiempo efectivo que el trabajador está
trabajando. Pídale al cliente que mida el tiempo de entrega del primer penique y el tiempo total de
entrega de todos los peniques.
Cuando la primera iteración de 20 peniques
esté en marcha, tendrá mucho tiempo para
dibujar una tabla para el resultado en la pizarra,
como la de la derecha. Espere para anotar los
resultados hasta que termine la iteración.
Cuando se agregan todos los resultados, haga
una pausa por un momento para que los
jugadores reflexionen sobre ellos.
A cada pareja de gerentes y trabajadores se
les puede permitir una breve "charla
motivacional", por diversión.
Ahora dígale al equipo que no está satisfecho con el resultado y que desea ejecutar la próxima
iteración con cinco peniques. Asegúrese de recordarles a todos que lo único que cambia es el WIP.
Mida todo el tiempo que cada empleado está trabajando.
Cuando termine la iteración de cinco

peniques, tenga en cuenta los resultados.
Puedes ver los resultados que tuvimos
con un equipo en la tabla de la izquierda.
Los resultados probablemente levantarán
algunas cejas, porque el tiempo de la
primera entrega se redujo mucho: ¡de
1:18 a 18 segundos en nuestro ejemplo!
El tiempo general también mejoró
considerablemente, cayendo de 1:18 a
solo 40 segundos. Dele al equipo un par
de minutos para hablar y reflexionar
sobre lo que sucedió.
Sin embargo, en poco tiempo, debe

comenzar la iteración final de un
penique. Use la misma meta y reglas que
antes. Cuando termine la última iteración
(pasa rápidamente), anote el resultado.
Debería terminar con una tabla como esta
(con columnas para 20, 5 y 1).
Asegúrese de agradecer a todos por jugar, y luego comience una discusión para analizar los
resultados.
13.1.3 Preguntas para discusión

A menudo hacemos preguntas como estas para provocar una discusión:
■ ¿Qué pasó con el tiempo total? ¿Por qué?
■ ¿Qué pasó con el tiempo de cada trabajador individual? ¿Por qué?
■ ¿Cómo se sintió al ejecutar el juego? ¿Cuándo fue estresante? ¿Cuándo estuvo más
tranquilo?
■ ¿Se puede traducir este juego a tu trabajo?
■ ¿Cuáles son los peniques en tu trabajo?
■ ¿Qué no es aplicable en su contexto?
■ ¿Qué pasaría si bajara el número de "peniques" en su contexto?
■ ¿Qué te impide hacer eso?
■ ¿Qué no se puede traducir a su situación laboral?
Siéntase libre de agregar otras preguntas como mejor le parezca o mientras la discusión divague.
El juego multitarea de números 291
13.1.4 Principales conclusiones

De las tablas de resultados anteriores, puede ver fácilmente que el tiempo para el primer penique
disminuye mucho. Esto suele ser lo que sucede con lotes pequeños que se mueven a través de la
cadena de valor en un flujo continuo.
Para cada trabajador individual, los tiempos generalmente (pero no siempre) tienden hacia
arriba. Esto puede desencadenar una discusión sobre cómo, cuando optimiza el flujo, los recursos
no pueden utilizarse al 100%. Puede hablar sobre para qué se está optimizando el equipo o si es
importante que todos estén plenamente utilizados en todo momento.
Este también es un buen momento para discutir el tiempo de entrega (de principio a fin)
versus el tiempo de ciclo (tiempos para cada trabajador individual). ¿En qué están interesados sus
clientes: material terminado o una excelente utilización de los recursos?
13.1.5 Consejos y variantes

Es casi seguro que alguien objetará que esto es una simplificación, y seguro que lo es. Pero la
simulación se realiza para ilustrar un principio: que menos WIP (número de peniques) hace que su
trabajo fluya más rápido a través del proceso. ¿Cómo se puede traducir ese principio en su contexto
laboral? En la forma más simple, los peniques representan elementos de trabajo, aunque los
elementos de trabajo a menudo son de diferentes tamaños y complejidad. Sin embargo, el principio
de limitar WIP todavía se aplica. Puede leer más sobre eso en los capítulos 5 y 6.
Pase los Peniques necesita nueve personas para jugar. Pero puede reducirlo de varias
maneras y aún así hacer un gran uso de él:
■ Juega con solo tres estaciones.
■ Deje que los trabajadores se cronometen.
■ Usted, el facilitador, puede jugar al cliente.
NOTA Hasta donde sabemos, este juego parece haber sido creado por un hombre llamado Joe
Little, bajo el nombre de Scrum Penny Game.3 Hay muchas variantes (Flip the Chip, por ejemplo),
y hemos escuchado a otros mencionados como probables creadores del juego: George Dinwiddie,
Jeff Sutherland y Henrik Kniberg.
13.2 El juego multitarea de números

Este juego es una simulación simple que se puede jugar con una sola persona. Muestra que menos
WIP mejora los tiempos de entrega y ayuda a aliviar el estrés y la presión. Aunque un solo jugador
puede jugar este juego, lo hemos ampliado para incluir hasta 65 personas.
Esta simulación es otra forma de ilustrar el valor de limitar WIP, pero tiene propiedades
adicionales que creemos que lo hacen un poco más interesante. Pass the Pennies muestra solo un
concepto, pero lo muestra bien. El juego de multitarea numérica es un poco más realista y tiene en
cuenta otros aspectos de su trabajo. La discusión después del juego será sobre la multitarea y los
malos efectos de que te empujen a trabajar. Eso es más realista que Pass the Pennies, en nuestra
3
Ver “Comfortably Scrum: Scrum Penny Game” por Tommy Norman at http://mng.bz/4R01.
opinión. El juego tarda unos 10 minutos en ejecutarse.

Necesitas lo siguiente para jugar:
■ 3 bolígrafos de diferentes colores por jugador
■ 2 hojas de papel por jugador
■ Un gerente que cronometra a cada jugador (si es necesario, el facilitador puede
desempeñar este papel)
■ Un cronómetro (o un teléfono con una aplicación de cronómetro)
13.2.2 Cómo jugar

Pídale a las personas que juegan que lo ayuden con tres tareas importantes que su empresa tiene por
delante. Aquí están las tareas:
1 Escriba los números romanos del I al X en una columna de arriba a abajo. Use un bolígrafo
negro para esta tarea.
2 Escriba las letras de la A a la J en otra columna de arriba a abajo. Use un bolígrafo rojo
para esta tarea.
3 Escriba los números del 1 al 10 en una columna final de arriba a abajo. Use un bolígrafo
azul para esta tarea.
Presente todas las tareas como prioridades principales y vitales para la supervivencia de la empresa.
En la primera iteración,4 desea utilizar los "recursos" (los jugadores) al máximo y, por lo tanto,
quiere que pasen la misma cantidad de tiempo en cada proyecto, porque todos son importantes.
Indique a los jugadores que escriban fila por fila. Aquí hay un ejemplo de alguien pasando por las
primeras tres filas:5
4
La iteración aquí significa terminar todas las tareas: los números romanos, las letras y las columnas numéricas.
5
Esta instrucción parece difícil de entender para algunas personas, así que asegúrese de que entiendan que desea que
escriban los números fila por fila.
El juego multitarea de números 293
El gerente cronometrará a los jugadores para

cada tarea, así como también registrará el tiempo
total (cuando se hayan completado todas las
tareas). Cuando termine la iteración, anote el
tiempo para cada tarea debajo de ella en el papel
(o en la pizarra). Descubrirá que cada tarea tarda
bastante tiempo en completarse (generalmente
más de un minuto) y que todas finalizan con
solo un par de segundos entre ellas. Un resultado
de ejemplo se muestra en la tabla a la derecha.
Deja unos segundos para reflexionar, pero
luego pasa a la siguiente iteración. Explique que
ahora lo ha pensado, y resulta que la primera tarea (números romanos) es la más importante. La
tarea de letras es la segunda más importante, y los números resultan no ser tan importantes.
Pídales a los jugadores que lo vuelvan a hacer, pero esta vez enfóquese primero en lo que es
más importante y termínelo antes de continuar con la siguiente tarea. En otras palabras, trabaje
columna por columna, así:6
6
Es posible que tenga que ser muy específico aquí y decir algo como: “Primero todos los números romanos, luego todas
las letras y finalmente todos los números. Columna por columna.
Como antes, tenga en cuenta el tiempo para completar cada proyecto y el tiempo total para
completar todos los proyectos. Como notará, los tiempos suelen jugar algo así como esta tabla:
Aquí puede ver que el tiempo de finalización de cada tarea individual se ha reducido drásticamente,
de 1 minuto 20 segundos a solo 12 segundos para los números romanos, por ejemplo. Observe
también que el tiempo total se ha reducido de 1 minuto 24 segundos a solo 32 segundos. Pídales a
los jugadores que señalen estas diferencias antes de hacer un mejor "¡Ajá!" efecto.
Asegúrese de agradecer a los jugadores por realizar el juego y luego comience la discusión.

Estas son algunas de las preguntas que usamos para comenzar una discusión fructífera después de
realizar este juego:
■ ¿Qué pasó con el tiempo total? ¿Por qué?
■ ¿Qué pasó con los tiempos de cada proyecto individual? ¿Por qué?
■ ¿Fue la primera ronda más difícil? ¿Por qué?
■ ¿La simulación se parece a su situación laboral?
■ ¿Cuáles son sus proyectos individuales?
■ ¿Qué representa "cambiar bolígrafos" en su contexto?
■ ¿Cómo se priorizan los proyectos en su empresa? ¿Sabes en qué es más importante
trabajar ahora?
■ ¿En cuántos proyectos/cosas diferentes estás trabajando ahora?
■ ¿Qué pasó con la calidad del resultado producido?
■ ¿Cómo se sintió el primer enfoque? ¿Se sintió mejor el segundo enfoque?

Los resultados deben mostrar una mejora (total para los tres proyectos) en el tiempo de entrega. El
tiempo para el primer proyecto se mejora dramáticamente, a menudo en un 70-80%.
No solo eso, sino que la calidad a menudo también mejora. Esto tiene que ver con el hecho
de que no tiene que cambiar las herramientas (bolígrafos) en la segunda iteración. A la mayoría de
las personas también les resulta bastante difícil escribir los números romanos de I a X, y la segunda
El juego de puntos 295
iteración permite un enfoque más concentrado en cada proyecto. Escribir los números del 1 al 10 es
fácil para la mayoría.7
La mayoría de las personas encuentran que el primer enfoque es mucho más estresante,
debido al hecho de que están cambiando de tareas todo el tiempo. Al reducir la cantidad de cosas
que ocurren al mismo tiempo, no solo aumenta el enfoque y la calidad de su trabajo, sino que
también mejora el tiempo de entrega de cada proyecto.
NOTA El origen de este juego también fue difícil de rastrear. Parece haber evolucionado de muchas
simulaciones ágiles diferentes. El ejercicio se asemeja al juego de nombres multitarea que utiliza
Henrik Kniberg8. Kniberg insinúa que él, a su vez, ha adoptado el suyo de otras simulaciones que ha
visto realizadas por otros, por ejemplo, Mary Poppendieck.
13.3 El juego de puntos

The Dot Game es una simulación de un proyecto de desarrollo de software que muestra los
beneficios de limitar su WIP. También tiene algunas características adicionales con respecto al
desarrollo de software que lo hacen un poco más interesante que los dos juegos que hemos visto
hasta ahora.
The Dot Game muestra desarrollos interesantes para un equipo de software que comienza a
limitar WIP. Primero ve lo que sucede con el flujo, pero también muestra cómo puede comenzar a
pensar en cambiar la forma en que trabaja para ayudar a que el trabajo fluya (otro de los principios
kanban). El juego tarda unos 45 minutos en ejecutarse.
UNA PALABRA DEL ENTRENADOR Este juego es un trabajo duro

en ciertas posiciones y puede ser estresante a veces. Asegúrese de que
todos participen voluntarios y que sea divertido. Hemos tenido gente
enojada durante este juego, y eso no es lo que quieres. Asegúrese de
que todos entiendan la diversión.

■ 8 jugadores (aunque puedes jugar un rol tú mismo)
■ Una mesa con 6 sillas para los 6 jugadores sentados.
■ Una pizarra o rotafolio
■ Cargas de adhesivos rectangulares: al menos 300
■ Pequeños puntos adhesivos (etiquetas de colores) en 4 colores diferentes (consulte la
sección 13.3.7 para alternativas más baratas)
■ Una plantilla prefabricada que actúa como la especificación de lo que se debe hacer
■ Un gerente de proyecto con un cronómetro para medir el tiempo.
■ Un cliente (el facilitador puede desempeñar este papel)
7
El tiempo récord para eso es de 2.8 segundos, realizado por un empleado del Grupo Avega.
8
Consulte "El juego de nombres multitarea, ¿o cuánto tiempo lleva escribir un nombre?" en http://mng.bz/YR06.
13.3.2 Cómo jugar
Puedes divertirte un poco jugando un rol y

presentarte como el propietario de una fábrica
que crea adhesivos con puntos de colores, como
el de la derecha (sostenlo para que el grupo lo
vea).9
El objetivo del ejercicio es crear tantos
adhesivos cubiertos de puntos como sea posible
en cinco minutos. Tiene un proceso bien
pensado y establecido, y ahora está
considerando comenzar una fábrica en esta sala.
El proceso requiere seis trabajadores dispuestos.
Le preguntas a las personas si están dispuestas a
ayudarte. Presente cada rol y describa su tarea.
Invite a voluntarios a tomar asiento en la mesa.
Aquí están los roles,10 en orden de proceso:
Business Analyst: Elimina un adhesivo del paquete y se lo entrega al siguiente trabajador.

1
Technical Analyst: Coloca un punto amarillo en la esquina inferior izquierda y entrega el
2
adhesivo a la siguiente estación.
3 Designer: Coloca un punto rojo en la esquina superior derecha y entrega el adhesivo al
siguiente jugador.
4 UI Developer: Agrega puntos verdes en las otras dos esquinas y pasa el adhesivo.
5 Developer: Agrega los dos puntos azules en el medio y lo pasa al Probador.
6 Tester: Se asegura de que los elementos producidos cumplan con los estándares de calidad.
Si es así, los elementos se entregan al cliente.
7 Project Manager: Cronometra el procedimiento. Coloque el Project Manager en una
pizarra o rotafolio para anotar los tiempos. El Project Manager mide el tiempo que tarda la
primera entrega (lo primero que llega al cliente). El Project Manager también advierte al
equipo cuando solo queda un minuto y anuncia cuándo se acabó el tiempo (después de cinco
minutos).
8 Customer: Acepta los elementos terminados. A menudo jugamos este papel nosotros
mismos y presionamos al equipo según sea necesario para que el ejercicio sea interesante y
divertido.
Siente a las personas como se muestra en el diagrama.
9
Esto significa que tendrás que crear una plantilla adhesiva antes de que comience el juego.
10
Siéntase libre de usar los títulos de trabajo de su lugar de trabajo actual si lo desea.
13.3.3 Primera iteración

Cuando todos estén sentados, nuevamente muéstreles la plantilla adhesiva y colóquela en el centro
de la mesa. Dígales que su proceso se ha optimizado para trabajar en lotes de cinco elementos: el
Analista de Negocio toma cinco adhesivos del paquete y se los entrega al Business Analyst, que
agrega puntos amarillos a los cinco y los entrega al Designer, y así. Hágales saber que los va a
evaluar individualmente. Cada estación debe producir tanto como sea posible y no importarle si las
siguientes estaciones se mantienen o no. Queremos que todos sean efectivos, ¿verdad?
No responda demasiadas preguntas (a menudo no hay tantas en esta etapa), pero procure que
la primera iteración se ejecute lo antes posible. El Project Manager empieza el juego iniciando el
temporizador. Tan pronto como se inicie el juego, lleve al Customer 11 a un lado y dígales que solo
se deben evaluar dos cosas para la aceptación de los elementos:
■ Los puntos en los bordes deben estar lo más cerca posible de los bordes, pero no sobre
ellos.
■ Los puntos azules en el medio deben estar lo más juntos posible, pero no superponerse.
11
El customer puede recibir instrucciones por adelantado si tiene tiempo. O desempeña ese papel tú mismo.
Indique al Customer que solo responda preguntas directas y que no revele los criterios de
aceptación a menos que se le solicite específicamente.
Cuando el equipo está en medio de la primera iteración, puedes dirigirte a ellos y motivarlos
para que produzcan tanto como sea posible. Cuando el primer lote de notas adhesivas llega al
Customer, el Customer acepta o rechaza las notas adhesivas según los criterios descritos
anteriormente. No digas nada de por qué.
Asegúrese de que el Project Manager tome nota del tiempo de la primera entrega (que
generalmente demora entre dos y medio a tres minutos) en la pizarra y advierte al equipo cuando
queda un minuto.
Cuando termine la iteración, pídale al Project Manager que cuente lo siguiente:
■ Cantidad de elementos completados
■ Cantidad de elementos aceptados
■ Número de elementos en proceso ( elementos "en la mesa" que no fueron entregados)
Tenga en cuenta todos estos resultados en la pizarra en una tabla como esta:
Explique al equipo que está decepcionado con su desempeño. El cliente quiere estos elementos.
¡Malamente! ¿Pueden por favor actuar juntos e ir más rápido, ya? Detente aquí y pregunta a la gente
cómo se sintió y cómo fue:
■ Debería ver un cuello de botella acumulándose después del Business Analyst (que tiene un
trabajo fácil). ¿Por qué sucedió eso? ¿Hubo otros cuellos de botella o flujos irregulares?
■ ¿Qué pasa si el Tester encontró fallas? ¿Qué podría hacer el Tester sobre ellos? ¿Qué
deberían haber hecho?
■ Pregunte al equipo sobre los criterios de aceptación: ¿se conocen? ¿Quién sabe de ellos?
¿Qué se puede hacer para conocer los criterios? Haga que el Customer responda brevemente
cualquier pregunta que el equipo pueda hacer, y luego pase a la siguiente iteración.
■ ¿Cuál es el valor de todos los elementos de la tabla que no se entregan? Ninguno, a los
ojos del Customer. Están desperdiciados.
La ley de Little en el juego de puntos

En las instrucciones originales del juego, se introduce la ley de Little (ver capítulo 5). Por lo
general, no hacemos eso por dos razones:
■ A menudo arruinamos el cálculo en el calor del momento.
■ Creemos que el punto se encuentra con los datos presentados en la pizarra de todos modos.
Pero si se siente preparado para el desafío de
contar, puede decirle al equipo que el tiempo
para la primera entrega es bastante engañoso.
Veamos la ley de Little en acción usando
nuestros números, como se indica en la tabla
que creamos durante la primera iteración.
La ley de Little enseña que el tiempo de ciclo se calcula de la siguiente manera:

tiempo de ciclo = trabajo en proceso / rendimiento
El rendimiento, a su vez, se calcula de la siguiente manera:
numero de elementos terminados / tiempo
Con los números del ejemplo, eso nos da lo siguiente:
WIP: 66 elementos que estaban en proceso
Rendimiento: 13 elementos completados / 5 minutos = 2.6 adhesivos por minuto
Tiempo de ciclo: 66 / 2.6 adhesivos por minuto = 25.4 minutos por adhesivos!
Esa es una gran diferencia con los 2:22 minutos ya malos para la primera entrega.
Esto también puede explicarse en la tabla haciendo que las personas se den cuenta de que un
adhesivo retirado del paquete debe "viajar" a través de todos los adhesivos en la mesa. El primer
lote no tenía elementos delante y, por lo tanto, se movió más rápido a través del sistema.
13.3.4 Segunda iteración

Explique al equipo que en un intento desesperado por mejorar el rendimiento y la calidad de esta
fuerza laboral, va a intentar algo realmente loco: para la segunda iteración, no cambiará
absolutamente nada sobre el proceso, excepto la cantidad de elementos trabajados al mismo tiempo.
Trabajarán en lotes de uno, no cinco.
El Business Analyst toma un adhesivo del paquete y se lo entrega al Technical Analyst, quien
agrega un punto amarillo y se lo entrega al Designer, y así sucesivamente. Trabaje como antes, pero
con un elemento a la vez.
Comience la siguiente iteración de cinco minutos cuando el equipo esté listo. Esta vez
puedes ir y asegurarte de que las personas estén trabajando como deberían. Asegúrese de verificar la
calidad de los elementos entregados (o ayudar al Customer). Verifique que el Project Manager
advierta al equipo cuando quede un minuto y les avise cuando se acabe el tiempo.
Tenga en cuenta los resultados para la segunda iteración, que probablemente se parece a
esto:
Pare aquí y discuta el resultado:

■ ¿Qué pasó con el tiempo de la primera entrega?
■ ¿Qué pasa con la cantidad de elementos entregados?
■ ¿Por qué mejoró la calidad (elementos aceptados versus número de elementos hechos)?
Alguien puede decir que esto fue más fácil durante la segunda iteración porque ahora saben
qué hacer. Eso es correcto, y también es exactamente el punto que desea hacer. Ahora saben
qué hacer porque le preguntaron al Customer durante las discusiones después de la primera
iteración y se ajustaron a la nueva información, ¿verdad?
■ ¿Dónde está el cuello de botella ahora? ¿Quién tiene muchos elementos frente a ellos? A
menudo, el cuello de botella aparece en diferentes posiciones que en la primera iteración.
13.3.5 Tercera (y final) iteración

Anuncie su renuncia al equipo. Es inútil No tiene idea de cómo mejorar el proceso para producir
buenos resultados de este equipo. El equipo ahora, por sí solo, puede encontrar formas de mejorar el
proceso para producir la mayor cantidad posible y desperdiciar la menor cantidad posible de
elementos.
En nuestra experiencia, muchos equipos necesitan algún aporte aquí para ponerse en
marcha12. Puede preguntarles quién es responsable de la calidad y qué deberían hacer al respecto. O
cómo pueden asegurarse de desperdiciar la menor cantidad de elementos posible. Los miembros del
equipo pueden preguntar si pueden intercambiar lugares, y usted puede permitir eso, pero hay una
penalización: las personas que intercambian trabajos tienen que reducir la velocidad del nuevo
trabajo para hacerlo más realista. Un probador que realiza desarrollo probablemente no lo hará tan
rápido como un desarrollador.
12
También hemos visto algunas variantes súper creativas aquí, como caminar alrededor de la mesa y hacer que el
Customer camine con el equipo, corrija los errores y dé su opinión mientras caminan. Te sorprendería lo que la gente
inventa. Permítales pensar por un momento antes de darles pistas.
Dele al equipo algunas sugerencias y luego permita tres minutos de autoorganización para
prepararse para la última iteración. Si tiene personas en la sala que no están sentadas alrededor de la
mesa, asegúrese de pedirles también su opinión sobre las mejoras.
Cuando el equipo esté listo, ejecute la tercera iteración como antes: cinco minutos, avise
cuando quede un minuto y programe la primera entrega. Cuando terminen los cinco minutos,
terminarás con una tabla como esta:
Como se observa el resultado, comience una discusión:

■ ¿Cómo se sintió la última iteración? Las respuestas comunes son "caos" o "no
estructurado". ¿Es tan malo?
■ ¿Qué pasó con el tiempo de la primera entrega? Por lo general, sube un poco. ¿Porqué es
eso?
■ ¿Qué pasó con la calidad? A menudo se mejora mucho. ¿Por qué?
■ ¿Cuánto se desperdició? ¿Por qué?
Asegúrate de agradecer a todos por jugar este juego bastante estresante y finaliza la sesión.

Este juego muestra muchas cosas que vale la pena destacar:
■ Con lotes más pequeños, el tiempo de entrega disminuye y la calidad aumenta.
■ Al hacer una retrospectiva y ajustar la forma en que trabaja después de cada iteración,
mejora el resultado. Pregunte al equipo, después de la última iteración, si creen que
mejorarían aún más si intentaran otra vez. La mayoría de los equipos dicen que sí.
■ Debe hacer preguntas y colaborar con el Customer para saber lo que quiere. Una
especificación perfecta no es suficiente.
■ No sirve de nada empujar el trabajo a un sistema que está sobrecargado. La primera
posición en la primera iteración suele ser una gran ilustración de eso. Hemos visto Business
Analyst con más de 200 adhesivos listos para ser recogidos en la próxima estación. Esto es
lo que Mary Poppendieck llama "ilusiones", lo que significa que esos elementos no
sucederán (más rápido) solo porque los apilas allí. De hecho, ralentizarán el sistema al
aumentar su WIP (lea más en el capítulo 5).

Este juego lleva tiempo. Permita una hora completa para el juego, aunque puede ejecutarlo en 45
minutos. Tómate un descanso después del partido. Aquí hay algunas reflexiones adicionales:
■ No olvides crear la plantilla antes de comenzar.

■ Los puntos verdes y azules se agotan primero. Si es necesario, compre más, probablemente
los necesite.
■ Para ahorrar dinero, puedes ejecutar este juego con los jugadores dibujando puntos con
marcadores de colores en lugar de colocar puntos. Al hacerlo, se agregan algunas
características al juego porque los errores no se pueden corregir fácilmente y es más difícil
que la calidad sea consistente en lo que respecta al tamaño y la forma.
■ Si tiene a alguien más jugando al Customer, asegúrese de que no sea demasiado exigente.
Eso pone el foco en el lugar equivocado. Tómese el tiempo para instruir al Customer antes
de la sesión y asegúrese de que solo se tengan en cuenta los criterios de aceptación
establecidos.
■ Tome notas de cualquier comentario durante las iteraciones. Los comentarios pueden ser
revisados durante las discusiones.
■ Invite a cualquier persona que no esté jugando a unirse a la conversión, pero solo después
de cada ronda. No quieres que interrumpan a los jugadores a mitad de la sesión.
■ En las retrospectivas entre rondas, deles a todos suficiente tiempo para hablar. Aquí es
donde tiene lugar el aprendizaje. Deja que los jugadores hablen primero; las personas que
miran (si las hay) pueden hablar después de eso.
NOTA Al Shalloway de Net Objectives creó este juego.13 Lo basó en el juego Lean Manufacturing
Cup.14 También revisó amablemente esta sección para nosotros, por lo cual estamos agradecidos.
13.4 The Bottleneck Game

El Juego del Cuello de Botella enseña efectivamente los cinco pasos de enfoque de la Teoría de las
Restricciones (ver capítulo 7). La Teoría de las Restricciones ve un proceso como un sistema con al
menos un cuello de botella (restricción) que ralentiza la producción. Los cinco pasos de enfoque son
técnicas que ayudan a identificar, elevar y gestionar los cuellos de botella para obtener un mejor
flujo.
Este juego de Cuello de Botella se parece al Dot Game (Juego de Puntos) de alguna
manera, pero es un poco más elaborado. Se centra más en los cuellos de botella 15 y la forma de la
Teoría de las Restricciones para abordar la resolución de problemas.
13
"The Dot Game", http://mng.bz/lONY.
14
Martin Boersema, "The Lean Cups Game - ¿Qué es el verano sin unos pocos fríos?" en http://mng.bz/0Von.
15
Duh! Con un nombre como ese, de alguna manera supimos ...
El juego del cuello de botella 303
El juego está bien documentado. Puede descargarlo gratis desde www.agile-coach.net/coach-

tools/bottleneck-game/.

Este es un ejercicio de equipo, y cada equipo consta de cuatro a siete personas:
■ Necesita mucho espacio para cada equipo en un formato de línea de producción largo.
■ Imprima las hojas de instrucciones del sitio web para distribuir a cada jugador según su
rol.
13.4.2 Cómo jugar

El juego se hace en tres rondas, con conceptos introducidos como parte del juego. El juego
completo dura entre dos y tres horas y se puede extender con un taller que aplique las cosas que has
aprendido a situaciones del mundo real.
La meta del juego Bottleneck es que cada equipo
cree tantos pares de sombreros y botes de papel
(como el par a la derecha) como sea posible y al
mismo tiempo asegúrese de no desperdiciar papel.
El proceso de juego sugerido está configurado
para revelar algunos cuellos de botella. Las
presentaciones y tutoriales ayudan a los asistentes a utilizar los cinco pasos de enfoque (de la Teoría
de las Restricciones) para resolver estos cuellos de botella.
Los cinco pasos de enfoque

Los cinco pasos de enfoque se basan en la simple premisa de que hay al menos un cuello de botella
en su sistema. Si no existiera, el flujo a través del sistema sería totalmente ilimitado y el
rendimiento sería instantáneo e ilimitado. Cualquier mejora realizada en el mayor cuello de botella
es una mejora del rendimiento de todo el sistema.
Estos son los pasos de enfoque a seguir para gestionar un cuello de botella:
1 Identifique la restricción que ralentiza el rendimiento. Por ejemplo, los probadores
siempre están sobrecargados de trabajo.
2 Explote la restricción para que se use a toda su capacidad. Por ejemplo, asegúrese de que
los probadores solo realicen pruebas y nada más.
3 Subordinar otras actividades a la explotación del cuello de botella. Por ejemplo, haga que
alguna otra función realice el trabajo que no sea de prueba para ayudar a los probadores.
Esto está bien porque la otra función no es el cuello de botella.
4 Eleve la restricción. Por ejemplo, haga que otras funciones también realicen pruebas o
contrate nuevos probadores. Esto suele ser lento y costoso, así que no intentes esto hasta
que hayas probado los primeros tres pasos.
(continuado)
5 Aclare y repita. Asegúrese de que, en cada punto del proceso, aquí, si no antes, verifique
que ninguna otra función se haya convertido en el cuello de botella. Por ejemplo,
asegurarse de que los probadores solo realicen pruebas y que nada más haya resuelto la
situación, pero ahora la implementación es la restricción del sistema. En ese caso, mueva
sus esfuerzos para administrar la implementación como su cuello de botella.
Puede encontrar más detalles y antecedentes en el excelente libro The Goal (North River Press,
2012, http://mng.bz/bRak) de Eliyahu Goldratt, que formula la Teoría de las Restricciones.
El proceso que se simula se optimiza cada vez más en el juego para gestionar el cuello de botella y
lograr un flujo más rápido y suave.

El extenso material suministrado en el sitio web del juego te ofrece una gran cantidad de temas de
discusión sugeridos y orientación sobre cómo ejecutar el taller posterior con el que puedes extender
la sesión. El material contiene un manual de sesiones completo y extenso para instructores,
instrucciones de trabajo para los asistentes al taller y folletos ya preparados para que los asistentes
los conserven.

Las cosas principales que revela el Bottleneck Games son las siguientes:
■ Cómo se puede manejar un cuello de botella mediante el uso de los cinco pasos de enfoque
de la Teoría de las Restricciones.
■ Cómo la Teoría de las Restricciones y lo que has aprendido en el ejercicio pueden
aplicarse a una situación real.
NOTA Este juego es lanzado bajo Creative Commons Attribution-Share Alike por Pascal Van
Cauwenberghe y Portia Tung. El juego y todo el material necesario se pueden descargar en
www.agilecoach.net/coach-tools/bottleneck-game/.
13.5 getKanban
getKanban es una simulación kanban
completa que en sí misma es una
introducción a kanban y sus principios. El
juego es un juego de mesa bastante
complejo con excelente documentación.
Probablemente debería jugarlo al menos una
vez con otra persona antes de intentar
facilitarlo usted mismo.
getKanban 305
El juego viene en tres modos: juego rápido, estándar y modo avanzado. Cada modo es cada vez más
detallado y, por lo tanto, lleva más tiempo jugarlo. Debe permitir al menos dos horas y media a tres
para el modo avanzado y debe incluir una breve introducción a kanban antes de comenzar el juego.
getKanban cuesta dinero16 y puede solicitarse en www.getkanban.com. Vale la pena la
inversión. También puede imprimir los materiales del juego de versiones anteriores del juego usted
mismo, de forma gratuita.
El juego getKanban está en constante evolución, y puedes esperar actualizaciones del juego
continuamente. La versión que describimos brevemente aquí es la versión 4.

■ El juego de mesa getKanban. Todos los materiales necesarios están incluidos en la caja.
■ Cerca de 6 jugadores por tablero (mínimo de 4 jugadores para que el juego sea
interesante).
■ Un gran espacio libre en la mesa.
■ Es útil una pizarra o rotafolio para rastrear resultados y explicar conceptos.
13.5.2 Cómo se juega el juego

Dar instrucciones completas sobre cómo jugar getKanban está más allá del alcance de este libro.
Eso se describe en el juego getKanban en sí. Considera esta sección una breve introducción al
juego.
En el juego, juegas con un equipo de desarrollo de software que crea un producto al que los
clientes se están suscribiendo, por ejemplo, un servicio en línea. El objetivo oficial del juego es
ganar la mayor cantidad de dinero posible, pero también se pueden usar otros objetivos, como
terminar la mayor cantidad de elementos posible, por ejemplo.
Juegas varios días con el equipo de desarrollo de software, comenzando un par de días en un
proyecto en curso, por lo que te lanzas directamente a la acción. El progreso está determinado por el
lanzamiento de un par de dados: cuanto más alta es la tirada, más trabajo (análisis, desarrollo o
prueba) realiza el equipo. El esfuerzo de trabajo se puede redirigir, de modo que los valores de
trabajo de desarrollo se puedan usar en las pruebas, por ejemplo, como parte de la estrategia del
equipo.
A lo largo del juego, se introducen tarjetas de eventos con características que el equipo debe
tener en cuenta. Habrá malos jefes haciendo políticas "estúpidas" que arrojan los planes por la
borda, conferencias que pueden darle suscriptores adicionales, y algunos trabajan con un valor que
no se determina hasta más adelante en el juego.
Cada ronda sigue un cronograma estricto que lo ayuda a jugar durante la ronda, actualizar
sus ganancias y ver algunas métricas y dibujar diagramas para ayudar a realizar un seguimiento de
su progreso. Todo es muy detallado y fácil de seguir y, en sí mismo, puede ser una gran
introducción a los diagramas y métricas utilizados en kanban.
16
$ 450 por juego al momento de escribir.
La estrategia del equipo para elegir en qué elementos enfocar el trabajo y cómo distribuir el trabajo
(valores de los dados) determina si tienen éxito o no.

Hay amplias oportunidades para la discusión durante el juego, pero al final una discusión de
resumen debe centrarse en lo siguiente:
■ ¿Qué aprendiste?
■ ¿Cómo puede aplicar esto en su contexto actual?
■ ¿Qué te sorprendió de cómo se desarrolló el juego?

Puedes cambiar las cosas cuando ejecutas este juego si es necesario. Estos son algunos de los
ajustes que hemos usado o visto:
■ Como facilitador, debe estar listo para caminar alrededor del grupo y ayudarlos,
respondiendo preguntas y dándoles consejos. El juego tiene bastantes reglas, y seguirlas
todas durante la primera prueba ha demostrado ser una tarea desalentadora para la mayoría
de los grupos con los que hemos probado el juego.
■ Dedique suficiente tiempo para jugar este juego. Probablemente sea necesaria una
introducción a kanban antes de jugar. El juego toma al menos 90 minutos para jugar.
Probablemente deberías reservar al menos 30 minutos para discutir el juego con los
asistentes después. En general, la sesión puede durar de dos horas y media a tres, si incluye
descansos.
■ Aunque el juego está controlado en parte por las cartas de evento, puedes jugarlo más de
una vez. El enfoque y las estrategias diferentes y cómo afectan el resultado son variantes
interesantes que puede presentar.
■ Puede jugar una versión en línea del juego usted mismo en
https://getkanban.corporatekanban.com. Es a la vez genial y un poco incómodo y triste, lo
sabemos, pero puede ser una buena forma de ejecutar el ejercicio para prepararse, o para
señalar a las personas para el seguimiento.

Las principales conclusiones de los juegos getKanban, para nosotros, son estas:
■ Ver kanban en acción de verdad. El juego toca muchas áreas del uso de kanban y los
principios sobre los que se basa kanban. El concepto de limitar WIP y el principio de halar
(halar el trabajo a la acción justo a tiempo en lugar de mantener un stock de trabajo, por si
acaso) se muestran en el uso práctico.
■ Cómo funciona y se puede diseñar una tabla kanban.
■ Cómo construir y usar métricas y diagramas como diagramas de flujo acumulativos y
diagramas de control.
El Juego de Pizza Kanban 307
■ Cómo usar las métricas y la información creada por el proceso para optimizar el desenlace
comercial.
LEE MAS En www.getkanban.com, puedes leer mucho más sobre este juego. Aunque el juego está
a la venta, también es de código abierto y puedes contribuir a su progreso.
13.6 El Juego de Pizza Kanban

Este es otro juego de simulación kanban que se
puede obtener (gratis) del sitio web de Agile42
(http://mng.bz/kYN7). El juego tarda
aproximadamente una hora en jugar, lo que lo hace
más rápido que el juego getKanban, y se puede
jugar con menos preparación. Requiere muchos
accesorios, y probablemente necesites a alguien que
te ayude a entrenar al equipo durante el juego para
alcanzar su máximo potencial.
El juego es bastante divertido y sencillo. Es un ejercicio perfecto de trabajo en equipo 17 que también
enseña algo útil. El objetivo general es que el equipo "sienta" cómo funciona kanban en la práctica.

El sitio web de Kanban Pizza Game tiene mucha información sobre lo que necesita para comenzar.
Se enumeran bastantes cosas, pero nada que no encontraría en la mayoría de las oficinas o tiendas
de suministros de oficina.
Además de los accesorios, también necesitarás lo siguiente:
■ 5 jugadores por equipo (4 jugadores también podrían funcionar).
■ Un líder del juego (que tiene experiencia jugando el juego).
■ Una mesa para jugar: una mesa por equipo que puede acomodar a todos los jugadores del
equipo fácilmente. Se colocará mucha pizza sobre la mesa.
■ Una pizarra o rotafolio para informar.
13.6.2 Cómo jugar

El objetivo del juego es crear rebanadas de pizza (que agregan puntos) pero evitar desperdiciar
rebanadas de pizza que no se hacen (que deducen puntos). El cliente ordena pizzas completas, y el
equipo solo obtiene puntos por pedidos totalmente completados. El equipo con la mayor cantidad de
puntos gana.
17
Debido a que naturalmente genera un apetito por la pizza, la sesión se puede completar con pizza para todos. Sin
embargo, no es la versión en papel.
El líder de simulación asume el papel de alguien que abre un nuevo restaurante de pizza y contrata a
los jugadores para que trabajen para ellos. Todos los materiales y herramientas para crear rebanadas
de pizza se suministran al equipo.
El juego se juega en cuatro iteraciones, de la siguiente manera:
1 Hornee/cree rebanadas de pizza de la manera que el equipo lo desee, en un proceso
arbitrario.
2 Introduzca el concepto de "pedidos" (lotes de rebanadas) y estaciones de trabajo que
limitan físicamente el WIP.
3 Introduzca una variación de producto en forma de pizza con una receta y un flujo de
trabajo diferentes.
4 Con todas las partes del juego en su lugar y la experiencia que el equipo ha adquirido de
las tres iteraciones anteriores, permítales organizarse y desarrollar mejoras en el proceso.
Después del juego formal, continúe con una sesión informativa para fijar los puntos de aprendizaje
del juego.

Puedes usar preguntas como las siguientes para abrir una discusión después de ejecutar este juego:
■ ¿Qué pasó con el tiempo de entrega cuando introdujo los límites de WIP? ¿Por qué?
■ ¿Te sentiste estresado? ¿Cómo puedes mejorar eso?
■ ¿Qué sucedió cuando se introdujo un nuevo producto?
■ ¿Qué similitudes o conexiones puedes hacer con tu forma de trabajar?
■ ¿Cuáles son las rebanadas de pizza?
■ ¿Qué pasa con el tablero?
■ ¿Quién está pidiendo pizzas?
Los creadores del juego también sugieren que sigas desde aquí y comiences a crear tu propio flujo
de trabajo visualizado con los principios aprendidos en el juego. Parece una gran idea, pero
probablemente requerirá algo de entrenamiento o ayuda para manejar las preguntas que puedan
surgir. De esta manera, el juego se puede usar como una entrada para que el equipo comience a usar
kanban para su trabajo.

Estos son las metas del juego:
■ Experimente kanban y los principios kanban en acción.
■ Comprenda y experimente el efecto de limitar su WIP.
■ Inspeccione su proceso y autoorganícese para mejorar el proceso.
■ Cree un tablero kanban para reflejar su flujo de trabajo.
Poder tener una idea de cómo funciona un sistema de halar en la práctica es una gran cosa que es
bastante difícil de hacer. Eso es lo que este juego logra.
Resumen 309
Hay mucha documentación en el sitio web, pero para aprovechar todo el potencial del juego, debes
tener experiencia práctica. Probablemente sea mejor jugarlo con algunos amigos antes de intentar
jugar con otros. Mejor aún, encuentre a alguien que tenga experiencia en la ejecución del juego y
pídales que lo ejecuten con usted.
NOTA El juego fue creado por Agile 42 (www.agile42.com) y está licenciado bajo Creative
Commons Attribution-Share Alike 3.0.
13.7 Resumen
Este capítulo le mostró algunos juegos y simulaciones que pueden ayudarlo a presentar los
conceptos principales de kanban a las personas que no lo han escuchado antes. En nuestra
experiencia, juegos como estos son excelentes maneras de aprender kanban y los principios en los
que se basa. Hemos escuchado a personas hablar sobre el Dot Game que jugaron hace un año
cuando discutían un problema con el flujo en su tablero. Y hemos escuchado que las personas se
recuerdan mutuamente que no deben hacer "más pizzas de las que el sistema puede manejar
actualmente".
Aunque los juegos son importantes, lo más valioso es la discusión que sigue. Asegúrese de haber
preparado muchas preguntas para hacerle a su equipo. Desea que razonen sobre lo sucedido y lo
transfieran a sus vidas laborales.
Apéndice A
Lectura recomendada
y otros recursos
Ambos somos lectores ávidos y hemos leído muchos textos a lo largo de los años que nos
influenciaron y nos enseñaron mucho sobre kanban, Lean, ágil y más. En este apéndice
compartimos nuestra lista principal de trabajos para aprender.
Los hemos agrupado por tema y le hemos dado una o dos oraciones para contarle un poco acerca de
cada elemento, por qué lo elegimos y qué encontramos al respecto que es particularmente bueno.
A.1 Libros sobre Lean y kanban

■ Kanban: Kanban: Successful Evolutionary Change for Your Technology Business (David
J. Anderson, Blue Hole Press, 2010, http://amzn.com/0984521402)— Este es el libro en el
que David J. Anderson define y explica el Método Kanban. Es básicamente una lectura
obligada si estás interesado en Kanban. Este libro le enseñará todo sobre cómo David y otros
idearon kanban y por qué y cómo funciona.
■ This Is Lean: Resolving the Efficiency Paradox (Per Åhlström y Niklas Modig, Rheologica
Publishing, 2012, http://amzn.com/919803930X)— Este pequeño gran libro explica
claramente el pensamiento fundamental detrás de Lean y ofrece una buena definición de qué
significa Lean. Está escrito por el profesor Per Åhlström y el investigador Niklas Modig de
la Escuela de Economía de Estocolmo y es una lectura fácil de aproximadamente 160
páginas.
■ The Toyota Way to Continuous Improvement: Linking Strategy and Operational
Excellence to Achieve Superior Performance (Jeffrey K. Liker y James K. Franz, McGraw-
Hill, 2011, http://amzn.com/0071477462)— Este libro es el resultado de 20 años de estudio
de Toyota y otras compañías Lean. Describe la filosofía y los principios detrás de Toyota
311
312 APÉNDICE A Lectura recomendada y otros recursos
Way y cómo Toyota implementa el Sistema de Producción Toyota en su actividad diaria. Los
autores también comparten sus consejos sobre cómo puede convertir su empresa en una
organización de aprendizaje.
■ Toyota Kata: Managing People for Improvement, Adaptiveness, and Superior Results
(Mike Rother, McGraw-Hill, 2009, http://amzn.com/0071635238) —Rother mira más allá
de lo que Toyota hace e intenta entender cómo y por qué. Luego formaliza esto en un
método llamado Toyota Kata. Es una verdadera revelación. El Kanban Kata del que
hablamos en el capítulo 10 se basa en este libro.
■ The Principles of Product Development Flow: Second Generation Lean Product
Development (Don Reinertsen, Celeritas Publishing, 2009, http://amzn.com/1935401009):
este denso libro sobre desarrollo de productos contiene 175 principios que sintetizan el
conocimiento de una amplia gama de campos, desde redes de telecomunicaciones hasta
doctrina militar, pasando por una teoría Lean de segunda generación que va más allá del
enfoque basado en la fe y aboga por la aplicación de una visión económica a las decisiones.
■ Lean from the Trenches: Managing Large-Scale Projects with Kanban (Henrik Kniberg,
Pragmatic Bookshelf, 2011, http://amzn.com/1934356859)— Este libro presenta un breve
estudio de caso sobre la implementación de Lean y kanban en la policía sueca. El autor es
una de las figuras ágiles prominentes en Suecia.
A.2 Libros sobre ágil

■ Scrum and XP from the Trenches (Henrik Kniberg, Lulu.com, 2007,
http://amzn.com/1430322640 o gratis como PDF descargable en
www.infoq.com/minibooks/scrum-xp-from-the-trenches)— Este libro es un excelente ,
introducción pragmática a Scrum y algunas prácticas ágiles. Ha sido el comienzo del viaje
ágil para muchas personas, incluido Marcus. Gracias Henrik!
■ Extreme Programming Explained: Embrace Change (Kent Beck, Addison-Wesley
Professional, 1999, http://amzn.com/0201616416)— Este libro es una introducción a la
programación extrema (XP), uno de los primeros métodos ágiles. Describe varias de las
prácticas ágiles más importantes utilizadas por muchos equipos kanban.
■ The Agile Samurai: How Agile Masters Deliver Great Software (Jonathan Rasmusson,
Pragmatic Bookshelf, 2010, http://amzn.com/1934356581)— Este libro es breve,
pragmático, divertido y una buena introducción a ágil y muchas prácticas en torno a él.
Incluye muchos consejos prácticos y puede usarse como introducción. Hemos dejado este
libro con clientes que hemos visitado como literatura de referencia.
■ The Art of Agile Development (James Shore y Shane Warden, O'Reilly Media, 2007,
http://amzn.com/0596527675)— Esta introducción detallada a muchas prácticas ágiles
(particularmente XP) es excelente para novicios y principiantes avanzados, pero también
presenta algunas nuevas perspectivas y buenos ejercicios para profesionales más
experimentados.
Libros sobre negocios y gestión del cambio 313
A.3 Libros sobre desarrollo de software.

Aunque este no es un libro sobre desarrollo de software como escribir código, hemos encontrado
interesantes los siguientes libros y hemos aprendido mucho de ellos que podemos usar en la práctica
para ayudar a nuestros equipos kanban:
■ Specification by Example: How Successful Teams Deliver the Right Software (Gojko
Adzic, Manning, 2011, www.manning.com/adzic/)— La especificación con el ejemplo es
una práctica para garantizar que está construyendo lo correcto: lo que se necesita, no solo lo
que el cliente quería. Este libro hace un excelente trabajo al describir todos los aspectos y
consecuencias de la especificación por ejemplo (también conocido como desarrollo
impulsado por el comportamiento o desarrollo impulsado por la aceptación).
■ Test-Driven Development: By Example (Kent Beck, Addison-Wesley Professional, 2002,
http://amzn.com/0321146530)— Este libro proporciona una excelente introducción al
desarrollo basado en pruebas (TDD) a través de un estudio de caso exhaustivo que muestra
los procedimientos en pequeños, pasos de grano fino.
■ Growing Object-Oriented Systems Guided by Tests (Steve Freeman y Nat Pryce, Addison-
Wesley Professional, 2009, http://amzn.com/0321503627)— En este libro (conocido en los
círculos internos como el libro GOOS), los autores muestran cómo se puede aplicar TDD en
el mundo en general. Incluye muchos ejemplos prácticos y consejos en todo momento.
■ Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin, Prentice
Hall, 2008, http://amzn.com/0132350882)— Esta es una lectura obligada para cualquier
desarrollador ágil. Le muestra cómo escribir código limpio y fácil de mantener.
Probablemente también te avergonzará de tu propio código (como lo hizo para el propio tío
Bob).
■ The Clean Coder: A Code of Conduct for Professional Programmers (Robert C. Martin,
Prentice Hall, 2011, http://amzn.com/0137081073)—Tío Bob dirige su atención al
desarrollador profesional y analiza lo que significa ser un gran desarrollador. Esto se hace a
través de muchas anécdotas e historias divertidas que te hacen pensar en tu profesión de una
manera nueva.
A.4 Libros sobre negocios y gestión del cambio.

■ The Goal: A Process of Ongoing Improvement (Eliyahu M. Goldratt, North River Press,
2012, http://amzn.com/0884271951)— Imagínese escribir un libro sobre la Teoría de las
Restricciones. Imagina lo aburrido que podría ser ese libro. Esto es lo contrario. Es una
novela apasionante y entretenida que te enseña sobre la Teoría de las Restricciones mientras
sigues el destino de Alex Rogo. Esto se hace de una manera tan sutil que casi no lo notas
hasta que terminas.
¡Es uno de los mejores libros que hemos leído!
■ Switch: How to Change Things When Change Is Hard (Chip Heath y Dan Heath, Crown
Business, 2010, http://amzn.com/0385528752)— Este libro le enseña sobre cómo hacer
cambios: cambios personales, ayudar a otros a cambiar y cambios en las organizaciones. Le
314 APÉNDICE A Lectura recomendada y otros recursos
brinda un marco práctico para realizar cambios y contiene muchos ejemplos y estudios para
respaldarlo.
Este libro nos hizo sentir casi como si estuviéramos haciendo trampa al conocer
todas estas técnicas cuando terminamos de leerlo. ¡También puedes tener ese sentimiento!
■ Made to Stick: Why Some Ideas Survive and Others Die (Chip Heath y Dan Heath,
Random House, 2007, http://amzn.com/1400064287)— Aquí hay otro gran título de los
hermanos Heath que habla sobre cómo hacer que sus ideas sean adhesivas, lo que a su vez es
una forma de mejorar el proceso de cambio . Proporciona muchos casos (el caso de apertura
se quedará con usted para siempre, por ejemplo) y consejos prácticos.
■ Fearless Change: Patterns for Introducing New Ideas (Mary Lynn Manns y Linda Rising,
Addison-Wesley, 2004, http://amzn.com/0201741571)— Este libro contiene muchos
patrones pequeños: formas, pensamientos y prácticas que pueden ayudarlo a lograr el
cambio. Después de una breve narración sobre las ideas detrás de los patrones, el libro
presenta una larga lista de patrones que puede comenzar mañana. Es imprescindible para
cualquier agente de cambio.
■ The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create
Radically Successful Businesses (Eric Ries, Crown Business, 2011,
http://theleanstartup.com/book, http://amzn.com/0307887898)— Este libro habla sobre la
aplicación de conceptos Lean a las ideas: más específicamente, ideas de negocios; e incluso
más específicamente, ideas de inicio. Estas ideas van desde el uso del método científico para
la exploración hasta las pruebas A/B para validar su hipótesis. Poco después de leerlo,
comenzará a darse cuenta de lo que muchos otros han visto: Lean Startup se puede aplicar a
su negocio independientemente de si es una startup.
A.5 Otros recursos

Aunque ambos leemos mucho, la comunidad kanban se está moviendo rápidamente. Para
mantenerse al día con las últimas noticias y acontecimientos, seguimos muchos recursos en línea,
como listas de correo, blogs y cuentas de Twitter. Aquí hay algunos de nuestros favoritos:
■ Kanban dev Yahoo mailing list—Esta es una lista de correo extremadamente activa para
todas las cosas kanban. Todos los grandes nombres del movimiento de desarrollo de
software Lean están activos en la lista, y se asegurará de obtener rápidamente excelentes
respuestas. http://finance.groups.yahoo.com/group/kanbandev/.
■ Personal Kanban 101—Este sitio presenta las ideas de Kanban Personal.
http://mng.bz/61Zn.
A.5.1 Blogs notables

Estos son algunos de los blogs y sitios que visitamos a menudo:
■ http://joakimsunden.com (Joakim Sundén)
■ http://www.marcusoft.net (Marcus Hammarberg)
■ http://positiveincline.com (Mike Burrows)
■ http://www.agilemanagement.net (David J. Anderson)
Libros sobre negocios y gestión del cambio 315
■ http://hakanforss.wordpress.com (Håkan Forss)

■ http://dannorth.net (Dan North)
■ http://flowchainsensei.wordpress.com (Bob Marshall)
■ http://availagility.co.uk (Karl Scotland)
■ http://brodzinski.com (Pawel Brodzinski)
■ http://www.dennisstevens.com (Dennis Stevens)
■ http://blog.crisp.se/author/mattiasskarin (Mattias Skarin)
■ http://leanandkanban.wordpress.com (David Joyce)
■ http://blog.jabebloom.com (Jabe Bloom)
■ http://www.klausleopold.com (Klaus Leopold)
■ http://www.software-kanban.de (Arne Roock)
■ http://lizkeogh.com (Liz Keogh)
■ http://zuill.us/WoodyZuill (Woody Zuill)
A.5.2 Cuentas de Twitter notables

Chris Achouiantz @ChrisAch Klaus Leopold @klausleopold
Gojko Adzic @gojkoadzic Janice Linden-Reed @jlindenreed
Agile Borat @AgileBorat Bob Marshall @flowchainsensei
David J. Anderson @djaa_dja Henrik Mårtensson @Kallokain
Jurgen Appelo @jurgenappelo Uncle Bob Martin @unclebobmartin
Kent Beck @KentBeck Benjamin Mitchell @benjaminm
Jim Benson @ourfounder Niklas Modig @LeanOnMyself
Jabe Bloom @cyetain Dan North @tastapod
Pawel Brodzinski @pawelbrodzinski Michael (Doc) Norton @DocOnDev
Martin Burns @martinburnsuk Staffan Nöteberg @staffannoteberg
Mike Burrows @asplake Jeff Patton @jeffpatton
George Dinwiddie @gdinwiddie Mary Poppendieck @mpoppendieck
Håkan Forss @hakanforss Jonathan Rasmusson @jrasmusson
Torbjörn Gyllebring @drunkcod Donald Reinertsen @DReinertsen
Kurt Häusler @Kurt_Haeusler Karl Scotland @kjscotland
Ron Jeffries @RonJeffries Al Shalloway @alshalloway
Liz Keogh @lunivore James Sutton @LeanSE
Henrik Kniberg @henrikkniberg Jean Tabaka @jeantabaka
LeanKanbanConference @LeanKanban Adam Yuret @AdamYuret
LeanKit @LeanKit Woody Zuill @WoodyZuill
apéndice B
Herramientas kanban
Algunas de las preguntas y sugerencias más comunes que recibimos al presentar kanban son sobre
herramientas: "Seguramente debe haber una herramienta electrónica para rastrear adhesivos",
"¿Pero y si estamos distribuidos geográficamente? ¿Sería mejor un tablero en línea? y así.
Hay muchas herramientas por ahí, y muchas de ellas son útiles y geniales. No hemos
hablado demasiado sobre herramientas electrónicas en línea en este libro por una simple razón: este
es un libro sobre los principios y el pensamiento de kanban y no sobre las herramientas. Cuando
comprenda los principios, puede doblar las herramientas a su voluntad.
A menudo sugerimos a los nuevos equipos que comiencen en un tablero físico y luego pasen
a una herramienta electrónica cuando la dominen. No es que no pueda comenzar electrónicamente,
pero a menudo hay una tendencia a no cambiar mucho las herramientas electrónicas si, por ejemplo,
es algo difícil de hacer y que lleva tiempo. 1 Cuando comience a usar kanban, desea que sea muy
simple cambiar su proceso cuando vea la necesidad: como limpiar una pizarra y comenzar de
nuevo.
Asegúrese de que la herramienta no dicta lo que puede hacer con su proceso. Una
herramienta es algo que debería servirle, no al revés.
Aquí hay una lista de herramientas sobre las que hemos usado o escuchamos cosas buenas.
Esta lista probablemente era antigua en el momento en que la escribimos, así que mantenga sus ojos
y oídos abiertos para obtener herramientas más nuevas, mejores y más frescas.
Las listas a continuación no están en un orden particular. Ninguno de estos proveedores nos
pagó, ni nos inclinamos hacia ninguna de las herramientas (porque preferimos tableros físicos
cuando podemos tenerlos). Hicimos un saludo rápido en Twitter y recibimos algunas sugerencias.
1
Por ejemplo, ambos trabajamos en una compañía que tenía "Greenhopper guys", que eran los únicos que sabían cómo
hacerlo y tenían la autorización para cambiar el tablero.
316
Herramientas independientes 317
B.1 Herramientas independientes

Estas herramientas pueden ejecutarse de forma independiente; no necesitas otro producto debajo de
ellos. En algunos casos, puede importar elementos de trabajo desde otras herramientas como JIRA,
Team Foundation Server, etc., pero en la mayoría de los casos estas herramientas son sistemas
separados.
B.1.1 LeanKit Kanban
LeanKit Kanban (http://leankit.com) es una herramienta kanban liviana que admite muchas de las
prácticas avanzadas analizadas en este libro. De hecho, lo hemos usado durante la planificación y
redacción del libro. A pesar de la naturaleza ligera de la herramienta, es potente y admite muchas
formas de trabajo. Todo, desde simples tableros personales hasta procesos avanzados de toda la
organización, se puede modelar en la herramienta. La versión gratuita permite hasta 25 usuarios y
10 tableros.
B.1.2 AgileZen
318 APÉNDICE B Herramientas kanban
AgileZen (www.agilezen.com) es una herramienta kanban simple que se puede utilizar desde el
nivel personal hasta el nivel de las grandes organizaciones. Tiene un plan de introducción gratuito
para un usuario y un proyecto de muestra que lo ayuda a conocer el producto.
B.1.3 Trello
Trello (https://trello.com) es una herramienta organizativa simple. Se puede usar para visualizar su
proceso kanban, pero no solo está orientado hacia kanban. Por lo tanto, faltan algunas
características que podría esperar (límites de WIP, por ejemplo). Sin embargo, sigue siendo útil: es
fácil comenzar y es completamente gratis.
B.1.4 KanbanFlow
KanbanFlow (https://kanbanflow.com) es otra herramienta de la que hemos escuchado grandes

cosas. Se centra en la simplicidad y es compatible con la mayoría de los casos de uso comunes,
incluidos algunos que quizás no haya pensado antes (temporizadores Pomodoro incorporados, 2 por
ejemplo). Es gratis con un número ilimitado de usuarios y ofrece algunas características adicionales
en la versión paga.
B.1.5 Kanbanize
Kanbanize (http://kanbanize.com) parece prometedor, aunque no lo hemos usado. La lista de

características es extensa y ofrece una demostración en vivo de la herramienta. También hay una
versión comunitaria gratuita.
B.1.6 Kanbanery
Kanbanery (https://kanbanery.com) es otra herramienta con una extensa lista de características y

admite la importación de elementos de trabajo desde otras herramientas (a través de archivos CSV).
Hay un plan de prueba gratuito de 30 días.
2
La técnica Pomodoro es una técnica personal de gestión del tiempo que le ayuda a enfocar su trabajo en cortos
períodos de tiempo.
320 APÉNDICE B Herramientas kanban
B.2 Herramientas sobre herramientas

Estas herramientas se instalan como complementos a los sistemas existentes.
B.2.1 JIRA Agile
JIRA Agile (www.atlassian.com/software/jira/agile) es la herramienta kanban de Atlassian para usar

en combinación con su popular sistema de seguimiento de problemas, JIRA.
B.2.2 Kanban in Team Foundation Service
Microsoft proporciona soporte integrado para tableros kanban en su herramienta de gestión de

proyectos, Team Foundation Service (TFS). Para los usuarios de TFS, esta es una adición muy útil a
la suite (http://mng.bz/4vd0).
B.2.3 HuBoard
HuBoard (http://huboard.com) es un sistema Kanban de GitHub que se basa en su sistema de

seguimiento de problemas.
Index
A BDD (behavior-driven work items on
A-team 142 development) 98 limiting 27–34
A/B testing 250 Bellware, Scott 106 overview 18–22
abandoned ideas, as big daily 152–154 See also kanban board
metric 252–253 blocked work items boredom 271–274
Accept column 14 as metric Bottleneck Game
acceptance testing 98 analyzing 247 benefits 304
accountability 268 capturing 246 how to play 303–304
Agile Adoption Patterns: overview 245–246 overview 302–304
A Roadmap to visualizing 247 questions for discussion 304
Organizational determining WIP limits 115 requirements 303
Success 205 blockers bottlenecks
Agile Manifesto 137 avoiding 137 cards displaying 70
Agile Retrospectives 218 avoiding new work 138 identifying 51
Agile software development 51 on cards limiting WIP starting
Agile42 307 overview 81–82 from 119–120
AgileZen 318 progress indicators 82–83 source of 158–159
Analyze column 13 removing 137–138 Theory of Constraints 159–
Anderson, David J. 48 reserving special tasks for 164
Andon boards 56 138 bugs
animals as avatars 78 swarming technique 139 giving precedence to 51
annotating cards 71 tracking 138–139 types of work items 83
Aptitud 105 board business impact 212, 265
avatars big daily 152
on cards 78–79 designing as team 54 C
defined 78 expedite items 35–37 cadence
implementation process 55 as information radiator 11 creating for celebration
limiting number of 124 limiting WIP for entire frequent flyer miles 274
on work items 20 avoiding idle time 116–117 WIP limit 274–275
experimenting with defined 208–209
B 117–119 iterations 209
balancing flow speed and work one vs. two per team kanban approach 210
items 29 member 115 for retrospectives 221–222
batches, working with mapping workflow 12–18 switching from Scrum
smaller 22–27 overview 8–11 209–210
walking, during daily
standup 146–147
232
324 Index
call centers 141 coin flipping game 22–27 overview 238–241

cards See also Pass the Pennies visualizing 242–243
avatars on 78–79 collaboration
blockers on advantage of using cards 71 D
overview 81–82 improvement from 52 Daily Kata 230–231
progress indicators 82–83 limiting WIP 116 daily standup 64–65
on board 70 colors best practices
collaboration 71 categorizing items 21 focused 145
deadlines on 79–80 deadlines and 79 on time 144–145
description types 75–77 differentiating types of regular 145
design principles 72–74 work 83 short length 65, 144
electronic vs. physical 71 as quality metric 84 blocked items 81
facilitating decision using on work items 20 focusing on smells 147–148
making 72–73 visualizing classes of focusing on work instead of
limited space as advantage 80 service 170 people 146
optimizing outcome 73–74 columns multiteams 151–154
size of 74 board divisions 66 prioritization 149
tracking IDs on 80–81 limiting WIP by 119–122 simplifying visualizations 149
cartoons on cards 78 purpose of 50 spontaneous kaizen 149–150
celebrations component teams 142 walking board 146–147
frequent flyer miles 274 constraints 161 work not displayed on
WIP limit 274–275 See also Theory of Constraints board 148–149
CFD (cumulative flow diagram) context switching dates, as workflow metric 88
data needed for 260–261 effects of excess WIP 99–101 days, avoiding use of in
drawing diagram 261–262 wastes in software estimates 198
overview 260 development 133 deadlines
reading diagram 262–263 continuous improvement 60 on cards 79–80
charts. See diagrams continuous integration 140 displaying on work items 19
classes of service converting story points 198 progress based on 86
advantages of 177–181 CONWIP 119 promoting on work items 73
Defects class 176 coordination cost 179 debt, technical 276
designing core practices 52 decisions, facilitating using
different workflow for 171 cost, balancing with scope and cards 72–73
impact on WIP 170 time 276 defects 133
prioritization 171 counting down as progress 86 Defects class 176
visualization 170 cross-functional teams delays
dividing work items and feature teams vs. component effects of excess WIP 101–102
reclassifying teams 142 wastes in software
favoring customers 182 overview 141–142 development 133
overview 182 cumulative flow diagram. See CFD descriptions
size of work item 182 current situation 8 on cards 76–77
source of demand 183 customers length of 19
Fixed Delivery Date class defining 15 referencing additional
172–173 favoring some over information 19
Intangible class 174–175 others 182 user story 75–76
managing 181 importance of in planning design principles for cards
overview 167–168 212–215 72–74
Regular class 173–174 promoting preferences on Development column 14
simplifying 183–184 work items 73 diagrams
Urgent class 168 value and 132 CFD
Coaching Kata 231–233 cycle times data needed for 260–261
Cockburn, Alistair 60 defined 239 drawing diagram 261–262
code vs. lead time 240 overview 260
not in production 98 as metric reading diagram 262–263
not integrated 97 analyzing 242
untested 98 capturing 241–242
Index 325
diagrams (continued) line of cards 202–203 Theory of Constraints

SPC Planning Poker 203–206 159–164
chart 256–257 using t-shirt sizes 199–201 cross-functional teams
data needed for 257 See also planning feature teams vs. compo-
drawing diagram 257–258 event-driven planning 189 nent teams 142
overview 254 events overview 141–142
reading diagram 259–260 order point as 190 daily standup
theory of variation 254–256 planning prompted by 210 best practices 144–145
discarded ideas, as metric excess WIP, effects of focusing on smells
analyzing 252–253 context switching 99–101 147–148
capturing 252–253 delays cause extra work focusing on work instead of
overview 252 101–102 people 146
discussion, as goal of motivation lost 106–108 multiteams 151–154
estimation 205 overhead increases 104–105 prioritization 149
Disneyland wait times 194–196 quality lowered 105–106 simplifying
Dot Game risk increases 103 visualizations 149
benefits 301 expedite items 35–37 spontaneous kaizen
first iteration 297–299 explicit policies 58–59 149–150
how to play 296 Extreme Programming. See XP walking board 146–147
Little's law in 299 work not displayed on
overview 295–302 F board 148–149
requirements 295 Facebook 103 defined 12
second iteration 299–300 failure demand expedite items and 37
third iteration 300–301 as metric importance of 132
tips 302 analyzing 252 improving 50
double bookkeeping 80 capturing 252 knowing what to do next 154
downstream 186 overview 251 limiting WIP 33, 134
drawings on cards 78 visualizing 252 optimizing for 135
Drive: The Surprising Truth About vs. value demand 140–141 reducing waiting time
What Motivates Us 274 feature requests 83 ensuring work is ready 136
due date performance 195 feature teams 142 overview 135
analyzing 248–249 feedback work items size 136
capturing 248 limiting WIP and 110 vs. resource utilization 135
overview 247–248 receiving quickly 102 resource utilization and 26
visualizing 248 feedback loops 52 setting target 143
Fibonacci series 198 waste
E FIFO (First In, First Out) 171, eliminating 132–133
electronic cards and tools 11, 71 174 in software
emotional data 89 finishing work in process 27–34 development 133–134
empty wall space 63 fist of five voting 221 Forss, Håkan 228
entry/exit criteria for Five Focusing Steps 161 Freedom from Command and
queues 68–69 five whys 223 Control 141
estimated data, vs. real data 267 Fixed Delivery Date class frequent flyer miles 274
estimating 172–173
defined 196–197 Flip the Chip. See Pass the Pen- G
need for diminishes 211–212 nies games
No Estimates movement 213 flow Bottleneck Game
story points avoiding rework 140–141 benefits 304
advantages of 198 blockers how to play 303–304
disadvantages of 198–199 removing 137–138 overview 302–304
overview 197–198 swarming technique 139 questions for
techniques tracking 138–139 discussion 304
Goldilocks 206–208 bottlenecks requirements 303
source of 158–159
326 Index
games (continued) groups, estimating in 201 information refrigerators 60

Dot Game Gyllebring, Torbjörn 213 Intangible class 174–175
benefits 301 iron triangle 275–279
first iteration 297–299 H issues. See blocked work items
how to play 296 handoffs 133 iterations 209
overview 295–302 hidden work
requirements 295 discovering 10 J
second iteration 299–300 visualizing 11 JIRA 9
third iteration 300–301 hours, avoiding use of in JIRA Agile 320
tips 302 estimates 198 just-in-time concept 130,
getKanban game HuBoard 321 188–189
benefits 306–307
how game is played 305–306 I K
overview 304–307 icons 170 kaizen 216
questions for idle time kanban
discussion 306 limiting WIP for entire basic principles of 22
requirements 305 board 116–117 board 8–11
tips 306 people vs. work 111 cadence in 210
Kanban Pizza Game Impact Mapping 251 core practices
benefits 308–309 implementation process 53–55 kanban board 59
how to play 307–308 Implementing Lean Software Devel- make policies explicit 58
overview 307–309 opment: From Concept to visualize 57, 59
questions for Cash 133 defined 3, 48
discussion 308 improvement guides using met- evolutionary introduction
requirements 307 rics to 280
list of 286–288 balancing metrics 266 expedite items 35–37
Number Multitasking Game business impact 265 finishing work in process
benefits 294–295 ease of gathering data 266 27–34
how to play 292–294 improvement and mapping workflow 12–18
overview 291–295 accountability 268 meaning of word 49
questions for metrics and results 265–266 as metaprocess 48, 282
discussion 294 real data vs. estimated metrics 38–41
requirements 292 data 267 not a process 282
Pass the Pennies game visualizations 264–265 principles of 49–53
benefits 291 Improvement Kata 231–233 process to implement 53–55
how to play 288–290 Increasingly Urgent class 174 tools 317–321
overview 288–291 index cards 70 work items 18–22
questions for information radiator working with small
discussion 290 board 63–65 batches 22–27
requirements 288 defined 11, 60 kanban board
tips 291 displaying information avatars on 124
Gantt chart 173 prominently 60–61 boxes for each work item 122
getKanban game examples of 60 cards on 70
benefits 306–307 legible text 62 columns 66
how game is played 305–306 location 61 daily standups 65
overview 304–307 low-tech equipment 60 electronic vs. physical 61, 64
questions for discussion 306 mapping workflow 66 erasable markers 66
requirements 305 overload of information 62 as information radiator 63–65
tips 306 overview 59–60 legible text 62
GitHub 321 size 62 location 61, 64
Goldilocks technique 206–208 valuable information only 62 mapping workflow 66
Google Analytics 250 See also kanban board
Google Tag Manager 250
Google time 175
Index 327
kanban board (continued) Lean 3, 52 metrics

overload of information 62 Lean Software Development: An abandoned and discarded
placeholders on 122 Agile Toolkit 133 ideas
queues on LeanKit Kanban 317 analyzing 252–253
entry and exit criteria length of daily standup 144 capturing 252–253
68–69 limiting WIP 22, 27–34 overview 252
overview 67–68 advantages of 28 blocked work items
sense of ownership 66 based on columns 119–122 analyzing 247
size 62 for entire board capturing 246
swim lanes 124 avoiding idle time 116–117 overview 245–246
unlimited number of items experimenting with visualizing 247
on 112 117–119 CFD
valuable information only 62 one vs. two per team data needed for 260–261
Kanban Kata member 115 drawing diagram 261–262
advantages of 234–236 flow and 134 overview 260
Coaching Kata 231–233 implementation process 55 reading diagram 262–263
Daily Kata 230–231 lower better than higher cycle and lead times
defined 150 110–111 analyzing 242
Five Questions 234 people idle vs. work idle 111 capturing 241–242
Improvement Kata 231–233 people-based limits 123–125 overview 238–241
overview 228–230, 234 picking a column 120 visualizing 242–243
Kanban Pizza Game pitfall of not using 283–285 deciding which to track 253
benefits 308–309 principle of kanban 50 due date performance
how to play 307–308 priority filters 191 analyzing 248–249
overview 307–309 queues and 127–128 capturing 248
questions for discussion 308 setting limits overview 247–248
requirements 307 one is not answer 113–114 visualizing 248
Kanbanery 319 stop starting, start failure demand
KanbanFlow 319 finishing 112–113 analyzing 252
Kanbanize 319 starting from bottleneck capturing 252
kata 229 119–120 overview 251
See also Kanban Kata by story points 120 visualizing 252
KPIs (key performance swarming technique 139 gathering data from work
indicators) 38 using avatars 78–79 items 87–89
work items vs. tasks 126–127 improvement guides using
L line of cards estimating balancing metrics 266
Law of Average Averages 214 technique 202–203 business impact 265
law of diminishing returns 197 Little’s law 95–96, 134 ease of gathering data 266
laziness 281–283 context switching 101 improvement and
lead time Dot Game 299 accountability 268
vs. cycle time 240 location metrics and results 265–266
defined 24, 94, 239 of board 64 real data vs. estimated
due date performance 196 of daily standup 145 data 267
as metric of information radiator 61 visualizations 264–265
analyzing 242 lower control limit 258 overview 38–41
capturing 241–242 predicting wait times 194
overview 238–241 M quality
visualizing 242–243 maintenance items 83 analyzing 250–251
number of work items and 26 mapping workflow 12–18, 66 capturing 249–250
as target 143 meetings 143 overview 249
throughput and 245 early participation in 219 visualizing 250
tracking 39 in front of board 65 SPC
WIP and 94 meta-process 48 chart 256–257
data needed for 257
drawing diagram 257–258
328 Index
metrics (continued) overview 288–291 designing classes of

overview 254 questions for discussion 290 service 171
reading diagram 259–260 requirements 288 during daily standup 149
theory of variation 254–256 tips 291 easier through
throughput pattern-matching using visualization 18
analyzing 245 avatars 78 priority filters 191
capturing 244 PDCA (Plan-Do-Check-Act) 232 urgent items 169
overview 243–244 peer pressure 62 priority filters 191–193
visualizing 245 people idle vs. work idle 111 proactive work 267
value demand people-based limits 123–125 process improvement
analyzing 252 performance and due dates Kanban Kata
capturing 252 analyzing 248–249 advantages of 234–236
overview 251 capturing 248 Coaching Kata 231–233
visualizing 252 overview 247–248 Daily Kata 230–231
metro vs. train 195 visualizing 248 Improvement Kata 231–233
miscellaneous classification 179 physical vs. electronic cards 71 overview 228–230, 234
mob programming 114 pictures on cards 78 retrospectives
Monte Carlo simulation 214 pitfalls cadence for 221–222
motivation 106–108 boredom 271–274 deciding what to do
multitasking 100 cadences, creating for celebra- 220–221
multiteam daily standups tion defined 218–219
151–154 frequent flyer miles 274 discussing data 220
WIP limit 274–275 gathering data 220
N creating revolution 279–281 setting stage for 220
#NoEstimates 213–214 laziness 281–283 voting on 221
non-value-added wastes 132 timeboxes 275–279 root-cause analysis
NPS (net promoter score) 250 WIP limits, not using 283–285 finding source of
Number Multitasking Game Plan-Do-Check-Act. See PDCA problem 225
benefits 294–295 planning overview 222–223
how to play 292–294 cadence why fix is needed 223–225
overview 291–295 defined 208–209 process policies 52
questions for discussion 294 iterations 209 process smells 73
requirements 292 kanban approach 210 procrastination of intangible
switching from Scrum items 175
O 209–210 progress indicators
one-piece continuous flow 130 customer importance on blockers 82–83
online tools 317–321 212–215 cards displaying 70
Optimizely 250 event-driven planning 189 counting down as progress 86
optimizing locally 241 just-in-time planning 188–189 on work items 85–86
order points 189–190 need for diminishes 211–212 prominently displaying
overhead 104–105 not overlooking 211 information 60–61
overload of information 62 order points 189–190 pull principle 146
overview 185–188 pulling work 210
P predicting wait times 194–196
priority filters 191–193 Q
pair programming 116, 140 See also estimating
parking lot for blocked items 82 quality
Planning Poker technique building in from start 140
partially done work 133 203–206
participation in meetings 219 effects of excess WIP 105–106
policies, making explicit 58–59 iron triangle 276
Pass the Pennies game 22–27 Pomodoro 319
benefits 291 as metric
positive peer pressure 62 analyzing 250–251
how to play 288–290 predicting wait times 194–196 capturing 249–250
principles of kanban 49–53 overview 249
prioritization visualizing 250
based on lead times 242
Index 329
queues S specifications not imple-

on board scheduling 180 mented yet 96–97
entry and exit criteria See also planning untested code 98
68–69 Schwaber, Ken 272 source of demand 183
overview 67–68 scientific method 234 SPC (statistical process control)
cards displaying 70 scope, balancing 276 chart 256–257
limiting WIP at 127–128 Scrum 8, 48, 79, 143 data needed for 257
sprints 208, 278 drawing diagram 257–258
R story points 197 overview 254
Rational Unified Process. See switching from 209 reading diagram 259–260
RUP transitioning from 209–210 theory of variation 254–256
reactive work 267 ScrumBan 210 specification by example 98, 136
real data vs. estimated data 267 self-organization specifications not
Refactoring: Improving the Design of deadlines and 79 implemented 96–97
Existing Code 73 knowing what to do next 154 spontaneous kaizen 149–150
Regular class 173–174 promoting 72 Spotify 61, 150
regularity of daily standup 145 separating types of work 83 sprints 208, 278
Reinertsen, Don 117 using classes of service 180 stakeholders
relative estimates 197 sense of ownership 66 accessibility of information
relearning 133 service-level agreement. See SLA radiators 60
reporting progress 212 7 Habits of Highly Effective People, assigning tasks directly 7
resource utilization 26, 135 The 175 building trust 195
Retrospective Handbook, The 218 sigma 258 predicting wait times 195
retrospectives signals, visual 67, 190 visualizing needs to 16
cadence for 221–222 simplifying classes of statistical process control. See
deciding what to do 220–221 service 183–184 SPC
defined 218–219 size stickers 170
discussing data 220 amount of work involved stickies 70
gathering data 220 86–87 blockers 82
online resources 219 cards 74 colors
setting stage for 220 information radiator 62 deadlines and 79
voting on 221 relative estimates 87 mixing 84
return of time invested. See work items information radiators 60
ROTI breaking up XL and limited space as advantage 80
revolution needed to introduce larger 200 removing without curling 72
kanban 279–281 classifying 182 size of 74
rework, avoiding 140–141 reducing waiting time 136 smells 73
risk SLA (service-level too much information on 73
abandoned ideas metric 252 agreement) 85 visualizing questions 150
effects of excess WIP 103 designing classes of stop starting, start finishing 53,
risk-management service 182 112–113, 155
information 79 due date performance stop-the-line cord 56
roles 8 metric 247 story points
root-cause analysis as target 143 estimating using
finding source of small batches 25 advantages of 198
problem 225 smells disadvantages of 198–199
overview 222–223 focusing on during daily overview 197–198
why fix is needed 223–225 standup 147–148 limiting WIP by 120
ROTI (return of time on work items 73 swarming technique 139, 169,
invested) 134 software development 171
RUP (Rational Unified waste in 133–134 swim lanes 124, 169
Process) 8, 48 WIP for synchronizing multiple
code not in production 98 teams 186
code not integrated 97
330 Index
T timespans for due date colors and 21

t-shirt sizes 199–201 performance 196 cycle times 242–243
Tame the Flow 163 Todo column 13 designing classes of
tasks tools 317–321 service 170
non-recorded 10 Toyota 130 due date performance 248
reserving for when kata 229 explicit policies and 58–59
blocked 138 Motomachi assembly plant 56 failure demand 141, 252
vs. work items 126 Toyota Way management hidden work 11
TDD (test-driven system 216 implementation process 53
development) 98, 140, 280 use of visualization 56 importance of 16
team Toyota Kata 229 improvement guides using
deciding on metrics 238 tracking blockers 138–139 metrics 264–265
deciding on type of board 61 tracking IDs 80–81 information radiator 11
designing board as 54 train vs. metro 195 board 63–65
Team Foundation Service. See transparency, visualization displaying information
TFS and 58 prominently 60–61
Team Kanbaneros 5–8 Trello 318 location 61
teams trends 242 mapping workflow 66
cross-functional triggering discussions 149 overload of information 62
feature teams vs. compo- triple constraints 276 overview 59–60
nent teams 142 Twitter 103 size 62
overview 141–142 valuable information
multiteam daily U only 62
standups 151–154 unit testing 98 lead times 242–243
swarming technique 139 untested code 98 of needs to stakeholders 16
synchronizing multiple 186 upper control limit 258 of order point 190
WIP limits for entire upstream 135, 186 principle of kanban 49
team 115 Urgent class 35 prioritization easier
technical debt 276 avoiding overuse 169 through 18
technical gold cards 175 overview 168 quality, as metric 250
test-driven development. See promoting fixed date items of questions 150
TDD to 173 queues
testers 162 user story description type 75–76 entry and exit criteria 68–69
Testing column 14 overview 67–68
TFS (Team Foundation V simplifying 149
Service) 320 valuable information only, on SPC
Theory of Constraints 51–52 board 62 chart 256–257
five focusing steps 161, 303 value demand data needed for 257
managing bottlenecks analyzing 252 drawing diagram 257–258
159–164 capturing 252 overview 254
teaching with Bottleneck vs. failure demand 140–141 reading diagram 259–260
Game 302 overview 251 theory of variation 254–256
theory of variation 254–256 visualizing 252 throughput 245
throughput value, for customer 132 trends 242
analyzing 245 visualization of urgent items 169
capturing 244 big daily 152 value demand 252
overview 243–244 blocked work items 247 of waiting time 135
visualizing 245 CFD voting with fist of five 221
time data needed for 260–261
balancing with scope and drawing diagram 261–262 W
cost 276 overview 260 wait times
reporting 105 reading diagram 262–263 making visible 135
timeboxes 143, 208, 275, predicting 194–196
277–279
Index 331
wait times (continued) people idle vs. work classifying

reducing idle 111 favoring customers 182
ensuring work is ready 136 people-based limits overview 182
overview 135–136 123–125 size of work item 182
size of work items 136 picking a column 120 source of demand 183
walking board 146–147 pitfall of not using 283–285 descriptions 19
wall space 63 principle of kanban 50 limiting 22
waste priority filters 191 number of simultaneous and
eliminating 132–133 queues and 127–128 lead time 26
obsessing about 133 setting limits 112–114 overview 18–22
in software development starting from progress indicators 85–86
133–134 bottleneck 119–120 size of work 86–87
whiteboards 63 by story points 120 size of, and waiting time 136
information radiators 60 swarming technique 139 smells on 73
starting with physical 316 using avatars 78–79 vs. tasks 126
Wild Ass Guess. See WAG work items vs. tasks 126–127 types of work 83–85
WIP (work in process) 26 Little’s law 95–96 using boxes for each 122
balancing flow and idle software development workflow data from 87–89
time 29 code not in production 98 workflow
cadences for code not integrated 97 designing classes of
celebrations 274–275 specifications not imple- service 171
defined 93 mented yet 96–97 gathering data from work
effects of excess untested code 98 items
context switching 99–101 work idle vs. people idle 111 emotions for
delays cause extra work items retrospective 89
work 101–102 blocked, as metric workflow metrics 87–89
motivation lost 106–108 analyzing 247 implementation process 53
overhead increases 104–105 capturing 246 lead time in 24
quality lowered 105–106 overview 245–246 mapping on board 12–18, 66
risk increases 103 visualizing 247 principle of kanban 50
expedite items 37 cards start and end of 12
finishing 27–34 avatars on 78–79
lead time and 94 blockers on 81–83 X
limiting deadlines on 79–80 XL items, breaking up 200
based on columns 119–122 description types 75–77 XP (Extreme Programming) 48,
for entire board 115–119 design principles 72–74 197
flow and 134 facilitating decision
lower better than making 72–73 Z
higher 110–111 optimizing outcome 73–74 Zuill, Woody 114
no limit is not answer tracking IDs on 80–81
111–112

Kanban en Accion

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Kanban en Accion

Cargado por

Copyright:

Formatos disponibles

Por: Ernesto J.J.

Special Sales Department

© 2014 por Manning Publications Co. Todos los derechos reservados.

Ninguna parte de esta publicación puede ser reproducida, almacenada en un sistema de

Reconociendo la importancia de preservar lo que se ha escrito, la política de Manning es tener

Manning Publications Co. Editores de desarrollo: Beth Lexleigh, Cynthia Kane

1 ■ Equipo de Kanbaneros comienza 3

PARTE 2 ENTENDIENDO KANBAN ...................................................... 45

PARTE 3 KANBAN AVANZADO. ............................................................ 165

8 ■ Clases de servicio 167

PARTE 1 APRENDIENDO KANBAN .......................................... 1

1 Equipo Kanbaneros comienza 3

PARTE 2 ENTENDIENDO KANBAN .............................. 45

5 Trabajo en proceso (Work in Process) 92

5.2 Efectos de demasiado WIP 99

6 Limitar el trabajo en proceso 109

7 Manejo de flujo 130

7.3 Standup diario 143

PARTE 2 KANBAN AVANZADO .............................. 165

8 Clases de servicio 167

9 Planificación y estimación 185

10 Mejora de procesos 216

11 Usando métricas para guiar las mejoras 237

12 Dificultades de Kanban 270

13 Enseñar kanban a través de juegos 286

13.2 El Juego Multitarea de Números 291

apéndice A Lecturas recomendadas y otros recursos 311.

Ver el trabajo y el proceso crea entendimiento.

Ver es la mitad de la batalla

El trabajo no encaja — fluye.

Demasiado WIP destruye el flujo

El siguiente año, participé en la primera tienda de entrenamiento de kanban de David J. Anderson

La estructura de este libro

No afirmamos que saldrás de un maestro kanban al final de este libro, pero

Cómo leer este libro

El compromiso de Manning con nuestros lectores es proporcionar un lugar donde pueda

JOAKIM es un pensador, el cerebro de nuestro dúo dinámico. A

En su tiempo libre, Joakim es aficionado a la comida y al cine, y citas de obscenas películas

MARCUS es un hacedor y, por lo tanto, el músculo de la pareja, para

Bienvenido a Kanban en acción!

"Adam es un probador. Ha estado presente por bastante tiempo y casi

"Beth es una nueva empleada. Ella es responsable del análisis de

"Cesar es el negocio. Prácticamente construyó la primera versión de la

"Daphne es una desarrolladora kick-ass. Se sabe que lanzó más

* A menudo entregamos tarde

* Las estimaciones son a menudo inexactas

* El equipo está inundado de trabajo

* Las prioridades no son claras

* El trabajo viene al equipo desde cualquier lugar

* Incierto quién está trabajando en qué

"Entendemos que estás ansioso por comenzar", respondió Joakim. "Pero tu

"¿Cómo se llama tu equipo, por cierto?", Preguntó Joakim.

* A menudo entregamos tarde

1.3 Mapeo del flujo de trabajo

"Para indicar que un trabajo se encuentra en cierta etapa, colocamos el

"¿Qué tal Bandeja de entrada?", Sugirió César.

"Pero podría llamarse Hecho o Fuera de nuestras manos, si lo desea",

se encuentra, puede ver un problema en su proceso".

"Mirando esto, ¿diría que es aproximadamente el

Asigne su flujo de trabajo al tablero

* Identifica todas las etapas, desde el trabajo que

1.4 Elementos de trabajo

RECUERDA No puedes mejorar lo que no ves.