Kanban:

Se basa en el trabajo en curso (WIP , Work in progress), debera

limitarse y solo empezar con algo nuevo cuando ya hayamos
acabado lo anterior (haya pasado a un fase posterior en la
cadena)
se genera una seal visual para indicar que hay nuevos bloques de

trabajo que pueden ser comenzados porque el trabajo en curso actual

no alcanza el mximo acordado
introduccin de cambios en un ciclo de vida de desarrollo de
software o metodologa de gestin de proyectos.
El principio de Kanban es que
o comienzas con lo que sea que ests haciendo ahora mismo
o Comprendes tu actual proceso mediante la realizacin de un
mapa del flujo de valor y entonces acuerdas los lmites de
trabajo en curso (WIP) para cada fase del proceso.
o A continuacin comienzas a hacer fluir el trabajo a travs del
sistema comenzndolo ("pull") cuando se van generando las
seales
o WIP est limitado, cualquier elemento que se bloquea por
tiende a atascar el sistema. Si un nmero suficiente de
elementos se bloquean todo el proceso se para en seco. Todo el
equipo y la organizacin se concentran en resolver el
problema, desbloqueando estos elementos para permitir la
restauracin del flujo productivo.
Kanban usa un mecanismo de control visual para hacer seguimiento
del trabajo conforme este viaja a travs del flujo de valor.
Tpicamente, se usa un panel
Kanban se est introduciendo para transformar la cultura de las
organizaciones y fomentar la mejora continua.
Las metodologas giles proporcionando transparencia respecto al
trabajo en curso y completado, as como en el reporte de mtricas
como la velocidad .
Kanban proporciona transparencia al proceso y su flujo. expone los
cuellos de botella, colas, variabilidad y desperdicios, que impactan al
rendimiento de la organizacin en trminos de la cantidad de trabajo
entregado y el ciclo de tiempo requerido para entregarlo. Kanban
motiva a una mayor colaboracin en el trabajo. La visibilidad de los
cuellos de botella, desperdicios y variabilidades y su impacto
tambin promueve la discusin sobre la posibles mejoras, y los
equipos comienzan rpidamente a implementar mejoras en su
proceso.
Kanban, por su naturaleza de Sistema Pull ("arrastre", "tirar"; la produccin
se realiza cuando el cliente retira un elemento terminado), la priorizacin

del trabajo nuevo como en la entrega del trabajo existente. Tpicamente, los
equipos llegarn a un acuerdo sobre la cadencia de reuniones de
priorizacin. Estas reuniones se pueden mantener de forma frecuente
porque habitualmente son bastante cortas. Se responde a una pregunta
simple, algo como "Desde nuestra ltima reunin hemos liberado dos
huecos de trabajo, y nuestro tiempo de ciclo actual es de 6 semanas para
entregar. Qu dos cosas son las que ms os gustara ver entregadas dentro
de 6 semanas. Proporciona respuestas rpidas y de buena calidad, y
mantiene las reuniones cortas.
efecto de limitar el WIP proporciona predecibilidad sobre el tiempo
de ciclo y hace que los entregables sean ms fiables. La estrategia de
"parar el proceso" ante impedimentos y bugs tambin parece
promover altos niveles de calidad y un rpido descenso del retrabajo.

Porque
Seguimos fracasando en nuestros Sprints
Porque nos resulta muy difcil comprometernos a una planificacin
de 2 semanas. Simplemente nos ponemos con lo ms urgente que
tenemos cada da.
tenemos asuntos que van surgiendo en el da a da y no podemos
hacer sprints
Podramos eliminar los sprints, usar lo que nos gusta de scrum y
combinarlo con Kaban

Kabam
Visualiza el flujo de trabajo: Divide el trabajo en bloques, escribe
cada elemento en una tarjeta y ponlo en el muro. Utiliza columnas
con nombre para ilustrar dnde est cada elemento en el flujo de
trabajo.
Limita el WIP (Work in Progress, trabajo en curso) - asigna lmites
concretos a cuntos elementos pueden estar en progreso en cada
estado del flujo de trabajo.
Mide el lead time (tiempo medio para completar un elemento, a
veces llamado "tiempo de ciclo"), optimiza el proceso para que el
lead time sea tan pequeo y predecible como sea posible.
http://www.crisp.se/kanban

