Kanban Vs Scrum

Kanban y Scrum
obteniendo lo mejor de
ambos
Scrum
Dvde tu organzacn en equpos pequeos, nterdscpnaros
y auto-organzados.
Dvde e traba|o en una sta de entregabes pequeos y
concretos. Ordena a sta por orden de prordad y estma e
esfuerzo reatvo de cada eemento.
_
Dvde e tempo en teracones cortas de ongtud |a
(generamente de 1 a 4 semanas), con cdgo
potencamente entregabe y demostrado despus de cada
teracn.
_ Optmza e pan de entregas y actuaza as prordades en
coaboracn con e cente, basada en os conocmentos
adqurdos medante a nspeccn de entregabe despus
de cada teracn.
_ Optmza e proceso tenendo una retrospectva despus de
cada teracn.
As en ugar de un grupo numeroso pasando mucho tempo
construyendo ago grande, tenemos un equpo menor pasando
un tempo ms corto construyendo ago menor. Pero ntegrando
con reguardad para ver e con|unto.
Kanban en pocas paabras
Vsuaza e u|o de traba|o
a o Dvde e traba|o en boques, escrbe cada eemento en
una tar|eta y pono en e muro.
b o Utza coumnas con nombre para ustrar dnde est
cada eemento en e u|o de traba|o.
Lmta e WIP (Work n Progress, traba|o en curso) -asgna
mtes concretos a cuntos eementos pueden estar en progreso
en cada estado de u|o de traba|o.
Mde e ead tme (tempo medo para competar un eemento,
a veces amado "tempo de cco"), optmza e proceso para que
e ead tme sea tan pequeo y predecbe como sea posbe.
Reacon entre Scrum y Kanban
Scrum y Kanban son ambos herramentas de
proceso
Herramienta = cuaquer cosa usada como medo para reazar
una tarea
o propsto
Proceso = cmo traba|as.
Scrum y Kanban son herramientas de proceso que te ayudan a
traba|ar ms ecazmente, en certa medda, dcndote qu
hacer. |ava tambn es una herramenta, te ofrece una forma
ms senca de programar una computadora. Un cepo de
dentes tambn es una herramenta, te ayuda a egar a tus
dentes para que puedas mparos.
Compara herramentas para entender,
no para |uzgar
Cucho o tenedor - Ou herramenta es me|or?
Es una pregunta ben expresada? Porque a respuesta depende
de contexto.
Para comer abndgas e tenedor es probabemente me|or. Para
cortar as
ENTONCES COMO SE RELACIONAN SCRUM Y KANBAN ENTRE S? | 7
setas e cucho es probabemente me|or. Para gopear a mesa
cuaquera de os dos servr. Para comer un ete probabemente
querrs utzar os dos de manera con|unta. Para comer arroz...
Bueno... agunos preeren e tenedor mentras que otros preeren
os paos.
As, cuando comparamos herramentas debemos ser cudadosos.
Comparar para comprender, no para |uzgar..
Nnguna herramenta es competa, nnguna
herramenta es perfecta
Como cuaquer herramenta, Scrum y Kanban no son n
perfectas n competas. No te dcen todo o que tenes que
hacer, soo proporconan certas restrccones y drectrces. Por
e|empo, Scrum te obga a tener teracones de duracn |a y
equpos nterdscpnaros, y Kanban te obga a usar taberos
vsbes y a mtar e tamao de tus coas.
Curosamente, e vaor de una herramenta es que limita tus
opciones. Una herramenta de proceso que te permte hacer
cuaquer cosa no es muy t. Podramos amar a ese proceso
"Hacer o que sea" o qu ta "Hacer o correcto". E proceso "Hacer
o correcto" garantza que funcona, es una baa de pata! Porque
s no funcona, es obvo que no estabas sguendo e proceso :o)
Usar as herramentas adecuadas te ayudar a trunfar, pero no
garantzar e xto. Es fc confundr e xto/fracaso de proyecto,
con e xto / fracaso de a herramenta.
_ Un proyecto puede trunfar debdo a una gran herramenta.
_ Un proyecto puede trunfar a pesar de una psma
herramenta.
_ Un proyecto puede faar debdo a una psma herramenta.
8 |KANBAN Y SCRUM - OBTENIENDO LO ME|OR DE AMBOSw
Un proyecto puede faar a pesar de una gran herramenta.
Scrum es ms prescrptvo que Kanban
Podemos comparar herramentas vendo cuntas regas
proporconan. Prescriptivo sgnca "ms regas a segur" y
adaptativo sgnca "menos regas a segur". 100% prescrptvo
sgnca que no te de|a usar e cerebro, hay una rega para todo.
100% adaptatvos sgncan Haz Lo Oue Sea, no hay nnguna
rega o restrccn. Como puedes ver, os dos extremos de a
escaa son de aguna manera rdcuos.
Los mtodos ges se denomnan a veces os mtodos ligeros,
en concreto, porque son menos restrctvos que os mtodos
tradconaes. De hecho, e prmer prncpo de Manesto Ag es
"Indvduos e nteraccones sobre procesos y herramentas".
Scrum y Kanban son muy adaptabes, pero en trmnos reatvos
Scrum es ms restrctvo que Kanban. Scrum te da ms
mtacones, y as de|a menos opcones abertas. Por e|empo
Scrum prescrbe e uso de teracones de duracn |a, Kanban
no.
Vamos a comparar agunas herramentas de proceso ms en a
escaa restrctvo vs adaptatvo:
RUP es muy restrctvo- tene ms de 30 peres, ms de 20
actvdades, y ms de 70 artefactos, una cantdad enorme de
cosas a aprender. Reamente no se espera que uses todos os
que hay, s ben, se supone que seecconars un subcon|unto
adecuado para tu proyecto. Lamentabemente, esto parece ser
dfc en a prctca. "Hmmmm ... Necestaremos artefactos
para la Confguracin de auditora de los resultados!
Necestaremos un perfl de gerente de Control de cambios ?No
estoy seguro, as que me|or os mantenemos por s acaso ". Esto
puede ser una de as razones por asque as mpementacones
de RUP sueen ser bastante pesadas en comparacn con os
mtodos ges como Scrum y XP.
XP (eXtreme Programmng) es ms restrctvo en comparacn
con Scrum. Se ncuye a mayora de Scrum + un montn de
buenas prctcas especcas de ngenera, taes como desarroo
drgdo por pruebas y a programacn en pare|as.
Scrum es menos restrctvo que XP, ya que no estabece nnguna
prctca especca de ngenera. Sn embrago, Scrum es ms
restrctvo que Kanban ya que prescrbe cosas como teracones
y equpos nterdscpnaros.
Una de as prncpaes dferencas entre Scrum y RUP es que en
RUP tenes demasado, y se supone que qutars aqueo que no
necestes. En Scrum tenes demasado poco, y se supone que
aadrs e matera que fata.
Kanban de|a cas todo aberto. Las ncas normas son Vsuaza
tu Fu|o de traba|o y Lmta tu WIP (Work In Progress, Traba|o en
curso). A pocos centmetros de Haz o que Sea, pero sgue
sendo sorprendentemente poderoso.
No te mtes a una nca herramenta!
Mezca y combna as herramentas que necestes! Me cuesta
magnar un extoso equpo Scrum que no ncuye a mayora de os
eementos de XP, por e|empo. Muchos equpos Kanban hacen
reunones daras (una prctca de Scrum). Agunos equpos Scrum
escrben agunos de sus eementos de a pa como Casos de Uso
(una prctca de RUP) o mtan e tamao de as coas (una
prctca de Kanban). Usa o que sea que funcone para t.
Musash o d|o muy ben (famoso Samura de sgo 17, famoso
por su tcnca de ucha de a dobe espada)
Sn embargo, presta atencn a as mtacones de cada
herramenta. Por e|empo, s utzas Scrum y decdes de|ar de
utzar teracones de duracn |a (o cuaquer otro aspecto
centra de Scrum), uego no dgas que ests utzando Scrum.
Scrum es bastante mnmasta en s msmo, s qutas cosas y
todava o amas Scrum entonces a paabra carecer de sentdo y
confundr. Lmao ago as como "nsprado en Scrum" o "un
subcon|unto de Scrum", o ago as como "Scrumsh" :o)
3
Scrum prescrbe roes
Scrum prescrbe 3 roes: dueo de producto (estabece a vsn
de producto y as prordades), equpo (mpementa e producto)
y Scrum Master (emna os mpedmentos y proporcona
derazgo en e proceso).
Kanban no estabece nngn ro en absouto.
Eso no sgnca que no puedas o no debas tener un pape de
dueo de producto en Kanban! So sgnca que no tienes "ue.
En ambos, Scrum y Kanban, eres bre de aadr os roes
adconaes que necestes.
Ten cudado sn embargo a aadr roes, asegrate de que os
roes adconaes reamente aaden vaor y no entran en
concto con otros eementos de proceso. Ests seguro de que
necestas e ro de |efe de proyectos? En un proyecto grande
puede ser una gran dea, ta vez es e tpo que ayuda a mtpes
equpos y dueos de producto a sncronzarse. En un proyecto
pequeo puede ser un desperdco, o peor, puede dar ugar a a
sub-optmzacn y a mcrogestn.
La mentadad genera, tanto en Scrum como en Kanban es
"menos es ms". As que en caso de duda, comenza con menos.
En e resto de artcuo voy a utzar e trmno "dueo de
producto" para representar a quen estabece as prordades de
un equpo, ndependentemente de mtodo utzado.
4
Scrum prescrbe teracones de tempo
|o
Scrum se basa en teracones de tempo |o. Puedes eegr a
duracn de a teracn, pero a dea genera es mantener a
msma ongtud de a teracn durante un perodo de tempo,
determnando as una
cadencia.
_ Inco de a teracn: Se crea un pan de teracn, es decr,
e equpo saca un nmero especco de eementos de a
pa de producto, en base a as prordades de dueo de
producto y a cunto pensa e equpo que puede termnar
en una teracn.
_ Durante a teracn: E equpo se centra en competar os
eementos a os que se compromet. Se |a e acance de
a teracn.
_ Fna de a teracn: E equpo muestra e cdgo
funconando a as partes nteresadas, deamente este
cdgo debe ser potencialmente entregable (es decr,
probado y sto para evar). Entonces, e equpo hace una
retrospectva para dscutr y me|orar su proceso.
As que una teracn de Scrum es una nca cadenca de tempo
|o que combna tres actvdades dstntas: a pancacn, a
me|ora de procesos, y (deamente) a entrega.
En Kanban no se prescrben teracones de tempo |o. Puedes
eegr e momento de hacer a pancacn, a me|ora de
procesos, y a entrega. Puedes eegr hacer estas actvdades de
manera reguar ( "a entrega todos os unes") o ba|o demanda
( "a entrega cada vez que tengamos ago t para entregar").
Equpo #1 (cadenca smpe)
"Nosotros hacemos teracones Scrum"
Equpo # 2 (tres cadencas)
"Tenemos tres cadencas dferentes. Cada semana entregamos
o que est sto para su entrega. Cada segunda semana
tenemos una reunn de pancacn, actuazacn de nuestras
prordades y os panes de entrega. Cada cuarta semana
tenemos una reunn retrospectva para modcar y me|orar
nuestro proceso".
Equpo # 3 (normamente drgdo por eventos)
"Lanzamos una reunn de pancacn cada vez que
comenzamos a quedarnos sn cosas que hacer. Lanzamos una
entrega sempre que hay un MMF (Mnmum Marketabe Feature
Set, con|unto mnmo de caracterstcas comercazabes) sto
para entregar. Lanzamos un crcuo de cadad espontneo
sempre que nos topamos con un msmo probema por segunda
vez. Adems hacemos una retrospectva ms en profunddad
cada cuatro semanas. "
5
Kanban mta e WIP por estado en u|o
de traba|o, Scrum mta e WIP por
teracn
En Scrum, a pa de sprnt muestra qu tareas han de ser
e|ecutadas durante a teracn actua (= "sprnt" en
termnooga Scrum). Se representa comnmente usando
tar|etas en a pared, amada una pzarra de Scrum o pzarra de
tareas.
Entonces, cu es a dferenca entre una pzarra de Scrum y
una pzarra de Kanban? Vamos a empezar con un proyecto
smpe y comparar as dos:
En ambos casos estamos sguendo un grupo de eementos a
medda que avanzan a travs de un u|o de traba|o. Hemos
seecconado tres estados: pendente, en curso, y termnado.
Puedes eegr os estados que queras - agunos equpos aaden
estados taes como ntegrar, probar, berar, etc. No te ovdes
de prncpo de #menos es m$s".
Entonces, cu es a dferenca entre estas dos pzarras de
e|empo? S, e pequeo 2 en a coumna centra en a pzarra
Kanban. Eso es todo. Ese 2 sgnca que "no puede haber ms
de 2 eementos en esta coumna en un momento dado".
En Scrum no hay nnguna rega que mpda que e equpo ponga
todos os eementos en a coumna en curso a msmo tempo!
Sn embargo, exste un mte mpcto ya que a teracn en s
tene un acance |o. En este caso, e mte mpcto por
coumna es de 4, ya que so hay 4 eementos en a pzarra. As
que Scrum mta e WIP ndrectamente, mentras que Kanban
mta e WIP drectamente.
La mayora de os equpos de Scrum aprenden namente que es
una maa dea tener demasados eementos en curso, y
desarroan una cutura de ntentar tener os eementos actuaes
termnados antes de comenzar con nuevos eementos. Agunos
ncuso decden mtar expctamente e nmero de eementos
permtdos en a coumna de en curso y, a contnuacn -
TADAAA! - a pzarra de Scrum se ha convertdo en una pzarra
de Kanban!
As que tanto Scrum como Kanban mtan e WIP, pero de
dferentes maneras. Los equpos de Scrum sueen medr a
velocidad - cuntos eementos (o undades correspondentes,
taes como "puntos de hstora") se hacen por teracn. Una vez
que e equpo sabe su veocdad, sta se converte en su mte
de WIP (o a menos una drectrz). Un equpo que tene una
veocdad meda de 10 no suee tomar ms de 10 eementos (o
puntos de hstora) para un sprnt.
De forma que en Scrum e %&P se limita por unidad de tiempo.
En Kanban e %&P se limita por el estado del 'ujo de trabajo.
En e e|empo anteror de Kanban, como mucho puede haber 2
eementos en e estado de u|o de traba|o "en curso" en un
momento dado, ndependentemente de as ongtudes de
cadenca. Tenes que eegr qu mte apcar a qu estados de
u|o de traba|o. Pero a dea genera es mtar e WIP de todos
los estados de u|o de traba|o, empezando por "o ms pronto
posbe" y termnando "o ms tarde posbe" a o argo de a
cadena de vaor. As, en e e|empo anteror deberamos
consderar aadr un mte a WIP tambn en e estado
"pendente" (o a que quera que sea tu coa de entrada). Una
vez que tenemos os mtes de WIP en su ugar, podemos
empezar a medr y predecr e tempo de entrega, es decr, e
tempo medo de un eemento para reazar todo e camno a
travs de a pzarra. Tener tempos de entrega predecbes nos
permte comprometer os SLA (acuerdos de nve de servco, en
ngs servce-eve agreements) y hacer panes de entrega
reastas.
KANBAN LIMITA WIP POR ESTADO, SCRUM LIMITA WIP POR ITERACION | 17
S os tamaos de os eementos varan drstcamente entonces
podras consderar mtes de WIP dendos en trmnos de
puntos de hstora en su ugar, o cuaquera que sea a undad de
medda que utces. Agunos equpos nverten sus esfuerzos en
a descomposcn de eementos de aproxmadamente e msmo
tamao para evtar este tpo de consderacones y reducr e
tempo empeado en a estmacn de as cosas (podras ncuso
consderar que a estmacn es un desperdco de tempo). Es
ms fc para crear un buen sstema de u|o s os artcuos son
ms o menos de gua tamao.
6
Ambos son emprcos
Imagna que hubese mandos en estos contadores y t pudeses
congurar tu proceso smpemente grando os mandos. "Ouero
ata capacdad, ba|o lead time, ata cadad y ata predecbdad.
Entonces grar os mandos a 10, 1, 10 y 10 respectvamente".
No sera maravoso? Por desgraca no exsten estos controes
drectos. A menos no que yo sepa. Hacdmeo saber s vosotros
os encontrs. En su ugar contamos con ese puado de
controes indirectos.
Scrum y Kanban son ambos emprcos en e sentdo de que se
espera que expermentes con e proceso y o adaptes a tu
entorno. De hecho, tienes que expermentar. N Scrum n Kanban
proporconan todas as respuestas - smpemente nos
proporconan una sere de regas y mtacones a a hora de
guar a me|ora de nuestros procesos.
AMBOS SON EMPRICOS | 19
_ Scrum dce que debemos tener equpos mutdscpnares.
Entonces, Oun debe estar en cada equpo? No o s,
expermenta.
_ Scrum dce que e equpo seeccona cuanto traba|o ncur
en un sprnt. Entonces, Cunto deben ncur? No o s,
expermenta.
_ Kanban dce que debemos mtar en traba|o en curso.
Entonces, Cu debe ser ese mte? No o s, expermenta.
Como he menconado con anterordad, Kanban mpone menos
mtacones que Scrum. Esto sgnca menos parmetros sobre
os que preocuparse, pero ms mandos que grar. Esto puede ser
tanto una venta|a como una desventa|a dependendo de
contexto. Cuando abres e cuadro de dogo de conguracn de
una herramenta de software, preeres tener 3 o 100 opcones
que a|ustar? Probabemente una cantdad entre ambas.
Depende de cunto necestes a|ustar e software a tus
necesdades y cmo de ben conozcas a herramenta.
Dgamos que reducmos e mte de traba|o en curso,
basndonos en a hptess de que esto va a me|orar nuestro
proceso. Observamos cmo otros factores como a capacdad, e
lead time, a cadad, y a predecbdad evouconan. Sacamos
concusones de os resutados y a|ustamos agunas cosas ms,
me|orando contnuamente nuestro proceso. Hay dferentes
trmnos para referrse a este proceso. Kai(en (me|ora contnua
en termnooga Lean), Inspeccn y Adaptacn (en termnooga
Scrum), contro emprco de procesos o, por qu no, E Mtodo
Centco.
E eemento ms crtco de este proceso es e cco de
retroamentacn, e )eedbac*. Camba ago => Observa cmo
funcona => Aprende de eo => Camba ago de nuevo. En
genera, o que buscamos es obtener )eedbac* en ccos o ms
cortos posbes, de manera que podamos adaptar nuestro
proceso rpdamente.
En Scrum e cco bsco de obtencn de )eedbac* es e sprnt.
Exsten otros, sn embargo. Especamente s combnas Scrum
con XP (eXtreme programmng):
Cuando se reazan correctamente, Scrum + XP nos
proporconan un buen puado de ccos de )eedbac*
extremadamente vaosos.
E cco de )eedbac* ms nterno, a programacn en pare|as,
proporcona retroamentacn en unos pocos segundos. Los
errores son detectados y corregdos en segundos desde que
ocurren (He!, no se supone que esa varabe debe vaer 3?).
Este es e cco de )eedbac* de "Estamos construyendo ben as
cosas?".
E cco de )eedbac* ms externo, e sprnt, nos proporcona un
cco de retroamentacn de unas cuantas semanas. Este e
cco de )eedbac* de "Estamos construyendo as cosas
adecuadas?
Y en Kanban, que? Bueno, en prmer ugar, puedes (y
seguramente debes) poner todos os anterores ccos de
)eedbac* en tus proyectos uses o no Kanban. Lo que Kanban te
proporcona es una sere de mtrcas en tempo rea muy tes.
_ +ead time medo: Actuazado cada vez que un eemento
acanza e nve de hecho (o como quera que ames a tu
coumna ms a a derecha).
_ Cueos de Botea: Un sntoma tpco es que a coumna X
est abarrotada de eementos mentras que a coumna
X+1 est vaca. Busca "burbu|as de are" en tu pane.
Lo me|or de as mtrcas en tempo rea es que t puedes eegr
a ongtud de tu cco de )eedbac*, basndote en con qu
frecuenca queres anazar estas mtrcas e ntroducr cambos.
Un cco demasado argo de retroamentacn sgnca que a
me|ora de tu proceso ser enta. Uno demasado corto sgnca
que tu proceso no podra no tener tempo para estabzarse
entre cambos, o que puede producr desperdco de esfuerzos.
De hecho, a ongtud de cco de retroamentacn en s msma
es uno de os aspectos con os que puedes expermentar. en
una espece de meta-cco de )eedbac*. OK, es sucente por
ahora.
E|empo: Expermentando con os mtes para e traba|o
en curso en Kanban
Uno de os tpcos "puntos de a|uste" de Kanban es e mte de
traba|o en curso. Cmo sabemos s o estamos estabecendo
correctamente?
Dgamos que tenemos un equpo de 4 personas y que decdmos
comenzar con un mte para e traba|o en curso de 1.
En cuanto comencemos a traba|ar en un eemento, no podremos
comenzar nnguno nuevo hasta que e prmer eemento est
Hecho. En consecuenca concuremos e prmer eemento
rpdamente.
Exceente!, pero resuta que habtuamente no es factbe que 4
personas traba|en en e msmo eemento (a menos en e
contexto de este e|empo), entonces tenemos gente mrando. S
esto soo ocurre de tanto en cuanto no ser un probema, pero s
esta stuacn se da con reguardad, a consecuenca es que e
lead time medo se ncrementar. Bscamente, un traba|o en
curso de 1 sgnca que os eementos pasaran por e estado "En
curso" reamente rpdo una vez egan a esta stuacn, pero
permanecern en estado "Pendente" ms tempo de necesaro,
de manera que e lead time a o argo de cco de traba|o
competo ser nnecesaramente ato.
Entonces s un traba|o en curso de 1 es demasado ba|o, por
qu no ncrementaro a 8?
Esto funcona me|or durante agn tempo. Hemos descuberto
que, de meda, traba|ando en pare|as reazamos e traba|o ms
rpdo. De esta manera, en un equpo de cuatro personas,
habtuamente, tendremos 2 eementos en curso en un nstante
dado. E traba|o en curso de 8 es soo un mte superor, uego
tener menos eementos en progreso es correcto!
Imagnemos ahora, sn embargo que encontramos un probema
con e servdor de ntegracn, de ta manera que no podemos
competar totamente nngn eemento (nuestra dencn de
Hecho ncuye ntegracn). Estas cosas pasan, no?
Como no podemos competar os eementos D o E, comenzamos
a traba|ar en e eemento F. No podemos ntegrar nnguno de
estos tampoco, uego cogeremos un nuevo eemento G. Tras un
tempo acanzaremos nuestro mte Kanban - 8 eementos "En
curso".
En este punto, ya no podemos coger nngn eemento ms. He,
me|or arregemos ese madto servdor de ntegracn! E mte
para e traba|o en curso nos mpusa a reacconar y corregr e
cueo de botea en ugar de segur acumuando un montn de
traba|o sn termnar.
Esto est ben. Pero s e mte de traba|o en curso hubese sdo
4, habramos reacconado mucho antes, de este modo
tendramos un me|or lead time medo. Medmos nuestro lead
time medo y contnuamente optmzamos nuestro mte de
traba|o en curso para optmzar e lead time.
Tras un perodo de tempo podramos encontrar que os
eementos se acumuan en a coumna "Pendente". Ouzs es e
momento de aadr un mte de traba|o en curso aqu tambn.
En cuaquer caso, por qu necestamos una coumna
"Pendente"?. Bueno, s e cente estuvese sempre dsponbe
para decr a equpo que hacer cada vez que preguntase, a
coumna "Pendente", no sera necesara. Pero en e caso de que
e cente est a veces no dsponbe, a
coumna "Pendente" da a equpo un pequeo bu,er de que
coger traba|o a medo pazo.
Expermenta o, como os "Scrumistas" dcen, Inspeccn y
Adaptacn.
7
Scrum se resste a os cambos durante a
teracn
Dgamos que nuestro tabero Scrum tene este aspecto:
Ou ocurre s aguen camba de dea y quere aadr E a
tabero?
Tpcamente un equpo Scrum dra ago como "No, o sento, nos
hemos comprometdo a A+B+C+D en este sprnt. Pero tomate a
berad de aadr E a a pa de producto. S e dueo de
producto consdera que es de ata prordad ser aaddo a
sguente sprnt". Sprnts de ongtud adecuada permten a
equpo mantenerse enfocados sucente tempo como para
ograr hacer ago, permtendo adems que e dueo de
producto gestone y actuace prordades de manera reguar.
Pero entonces que es o que dce e equpo Kanban?
La respuesta de Kanban podra decr "Aade con bertad E a a
coumna Pendente pero hay un mte de 2 para esta coumna,
en consecuenca tendrs que qutar C o D. Ahora estamos
traba|ando en A y B, pero tan pronto como tengamos capacdad
dsponbe cogeremos e prmer eemento de a coumna
Pendente".
E tempo de respuesta (cunto tempo pasa hasta que
respondemos a cambos de prordades) de un equpo Kanban es
tan argo como e tempo que trascurre hasta que tenemos
capacdad dsponbe, sguendo e prncpo genera de "un
eemento sae = un eemento entra" (segn os mtes para e
traba|o en curso).
En Scrum, e tempo de respuesta medo es a mtad de a
duracn de Sprnt.
En Scrum, e dueo de producto no puede tocar e tabero
Scrum una vez e equpo se ha comprometdo a competar un
con|unto de eementos en a teracn. En Kanban t tenes que
estabecer tu propas regas sobre qun puede cambar qu en
e tabero. Tpcamente e dueo de producto controa una
coumna de tpo "Pendente", "Lsto", "Propuesto", "Pa de
Producto" en a parte ms a a zquerda en e pane, en a que
puede hacer todos os cambos que desee.
Sn embargo, estas dos aproxmacones no son excuyentes
entre s. Un equpo Scrum podra decdr permtr a dueo de
producto cambar prordades a mtad de sprnt. Y un equpo
Kanban podra decdr aadr restrccones sobre cuando as
prordades pueden ser cambadas. Un equpo Kanban puede
ncuso decdr utzar teracones mtadas en e tempo y con
compromsos pre|ados, exactamente gua que Scrum.
8
E tabero sprnt se mpa entre
teracones
Un tabero Scrum suee tener un aspecto smar a este durante
as dferentes etapas de un sprnt.
Cuando se naza un sprnt, se mpa e tabero - todos os
eementos son emnados. Se nca un nuevo sprnt y tras a
reunn de pancacn de sprnt tendremos un nuevo tabero
Scrum, con nuevos eementos en a prmera coumna.
Tcncamente esto es una prdda de tempo, pero para equpos
Scrum expermentados no suee evar mucho, y e proceso de
mpar e tabero puede dar una grata sensacn de ogro y
cerre. Es ago as como avar os patos tras a cena - hacero
resuta pesado pero senta ben a nazar.
En Kanban, e tabero normamente es ago persstente - no se
necesta mparo y vover a empezar.
9
Scrum prescrbe equpos mutfunconaes
Un tabero Scrum es propedad de soamente un equpo Scrum.
Un equpo Scrum es mut-funcona, contene todos os
conocmentos necesaros para competar todos os eementos
de a teracn. Un tabero Scrum suee ser vsbe para
cuaquera que est nteresado, pero so e equpo Scrum a que
pertenece puede edtaro - es su herramenta para admnstrar
su compromso para esta teracn.
En Kanban, os equpos mut-funconaes son opconaes, y un
tabero no necesta estar en manos de un equpo especco. Un
tabero est reaconado con un u|o de traba|o, no
necesaramente con un equpo.
30 |KANBAN Y SCRUM - OBTENIENDO LO ME|OR DE AMBOSwHe aqu dos
e|empos:
E|empo 1: Todo e tabero est a servco de un equpo mut-
funcona. |usto como en Scrum.
E|empo 2: E dueo de producto estabece as prordades en a
coumna 1. Un equpo de desarroo mut-funcona reaza e
desarroo (coumna 2) y prueba (coumna 3). La puesta en
produccn (coumna 4) es reazada por un equpo de
especastas. Exste un gero soapamento de competencas, de
modo que s e equpo de puesta en produccn se converte en
un cueo de botea uno de os desarroadores es ayudar.
As, en Kanban es necesaro estabecer agunas regas bscas
para qun usa e tabero y cmo, uego se expermenta con as
normas para optmzar e u|o.
10
Los eementos de a pa de producto
deben caber en un sprnt
Ambos Scrum y Kanban se basan en e desarroo ncrementa,
por e|empo, descomponer e traba|o en trozos ms pequeos.
Un equpo Scrum so se comprometer con os eementos que
creen que pueden termnar en una teracn (basado en a
dencn de "Hecho"). S un eemento es demasado grande
para caber en un sprnt, e equpo y e propetaro de producto
ntentarn encontrar a manera de partro en pedazos ms
pequeos hasta que se pueda abordar en un sprnt. S os
eementos tenden a ser grandes, as teracones debern ser
ms argas (aunque generamente no ms de 4 semanas).
Los equpos de Kanban tratan de mnmzar e tempo de entrega
y e nve de u|o, por o que, ndrectamente, se crea un
ncentvo para descomponer os eementos en pedazos
reatvamente pequeos. Pero no hay nnguna norma expcta
que ndque que os eementos deben ser o sucentemente
pequeos como para caber en un ntervao de tempo especco.
En e msmo tabero podra haber un eemento que necesta un
mes para termnarse y otro eemento que necesta un da.
11
Scrum prescrbe a estmacn y a
veocdad
En Scrum, os equpos tenen que estmar e tamao reatvo (=
cantdad de traba|o) de cada eemento a que se comprometen.
Sumando e tamao de cada eemento competado a na de
cada sprnt, obtenemos a veocdad. La veocdad es una
medda de a capacdad - a cantdad de cosas que podemos
ofrecer por Sprnt. He aqu un e|empo de un equpo con una
veocdad meda de 8.
Saber que a veocdad meda es de 8 es bueno, porque
entonces podemos hacer predccones reastas sobre os
eementos que se pueden competar en os prxmos sprnts, y
por o tanto hacer panes de entrega reastas.
En Kanban, no se prescrbe a estmacn. As que s necestas
comprometerte necestas decdr a forma de garantzar a
prevsbdad.
Agunos equpos optan por hacer estmacones y medr a
veocdad como en Scrum. Otros equpos egen omtr a
estmacn, pero tratan de descomponer cada eemento en
partes de aproxmadamente e msmo tamao -entonces pueden
medr a veocdad smpemente en funcn de cuntos
eementos se competan por undad de tempo (por e|empo, por
semana).
Agunos equpos agrupan os eementos en MMF's
(caracterstcas mnmas de comercazacn) y mden e tempo
de entrega promedo por MMF, y o usan para estabecer SLA
(acuerdos de nve de servco,
en ngs servce-eve agreements) - por e|empo, "cuando nos
comprometemos con un MMF sempre ser entregado en 15 das
".
Hay todo tpo de tcncas nteresantes para e esto de
pancacn de entregas y gestn de compromsos de Kanban-
pero no se prescrbe nnguna tcnca especca, as que
adeante, googea y prueba dferentes tcncas hasta que
encuentres una que se adapte a su contexto. Probabemente
veremos agunas "me|ores prctcas" emerger con e tempo.
12
Ambos permten traba|ar en mtpes
productos smutneamente
En Scrum, a Pa de Producto es un nombre un tanto
desacertado pues mpca que todos os tems deben pertenecer
a un msmo producto. Aqu vemos dos productos, uno verde y e
otro amaro, cada uno con su respectva pa y su respectvo
equpo:
Producto
Producto
Oue pasa s tenemos un so equpo para varos productos?
Ben, pensemos en a Pa de Producto ms ben como una Pa
de Equpo. Lsta as prordades para as sguentes teracones
de equpo (o con|unto de equpos) en partcuar. De esta forma,
s un equpo mantene ms de un producto, debe fusonar ambos
productos en una soa sta. Esto nos obga a prorzar entre
productos, o cua puede resutar t en agunos casos. Hay
varas formas de hacer esto en a prctca:
Una estratega sera hacer que e equpo se enfoque en un so
producto durante e sprnt:
Otra estratega sera hacer que e equpo traba|e en a
funconadad de ambos productos cada sprnt:
Es o msmo en e caso de Kanban. Podemos tener varos
productos uyendo por e msmo tabero. Ta vez podemos
dstnguros utzando tar|etas de dferentes coores:
... o medante dstntas "pstas" o "caes" ("s-inlanes") :
13
Ambos son Lean y Ages
No voy a revsar aqu e Pensamento 'Lean', n e Manesto Ag.
Pero se puede generazar que tanto Scrum como Kanban estn
ben aneados con os vaores y prncpos de stos.
Por e|empo:
_ Tanto Scrum como Kanban son sstemas de pancacn
tpo "Pu", prncpo de gestn de nventaro '|ust In Tme'
(|IT) propo de Lean. Esto sgnca que e equpo ege
cundo y cunto traba|o acometer. Eos (os componentes
de equpo) "tran" de traba|o cuando estn stos, en
contraposcn a que desde e exteror se "empu|e" a
equpo a hacero. A gua que una mpresora tra de a
sguente pgna soo cuando esta sta para mprmr en
ea (aunque tenga ho|as de pape en a bande|a).
_ Scrum y Kanban se basan en procesos de optmzacn
contnuos y emprcos, que se corresponden con e prncpo
Kazen de Lean.
_ Scrum y Kanban dan ms mportanca a a respuesta a
cambo que a segumento de un pan (aunque Kanban
permte, tpcamente, una respuesta ms rpda que
Scrum). Uno de os cuatro prncpos de manesto g.
...y mas.
Desde un determnado punto de vsta, Scrum se puede ver como
no-tanean, ya que contempa agrupar tareas por otes dentro de
teracones de tempo pre|ado. Pero eso depende de a ongtud
de tu teracn, y tambn de con qu se compare. En un
proceso ms tradcona, en e que quzs se ntegren versones
unas 2-4 veces a ao, un equpo Scrum producendo cdgo
entregabe cada 2 semanas se puede consderar muy Lean.
Por consguente, s haces teracones cada vez ms cortas,
esencamente te ests aproxmando a Kanban. Una vez que se
empeza
a habar de hacer durar a teracn menos de una semana, se
debera consderar abandonar dentvamente as teracones a
tempo cerrado.
Ya o he dcho antes y o segur dcendo: Expermenta hasta
que encuentres ago que te funcone! y entonces contna
expermentando.
14
Dferencas menores
He aqu agunas dferencas que parecen ser menos reevantes
en comparacn con as menconadas arrba. De todas formas,
es bueno estar a tanto de eas.
Scrum prescrbe una Pa de Producto
prorzada
En Scrum, a prorzacn se hace sempre ordenando a pa de
producto y os cambos en as prordades tenen efecto en e
sguente sprnt (no en e actua). En Kanban, puedes eegr
cuaquer esquema de prorzacn (o ncuso nnguno) y os
cambos tenen efecto tan pronto como a capacdad est
dsponbe (y no en perodos de tempo preestabecdos). Puede
que exsta o no un pa de producto, y puede estar prorzada o
no.
En a prctca, a dferenca es muy pequea. En un tabero
Kanban a coumna de ms a a zquerda tpcamente satsface
e msmo propsto que a pa de producto en Scrum. Tanto en e
caso de que a sta est ordenada por prordad, como s no, e
equpo necesta una rega de decsn que permta saber cu es
e sguente eemento de que trar. E|empos de regas de
decsn:
_ Sempre toma a prmera tarea.
_ Sempre toma a tarea ms antgua (cada tarea tene que
tener fecha, caro).
_ Toma cuaquer tarea.
_ Empea aproxmadamente e 20% en tareas de
mantenmento y e 80% en nuevos desarroos.
_ Dvde a capacdad de equpo, de forma aproxmada, entre
e producto A y e producto B.
Sempre toma as tareas en ro|o, s as hay.
En Scrum, a pa de producto tambn se puede usar a esto
Kanban. Podemos mtar su tamao y crear as regas de
decsn sobre cmo se debera prorzar.
En Scrum se estabecen reunones daras
Un equpo Scrum tene una reunn corta (de aproxmadamente
15 mnutos) cada da, a a msma hora y en e msmo ugar. E
ob|eto de estas reunones es compartr nformacn sobre o que
est pasando, pancar e da de traba|o actua e dentcar
cuaquer probema sgncatvo. E trmno que se empea a
veces en ngs, 'day standup', ree|a e hecho de que
normamente se ceebra de pe (para que sea breve y mantener
un nve ato de energa).
Las reunones daras no se utzan en Kanban, pero a mayora
de os equpos Kanban parece que o hacen de todos modos. Es
una gran tcnca, con ndependenca de proceso que utces.
En Scrum, este formato de reunn est muy orentado a a
persona. Cada membro de equpo va hacendo su reporte uno a
uno. Muchos equpos Kanban utzan un formato ms orentado
a pane, ponendo e foco en os cueos de botea y otros
probemas vsbes. Esta tma aproxmacn es ms escaabe.
S tenes 4 equpos compartendo e msmo pane y hacendo sus
reunones daras |untas, puede que no sea necesaro tener que
escuchar habar a cada uno en tanto y en cuanto nos
enfoquemos en as partes que son cueos de botea de pane.
En Scrum se usan dagramas de Burndown
Un grco burndo-n representa,
daramente, a cantdad de
traba|o restante en a teracn
actua.
La undad de e|e-Y es a msma
que a utzada en as tareas de
sprnt. Tpcamente, horas o das
(s e equpo converte a pa en
tareas) o puntos de hstora (s e
DIFERENCIAS MENORES | 41
equpo no o hace). Exsten muchas varacones de esto.
En Scrum, os grcos burndo-n se usan como herramenta
prmorda para e segumento de progreso de una teracn.
Agunos equpos tambn utzan grcos burndo-n de versn
que sgue e msmo formato pero a nve de versn -
tpcamente muestran cuantos puntos de hstora quedan
pendentes en a pa despus de cada sprnt.
E prncpa propsto de un grco Burndown es encontrar,
fcmente y tan pronto como sea posbe, s nos encontramos
avanzados o retrasados respecto a pancacn para poder
adaptarnos.
En Kanban, no se prescrben grcos burndown. De hecho, no
exste nngn tpo partcuar de grco. Pero, desde uego que se
permte utzar cuaquer tpo de grco que se quera
(ncuyendo os burndo-ns).
A contnuacn se muestra un e|empo de Dagrama de Fu|o
Acumuatvo. Este tpo de grcos representan namente a
suavdad de u|o y cmo e WIP afecta a tu pazo de entrega.
La echa horzonta nos muestra que as tareas aaddas a a
pa e da 4
costaron una meda de 6 das en egar a produccn.
Aproxmadamente
a mtad de ese tempo fueron Test. Podemos ver que s se
mtramos
e WIP en Test y Pa, reducramos sgncatvamente e pazo de
entrega tota.
La pendente de rea azu-oscura nos muestra a veocdad (por
e|empo, nmero de tareas desarroadas a da). Con e tempo
podemos ver como veocdades mayores reducen e pazo de
entrega, mentras que un mayor WIP o ncrementa.
La mayora de as organzacones queren tener reazado e
traba|o ms rpdo (= reducr e pazo de entrega).
Desafortunadamente muchas caen en a trampa de asumr que
esto sgnca contratar ms personas o traba|ar horas extras.
Normamente a forma ms efectva de hacer e traba|o ms
rpdamente es suavzar e u|o y mtar e traba|o a a
capacdad. No aadr ms gente o traba|ar ms duro. Este tpo
de dagrama muestra por qu. Y de este modo se ncrementa a
probabdad de que e equpo y a gerenca coaboren de forma
efectva.
Esto se ve de forma an ms cara s dstngumos entre estados
'a coa' (como por e|empo "esperando para test") y estados de
'traba|o' (como por e|empo "Testeando"). Oueremos, mnmzar
de forma absouta e nmero de actvdades esperando 'a coa'.
Y e Dagrama de Fu|o Acumuatvo ayuda a proporconar os
ncentvos adecuados para esto.
15
E tabero Scrum vs. e tabero Kanban
- un e|empo menos trva
En Scrum, a pa de sprnt es so una parte de a foto - a parte
que muestra o que est hacendo e equpo durante e sprnt
actua. La otra parte es a pa de producto - a sta de cosas que
e dueo de producto quere tener hecho en futuros sprnts.
Cuando se hace e sprnt, e equpo "facta e cdgo
potencamente entregabe" a dueo de producto. De este
modo, cundo e equpo naza e sprnt o revsa y, con orguo,
muestra as caracterstcas A, B, C y D a dueo de producto. E
dueo de producto puede decdr ahora s quere o no entregar
e sprnt. Esta tma parte - e hecho de entregar e producto -
no suee estar ncudo en e sprnt, y por o tanto no es vsbe
en a pa de sprnt.
En este escenaro, un tabero Kanban podra ser ago como esto:
Ahora, e u|o de traba|o competo se encuentra en e msmo
tabero -no so estamos mrando o que un equpo Scrum est
hacendo en una teracn.
En e e|empo anteror a coumna "Pa" es so una sta genera
de deseos sn nngn orden en partcuar. La coumna
"Seecconado" contene os eementos de prordad ata, con un
mte Kanban de 2. Por o tanto, so puede haber 2 eementos
de prordad ata en un momento dado. Cada vez que e equpo
est sto para comenzar a traba|ar en un nuevo eemento
tendr que tomar e prmer eemento de a coumna
"Seecconado". E dueo de producto puede hacer cambos en
as coumnas "Pa" y "Seecconado" en cuaquer momento,
pero no en as otras coumnas.
La coumna "Des" (dvdda en dos subcoumnas) muestra o que
se est desarroando, con un mte Kanban de 3. En trmnos de
red, e mte Kanban corresponde a "ancho de banda" y e
tempo de entrega corresponde a "png" o tempo de respuesta.
Por qu hemos dvddo a coumna "Des" en dos subcoumnas
"En curso" y "Termnado"? Es para dar a equpo de produccn a
oportundad de conocer os eementos que pueden arrastrar -
pu - a produccn.
EL TABLERO SCRUM VS EL TABLERO KANBAN | 45
E mte "Des" de 3 es compartdo entre as dos subcoumnas.
Por qu? Dgamos que hay 2 artcuos en "Termnado":
Esto sgnca que so puede estar 1 eemento "En curso". Por o
tanto, sgnca que habr exceso de capacdad, os
desarroadores podran comenzar un nuevo eemento, pero no
estn autorzados a causa de mte Kanban. Esto es da un
fuerte ncentvo para concentrar sus esfuerzos y ayudar a poner
cosas en produccn, para borrar de a coumna "Termnado" y
maxmzar e u|o. Este efecto es agradabe y progresvo - a ms
cosas en "Termnado", menos cosas se permten "En curso" - o
que ayuda a centrar a atencn de equpo en as cosas
adecuadas.
Fu|o de una soa peza
E u|o de una soa peza es una espece de escenaro de "u|o
perfecto", donde un eemento uye a travs de tabero sn
quedar atrapado en una coa. Esto sgnca que en cada
momento hay aguen traba|ando en ese eemento. Aqu puedes
ver cmo e tabero podra representar este caso:
Cues deberan ser os mtes Kanban?
Cuando e mte Kanban para "tu" coumna se ha acanzado y no
tenes nada que hacer, empeza a buscar un cueo de botea
aguas aba|o (es decr, acumuando puntos a a derecha de a
pzarra) y ayuda a resover e cueo de botea. S no hay un
cueo de botea puede que sea una ndcacn de que e mte
Kanban pueda ser demasado ba|o, ya que a razn de tener e
mte es reducr e resgo de amentacn de os cueos de
botea dervados. S notas que muchos eementos no son
atenddos durante mucho tempo sn que se est traba|ando,
puede ser una sea de que e mte de Kanban puede ser
demasado ato.
_ Lmte Kanban demasado ba|o => gente ocosa => maa
productvdad
_ Lmte Kanban demasado ato => tareas ocosas => ma
tempo de respuesta
Cmo de estrctos son os mtes Kanban?
Agunos equpos os toman como normas estrctas (es decr, e
equpo no podr superar e mte), otros equpos os toman
como drectrces o desencadenantes de una dscusn (es
decr, romper un mte Kanban est permtdo, pero debe ser
una decsn ntencona, con un motvo concreto). As que una
vez ms, te toca a t. Ya te d|e que Kanban no era muy
prescrptvo?
16
Resumen de Scrum vs Kanban
Parecdos
_ Ambos son Lean y Ages.
_ Ambos empean sstemas de pancacn "pu".
_ Ambos estabecen mtes WIP.
_ En ambos a vsbdad de proceso es a base de su
me|ora.
_ Ambos tenen como ob|etvo a entrega temprana y
frecuente de software.
_ Ambos traba|an con equpos auto-organzados.
_ Ambos necestan a dvsn de traba|o en partes.
_ Ambos revsan y me|oran de forma contnua e pan de
producto en base a datos emprcos (veocdad / tempo de
entrega)
Dferencas
E equpo asume un
compromso de traba|o por
teracn.
E compromso es opcona.
La mtrca por defecto para a
pancacn y a me|ora de
proceso es a Veocdad.
La mtrca por defecto para a
pancacn y a me|ora de
proceso es e Lead Tme
(tempo de entrega o tempo
medo que tarda una petcn
en sar de cco)
Los equpos deben ser mut-
funconaes.
Los equpos pueden ser mut-
funconaes o especazados.
Las funconadades deben
dvdrse en partes que
puedan competarse en un
sprnt.
No hay nnguna prescrpcn
en cuanto a tamao de as
dvsones.
Deben empearse grcos
Burndown.
No se prescrben dagramas
de segumento concretos.
Se empea una mtacn WIP
ndrecta (por sprnt).
Se empea una mtacn WIP
drecta (marcada por e estado
de traba|o).
Se deben reazar
estmacones.
Las estmacones son
opconaes.
No se pueden aadr tareas en
medo de una teracn.
Sempre que haya capacdad
dsponbe, se pueden aadr
tareas.
La pa de sprnt pertenece a
un equpo determnado.
Varos equpos o personas
pueden compartr a msma
pzarra Kanban.
Se prescrben 3 roes
(PP/SM/Equpo).
No hay roes prescrtos.
En cada sprnt se mpa e
tabero de segumento.
E tabero Kanban es
persstente.
La pa de producto debe
estar prorzada.
La prorzacn es opcona.
Aa. Esto es todo. Ahora ya conoces as dferencas.
Sn embargo, an no ha termnado, ahora es e momento de a
me|or 52
EL TABLERO SCRUM VS EL TABLERO KANBAN | 53
parte!. Czate as botas, porque es hora de r a as trncheras
con Mattas para ver cmo se pone esto en prctca!
Parte II - Caso de estudo
Kanban en a vda rea
*
Graphca User Interface: Interfaz Grca de Usuaro
.sta es la historia de cmo hemos aprendido a mejorar usando
Kanban. Cuando empe(amos no haba mucha in)ormacin, y el
/r. 0oogle nos dej con las manos vacas. Hoy en da Kanban
est$ evolucionando satis)actoriamente y hay un cuerpo de
conocimiento incipiente. 1ecomiendo echar un vista(o al trabajo
de /avid 2nderson, por ejemplo a #classes o) service#. 2s "ue
a"u viene la primera 3y 4ltima5 advertencia 36lo prometo75.
&ndependientemente de la solucin "ue vayas a implementar,
aseg4rate de tratar sus problemas especfcos. 8na ve( dicho,
vamos con nuestra historia.
9:attias S*arin
17
La naturaeza de as operacones tcncas
S aguna vez has estado en un servco de soporte 24/7, tendrs
una dea cara de a responsabdad que se sente a gestonar
un entorno de produccn. Se espera que resuevas a stuacn
en medo de a noche, sn mportar s e probema era por tu
cupa o no. Nade o sabe, por eso te aman. Es un reto
compcado porque t no eres e fabrcante de hardware, os
drvers, e sstema operatvo n e software de usuaro. A
menudo tus opcones se mtan a acotar e probema o su
mpacto, y a regstrar a nformacn necesara para poder
repetr e error, de manera que a persona responsabe pueda
souconar e probema de que tu has sdo testgo.
La respuesta y a capacdad para resover probemas son caves,
sempre con veocdad y precsn.
18
Por qu dabos cambar?
En 2008 uno de nuestros centes, una empresa escandnava de
desarroo de |uegos, pas por un por una sere de me|ora de
procesos. Uno de eos ncua escaar Scrum a a empresa de
desarroo y uno por uno emnar os obstcuos que mpedan a
equpo de desarroo a entrega de software. Cuando e software
empez a ur y e rendmento me|or, se despaz a presn
haca e grupo de Operacones. Anterormente, os equpos de
Operacn haban observado e proceso desde fuera, pero ahora
estaban cada vez ms nvoucrados como parte actva de
proceso de desarroo.
Fgura 1. La organzacn de grupo de Operacn ncua tres
equpos; os admnstradores de bases de datos (DBAs) os
admnstradores de sstemas y a segunda nea de soporte.
As que ayudar a os equpos de desarroo no era sucente. S
mantenamos e foco so en os equpos de desarroo
causaramos retrasos en as me|oras de nfraestructura crtcas
reazadas por os equpos de Operacn. Por o tanto se
necestaban me|oras en ambas reas.
Adems, e progreso en os equpos de desarroo sgncaba un
aumento de as petcones a os gerentes para echar una mano
en e anss y a revsn de deas. Esto sgncaba que tenan
menos tempo para a prorzacn de tareas y resoucn de
probemas en e da a da. E equpo de gerentes se do cuenta
de que necestaban actuar antes de que a stuacn se vovera
nmane|abe.
19
Por dnde empezamos?
Una buena forma de empezar era preguntar a os equpos de
desarroo, porque eran os centes de grupo de Operacones.
E equpo de operacones, vsto por os
desarroadores
Les pregunt; "qu tres cosas os venen a a cabeza cuando
penss en 'Operacones'?". Las respuestas ms comunes
fueron:
;Conocimiento variable< ;Su sistema de -or*'o-
apesta< ;:uy
competentes cuando se trata ;=>u? est$n haciendo los de
in)raestructura< chicos!<
;.llos "uieren ayudar, pero en ;@ecesito
muchos correos realidad es di)cil obtener
ayuda< electrnicos para hacer cosas
simples< ;+os proyectos duran demasiado<
;/i)ciles de contactar<
En resumen, as era cmo os desarroadores vean a equpo de
Operacn. Comparmoso con a vsn de Desarroo que tena
e equpo de Operacn:
Desarroo, vsto desde e equpo de operacones
wwwwwwww
wwwwwwwwwww
wwwwwwwwwwwww
wwwwwwwwwwww
;=Por "u? no utili($is las ventajas "ue os o)recen las
plata)ormas!<
;6Hagamos de la distribucin algo menos pesado7<
;6Auestra baja calidad nos a)ecta7<
#Bienen "ue cambiar# - era e tema comn en as que|as de
ambos equpos. Obvamente, debamos cambar ese esquema
menta s queramos avanzar en a resoucn de os probemas
comunes. Por o menos, "muy competentes cuando se trata de
in)raestructura" ndcaba conanza en as capacdades y me
haca pensar que esa mentadad de "nosotros contra ellos#
poda arregarse s se creaban as condcones de traba|o
adecuadas. Una opcn vabe poda ser emnar e sobre-
esfuerzo y concentrarnos en a cadad.
20
Incando a marcha
As que necestbamos ncar a marcha, pero por dnde
empezamos? La nco certo que sabamos es: e sto donde
empecemos no ser donde termnemos.
M experenca es a de un desarroador, as que seguramente
saba muy poco sobre a naturaeza de traba|o de Operacones.
Y no era cuestn de entrar a o oco y comenzar a cambar
cosas. Necestaba un enfoque menos fronta que an as nos
enseara as cosas reevantes, descartara as no reevantes y
fuera fc de aprender.
Los canddatos eran:
1 Scrum - estaba funconando ben en equpos de desarroo.
2 Kanban - era nuevo y no estaba probado, aunque enca|a
ben con os prncpos Lean que se echaban en fata.
En dscusones con os gerentes os prncpos de Kanban y Lean
parecan enca|ar con os probemas que estbamos ntentando
resover. Desde su punto de vsta os sprnts no se adaptaran
muy ben ya que hacan reprorzacn de forma dara.
Por o tanto Kanban pareca e punto de partda ms gco,
ncuso aunque fuera ago nuevo para todos nosotros.
21
Puesta en marcha de os equpos
Cmo poner en marcha os equpos? No haba nngn manua
que d|era cmo hacero. Y hacero ma poda ser muy
arresgado. Aparte de perder as me|oras, tenamos que tratar
con una pataforma de produccn con persona atamente
especazado y cuacado; dfces de reempazar. De|aros de
ado era una dea muuuy maa.
_ Deberamos smpemente ponernos en marcha? Asumr
as consecuencas segn vayan surgendo?
_ O ben, hacer prmero un taer?
Era obvo para nosotros - Hacer e taer, verdad? Pero cmo?
Era un reto consegur que todo e equpo de soporte partcpara
en un taer (Oun contestar a tefono s aguen ama?). A
na decdmos hacer un taer de medo da, y mantenero
senco y basado en e|erccos.
E taer
Uno de os benecos de taer era que ayudara a poner de
manesto cuanto antes nuestros probemas. Pero adems
proporcon un ambente de ata conanza donde as
mpcacones podan ser dscutdas drectamente con os
membros de equpo. Porque, seamos snceros, no todo e
mundo era demasado entusasta acerca de cambar a actua
forma de traba|o. Pero a mayora de os membros de equpo
estaban abertos a ntentaro, as que se ev a cabo un taer de
demostracn de os prncpos ms mportantes y se hzo una
smuacn a escaa de Kanban.
A na de taer hcmos una votacn a mano azada para
comprobar s os equpos estaban dspuestos a ponero en
prctca. No se pantearon ob|econes a este punto, as que
tenamos e vsto bueno para segur adeante.
22
Drgndonos a os nvoucrados
Era muy probabe que otras partes nteresadas (soporte,
centes, otros equpos, ...) se veran afectadas por a apcacn
de Kanban. Aunque os cambos seran para me|or, sgncara
que e equpo comenzara a decr "no" a traba|o que no podan
competar, a defender a cadad, y a emnar tareas de ba|a
prordad de a pa de equpo. A pesar de eo, tener una
dscusn preva sempre es una buena dea.
Los nteresados ms cercanos eran a prmera nea de soporte y
os gerentes de departamento. Como haban partcpado en e
taer, ya eran partdaros de segur adeante. Lo msmo para os
equpos de desarroo (que esperaban en mayor o menor medda
as me|oras). Pero, para un equpo, e equpo de soporte, as
cosas eran dferentes. Su probema ms mportante era que
estaban sobrecargados de traba|o. Adems, eos gestonaban
as soctudes de os centes y a empresa se haba
comprometdo a responder a todas as soctudes.
Ahora esto era muy probabe que cambara s apcbamos
Kanban y se comenzbamos a cumpr os mtes de WIP
(traba|o en curso). As que hcmos una vsta a os prncpaes
nteresados para presentares nuestras ntencones, benecos
esperados, y posbes consecuencas.
Para m avo, nuestras deas fueron muy ben acogdas, a veces
con una observacn: "estupendo si fnalmente podemos dejar
estos asuntos en pa(".
23
Construyendo e prmer tabero
Una buena manera de comenzar a construccn de un tabero
de Kanban es hacendo un mapa de a cadena de vaor (vaue
stream map). Se trata bscamente de una vsuazacn de a
cadena de vaor y proporcona a comprensn de os estados de
os traba|os, e u|o y e tempo a en e sstema (tempo de
cco).
Pero empezamos por ago mucho ms smpe; un tabero de
e|empo Kanban dbu|ado en pape |unto con e gerente.
Revsado un par de veces y uego nos pusmos en marcha. Las
cuestones que surgeron en esta etapa ncuyen:
_ Ou tpos de traba|o tenemos?
_ Oun os mane|a?
_ Debemos compartr a responsabdad entre os
dferentes tpos de traba|o?
_ Cmo podemos hacer frente a a responsabdad
compartda tenendo en cuenta que tenemos
conocmentos especazados?
Dado que para os dferentes tpos de traba|o haba acuerdos de
nve de servcos dferentes, pareca natura permtr que cada
equpo evara e contro de su propo tabero. Eos msmos
hceron as as y coumnas.
La sguente gran decsn era s utzar o no una
responsabdad compartda entre os dferentes tpos de traba|o.
#=/ebemos dejar "ue una parte fja del e"uipo trate con las
preguntas directas 3trabajo reactivo5 y dejar "ue el resto del
e"uipo se centre en los proyectos 3trabajo proactivo5!#
Decdmos en un prmer momento probar a responsabdad
compartda. Una razn fundamenta era que habamos
dentcado que a auto-organzacn y e crecmento de os
membros de equpo eran esencaes para e crecmento
sostendo. E nconvenente de esta decsn eran as potencaes
nterrupcones para todo e mundo, pero esta era a me|or
soucn que pensamos para comenzar.
Una pequea nota a margen: cuando reazamos e taer os
equpos se organzaron soos para souconar este probema.
De|aron que una persona a mane|ara as soctudes nmedatas
y e resto as cuestones ms extensas.
E prmer modeo Kanban
A contnuacn se muestra e modeo bsco que utzamos para
Kanban. Tenga en cuenta que e equpo decd poner e u|o de
producto haca arrba (como burbu|as en e agua) en ugar de
usar e modeo de u|o ms tpco de zquerda a derecha.
Fgura 2. Este es e prmer modeo de Kanban. Prordades de
e|ecucn de zquerda a derecha, u|o de e|ecucn haca arrba.
Traba|os en curso contados como e nmero tota de tareas en a
CONSTRUYENDO EL PRIMER TABLON | 71
nea de traba|o en curso (con crcuo ro|o). E modeo est
nuencado por as experencas transmtdas por Lnda Cook.
Fgura 3. Prmer tabero Kanban para e equpo de admnstracn
de sstemas.
Fas utzadas:
Estado de u|o de traba|o
(a)
Como o denmos
Backog (Pa de producto) Hstoras que e gerente
decde que son necesaras.
Lsto para WIP Hstoras estmadas y
dvddas en tareas con una
duracn mxma de 8 horas.
Traba|o en curso Fa que contena un mte
para e traba|o en curso.
Empezamos con un mte de
2 X tamao de equpo -1 (-1
para coaboracn). As, un
equpo de 4 personas tendra
un mte de 7.
Hecho E|ecutabe por e usuaro.
Coumnas utzadas:
Tpo de traba|o Como o denmos
Reease (beracn) Ayudar a os equpos de
desarroo a berar software.
Soporte Pequeas petcones de otros
equpos.
No pancado Traba|o mprevsto que es
necesaro reazar pero que
no tene un propetaro
dendo. Por e|empo,
pequeas me|oras en a
nfraestructura.
Proyecto A Proyectos grandes de soporte
tcnco, por e|empo cambar
e hardware de entorno de
pruebas.
Proyecto B Otro proyecto argo
No todos os taberos Kanban tenan a msma aparenca. Todos
comenzaron con un boceto smpe y evouconaron por e camno.
24
Estabecendo e prmer mte de WIP
Nuestro prmer mte de WIP (traba|o en curso) era bastante
generoso. Supusmos que medante a vsuazacn de u|o
veramos y expermentaramos o que ba sucedendo y que era
poco probabe que furamos capaces de advnar e mte
ptmo desde e prncpo. Segn pasara e tempo, a|ustaramos
os mtes de WIP cada vez que encontrramos una buena razn
para eo (so haca fata apuntaro en e tabero).
E prmer mte WIP que usamos fue 2n-1 donde "n" era e
nmero de membros de equpo y "-1" un modo de potencar a
cooperacn. Por qu decdmos este mte? Smpemente,
porque no tenamos una dea me|or |. Adems, pareca ago poco
controvertdo para empezar. La frmua proporconaba una
expcacn smpe y gca para cuaquera que ntentara cargar
ms traba|o a equpo: "...s cada membro de equpo so puede
traba|ar en un mxmo de dos cosas a a vez, una actva y otra
en espera... cmo crees que pueden aceptar ms?". Mrando
ahora haca atrs, cuaquer mte generoso habra funconado
para un equpo novato. Montorzando e tabero Kanban es
senco descubrr os mtes correctos sobre a marcha.
Fgura 4. Cmo apcbamos e mte de WIP para e equpo de
DBA y admnstracn de sstemas, con un mte por cada tpo
de traba|o
Pronto descubrmos que no era t denr e mte WIP en
puntos de hstora porque era dfc de controar. E nco mte
sucentemente senco de controar era smpemente a cuenta
de nmero de eementos de pane, es decr, e nmero de
tareas en paraeo.
Para e equpo de suporte estabecmos un mte WIP por
coumna, porque necestbamos capacdad de reaccn rpda s
e mte se sobrepasaba.
25
Respetando e mte WIP
Aunque respetar e mte WIP estabecdo suena fc en teora,
es una tarea dfc de consegur en a prctca, porque sempre
sgnca decr "no" en agn momento. Pusmos en prctca
dferentes aproxmacones para consegur esto.
Dscutr frente a tabero
Cada vez que se descubra una voacn de os mtes WIP
evbamos a as partes nteresadas ante e tabero Kanban y es
preguntbamos qu pretendan consegur. A prncpo, a razn
ms habtua para esas voacones era smpe nexperenca. En
agunos casos nos encontramos con perspectvas dferentes
sobre a prorzacn, sendo tpcos os casos de especastas
traba|ando sobre su rea especca. Estas fueron as ncas
ocasones en que expermentamos aguna frccn, porque a
mayora de as veces estas voacones se souconaban a
msmo dscutndoo a a vsta de tabero.
Creando una seccn de sobrecarga
Cuando decr "no" supona demasada confrontacn, y emnar
eementos de tabero era compcado, movamos os eementos
de menor prordad a una seccn de "sobrecarga" en e tabero,
a donde os mtes WIP se haban sobrepasado. Dos regas
apcaban a as tareas en sobrecarga:
1 No han sdo ovdadas. En cuanto tengamos tempo as
trataremos.
2 S as abandonamos, sers nformado.
|usto pasadas dos semanas se haca obvo que os eementos de
sobrecarga ncuso n se trataran nunca, de forma que con e
apoyo de |efe de equpo namente se podran qutar.
Fgura 5. Boceto de tabero Kanban para e equpo de soporte,
con a seccn de sobrecarga en a tma coumna.
26
Ou tareas evar a tabero?
Pronto tomamos a decsn de no ncur todo e traba|o hecho
por e equpo en e tabero. Montorzar cosas como una amada
teefnca o tomar un caf convertra e Kanban en un monstruo
admnstratvo. Estbamos aqu para resover probemas, no
para crearos |. As que decdmos so poner en e tabero as
tareas con tamao mayor de una hora. Todo o menor de una
hora se consderaba "rudo banco".
E mte de 1h reamente funcon bastante ben, y fue de as
pocas cosas que permaneceron sn cambos a o argo de
tempo (tuvmos que revsar nuestras prevsones acerca de
mpacto que e rudo de fondo tena, pero habaremos de eso
ms tarde).
Fgura 6. Comenzamos por sumr que a capacdad tota era
prncpamente ocupada en dos tpos de traba|o; "grande"
(proyectos) y "pequeos" (soporte). E segumento de a
veocdad en proyectos nos poda dar pstas acerca de a fecha
de entrega s era necesaro. Sempre contbamos con que e
"rudo banco" (pequeo soporte menor de 1h, reunones, caf,
ayudar a os coegas) estara por ah de todos modos.
27
Cmo estmar?
Este es un tema sempre recurrente y reamente hay ms de una
respuesta correcta:
_ Estmar reguarmente.
_ Estmar cuando se necesta.
_ Usar estmacones en "das deaes" o en "puntos de
hstora".
0 Las estmacones son ncertas, usa taas de camseta
(S
1 pequea, M-meda, L-grande)
_ No estmes, o estma so cuando exsta un coste asocado
a
retraso que o |ustque.
Lgeramente nudos por Scrum (dado que de ah es de donde
venamos, de todos modos) decdmos comenzar con puntos de
hstora. Pero en a prctca, os equpos trataban os puntos de
hstora como equvaentes a horas-hombre, que es resutaba
ms natura. Incamente, estmbamos todas as hstoras.
Con e tempo, os gerentes descubreron que s mantenan ba|o
e nmero de proyectos concurrentes, no tenan a as partes
nteresadas esperando. Tambn descubreron que as, en caso
de un cambo mprevsto, podan reprorzar as tareas para
souconar e probema.
La necesdad de una fecha de entrega de proyecto haba de|ado
de ser un gran probema, y esto ev a os gerentes a de|ar de
soctar estmacones a pror. So o hacan s se tema que
tendran gente esperando.
#2l poco tiempo hubo un gerente "ue, presionado por una
llamada tele)nica, prometi la entrega de un proyecto ;al fnal
de esta semana<. /ado "ue el proyecto estaba en el tablero
Kanban, era )$cil estimar el avance 3contar historias seg4n se
completaban5 y concluir "ue, m$s o menos el CDE ,se fnali(aba
cada semana. 2s, eran necesarias otras tres semanas
adicionales. .n)rentado a este hecho, el gerente cambi la
prioridad del proyecto, detuvo el trabajo concurrente, e hi(o la
entrega posible. Siempre che"uea contra el tablero w<
Ou sgnca "tamao estmado"? Pazo o
esfuerzo?
Nuestras estmacones en puntos de hstora ree|aban e tempo
de traba|o, es decr, cuntas horas de esfuerzo nnterrumpdo
esperbamos que una hstora necestara, y no "pazo de
entrega" (o das de caendaro, o cuntas horas esperar a que e
traba|o est termnado). Mdendo e nmero de puntos de
hstora que acanzan e estado "hecho" cada semana
(veocdad), podamos deducr nuestros tempos de respuesta
medo (e "ead tme" medo).
Estmbamos cada nueva hstora so una vez, y no nos
parbamos a revsar as estmacones de a hstora durante su
e|ecucn. Esto nos permta mnmzar e tempo de equpo que
se dedcaba a tareas de estmacn.
28
Entonces Cmo traba|bamos
reamente?
Kanban mpone muy pocas restrccones y te permte traba|ar en
toda case de formas. Puedes hacer que e equpo traba|e en
actvdades pancadas en e tempo, o puedes eegr reazar
as actvdades cuando se ha generado a sucente nerca como
para |ustcaro.
Fgura 7 Cuando tres tareas egaban a a pa de producto se
anzaba e evento de pancacn/estmacn.
Nosotros decdmos pancar dos eventos recurrentes en e
tempo:
_ Reunn dara - con e equpo en frente de tabero, para
sacar a a uz probemas y ayudar a crear una vsn
compartda de as tareas de todo e equpo.
_ Pancacn semana de a teracn - con propstos de
pancacn y me|ora contnua
Este enfoque funconaba ben en nuestro caso.
Reunn dara
La reunn dara era smar a un Scrum daro. Se ceebraba
cada da, despus de a reunn de "Scrum de Scrums" con
partcpacn de todos os equpos (desarroo, pruebas,
operacn). E Scrum de Scrums generaba nformacn
mportante para os equpos Kanban, como qu probemas
deban tratarse prmero, o qu equpo de desarroo estaba
sufrendo ms en cada momento. Incamente, os gerentes
asstan a estas reunones daras con frecuenca, proponendo
soucones y prorzando as decsones. Pero con e tempo,
segn os equpos se hacan me|or auto-organzados, de|aron de
asstr tan a menudo (aunque nunca estaban e|os s se es
necestaba).
Pancacn de teracn
Una vez a a semana, tenamos una reunn de pancacn de
a teracn. La hacamos semanamente, en un momento
pancado, porque descubrmos que s no a pancbamos, ese
tempo se consuma en otras prordades :), y necestbamos
ms chara de equpo.
COMO TRABA|ABAMOS REALMENTE | 83
Un orden de da tpco era:
_ Actuazar grcos y tabero. Los proyectos termnados se
movan a "Muro de o hecho".
_ Revsar a semana pasada. Ou pas? Por qu? Ou se
podra hacer para me|oraro?
_ Rea|uste de os mtes de WIP s era necesaro.
_ Dvsn de tareas y estmacn de nuevos proyectos (s se
vea necesdad).
Bscamente, a reunn de pancacn es una combnacn
entre reunn de estmacn y de me|ora contnua. Los
probemas pequeos o medos se resovan sobre a marcha con
e apoyo de una prmera nea de gerentes. Pero se haca
compcado mantener a traccn sobre os probemas compe|os
o de nfraestructura. As que para me|orar esto, dotamos a os
equpos de a habdad de asgnar hasta dos "mpedmentos de
equpo" a sus gerentes.
Las regas eran:
1 Un gerente puede traba|ar en dos huecos en un momento
dado de tempo.
2 S ambos huecos estn ocupados, pods aadr uno
sempre que emns e menos mportante de os actuaes.
3 E equpo decde cuando se ha resueto un
mpedmento.
Esto produ|o un cambo muy postvo. De repente, os equpos
podan ver cmo os gerentes estaban traba|ando para
ayudares ncuso en
temas compcados. Podan apuntar a os mpedmentos y
preguntar "cmo va esto?" .Los mpedmentos no se podan
ovdar, n ser redendos debdo a nuevas prordades
estratgcas.
Un e|empo de mpedmento sero fue que e Departamento de
Operacones no estaba obtenendo a ayuda que necestaba de
os desarroadores cuando sospechaban que haba un bug.
Necestaban ayuda para descubrr qu parte de sstema estaba
causando e probema, pero como os desarroadores estaban
ocupados en sus sprnts desarroando nuevo matera, os
probemas se ban acumuando. No era sorprendente que
Operacones sntera que os desarroadores no se preocupaban
o sucente por a cadad.
Cuando este mpedmento aor, se remt prmero a gerente
de a nea, y despus a gerente de departamento, y este
convoc una reunn con e drector de desarroo.
En as conversacones que sgueron se acord poner a cadad
prmero y se estructur una soucn de soporte "round-robn" -
cada sprnt, un equpo de desarroo estara "en nea" para
atender nstantneamente as petcones de ayuda. Tras
asegurarse e soporte de sus gerentes, e drector de desarroo
pas una sta de contactos a os equpos de soporte.
La soucn se puso a prueba nmedatamente, aunque
sospechbamos que e pan no funconara a a prmera. Pero
esta vez os deberes estaban ben hechos; e equpo do e
mpedmento por resueto, y supuso un gran avo para os
equpos de Operacones.
29
Encontrando una forma de pancar que
funcone
Una hstora
1ecuerdo el momento del cambio para uno de los e"uipos.
.staba sentado con ellos en su segunda sesin de estimacin. .l
e"uipo estaba atascado con un proyecto "ue no saban cmo
estimar. Haba demasiadas incgnitas y la sesin de estimacin
se blo"ue. .n lugar de dar un paso al )rente y hacerme cargo,
les pregunt? cmo refnar el proceso para encontrar una
solucin mejor. 0uiados por su gerente, recogieron el guante y
se pusieron a diseFar su propia solucin. .se momento )ue un
punto de in'eGin, una victoria importante a partir de la cual se
convirtieron en un e"uipo con confan(a. /espu?s de eso
comen(aron a evolucionar tan r$pidamente "ue tenamos "ue
apartarnos de su lado.
/os meses m$s tarde, su gerente me abord despu?s de una
retrospectivaH ;Bengo un problema< dijo seFalando el tablero
Kanban de su e"uipo. ;@o tenemos problemas reales, ="u?
debemos hacer!<
Renventando a pancacn
Las sesones de estmacn medante "pannng poker"
ncuyendo a todos os membros de equpo no estaban
funconando ben en nnguno de nuestros equpos de
operacones. Agunas razones:
1. E conocmento estaba desperdgado de manera muy
desgua en e equpo.
1 A menudo so hababa una persona.
2 Los membros de equpo queran resover os temas
urgentes que es quemaban en as manos.
Pero medante a expermentacn, os equpos egaron de forma
ndependente a dos procesos de estmacn dferente. Cada uno
funconaba ben para su equpo.
wwwwwwwwwwwwwwww
wwwwwwwwwwwwwwww
www
_ Por cada proyecto/hstora, se asgna una pare|a de senor
+ |unor para estmaro (esto es, una persona que conoce
esa hstora ben, y otra que no a conoce). Esto ayuda a
propagar e conocmento.
_ Los restantes membros de equpo egen qu hstoras
queren ayudar a estmar, con e mte de 4 personas por
hstora para mantener a efectvdad de os debates.
_ Cada equpo de estmacn hace una descomposcn de
tareas de su hstora y, so s se requere, a estma.
_ Los equpos ntercamban hstoras y revsan os traba|os de
os dems (una persona de equpo orgna permanece
para expcar e traba|o de su equpo a os revsores).
_ Hecho!
La sesn de estmacn de teracn tpca duraba arededor de
45 mnutos, de forma que e nve de energa se mantena ato
durante a
ENCONTRANDO UNA FORMA DE PLANIFICAR OUE FUNCIONE | 87
reunn. Tpcamente se hacan un par de a|ustes cuando as
hstoras rotaban y eran revsadas por nuevos o|os.
Enfoque 2 - revsn preva por un senor y
uego estmar
Dos membros de equpo con experenca reazaban una
revsn a ato nve de a hstora/proyecto antes de a
pancacn. Anazaban as posbes soucones de arqutectura
y decdan una para e probema. Una vez estabecdo, e equpo
entra en |uego y descompone a hstora en tareas usando a
soucn propuesta como punto de partda.
Iigura J. /escomposicin en tareas y revisin por el otro e"uipo
durante la reunin de planifcacin de la iteracin.
30
Ou medr?
Hay muchas cosas que pueden medrse - tempo de cco (desde
que se descubre una necesdad hasta que se cubre), veocdad,
coas, burndowns...
La pregunta mportante es qu mtrcas pueden usarse para
me|orar e proceso?. M conse|o es expermentar y ver qu
funcona para vuestro caso concreto. Nosotros aprendmos que
os dagramas de burndown eran excesvos para cuaquer
proyecto menor de 4 semanas. E progreso base todava poda
medrse mrando e tabero Kanban (cuntas hstoras en a pa
de producto, cuntas hechas).
Mtrca canddataPros Contras
Tempo de cco Fc de medr. No
necesta estmar.
Comenza y
termna en e
cente.
No tene en cuenta
e tamao.
Veocdad tota
(sobre todos os
tpos de traba|o)
Indcador
aproxmado pero
smpe de a
dreccn de as
me|oras y de a
varacn.
No ayuda a predecr
fechas de entrega
para tpos de
traba|o concretos.
Veocdad por tpo
de traba|o.
Ms precso que a
Veocdad tota.
Para ser t
necesta ncarse
en e cente y
segurse hasta a
entrega na. Es
ms compcada de
medr que a
veocdad tota.
Longtud de coas Indcador rpdo de
a varacn de a
demanda. Fc de
vsuazar.
No dstngue s a
causa es una
demanda nusua o
una capacdad
nadecuada. Una
coa "cero" puede
ree|ar
sobrecapacdad.
Comenzamos por medr "Veocdad por tpo de traba|o" y
"ongtud de coas". La veocdad por tpo de traba|o es smpe
de medr y hace su traba|o. Por su parte as ongtudes de coa
son buenos ndcadores prmaros porque pueden vsumbrarse
nstantneamente (una vez que sabes donde mrar).
Fgura 9. Cueos de botea y oportundades. E rea ro|a
muestra como as coas se han organzado para provocar un
cueo de botea en Pruebas. La ausenca de coas en a coumna
de soporte ndcan que no hay tempo de espera para nuevo
traba|o de soporte. Esto es un buena sea para un gran nve de
servco.
No usbamos dagramas de u|o acumuatvos, pero habra sdo
nteresante.
OU MEDIR?| 91
No usbamos dagramas de u|o acumuatvos porque e tabero
Kanban y e dagrama de veocdad nos daban sucente
nformacn, a menos en nuestro temprano estado de madurez.
Los cueos de botea, as dspardades y e sobretraba|o podan
todava ser fcmente dentcadas, y resover esos probemas
nos mantuvo ocupados durante os prmeros ses meses.
31
Cmo empezaron a cambar as cosas
Tres meses uego de haber ntroducdo Kanban, e equpo de
admnstracn de sstemas fue premado como e "equpo de
me|or performance" de departamento de sstemas por a
gerenca. A msmo tempo, e equpo fue votado como una de
as tres "experencas postvas" en a retrospectva de a
compaa. La retrospectva de a compaa es un evento de toda
a empresa que se reaza cada 6 semanas, y esta era a prmera
vez que un equpo termnaba en uno de os prmeros 3 ugares. Y
hace soamente 3 meses, este equpo era un cueo de botea
de que cas todos se que|aban.
La cadad de servco caramente haba me|orado. Como
suced esto? E momento esenca fue cuando todos
comenzaron a trar en a msma dreccn. Los gerentes
proveyeron un foco caro y protegeron a equpo de traba|o de
que no pertenecera a, y os equpos tomaron a
responsabdad de as fechas de entrega y a cadad. Lev
aproxmadamente tres a cuatro meses hasta que esto emerg,
pero uego uy con facdad. No es que todos os probemas de
mundo hayan desaparecdo (eso nos de|ara a todos sn traba|o,
no? w) - pero nos enfrentamos a nuevos desafos, como por
e|empo "Cmo mantenemos a un equpo motvado por me|orar
(cuando ya no son un cueo de botea)?"w
Una peza mportante de rompecabezas de a autogestn fue a
ntroduccn de concepto de "un contacto de operacones por
equpo". Esto sgnc dare a cada equpo de desarroo un
contacto de soporte persona dentro de equpo de operacones.
Kanban hzo esto posbe a permtr a equpo de operacones
autogestonarse arededor de traba|o, prevnendo sobrecarga y
permtendo me|ora contnua. Antes, una persona a azar sacara
una tarea de a coa, a souconara o me|or posbe segn sus
habdades, y uego comenzaran con a sguente.
Cuaquer probema de comuncacn sgncaba empezar todo
de nuevo con un peddo de soporte nuevo. Cuando e concepto
de uno-auno fue mpementado, e equpo de soporte adqur a
capacdad de
responder rpdamente cuando nformacn ncorrecta o
probemas de cadad puseran en resgo a sstema.
Ancdota curosa: con e tempo, os protocoos de comuncacn
evouconaron. Persona de operacones comenz a utzar a
mensa|era nstantnea con desarroadores que conocan ben,
correo eectrnco para os que escrban me|or de o que
hababan, y tefono s esa era a forma ms rpda de
souconar e probema.
Antes
Fgura 10. Antes: E gerente de nea es e punto de contacto
prncpa con e equpo. Cuaquer cosa mportante que haya que
hacer debe pasar prmero por . Probemas ms pequeos,
tpcamente os probemas de os desarroadores, son recbdos
a travs de un sstema de segumento de ncdentes. Hay poca
nteraccn drecta entre personas.
COMO EMPEZARON A CAMBIAR LAS COSAS | 95
Despus
Fgura 11. Despus: "un contacto de operacones por equpo"
mpementado. Los equpos de desarroo haban drectamente
con su contacto en operacones. Hay muchas nteraccones
drectas entre personas. Los membros de equpo de
operacones autogestonan su traba|o utzando e tabero
Kanban. E gerente mueve su foco a prorzar proyectos de
mayor tamao y a ayudar cuando surgen probemas compe|os.
Y que hay de mpacto sobre as capacdades de equpo?
Fgura 12. Veocdad tota y veocdad de proyecto, meddas en
puntos de hstora "termnados" por semana. Tota es a suma
sobre todas as coumnas, veocdad de Proyecto representa a
parte dedcada a "proyectos" (traba|os de mayor tamao, por
e|empo una me|ora en a pataforma de hardware). Las dos
cadas corresponden a 1) una semana en a que cas todos os
membros de equpo estaban de va|e y 2) una entrega grande
de equpo de desarroo.
De esta forma, a veocdad de equpo muestra una tendenca
postva. A msmo tempo, e equpo nvrt substancamente
en compartr conocmento utzando programacn por pare|as.
COMO EMPEZARON A CAMBIAR LAS COSAS | 97
Ya que estamos, echmose una mrada a rendmento de
equpo de DBAs (admnstradores de bases de datos):
La tendenca de a veocdad tota es ascendente, aunque a
varacn es sgncatva. E tamao de a varacn nspr a
equpo a montorzar e numero de pequeas tareas de soporte
(tareas generamente demasado pequeas como para egar a
tabero Kanban). Como pueden ver, e grco ndca una cara
correacn nversa entre a cantdad de tareas pequeas y a
veocdad tota.
E equpo de soporte comenz a hacer Kanban ms tarde que os
otros dos equpos, as que todava no tenemos sucente
nformacn conabe.
Maduracn
Cuando comenzamos, encontrar reas probemtcas era tarea
senca. Pero ocazar as oportundades de me|ora ms grandes
era dfc. E tabero Kanban nos brnd un nuevo nve de
transparenca. No soo era ms fc detectar probemas, sno
tambn surgeron preguntas mportantes sobre u|o, varanza y
coas. Comenzamos a utzar coas como una herramenta para
detectar probemas. A cuatro meses de comenzar con Kanban,
os gerentes ya estaban a a caza de as fuentes de varacn
que tenan un mpacto negatvo en sus equpos.
A medda que os equpos evouconaron de ndvduos a
undades autogestonadas, os gerentes se encontraron con que
se enfrentaban una nueva sere de desafos respecto a cmo
derar. Necestaban tratar ms con asuntos humanos - ocuparse
de que|as, denr ob|etvos comunes, resover conctos,
negocar acuerdos. No fue una transcn sn door - comentaron
abertamente que aprender esto requr habdad y energa.
Pero aceptaron e desafo y termnaron convrtndose en
me|ores deres.
32
Leccones aprenddas generaes
Conforme dmnuye e traba|o en curso,
aparecen restrccones
Todos os equpos empezaban con unas mtacones de Traba|o
en Curso (WIP) bastante hogadas. En ese momento a mayora
de a energa se consuma ntentando crear e u|o y asegurando
que a organzacn tena todo e soporte requerdo.
A prncpo os gerentes queran tener mtpes proyectos
e|ecutndose smutneamente, pero despus de pocas
semanas se evdencaba que no haba capacdad sucente para
tratar con os proyectos de menor prordad. De un vstazo a
pane se vea que nunca se empezaba nngn traba|o que
estuvera entre os de ba|a prordad. Esto provoc en os
gerentes reducr e nmero de proyectos por equpo.
Con e tempo, a medda que se estabzaba e u|o para e
traba|o de ata prordad, empezamos a a|ustar os mtes de
WIP. Esto se hzo reducendo e nmero de proyectos (coumnas)
de tres, a dos, y uego a uno. Mentras ocurra esto, aoraron a
a superce as restrccones de grupo. Los membros de
equpo empezaron a nformar de que no estaban recbendo
ayuda a tempo de resto, as que os gerentes prestaron
atencn a a gestn de esto.
Otras cuestones que aoraron fueron como per|udcaban as
soctudes ma reazadas de otros equpos en e rendmento.
Resutaba dfc mantener un u|o suave y rpdo cuando as
tareas entrantes requeran correccn constante.
Estos probemas no daban a cara hasta que se empezaba. La
cuestn era "Oue probema deberamos tratar prmero?" - y
acanzar un acuerdo comn arededor de . Con e pane de
Kanban todos podan ver cmo un probema especco
mpactaba en e 'ujo, o que factaba adqurr veocdad para
tratar e tema a travs de as fronteras organzaconaes.
E tabn cambar con e tempo, no
dsearo con ndeebes
Todos os panees Kanban cambaban a o argo de camno.
Normamente se pasaba por 2 o tres redseos hasta que un
equpo egaba a uno con e que traba|aba ben. As que nvertr
mucho tempo en a prmera forma probabemente sea una
prdda de tempo. Asegrate de que e pane se puede cambar
fcmente. Nosotros usbamos tras de cnta negra para a
forma. Estas se podan reordenar fcmente y se podan utzar
tanto en paredes como en pzarras. Otra forma que he vsto es
dbu|ar as neas de re|a de pane utzando gruesos
marcadores (asegurndonos de que se pueden borrar!).
Aba|o se puede ver un e|empo de optmzacn. Las prordades
cambaban frecuentemente a prncpo, as que hay que evtar
tener que mover a coumna entera de post-t de notas haca
deante y haca atrs.
LECCIONES APRENDIDAS GENERALES | 101
En vez de esto, e equpo pone e nmero de prordad encma
de cada coumna.
No tengas medo de expermentar y faar
La eccn que saqu de esta aventura es que en readad no hay
punto na. Faamos en e momento que percbmos que o hay.
Soo exste a expermentacn sn na y e aprendza|e. No
equvocarse nunca sgnca no aprender. Nosotros fabamos
muchas veces a o argo de camno (maos dseos de panees,
estmacones, grcos burndown redundantes..) - pero cada vez
aprendamos ago nuevo e mportante. S parbamos de hacer
ntentos, Cmo podramos estar aprendendo entonces?
E xto de Kanban ha nsprado a equpos de gestn y de
desarroo Scrum a empezar a expermentar con os panees
Kanban tambn. Puede que este bro ayude!
Puntos naes para e camno
Comenza con retrospectvas!
Montones de opcones y cosas sobre as que pensar, verdad?.
Espero que este bro te ayude a acarar un poco a neba. A
menos funcon para nosotros :o)
S ests nteresado en cambar y me|orar vuestro proceso,
d|anos tomar esta decsn por t ahora. S no ests hacendo
retrospectvas a ntervaos reguares, comenza por ah!
Y asegrate de que even a cambos reaes. Consgue un
factador externo s es necesaro.
Una vez que tengas retrospectvas efectvas funconando, habs
comenzado vuestro va|e haca evouconar e proceso adecuado
para vuestro contexto, est este basado en Scrum, XP, Kanban,
una combnacn de estos, o cuaquer otra cosa.
Nunca de|es de expermentar!
Kanban o Scrum no son e ob|etvo. E aprendza|e contnuo es e
ob|etvo. Una de as grandes cosas de software es que e cco
de respuesta es rpdo, o que es cave para e aprendza|e. As
que usa esa respuesta! Cuestnao todo, expermenta, faa, y
expermenta otra vez.
No te preocupes por hacero ben a a prmera, porque no o
hars.
Smpemente empeza por ago, y evoucona desde ah.
E nco fracaso rea es no aprender de os fracasos. Pero,
oye!, puedes aprender de esto tambn. Buena suerte, y
dsfruta de va|e!
/Henrk & Mattas, Stockhom 2009-06-24
PUNTOS FINALES PARA EL CAMINO | 105
HH =K esto es todo lo "ue tenemos!
:H Creo "ue s. /ej?moslo a"u.
HH =>ui($s deberamos decirles "uienes somos!
:H Luen punto. Si hacemos "ue pare(ca "ue somos tos
majos podramos sacar algo de pasta como consultores.
HH 6Hag$moslo entonces7 K luego lo damos por
cerrado.
:H S, tenemos otras cosas "ue hacer, y tambi?n los
lectores.
HH Lueno, en realidad ahora empie(an mis
vacaciones Ho5
:H 6.h7 6@o me lo restriegues7
Sobre os autores
Henrk Knberg y Mattas Skarn son consutores en Crsp en
Estocomo. Dsfrutan ayudando a as compaas a trunfar en os
ados tcnco y humano de desarroo de software, y han
ayudado a docenas de empresas a poner os prncpos de Lean
y Ages en prctca.
Henrk Knberg
Durante a pasada dcada Henrk ha sdo CTO de
tres compaas de IT Suecas y ha ayudado a muchas
ms a me|orar sus procesos. Es "Certed Scrum
Traner" y traba|a reguarmente con poneros de
Lean y de Agsmo como |eh Sutherand, Mary
Poppendeck y Davd
Anderson.
E anteror bro de Henrk, "Scrum y XP desde as Trncheras",
tene ms de 150.000 ectores y es uno de os bros ms
popuares sobre e tema. Ha ganado e premo a me|or orador
mtpes veces por sus charas en conferencas
nternaconaes.
Henrk crec en Toko y ahora vve en Estocomo con su mu|er
Sofa y tres nos. Es un msco actvo en su tempo bre.
Compone y toca e ba|o y os tecados en bandas ocaes.
henrk.knberg<at>crsp.se
http://bog.crsp.se/henrkknberg
http://www.crsp.se/henrk.knber
g
SOBRE LOS AUTORES | 107
Mattas Skarn
Mattas traba|a como coach de Lean, ayudando a as empresas
de software a dsfrutar os benecos de Lean y Age. Tutea a
todas as capas, desde os desarroadores a a gerenca. Ha
ayudado a una compaa de desarroo de |uegos a recortar os
tempos de desarroo de 24 meses a 4, devueto a conanza a
un departamento de desarroo competo, y fue uno de os
poneros en e uso de Kanban. Como emprendedor, ha
cofundado y gestonado dos empresas.
Mattas tene un grado en Master de Cencas y gestn de a
Cadad, y ha traba|ado como desarroador durante 10 aos en
sstemas de msn crtca.
Vve en Estocomo y dsfruta baando rock & ro, correndo y
esquando.
mattas.skarn<at>crsp.se
http://bog.crsp.se/mattasskarn
http://www.crsp.se/mattas.skarn

Kanban Vs Scrum

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 Vs Scrum

Cargado por

Copyright:

Formatos disponibles

Kanban y Scrum

También podría gustarte