Que son
Scrum y Kanban no son ni perfectas ni completas. No te dicen todo
lo que tienes que hacer, solo proporcionan ciertas restricciones y
directrices. Por ejemplo, Scrum te obliga a tener iteraciones de
duracin fija y equipos interdisciplinarios, y Kanban te obliga a usar
tableros visibles y a limitar el tamao de tus colas.
Los mtodos giles se denominan a veces los mtodos ligeros, en
concreto, porque son menos restrictivos que los mtodos
tradicionales.
Scrum y Kanban son muy adaptables, pero en trminos relativos
Scrum es ms restrictivo que Kanban. Scrum te da ms
limitaciones, y as deja menos opciones abiertas. Por ejemplo
Scrum prescribe el uso de iteraciones de duracin fija, Kanban no.
Kanban deja casi todo abierto. Las nicas normas son Visualiza tu
Flujo de trabajo y Limita tu WIP

Mezcla y combina las herramientas que necesites! equipo Scrum que no

incluye la mayora de los elementos de XP. equipos Kanban hacen
reuniones diarias (una prctica de Scrum). Algunos equipos Scrum limitan
el tamao de las colas (una prctica de Kanban). Usa lo que sea que
funcione para ti.
Sin embargo, presta atencin a las limitaciones de cada herramienta

Diferencias Scrum/kanban
Scrum prescribe 3 roles: dueo de producto (establece la visin del
producto y las prioridades), equipo (implementa el producto) y
Scrum Master (elimina los impedimentos y proporciona liderazgo en
el proceso). Kanban no establece ningn rol en absoluto. Eso no
significa que no puedas o no debas eres libre de aadir los roles
adicionales que necesites. Ten cuidado que los roles adicionales
realmente aaden valor y no entran en conflicto con otros elementos
del proceso.
dueo de producto" para representar a quien establece las
prioridades de un equipo,
Scrum se basa en iteraciones de tiempo fijo. mantener la misma
longitud de la iteracin durante un perodo de tiempo, determinando
as una cadencia. combina tres actividades distintas: la planificacin,
la mejora de procesos, y (idealmente) la entrega. En Kanban no se
prescriben iteraciones de tiempo fijo. Puedes elegir el momento de
hacer la planificacin, la mejora de procesos, y la entrega. Puedes
elegir hacer estas actividades de manera regular o bajo demanda (
"la entrega cada vez que tengamos algo til para entregar"). Ejemplo

o Cadencia simple (scrum)

o 3 cadencias. Entrega cada semana, planif cada 2,
restropectiva cada 4
o Por eventos. entrega siempre que hay un MMF (Minimum
Marketable Feature Set, conjunto mnimo de caractersticas
comercializables) listo para entregar. Lanzamos un crculo de
calidad espontneo siempre que nos topamos con un mismo
problema por segunda vez. Adems hacemos una retrospectiva
ms en profundidad cada cuatro semanas. "
Limite del Wip: En Scrum, la pila de sprint muestra qu tareas han
de ser ejecutadas durante la iteracin actual En Scrum no hay
ninguna regla que impida que todos los elementos en la columna
en curso al mismo tiempo! Sin embargo, existe un lmite
implcito ya que la iteracin en s tiene un alcance fijo. lmite
implcito por columna es de 4, ya que slo hay 4 elementos en la
pizarra.
o As que Scrum limita el WIP indirectamente, mientras que
Kanban limita el WIP directamente.
o La mayora de los equipos de Scrum aprenden finalmente que
es una mala idea tener demasiados elementos en curso, tener
los elementos actuales terminados antes de comenzar con
nuevos elementos. Algunos incluso deciden limitar
explcitamente el nmero de elementos permitidos en la
columna de en curso y, - la pizarra de Scrum se ha convertido
en una pizarra de Kanban!
o Scrum suelen medir la velocidad cuntos elementos (o
unidades correspondientes, tales como "puntos de historia") se
hacen por iteracin. velocidad, sta se convierte en su lmite
de WIP Un equipo que tiene una velocidad media de 10 no
suele tomar ms de 10 elementos (o puntos de historia) para
un sprint. De forma que en Scrum el WIP se limita por unidad
de tiempo.
o En Kanban el WIP se limita por el estado del flujo de trabajo.
la idea general es limitar el WIP de todos los estados del flujo
de trabajo, empezando por "lo ms pronto posible" y
terminando " Una vez que tenemos los lmites de WIP en su
lugar, podemos empezar a medir y predecir el tiempo de
entrega, tiempo medio de un elemento para realizar todo el
camino a travs de la pizarra. Tener tiempos de entrega
predecibles nos permite comprometer los SLA (acuerdos de
nivel de servicio, en ingls service-level agreements) y hacer
planes de entrega realistas.

o Si los tamaos de los elementos varan drsticamente entonces

podras considerar lmites de WIP definidos en trminos de
puntos de historia. Algunos equipos invierten sus esfuerzos en
la descomposicin de elementos de aproximadamente el
mismo tamao para evitar este tipo de consideraciones y
reducir el tiempo empleado en la estimacin de las cosas Es
ms fcil para crear un buen sistema de flujo si los artculos
son ms o menos de igual tamao.
Scrum y Kanban son ambos empricos. experimentes con el
proceso y lo adaptes a tu entorno.Ni Scrum ni Kanban proporcionan
todas las respuestas simplemente nos proporcionan una serie de
reglas y limitaciones. Hay diferentes trminos para referirse a este
proceso. Kaizen (mejora continua en terminologa Lean).
o EJ reducimos el lmite de trabajo en curso, Observamos cmo
la capacidad, el lead time, la calidad, y la predictibilidad
evolucionan. Sacamos conclusiones de los resultados y
ajustamos algunas cosas ms, mejorando continuament
o El elemento ms crtico de este proceso es el ciclo de
retroalimentacin, el feedback. Cambia algo => Observa cmo
funciona => Aprende de ello => Cambia algo de nuevo. En
general, lo que buscamos es obtener feedback en ciclos lo ms
cortos posibles, de manera que podamos adaptar nuestro
proceso rpidamente.
o En Scrum el ciclo bsico de obtencin de feedback es el sprint
o Y en Kanban. Seguramente debes poner todos los anteriores
ciclos de feedback en tus proyectos. Lo que Kanban te
proporciona es una serie de mtricas en tiempo real muy
tiles. Lead time medio: Actualizado cada vez que un
elemento alcanza el nivel de hecho. Cuellos de Botella: Un
sntoma tpico es que la columna X est abarrotada de
elementos mientras que la columna X+1 est vaca.
o Puedes elegir la longitud de tu ciclo de feedback, basndote en
con qu frecuencia quieres analizar estas mtricas e introducir
cambios. Un ciclo demasiado largo de retroalimentacin
significa que la mejora de tu proceso ser lenta. Uno
demasiado corto significa que tu proceso no podra no tener
tiempo para estabilizarse entre cambios, lo que puede producir
desperdicio de esfuerzos.
o Uno de los tpicos puntos de ajuste de Kanban es el lmite de
trabajo en curso. Cmo sabemos si lo estamos estableciendo
correctamente? Limite bajo: tenemos gente mirando. Si esto
ocurre con regularidad, la consecuencia es que el lead time

medio se incrementar. lead time a lo largo del ciclo de trabajo

completo ser innecesariamente alto. Limite alto. Si ocurre un
problema, por el que no podamos pasar tareas a la siguiente
fase (Falla el servidor de integraccin), llegar un momento
donde ya no podemos coger ningn elemento ms. El lmite
para el trabajo en curso nos impulsa a reaccionar y corregir el
cuello de botella en lugar de seguir acumulando un montn de
trabajo sin terminar. Esto est bien. Pero si el lmite de trabajo
en curso hubiese sido menor habramos reaccionado mucho
antes, de este modo tendramos un mejor lead time medio.
Medimos nuestro lead time medio y continuamente
optimizamos nuestro lmite de trabajo en curso para optimizar
el lead time
Cambios de prioridades:
o En Scrum , Si el dueo del producto considera que es de alta
prioridad ser aadido al siguiente sprint. Sprints de longitud
adecuada permiten al equipo mantenerse enfocados suficiente
tiempo como para lograr hacer algo, permitiendo adems que
el dueo del producto gestione y actualice prioridades de
manera regular.
o En Kanban. Aade con libertad a la columna Pendiente pero
hay un lmite de 2 para esta columna, en consecuencia tendrs
que quitar algo. Ahora estamos trabajando en xx, pero tan
pronto como tengamos capacidad disponible cogeremos el
primer elemento de la columna Pendiente.
o El tiempo de respuesta (cunto tiempo pasa hasta que
respondemos a cambios de prioridades) de un equipo Kanban
es tan largo como el tiempo que trascurre hasta que tenemos
capacidad disponible, En Scrum, el tiempo de respuesta medio
es la mitad de la duracin del Sprint.
o En Scrum, el dueo del producto no puede tocar el tablero una
vez el equipo se ha comprometido a completar un conjunto de
elementos en la iteracin. En Kanban t tienes que establecer
tu propias reglas sobre quin puede cambiar qu en el tablero.
estas dos aproximaciones no son excluyentes entre s. Un
equipo Scrum podra decidir permitir al dueo del producto
cambiar prioridades a mitad de sprint. Y un equipo Kanban
podra decidir aadir restricciones sobre cuando las
prioridades pueden ser cambiadas.
Scrum, Cuando se finaliza un sprint, se limpia el tablero - todos los
elementos son eliminados. Tras la reunin de planificacin del sprint
tendremos un nuevo tablero Scrum Tcnicamente esto es una prdida

de tiempo, pero para equipos Scrum experimentados no suele llevar

mucho, y el proceso de limpiar el tablero puede dar una grata
sensacin de logro. En Kanban, el tablero normalmente persiste
Un tablero Scrum es propiedad de solamente un equipo Scrum. Un
equipo Scrum es multi-funcional (tienen todos lo conocimientos
realizar la iteracin). tablero Scrum suele ser visible para cualquiera
En Kanban, los equipos multi-funcionales son opcionales, y un
tablero no necesita estar en manos de un equipo especfico. Un
tablero est relacionado con un flujo de trabajo, no necesariamente
con un equipo. Ejemplo 1 como Scrum, Ej 2, columna 1 pertenece al
Po, columna 2, y 3 a desarrollo y prueba. La columna 4 es la puesta
de produccin, realizada por especialistas. Hay solapamiento de
competencias. Hay que poner reglas bsica a quin usa el tablero. Si
el equipo de produccin es un cuello de botella uno de los
desarrolladores le ayudar
Un equipo Scrum slo se comprometer con los elementos que creen
que pueden terminar en una iteracin . Si un elemento es demasiado
grande para caber en un sprint, hay que partirlo en pedazos ms
pequeos hasta que se pueda abordar en un sprint. Kanban tratan de
minimizar el tiempo de entrega y el nivel de flujo. Incentivo para
descomponer los elementos en pedazos relativamente pequeos. No
hay ninguna norma explcita que indique que los elementos deben
ser lo suficientemente pequeos como para caber en un intervalo de
tiempo especfico. En un tablero puede haber elementos de distintos
tamaos
Metricas:
o En Scrum, los equipos tienen que estimar el tamao relativo
de cada elemento al que se comprometen. Sumando el tamao
de cada elemento completado al final de cada sprint,
obtenemos la velocidad. La velocidad es una medida de la
capacidad - la cantidad de cosas que podemos ofrecer por
Sprint. Entonces podemos hacer predicciones realistas sobre
los elementos que se pueden completar en los prximos
sprints, y por lo tanto hacer planes de entrega realistas.
o En Kanban, no se prescribe la estimacin. garantizar la
previsibilidad.
hacer estimaciones y medir la velocidad como en
Scrum.
descomponer cada elemento en partes de
aproximadamente el mismo tamao -entonces pueden
medir la velocidad simplemente en funcin de cuntos
elementos se completan por unidad de tiempo

 Algunos equipos agrupan los elementos en MMF's

(caractersticas mnimas de comercializacin) y miden
el tiempo de entrega promedio por MMF, y lo usan para
establecer SLA (acuerdos de nivel de servicio)

Son Lean
o Planificacin tipo "Pull", principio de gestin de inventario
'Just In Time' (JIT). El equipo elige cundo y cunto trabajo
acometer. Ellos (los componentes del equipo) "tiran" del
trabajo cuando estn listos, en contraposicin a que desde el
exterior se "empuje" al equipo a hacerlo.
o se basan en procesos de optimizacin continuos y empricos,
que se corresponden con el principio Kaizen de Lean.
o dan ms importancia a la respuesta al cambioque al
seguimiento de un plan
o Scrum se puede ver como no-tan lean, ya que contempla
agrupar tareas por lotes dentro de iteraciones de tiempo
prefijado. Pero eso depende de la longitud de tu iteracin un
equipo Scrum produciendo cdigo entregable cada 2 semanas
se puede considerar muy Lean.
o Por consiguiente, si haces iteraciones cada vez ms cortas,
esencialmente te ests aproximando a Kanban.
Priorizacin: En Scrum, la priorizacin se hace siempre ordenando
la pila de producto y los cambios en las prioridades tienen efecto en
el siguiente sprint (no en el actual). En Kanban, puedes elegir
cualquier esquema de priorizacin (o incluso ninguno) y los cambios
tienen efecto tan pronto como la capacidad est disponible. Kanban
la columna de ms a la izquierda = que la pila de producto en Scrum.
Tanto en el caso de que la lista est ordenada por prioridad, como si
no, el equipo necesita una regla de decisin que permita saber cul es
el siguiente elemento del que tirar (la primera, la ms antigua, 20%
mantenimiento, 80% nuevos desarrollos,)
Reuniones diarias
o Scrum tiene una reunin corta cada da, a la misma hora y en
el mismo lugar. El objeto de estas reuniones es compartir
informacin sobre lo que est pasando, planificar el da de
trabajo actual e identificar cualquier problema significativo.
este formato de reunin est muy orientado a la persona.
o Las reuniones diarias no se utilizan en Kanban, pero la
mayora de los equipos Kanban parece que lo hacen de todos
modos. equipos Kanban utilizan un formato ms orientado al
panel, poniendo el foco en los cuellos de botella y otros
problemas visibles. Esta ltima aproximacin es ms

escalable. Si tienes 4 equipos compartiendo el mismo panel y

haciendo sus reuniones diarias juntas, puede que no sea
necesario tener que escuchar hablar a cada uno en tanto y en
cuanto nos enfoquemos en las partes que son cuellos de botella
del panel.
Graficos:
o Scrum usa grfico burndown representa, diariamente, la
cantidad de trabajo restante en la iteracin actual. herramienta
para el seguimiento del progreso de una iteracin. tambin
utilizan grficos burndown de versin muestran cuantos
puntos de historia quedan pendientes en la pila despus de
cada sprint. Proposito encontrar, fcilmente y tan pronto como
sea posible, si nos encontramos avanzados o retrasados
respecto a planificacin para poder adaptarnos.
o En Kanban, no se prescriben grficos burndown. Pero, desde
luego que se permite utilizar cualquier tipo de grfico .
ejemplo de Diagrama de Flujo Acumulativo. Este tipo de
grficos representan finamente la suavidad del flujo y cmo el
WIP afecta a tu plazo de entrega. Linea horizontal. tareas
aadidas a la pila el da 4 costaron una media de 6 das en
llegar a produccin. Aproximadamente la mitad de ese tiempo
fueron Test. Podemos ver que si se limitramos el WIP en Test
y Pila, reduciramos significativamente el plazo de entrega
total. La pendiente del rea azul-oscura nos muestra la
velocidad (por ejemplo, nmero de tareas desarrolladas al da).
Con el tiempo podemos ver como velocidades mayores
reducen el plazo de entrega, mientras que un mayor WIP lo
incrementa.
o La mayora de las organizaciones quieren tener realizado el
trabajo ms rpido (= reducir el plazo de entrega).
Desafortunadamente muchas caen en la trampa de asumir que
esto significa contratar ms personas o trabajar horas extras.
Normalmente la forma ms efectiva de hacer el trabajo ms
rpidamente es suavizar el flujo y limitar el trabajo a la
capacidad. No aadir ms gente o trabajar ms duro. Este tipo
de diagrama muestra por qu. Para aumentar velocidad,
minimizar de forma absoluta el nmero de actividades
esperando 'a cola'.
Tablero
En Scrum, la pila de sprint : muestra lo que est haciendo el
equipo durante el sprint actual. la pila de producto - la lista de
cosas que el dueo del producto quiere tener hecho en futuros

sprints. El entregar el producto - no suele estar incluido en el

sprint, y por lo tanto no es visible en la pila de sprint.
Kaban: Pila es slo una lista general de deseos sin ningn orden
en particular. La columna "Seleccionado" contiene los elementos
de prioridad alta, con un lmite Kanban de 2 (2 elementos de
prioridad alta en un momento dado. Cada vez que el equipo est
listo para trabajar en un nuevo elemento tendr que tomar el
primer elemento de la columna "Seleccionado". El dueo del
producto puede hacer cambios en las columnas Pila y
Seleccionado en cualquier momento, pero no en las otras
columnas. La columna "Des" (dividida en dos subcolumnas)
muestra lo que se est desarrollando, con un lmite Kanban de 3.
(limite ancho de banda y el tiempo de entrega corresponde a
"ping" o tiempo de respuesta). Des" en dos subcolumnas "En
curso" y "Terminado"? Es para dar al equipo de produccin la
oportunidad de conocer los elementos que pueden arrastrar pull
a produccin. El lmite "Des" de 3 es compartido entre las dos
subcolumnas. Por qu?
Digamos que hay 2 artculos en "Terminado": Esto significa que
slo puede estar 1 elemento En curso". Por lo tanto, habr
exceso de capacidad, los desarrolladores podran comenzar un
nuevo elemento, pero no estn autorizados a causa del lmite
Kanban. incentivo para concentrar sus esfuerzos y ayudar a poner
cosas en produccin, para borrar de la columna "Terminado" y
maximizar el flujo. Este efecto ayuda a centrar la atencin del
equipo en las cosas adecuadas.
Flujo de una sola pieza o "flujo perfecto", donde un elemento
fluye a travs del tablero sin quedar atrapado en una cola. Esto
significa que en cada momento hay alguien trabajando en ese
elemento. Si este escenario ideal persiste podemos deshacernos
de las dos colas "Pila" y "Seleccionado" y tener un tiempode
entrega muy corto!
Los lmites del trabajo en curso (WIP) estn ah para evitar
problemas antes de que aparezcan. As, si las cosas estn fluyendo
sin problemas, los lmites del trabajo en curso (WIP) no son
realmente utilizados.

Resumen
Parecidos

Ambos son Lean y giles.

Ambos emplean sistemas de planificacin "pull".

 Ambos establecen lmites WIP.

En ambos la visibilidad del proceso es la base de su mejora.
Ambos tienen como objetivo la entrega temprana y
frecuente de software.
Ambos trabajan con equipos auto-organizados.
Ambos necesitan la divisin del trabajo en partes.
Ambos revisan y mejoran de forma continua el plan del
producto en base a datos empricos (velocidad / tiempo de
entrega)
Diferencias
Scrum
Las iteraciones deben ser de tiempo fijo.
El equipo asume un compromiso de trabajo por iteracin.
La mtrica por defecto para la planificacin y la mejora del proceso es la
Velocidad.
Los equipos deben ser multifuncionales.
Las funcionalidades deben dividirse en partes que puedan completarse en
un sprint.
Deben emplearse grficos Burndown.
Se emplea una limitacin WIP indirecta (por sprint).
Se deben realizar estimaciones.

No se pueden aadir tareas en medio de una iteracin.

La pila del sprint pertenece a un equipo determinado.
Se prescriben 3 roles (PP/SM/Equipo).
En cada sprint se limpia el tablero de seguimiento.
La pila del producto debe estar priorizada.

Kanban
El tiempo fijo en las iteraciones es opcional. La cadencia puede variar en
funcin del plan del producto y la mejora del proceso. Pueden estar
marcadas por la previsin de los eventos en lugar de tener un tiempo prefijado.
El compromiso es opcional.
La mtrica por defecto para la planificacin y la mejora del proceso es el
Lead Time (tiempo de entrega o tiempo medio que tarda una peticin en
salir del ciclo)
Los equipos pueden ser multifuncionales o especializados.
No hay ninguna prescripcin en cuanto al tamao de las divisiones.

 No se prescriben diagramas de seguimiento concretos.

Se emplea una limitacin WIP directa (marcada por el estado del trabajo).
Las estimaciones son opcionales.
Siempre que haya capacidad disponible, se pueden aadir tareas.
Varios equipos o personas pueden compartir la misma pizarra Kanban.
No hay roles prescritos.
El tablero Kanban es persistente.
La priorizacin es opcional.

Porque cambiar
Cuando el software mejor, se desplaz la presin hacia el grupo de
Operaciones. los equipos de Operacin cada vez ms involucrados
como parte activa del proceso de desarrollo. ayudar a los equipos de
desarrollo no era suficiente. necesitaban mejoras en ambas reas. Si
causaramos retrasos en las mejoras de infraestructura crticas
realizadas por los equipos de Operacin.
aumento de las peticiones a los gerentes para echar una mano en el
anlisis y la revisin de ideas. Esto significaba que tenan menos
tiempo para la priorizacin de tareas y resolucin de problemas en el
da a da
Segn desarrollo operaciones es : Conocimiento variable Su
sistema de workflow apesta Muy competentes cuando se trata de
infraestructura Qu estn haciendo los chicos? Ellos quieren
ayudar, pero en realidad es difcil obtener ayuda Necesito muchos
correos electrnicos para hacer cosas simples Los proyectos duran
demasiado Difciles de contactar
Operaciones describe desarrollo: Por qu no utilizis las
ventajas que os ofrecen las plataformas? Hagamos de la
distribucin algo menos pesado! Vuestra baja calidad nos
afecta!
Ambos: "Tienen que cambiar"

Como empezar
UN taller, enseando los principios bsicos y poniendo manifiesto
problemas

Primer tablero
Las cuestiones que surgieron en
esta etapa incluyen:
Qu tipos de trabajo tenemos?
Quin los maneja?
Debemos compartir la responsabilidad entre los diferentes tipos
de trabajo?
Cmo podemos hacer frente a la responsabilidad compartida
teniendo en cuenta que tenemos conocimientos especializados?
Dado que para los diferentes tipos de trabajo haba acuerdos de nivel de
servicios diferentes, pareca natural permitir que cada equipo llevara el
control de su propio tablero.

Estado del flujo de trabajo (fila) Como lo definimos

Backlog (Pila de producto) Historias que el gerente decide que
son necesarias.
Listo para WIP Historias estimadas y divididas en
tareas con una duracin mxima de
8 horas.
Trabajo en curso Fila que contena un lmite para el
trabajo en curso. Empezamos con un
lmite de 2 X tamao del equipo -1
(-1 para colaboracin). As, un
equipo de 4 personas tendra un
lmite de 7.
Hecho Ejecutable por el usuario.
Tipo de trabajo Como lo definimos
Release (liberacin) Ayudar a los equipos de desarrollo a
liberar software.
Soporte Pequeas peticiones de otros
equipos.
No planificado Trabajo imprevisto que es necesario
realizar pero que no tiene un
propietario definido. Por ejemplo,
pequeas mejoras en la
infraestructura.
Proyecto A Proyectos grandes de soporte
tcnico, por ejemplo cambiar el
hardware del entorno de pruebas.
Proyecto B Otro proyecto largo

Limite Wip
El primer lmite WIP que usamos fue 2n-1 donde n era el nmero
de miembros del equipo y -1 un modo de potenciar la cooperacin.
cualquier lmite generoso habra funcionado para un equipo novato.
Monitorizando el tablero Kanban es sencillo descubrir los lmites
correctos sobre la marcha.
no era til definir el lmite WIP en puntos de historia porque era
difcil de controlar. El nico lmite suficientemente sencillo de
controlar era simplemente la cuenta del nmero de elementos del
panel, es decir, el nmero de tareas en paralelo
Para el equipo de suporte establecimos un lmite WIP por columna,

porque necesitbamos capacidad de reaccin rpida si el lmite se

sobrepasaba

respetar el wip
respetar el lmite WIP establecido es una tarea difcil de conseguir
siempre significa decir no en algn momento.
Cada vez que se descubra una violacin de los lmites WIP
llevbamos a las partes interesadas ante el tablero Kanban y les
preguntbamos qu pretendan conseguir. Al principio, la razn ms
habitual para esas violaciones era simple inexperiencia. En algunos
casos nos encontramos con perspectivas diferentes sobre la
priorizacin. se solucionaban all mismo discutindolo a la vista del
tablero.
Cuando decir no supona demasiada confrontacin, movamos los
elementos de menor prioridad a una seccin de sobrecarga en el
tablero, all donde los lmites WIP se haban sobrepasado. Dos reglas
aplicaban a las tareas en sobrecarga:
1. No han sido olvidadas. En cuanto tengamos tiempo las trataremos.
2. Si las abandonamos, sers informado.
pasadas dos semanas se haca obvio que los elementos de sobrecarga
incluso ni se trataran nunca y se quitaban
Incluir tablero As que las tareas con tamao mayor de una hora.
Todo lo menor de una hora se consideraba ruido blanco.

Como estimar
decidimos comenzar con puntos de historia. estimbamos todas las
historias
descubrieron que si mantenan bajo el nmero de proyectos
concurrentes, no tenan a las partes interesadas esperando. Tambin
descubrieron que as, en caso de un cambio imprevisto, podan
repriorizar las tareas para solucionar el problema. La necesidad de
una fecha de entrega del proyecto haba dejado de ser un gran
problema, y esto llev a los gerentes a dejar de solicitar estimaciones
a priori. Slo lo hacan si se tema que tendran gente esperando.
gerente que, presionado prometi la entrega de un proyecto al final
de esta semana. Fcil estimar el avance (contar historias segn se
completaban) y concluir que, ms o menos el 25% ,se finalizaba
cada semana. As, eran necesarias otras tres semanas adicionales.
Enfrentado a este hecho, el gerente cambi la prioridad del proyecto,
detuvo el trabajo concurrente, e hizo la entrega posible.

Tamao estimado o plazo o esfuerzo

estimaciones en puntos de historia reflejaban horas de esfuerzo
ininterrumpido esperbamos que una historia necesitara, y no plazo
de entrega ( cuntas horas esperar a que el trabajo est terminado).
Midiendo el nmero de puntos de historia que alcanzan el estado
hecho cada semana (velocidad), podamos deducir nuestros
tiempos de respuesta medio (el "lead time" medio).
Estimbamos cada nueva historia slo una vez,

Reuniones
Kanban impone muy pocas restricciones
Nosotros decidimos planificar dos eventos recurrentes en el tiempo:
Reunin diaria con el equipo en frente del tablero, para sacar
a la luz problemas y ayudar a crear una visin compartida de las
tareas de todo el equipo.
Planificacin semanal de la iteracin con propsitos de
planificacin y mejora continua

Reunin diaria
similar a un Scrum diario. Se celebraba despus de la reunin del
Scrum de Scrums con participacin de todos los equipos
(desarrollo, pruebas, operacin).

El Scrum de Scrums generaba informacin importante como qu

problemas deban tratarse primero, o qu equipo de desarrollo estaba
sufriendo ms en cada momento.

Planificacin de iteracin
La hacamos semanalmente, en un momento planificado, porque
descubrimos que si no la planificbamos, ese tiempo se consuma en
otras prioridades :), y necesitbamos ms charla de equipo.
Un orden del da tpico era:
Actualizar grficos y tablero. Los proyectos terminados se movan al
Muro de lo hecho.
Revisar la semana pasada. Qu pas? Por qu? Qu se podra
hacer para mejorarlo?
Reajuste de los lmites de WIP si era necesario.
Divisin de tareas y estimacin de nuevos proyectos (si se vea
necesidad).

 problemas complejos o de infraestructura. asignar hasta dos

impedimentos de equipo a sus gerentes.

Planificacin
planning poker incluyendo a todos los miembros del equipo no estaban
funcionando bien
1. El conocimiento estaba desperdigado de manera muy desigual en
el equipo.
2 Los miembros del equipo queran resolver los temas urgentes que
les quemaban en las manos
2 enfoques:
Por cada proyecto/historia, se asigna una pareja de senior +
junior para estimarlo (esto es, una persona que conoce esa
historia bien, y otra que no la conoce). Esto ayuda a propagar el
conocimiento.
Los restantes miembros del equipo eligen qu historias quieren
ayudar a estimar, con el lmite de 4 personas por historia para
mantener la efectividad de los debates.
Cada equipo de estimacin hace una descomposicin de tareas
de su historia y, slo si se requiere, la estima.
Los equipos intercambian historias y revisan los trabajos de los
dems (una persona del equipo original permanece para
explicar el trabajo de su equipo a los revisores).
La sesin de estimacin de iteracin tpica duraba alrededor de 45
minutos, de forma que el nivel de energa se mantena alto durante la
2 enfoque
Dos miembros del equipo con experiencia realizaban una revisin a alto
nivel de la historia/proyecto antes de la planificacin. Analizaban las
posibles soluciones de arquitectura y decidan una para el problema.
Una vez establecido, el equipo entra en juego y descompone la historia
en tareas usando la solucin propuesta como punto de partida.

Lecciones aprendidas
Todos los equipos empezaban con unas limitaciones del Trabajo en
Curso (WIP) bastante holgadas
reducir el nmero de proyectos por equipo. nunca se empezaba
ningn trabajo que estuviera entre los de baja prioridad
Empezarn a sugir restricciones cuando el Wip se estabilizo.

Gerentes atenderlas
Todos los paneles Kanban cambiaban a lo largo del camino. As que
invertir mucho tiempo en la primera forma probablemente sea una
prdida de tiempo