8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
1/123
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
2/123
ii
2010 C4Media Inc.Todos los derechos reservados
C4Media, editores de InfoQ.com.
Este libro es parte de la serie de libros Desarrollo Empresarial de Software de InfoQ.
Para informacin sobre cmo solicitar este u otros libros de InfoQ, por favorcontacte con [email protected].
Ninguna parte de esta publicacin puede ser reproducida, almacenada en un sistemade recuperacin o transmitida en ninguna forma o por ningn medio electrnico,mecnico, fotocopia, recodificacin, escaneo u otros medios, excepto en los casos
permitidos por las Secciones 107 o 108 del Acta de Copyright de los EstadosUnidos, sin la autorizacin previa por escrito del editor.
Las denominaciones usadas por las compaas para distinguir sus productos sonreconocidas habitualmente como marcas registradas. En todos los casos en los queC4Media Inc. tiene noticia de dicho reconocimiento, los nombres de los productosaparecen con las Iniciales En Maysculas o TODO EN MAYSCULAS. Loslectores, en cualquier caso, deben contactar con las compaas en cuestin para lainformacin completa sobre la marca registrada.
Editor Jefe: Diana Plesa
Diseo de Portada: Bistrian IosipComposicin: Accurance
Datos de catalogacin de la publicacin por la Librera del Congreso:ISBN: 978-0-557-13832-6Impreso en los Estados Unidos de Amrica
Traduccin al castellano: Equipo de contenidos de Agile Spain (www.agilespain.com)Rodrigo Corral Plain Concepts - http://www.plainconcepts.com/Xavier Quesada-Allue Agilar - http://www.agilar.org/Jorge Uriarte Gailen Tecnologas - http://www.gailen.esAgustn Yage UPM - https://syst.eui.upm.es/
Teo Snchez - http://teosanchez.blogspot.comJuan Palacio - http://www.navegapolis.net/Gregorio Mena - http://eclijava.blogspot.com/ngel Agueda - http://legnita.wordpress.comLaura Morillo-VelardeJorge JimnezJavier SnchezJuan Quijano
Coordinacin de la traduccin: ngel Medinilla - http://www.proyectalis.com
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
3/123
INTRODUCCIN | iii
iii
Contenido
33333333333333333333333333333333333333333333333333333333333 * 3333333333333333333333333333333333333333333333333333333333333 * 333333333333333333333333333333333333333333333333333333333333333333333333333333333333333+333333333333333333333333333333333333333333333333333333333333333333333333339
9(!#%!2,!21$(&!%(,0 333333;:'!&21"!&%!,%('%&03333333> ;%(#%&%%!& 333333333333333333333333333333333333333333333333333333333399
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
4/123
iv
9>&(%(*& 333333333333333333333333333333333333333333333 =9 3333333333333333333333333333333333333333333333333333333333333333333==
9?'(%-&!#%!&'& 333333333333333333333333 =?9@1!%$(!&%03333333333333333333333333333333333333333333333333 =A9A1!%"#-!&0333333333333333333333333333333333333333333333333333 >9:8!%33333333333333333333333333333333333333333333333333333333333333 >;:9(&'%!&$(#!& 333333333333333333333333333333333333333 >=::%!!&!&*!(%!& 333333333333333333333333333333333333333333 >?:;!&'%(,!#%%'%! 3333333333333333333333333333333333333333333 >A:1('%&*%'%!033333333333333333333333333333333333333333333 ??:?1"!&'%0333333333333333333333333333333333333333333333333333333333333333333 ?A:@'!&1"!'%!&%'0333333333333333333333333 @9:A!'%!(!%#%$((!3333333333333 @=;81(%033333333333333333333333333333333333333333333333333333333333333333333333 @A;9"!#-%!%&!&& 3333333333333333333333333333333 A;;:!%&%& 333333333333333333333333333333333333333333 AA
333333333333333333333333333333333333333333333333333333333398; 33333333333333333333333333333333333333333333333333333333333333333333333333333398>
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
5/123
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
6/123
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
7/123
Prlogo por David AndersonKanban se basa en una idea muy simple: el trabajo en curso (Work InProgress, WIP) debera limitarse, y slo deberamos empezar con algonuevo cuando un bloque de trabajo anterior haya sido entregado o ha pasado a otra funcin posterior de la cadena. El Kanban (o tarjeta
sealizadora) implica que se genera una seal visual para indicar quehay nuevos bloques de trabajo que pueden ser comenzados porque eltrabajo en curso actual no alcanza el mximo acordado. Esto no suenamuy revolucionario ni parece que vaya a afectar profundamente elrendimiento, cultura, capacidad y madurez del equipo y de laorganizacin que les rodea. Lo increble es que s lo hace! Kanbanparece un cambio muy pequeo pero aun as cambia todos los aspectosde una empresa.
Hemos llegado a la conclusin de que Kanban es una aproximacin a lagestin del cambio. No es un proceso de desarrollo de software o degestin de proyectos. Kanban es una aproximacin a la introduccin decambios en un ciclo de vida de desarrollo de software o metodologa degestin de proyectos. ya existente El principio de Kanban es quecomienzas con lo que sea que ests haciendo ahora mismo. Comprendestu actual proceso mediante la realizacin de un mapa del flujo de valor yentonces acuerdas los lmites de trabajo en curso (WIP) para cada fasedel proceso. A continuacin comienzas a hacer fluir el trabajo a travsdel sistema comenzndolo ("pull") cuando se van generando las seales
Kanban.
Kanban ha demostrado ser til en equipos que realizan desarrollo gilde software, pero tambin estn ganando fuerza en equipos que utilizanmtodos ms tradicionales. Kanban se est introduciendo como parte deiniciativas Lean para transformar la cultura de las organizaciones yfomentar la mejora continua.
Dado que el WIP est limitado en un sistema Kanban, cualquier
elemento que se bloquea por cualquier razn tiende a atascar el sistema.Si un nmero suficiente de elementos se bloquean todo el proceso se
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
8/123
viii
para en seco. Esto tiene el efecto de que todo el equipo y la organizacinse concentran en resolver el problema, desbloqueando estos elementospara permitir la restauracin del flujo productivo.
Kanban usa un mecanismo de control visual para hacer seguimiento deltrabajo conforme este viaja a travs del flujo de valor. Tpicamente, seusa un panel o pizarra con notas adhesivas o un panel electrnico detarjetas. Las mejores prcticas apuntan probablemente al uso de ambos.La transparencia que esto genera contribuye tambin al cambio cultural.Las metodologas giles han obtenido buenos resultadosproporcionando transparencia respecto al trabajo en curso y completado,as como en el reporte de mtricas como la velocidad (cantidad detrabajo realizada en una iteracin). Kanban sin embargo va un paso msall y proporciona transparencia al proceso y su flujo. Kanban expone
los cuellos de botella, colas, variabilidad y desperdicios. Todas las cosasque impactan al rendimiento de la organizacin en trminos de lacantidad de trabajo entregado y el ciclo de tiempo requerido paraentregarlo. Kanban proporciona a los miembros del equipo y a las partesinteresadas visibilidad sobre los efectos de sus acciones (o falta deaccin). De esta forma, los casos de estudios preliminares estndemostrando que Kanban cambia el comportamiento y motiva a unamayor colaboracin en el trabajo. La visibilidad de los cuellos debotella, desperdicios y variabilidades y su impacto tambin promueve la
discusin sobre la posibles mejoras, y los equipos comienzanrpidamente a implementar mejoras en su proceso.
Como resultado, Kanban propicia la evolucin incremental de losprocesos existentes, una evolucin que generalmente est alineada conlos valores del Agilismo y de Lean. Kanban no pide una revolucinradical de la forma en la que las personas trabajan, sino que sugiere uncambio gradual. Es un cambio que surge del entendimiento y elconsenso entre todos los trabajadores y sus colaboradores.
Kanban, por su naturaleza de Sistema Pull ("arrastre", "tirar"; laproduccin se realiza cuando el cliente retira un elemento terminado),tambin propicia diferir el compromiso tanto en la priorizacin deltrabajo nuevo como en la entrega del trabajo existente. Tpicamente, losequipos llegarn a un acuerdo sobre la cadencia de reuniones depriorizacin con el bloque funcional que les precede en el proceso paradecidir en qu deben trabajar a continuacin. Estas reuniones se puedenmantener 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 cicloactual es de 6 semanas para entregar. Qu dos cosas son las que ms os
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
9/123
INTRODUCCIN | ix
ix
gustara ver entregadas dentro de 6 semanas?". Esto tiene un efectodoble. Formular una pregunta simple generalmente proporcionarespuestas rpidas y de buena calidad, y mantiene las reuniones cortas.La naturaleza de la pregunta muestra que el compromiso acerca de en
qu trabajar se difiere hasta el ltimo momento responsable. Esto mejorala Agilidad mediante una gestin de las expectativas, un acortamiento delos tiempos de ciclo desde el compromiso hasta la entrega y eliminandolos re-trabajos, ya que las probabilidades de un cambio en lasprioridades se minimizan.
Un ltimo comentario sobre Kanban es que el efecto de limitar el WIP proporciona predecibilidad sobre el tiempo de ciclo y hace que losentregables sean ms fiables. La estrategia de "parar el proceso" ante
impedimentos y bugs tambin parece promover altos niveles de calidady un rpido descenso del re-trabajo.
Aunque todo esto se volver evidente con las increblemente clarasexplicaciones de este libro, no ocurre lo mismo con la explicacin decmo hemos llegado hasta aqu. Kanban no se concibi en una solatarde mediante una increble epifana. Surgi a lo largo de muchos aos.Muchos de sus profundos aspectos psicolgicos y sociolgicos quecambian la cultura, capacidad y madurez de las organizaciones nuncafueron imaginados en un principio. Fueron ms bien descubiertos.Muchos de los resultados de Kanban son contra-intuitivos. Lo queparece ser una aproximacin muy mecnica - limitar el WIP y retirar eltrabajo - tiene en realidad profundos efectos en las personas y en comointeractan y colaboran unas con otras. Ni yo, ni ninguno de los queestuvieron involucrado en los inicios de Kanban, previmos esto.
Implement lo que luego se convirti en Kanban como una estrategiapara la gestin del cambio que encontrase una resistencia mnima. Tenaesto claro ya en el 2003. Tambin lo implement por los beneficios
mecnicos. Como ya estaba descubriendo en aquellos das mediante laaplicacin de tcnicas Lean, si gestionar el WIP tena sentido, entonceslimitarlo tena ms sentido aun, ya que eliminaba el coste de gestinasociado. As que en 2004 decid intentar implementar un sistema pulldesde sus principios bsicos. Tuve la oportunidad cuando un Gerente deMicrosoft contact conmigo y me pidi que le ayudase a gestionar encambio en su equipo de mantenimiento evolutivo de aplicaciones TIinternas. La primera implementacin estaba basada en el Sistema Pull deTeora de las Limitaciones conocido como Drum-Buffer-Rope (tambor-
inventario-cuerda). Fue un gran xito: el tiempo de ciclo bajo un 92%, elcaudal de salida (troughput) se increment en ms del triple y la
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
10/123
x
predecibilidad (cumplimiento de fechas) fue de un muy aceptable 98%.En 2005, Donald Reinertsen me convenci de implementar un sistematotalmente Kanban. Tuve la oportunidad en 2006, cuando asum ladireccin del Departamento de Ingeniera de Corbis en Seattle. En 2007comenc a reportar los resultados. La primera presentacin fue en elLean New Product Development Summit de Mayo de 2007 en Chicago.Continu con un Open Space en Agile 2007 en Washington DC enAgosto de ese ao. 25 personas asistieron. 3 de ellas eras de Yahoo! :Aaron Sanders, Jarl Scotland y Joe Arnold. Volvieron a sus hogares deCalifornia, India y el Reino Unido e implementaron Kanban con susequipos, que ya estaban luchando con Scrum. Tambin crearon un grupode discusin de Yahoo! que, en el momento de escribir estas lneas,cuenta con casi 800 miembros. Kanban estaba comenzando adiseminarse y los "early adopters" empezaban a hablar de sus
experiencias.
Ahora en 2009, la adopcin de Kanban est creciendo realmente y ms yms informes de campo estn apareciendo. Hemos aprendido mucho deKanban en los ltimos 5 aos y seguimos aprendiendo todos los das. Heconcentrado mi propio trabajo en hacer Kanban, escribir sobre Kanban,hablar sobre Kanban y pensar sobre Kanban para as poder entenderlomejor y explicrselo a otros. Me he abstenido deliberadamente decompararlo con otros mtodos giles existentes, aunque en 2008
invertimos algo de esfuerzo en explicar por qu Kanban deba serconsiderada como una aproximacin gil compatible.
He dejado a otros con mayor experiencia contestar preguntas como "Enqu se diferencian Kanban y Scrum?". Me alegra que Henrik Kniberg yMattias Skarin hayan surgido como lderes en este aspecto. Usted, eltrabajador del conocimiento en el da a da, necesita informacin para poder tomar decisiones ms informadas y poder progresar con sutrabajo. Henrik y Mattias estn solucionando sus necesidades de unaforma que yo nunca pude. Estoy particularmente impresionado con lasesuda comparacin de Henrik y su presentacin equilibrada, imparcialy basada en los hechos. Sus dibujos e ilustraciones son particularmenteperspicaces y muchas veces te ahorran tener que leer muchas pginas detexto. El informe de campo de Mattias es importante, ya que demuestraque Kanban es mucho ms que una teora y nos muestra mediante elejemplo cmo podra ser til para usted en su organizacin.
Espero que disfruten este texto de comparacin entre Kanban y Scrum yque les aporte una mayor visin de Agile en general y de Kanban y
Scrum en particular. Si desea aprender ms sobre Kanban, por favor,
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
11/123
INTRODUCCIN | xi
xi
visite el sitio Web de nuestra comunidad, la Limited WIP Society,http://www.limitedwipsociety.org/
David J. Anderson
Sequim, Washington, USA. 8 de Julio de 2009
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
12/123
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
13/123
IntroduccinNormalmente no escribimos libros. Preferimos pasar el tiempo metidosa fondo en las trincheras ayudando a los clientes a optimizar, corregir yrefactorizar su proceso de desarrollo y su organizacin. No obstante,hemos notado una clara tendencia ltimamente, y nos gustara compartir
algunas reflexiones sobre ella. Este sera un caso tpico: Jim: Por fin hemos conseguido implantar Scrum del
todo!
Fred: Y qu tal os va
Jim: Bueno, mucho mejor que lo que tenamosantes...
Fred: ...pero? Jim: ... pero claro, est el equipo de operacin y
mantenimiento.
Fred: s, Y?
Jim: Bueno, nos encanta todo lo de organizar por prioridades en una Pila de Producto, los equipos auto-organizados, el Scrum diario, las retrospectivas, etc....
Fred: Y cul es el problema?
Jim: Seguimos fracasando en nuestros Sprints
Fred: Por qu?
Jim: Porque nos resulta muy difcil comprometernos auna planificacin de 2 semanas. Las iteraciones no tienenmucho sentido para nosotros, simplemente nos ponemos
con lo ms urgente que tenemos cada da. Quizsdeberamos hacer iteraciones de una semana?
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
14/123
xiv
Fred: Os podrais comprometer al trabajo de unasemana? Se os permitira concentraros en eso y trabajar enpaz durante una semana?
Jim: En realidad no, tenemos asuntos que van
surgiendo en el da a da. Quizs si hiciramos sprints de unda
Fred: Vuestras tareas tardan menos de un da ensolucionarse?
Jim: No, a veces tardan varios das
Fred: As que los sprints de 1 da tampoco funcionaran. Habis considerado eliminar por completo los sprints?
Jim: Bueno, la verdad es que eso nos gustara. Perono va eso en contra de Scrum?
Fred: Scrum es solo una herramienta. T eliges cundoy cmo usarla. No seas su esclavo!
Jim: Qu deberamos hacer entonces?
Fred: Has odo hablar de Kanban?
Jim: Qu es eso? En qu se diferencia de Scrum?
Fred: Toma, lee este libro!
Jim: Pero a mi me gusta el resto de Scrum, tengo quecambiar ahora?
Fred: No! Puedes combinar ambas tcnicas
Jim: Qu? Cmo?
Fred: Slo sigue leyendo..
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
15/123
INTRODUCCIN | xv
xv
Si ests interesado en el desarrollo de software gil probablementehabrs odo hablar de Scrum, y puede que tambin hayas odo hablar deKanban. Una pregunta que cada vez nos hacen con ms frecuencia esY qu es Kanban, y en qu se diferencia de Scrum? Dnde secomplementan? Hay conflictos potenciales?
El propsito de este libro es aclarar la niebla, de forma que puedas
entender como Kanban y Scrum pueden ser tiles en tu entorno.
Haznos saber si lo hemos conseguido!
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
16/123
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
17/123
1
Parte I ComparacinEsta primer parte del libro es un intento de realizar una comparacin
prctica y objetiva de Scrum y Kanban. Es una versin algo actualizada
del artculo Kanban vs. Scrum de Abril de 2009. Este artculo se hizo
muy popular, as que decid convertirlo en un libro y le ped a mi colega
Mattias que lo aliase con un caso de estudio desde las trincheras de
uno de nuestros clientes. Cosa fina! Sintete libre de saltar
directamente a la Parte II si prefieres comenzar con el caso de estudio,
no me ofender. Bueno, quizs solo un poco.
/Henrik Kniberg
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
18/123
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
19/123
3
1Bueno pero, al fin y al cabo, qu sonScrum y Kanban?De acuerdo, tratemos de resumir Scrum y Kanban en menos de 100palabras cada uno.
Scrum en pocas palabras
Divide tu organizacin en equipos pequeos, interdisciplinarios yauto-organizados.
Divide el trabajo en una lista de entregables pequeos yconcretos. Ordena la lista por orden de prioridad y estima elesfuerzo relativo de cada elemento.
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
20/123
4 |KANBAN Y SCRUMOBTENIENDO LO MEJOR DE AMBOS
4
Divide el tiempo en iteraciones cortas de longitud fija(generalmente de 1 a 4 semanas), con cdigo potencialmenteentregable y demostrado despus de cada iteracin.
Optimiza el plan de entregas y actualiza las prioridades encolaboracin con el cliente, basada en los conocimientosadquiridos mediante la inspeccin del entregable despus decada iteracin.
Optimiza el proceso teniendo una retrospectiva despus decada iteracin.
As en lugar de un grupo numeroso pasando mucho tiempoconstruyendo algo grande, tenemos un equipo menor pasando untiempo ms corto construyendo algo menor. Pero integrando conregularidad para ver el conjunto.
138 palabras ... bastante cerca.
Para ms detalles, consulte "Scrum y XP desde las trincheras". El libroes de lectura gratuita online. Conozco al autor, es un buen tipo: o)
http://www.crisp.se/ScrumAndXpFromTheTrenches.html
Para obtener ms enlaces sobre Scrum echa un vistazo ahttp://www.crisp.se/scrum
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
21/123
BUENO PERO, AL FIN Y AL CABO QU SON SCRUM Y KANBAN? | 5
5
Kanban en pocas palabras
Visualiza el flujo de trabajo
o Divide el trabajo en bloques, escribe cadaelemento en una tarjeta y ponlo en el muro.
o Utiliza columnas con nombre para ilustrar dndeest cada elemento en el flujo de trabajo.
Limita el WIP (Work in Progress, trabajo en curso) -
asigna lmites concretos a cuntos elementos pueden estar enprogreso en cada estado del flujo de trabajo.
Mide el lead time (tiempo medio para completar unelemento, a veces llamado "tiempo de ciclo"), optimiza el proceso para que el lead time sea tan pequeo y predeciblecomo sea posible.
Se han agrupado enlaces tiles sobre Kanban en:
http://www.crisp.se/kanban
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
22/123
6
2Entonces, Cmo se relacionan Kanbany Scrum entre s?Scrum y Kanban son ambos herramientas de
proceso
Herramienta = cualquier cosa usada como medio para realizar una tareao propsito
Proceso = cmo trabajas.
Scrum y Kanban son herramientas de proceso que te ayudan a trabajarms eficazmente, en cierta medida, dicindote qu hacer. Java tambin
es una herramienta, te ofrece una forma ms sencilla de programar unacomputadora. Un cepillo de dientes tambin es una herramienta, teayuda a llegar a tus dientes para que puedas limpiarlos.
Compara herramientas para entender,no para juzgar
Cuchillo o tenedor - Qu herramienta es mejor?
Es una pregunta bien expresada? Porque la respuesta depende del contexto.
Para comer albndigas el tenedor es probablemente mejor. Para cortar las
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
23/123
ENTONCES CMO SE RELACIONAN SCRUM Y KANBAN ENTRE S? | 7
7
setas el cuchillo es probablemente mejor. Para golpear la mesa cualquiera
de los dos servir. Para comer un filete probablemente querrs utilizar los
dos de manera conjunta. Para comer arroz... Bueno... algunos prefieren el
tenedor mientras que otros prefieren los palillos.
As, cuando comparamos herramientas debemos ser cuidadosos. Comparar
para comprender, no para juzgar..
Ninguna herramienta es completa, ningunaherramienta es perfecta
Como cualquier herramienta, Scrum y Kanban no son ni perfectas nicompletas. No te dicen todo lo que tienes que hacer, solo proporcionanciertas restricciones y directrices. Por ejemplo, Scrum te obliga a tener
iteraciones de duracin fija y equipos interdisciplinarios, y Kanban teobliga a usar tableros visibles y a limitar el tamao de tus colas.
Curiosamente, el valor de una herramienta es que limita tus opciones. Una
herramienta de proceso que te permite hacer cualquier cosa no es muy til.
Podramos llamar a ese proceso "Hacer lo que sea" o qu tal "Hacer lo
correcto". El proceso "Hacer lo correcto" garantiza que funciona, es una
bala de plata! Porque si no funciona, es obvio que no estabas siguiendo el
proceso :o)
Usar las herramientas adecuadas te ayudar a triunfar, pero no garantizar el
xito. Es fcil confundir el xito/fracaso del proyecto, con el xito / fracaso
de la herramienta.
Un proyecto puede triunfar debido a una gran herramienta.
Un proyecto puede triunfar a pesar de una psima herramienta.
Un proyecto puede fallar debido a una psima herramienta.
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
24/123
8 |KANBAN Y SCRUMOBTENIENDO LO MEJOR DE AMBOS
8
Un proyecto puede fallar a pesar de una gran herramienta.
Scrum es ms prescriptivo que KanbanPodemos comparar herramientas viendo cuntas reglas proporcionan.Prescriptivo significa "ms reglas a seguir" y adaptativo significa"menos reglas a seguir". 100% prescriptivo significa que no te deja usarel cerebro, hay una regla para todo. 100% adaptativos significan Haz LoQue Sea, no hay ninguna regla o restriccin. Como puedes ver, los dosextremos de la escala son de alguna manera ridculos.
Los mtodos giles se denominan a veces los mtodos ligeros, enconcreto, porque son menos restrictivos que los mtodos tradicionales.De hecho, el primer principio del Manifiesto gil es "Individuos einteracciones sobre procesos y herramientas".
Scrum y Kanban son muy adaptables, pero en trminos relativos Scrumes ms restrictivo que Kanban. Scrum te da ms limitaciones, y as dejamenos opciones abiertas. Por ejemplo Scrum prescribe el uso deiteraciones de duracin fija, Kanban no.
Vamos a comparar algunas herramientas de proceso ms en la escalarestrictivo vs adaptativo:
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
25/123
ENTONCES CMO SE RELACIONAN SCRUM Y KANBAN ENTRE S? | 9
9
RUP es muy restrictivo- tiene ms de 30 perfiles, ms de 20 actividades,y ms de 70 artefactos, una cantidad enorme de cosas a aprender.Realmente no se espera que uses todos los que hay, si bien, se suponeque seleccionars un subconjunto adecuado para tu proyecto.
Lamentablemente, esto parece ser difcil en la prctica. "Hmmmm ...Necesitaremos artefactos para la Configuracin de auditora de losresultados?Necesitaremos un perfilde gerente de Control de cambios?No estoy seguro, as que mejor los mantenemos por si acaso ". Estopuede ser una de las razones por lasque las implementaciones de RUPsuelen ser bastante pesadas en comparacin con los mtodos gilescomo Scrum y XP.
XP (eXtreme Programming) es ms restrictivo en comparacin conScrum. Se incluye la mayora de Scrum + un montn de buenas prcticas especficas de ingeniera, tales como desarrollo dirigido porpruebas y la programacin en parejas.
Scrum es menos restrictivo que XP, ya que no establece ningunaprctica especfica de ingeniera. Sin embrago, Scrum es ms restrictivo
que Kanban ya que prescribe cosas como iteraciones y equiposinterdisciplinarios.
Una de las principales diferencias entre Scrum y RUP es que en RUPtienes demasiado, y se supone que quitars aquello que no necesites. EnScrum tienes demasiado poco, y se supone que aadirs el material quefalta.
Kanban deja casi todo abierto. Las nicas normas son Visualiza tu Flujode trabajo y Limita tu WIP (Work In Progress, Trabajo en curso). A pocos centmetros de Haz lo que Sea, pero sigue siendosorprendentemente poderoso.
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
26/123
10 |KANBAN Y SCRUMOBTENIENDO LO MEJOR DE AMBOS
10
No te limites a una nica herramienta!Mezcla y combina las herramientas que necesites! Me cuesta imaginar un
exitoso equipo Scrum que no incluye la mayora de los elementos de XP,
por ejemplo. Muchos equipos Kanban hacen reuniones diarias (una prctica
de Scrum). Algunos equipos Scrum escriben algunos de sus elementos de la
pila como Casos de Uso (una prctica de RUP) o limitan el tamao de las
colas (una prctica de Kanban). Usa lo que sea que funcione para ti.
Musashi lo dijo muy bien (famoso Samurai del siglo 17, famoso por sutcnica de lucha de la doble espada)
Sin embargo, presta atencin a las limitaciones de cada herramienta. Porejemplo, si utilizas Scrum y decides dejar de utilizar iteraciones de duracin
fija (o cualquier otro aspecto central de Scrum), luego no digas que estsutilizando Scrum. Scrum es bastante minimalista en s mismo, si quitascosas y todava lo llamas Scrum entonces la palabra carecer de sentido yconfundir. Llmalo algo as como "inspirado en Scrum" o "un subconjuntode Scrum", o algo as como "Scrumish" :o)
- Miyamoto Musashi
No te cias a una nica arma o auna nica escuela de lucha.
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
27/123
ENTONCES CMO SE RELACIONAN SCRUM Y KANBAN ENTRE S? | 11
11
3Scrum prescribe rolesScrum prescribe 3 roles: dueo de producto (establece la visin delproducto y las prioridades), equipo (implementa el producto) y ScrumMaster (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 tener un papel de dueo deproducto en Kanban! Slo significa que no tienes que. En ambos, Scrumy Kanban, eres libre de aadir los roles adicionales que necesites.
Ten cuidado sin embargo al aadir roles, asegrate de que los roles
adicionales realmente aaden valor y no entran en conflicto con otroselementos del proceso. Ests seguro de que necesitas el rol de jefe deproyectos? En un proyecto grande puede ser una gran idea, tal vez es eltipo que ayuda a mltiples equipos y dueos de producto asincronizarse. En un proyecto pequeo puede ser un desperdicio, o peor,puede dar lugar a la sub-optimizacin y la microgestin.
La mentalidad general, tanto en Scrum como en Kanban es "menos esms". As que en caso de duda, comienza con menos.
En el resto del artculo voy a utilizar el trmino "dueo de producto" para representar a quien establece las prioridades de un equipo,independientemente del mtodo utilizado.
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
28/123
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
29/123
13
4Scrum prescribe iteraciones de tiempofijoScrum se basa en iteraciones de tiempo fijo. Puedes elegir la duracin dela iteracin, pero la idea general es mantener la misma longitud dela iteracin durante un perodo de tiempo, determinando as una
cadencia.
Inicio de la iteracin: Se crea un plan de iteracin, es decir, elequipo saca un nmero especfico de elementos de la pila deproducto, en base a las prioridades del dueo de producto y a cuntopiensa el equipo que puede terminar en una iteracin.
Durante la iteracin: El equipo se centra en completar loselementos a los que se comprometi. Se fija el alcance de laiteracin.
Final de la iteracin: El equipo muestra el cdigo funcionando alas partes interesadas, idealmente este cdigo debe ser potencialmente entregable (es decir, probado y listo para llevar).Entonces, el equipo hace una retrospectiva para discutir y mejorarsu proceso.
As que una iteracin de Scrum es una nica cadencia de tiempo fijo quecombina tres actividades distintas: la planificacin, la mejora deprocesos, y (idealmente) la entrega.
En Kanban no se prescriben iteraciones de tiempo fijo. Puedes elegir elmomento de hacer la planificacin, la mejora de procesos, y la entrega.Puedes elegir hacer estas actividades de manera regular ( "la entregatodos los lunes") o bajo demanda ( "la entrega cada vez que tengamosalgo til para entregar").
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
30/123
14 |KANBAN Y SCRUMOBTENIENDO LO MEJOR DE AMBOS
14
Equipo #1 (cadencia simple)
"Nosotros hacemos iteraciones Scrum"
Equipo # 2 (tres cadencias)
"Tenemos tres cadencias diferentes. Cada semana entregamos lo que
est listo para su entrega. Cada segunda semana tenemos una reunin de planificacin, actualizacin de nuestras prioridades y los planes deentrega. Cada cuarta semana tenemos una reunin retrospectiva paramodificar y mejorar nuestro proceso".
Equipo # 3 (normalmente dirigido por eventos)
"Lanzamos una reunin de planificacin cada vez que comenzamos aquedarnos sin cosas que hacer. Lanzamos una entrega siempre que hayun MMF (Minimum Marketable Feature Set, conjunto mnimo de
caractersticas comercializables) listo para entregar. Lanzamos uncrculo de calidad espontneo siempre que nos topamos con un mismoproblema por segunda vez. Adems hacemos una retrospectiva ms enprofundidad cada cuatro semanas. "
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
31/123
15
5Kanban limita el WIP por estado en flujode trabajo, Scrum limita el WIP poriteracinEn Scrum, la pila de sprint muestra qu tareas han de ser ejecutadasdurante la iteracin actual (= "sprint" en terminologa Scrum). Serepresenta comnmente usando tarjetas en la pared, llamada una pizarrade Scrum o pizarra de tareas.
Entonces, cul es la diferencia entre una pizarra de Scrum y una pizarrade Kanban? Vamos a empezar con un proyecto simple y comparar lasdos:
En ambos casos estamos siguiendo un grupo de elementos a medida queavanzan a travs de un flujo de trabajo. Hemos seleccionado tresestados: pendiente, en curso, y terminado. Puedes elegir los estados quequieras - algunos equipos aaden estados tales como integrar, probar,liberar, etc. No te olvides del principio de "menos es ms".
Entonces, cul es la diferencia entre estas dos pizarras de ejemplo? S,el pequeo 2 en la columna central en la pizarra Kanban. Eso es todo.Ese 2 significa que "no puede haber ms de 2 elementos en esta columnaen un momento dado".
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
32/123
16 |KANBAN Y SCRUMOBTENIENDO LO MEJOR DE AMBOS
16
En Scrum no hay ninguna regla que impida que el equipo ponga todoslos 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.En este caso, el lmite implcito por columna es de 4, ya que slo hay 4
elementos en la pizarra. As que Scrum limita el WIP indirectamente,mientras que Kanban limita el WIP directamente.
La mayora de los equipos de Scrum aprenden finalmente que es unamala idea tener demasiados elementos en curso, y desarrollan unacultura de intentar tener los elementos actuales terminados antes decomenzar con nuevos elementos. Algunos incluso deciden limitarexplcitamente el nmero de elementos permitidos en la columna de encurso y, a continuacin - TADAAA! - la pizarra de Scrum se ha
convertido en una pizarra de Kanban!As que tanto Scrum como Kanban limitan el WIP, pero de diferentesmaneras. Los equipos de Scrum suelen medir la velocidad - cuntoselementos (o unidades correspondientes, tales como "puntos dehistoria") se hacen por iteracin. Una vez que el equipo sabe suvelocidad, sta se convierte en su lmite de WIP (o al menos unadirectriz). Un equipo que tiene una velocidad media de 10 no sueletomar ms de 10 elementos (o puntos de historia) para un sprint.
De forma que en Scrum el WIP se limita por unidad de tiempo.
En Kanban el WIP se limita por el estado del flujo de trabajo.
En el ejemplo anterior de Kanban, como mucho puede haber 2elementos en el estado de flujo de trabajo "en curso" en un momentodado, independientemente de las longitudes de cadencia. Tienes queelegir qu lmite aplicar a qu estados del flujo de trabajo. Pero la ideageneral es limitar el WIP de todos los estados del flujo de trabajo,
empezando por "lo ms pronto posible" y terminando "lo ms tarde posible" a lo largo de la cadena de valor. As, en el ejemplo anteriordeberamos considerar aadir un lmite al WIP tambin en el estado"pendiente" (o la que quiera que sea tu cola de entrada). Una vez quetenemos los lmites de WIP en su lugar, podemos empezar a medir ypredecir el tiempo de entrega, es decir, el tiempo medio de un elemento para realizar todo el camino a travs de la pizarra. Tener tiempos deentrega predecibles nos permite comprometer los SLA (acuerdos denivel de servicio, en ingls service-level agreements) y hacer planes de
entrega realistas.
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
33/123
KANBAN LIMITA WIP POR ESTADO, SCRUM LIMITA WIP POR ITERACIN | 17
17
Si los tamaos de los elementos varan drsticamente entonces podrasconsiderar lmites de WIP definidos en trminos de puntos de historia ensu lugar, o cualquiera que sea la unidad de medida que utilices. Algunosequipos invierten sus esfuerzos en la descomposicin de elementos de
aproximadamente el mismo tamao para evitar este tipo deconsideraciones y reducir el tiempo empleado en la estimacin de lascosas (podras incluso considerar que la estimacin es un desperdicio detiempo). Es ms fcil para crear un buen sistema de flujo si los artculosson ms o menos de igual tamao.
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
34/123
18
6Ambos son empricosImagina que hubiese mandos en estos contadores y t pudiesesconfigurar tu proceso simplemente girando los mandos. Quiero altacapacidad, bajo lead time, alta calidad y alta predecibilidad. Entoncesgirar los mandos a 10, 1, 10 y 10 respectivamente.
No sera maravilloso? Por desgracia no existen estos controles directos.Al menos no que yo sepa. Hacdmelo saber si vosotros los encontris.
En su lugar contamos con ese puado de controles indirectos.
Scrum y Kanban son ambos empricos en el sentido de que se esperaque experimentes con el proceso y lo adaptes a tu entorno. De hecho,tienes que experimentar. Ni Scrum ni Kanban proporcionan todas lasrespuestas simplemente nos proporcionan una serie de reglas ylimitaciones a la hora de guiar la mejora de nuestros procesos.
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
35/123
AMBOS SON EMPRICOS | 19
19
Scrum dice que debemos tener equipos multidisciplinares.Entonces, Quin debe estar en cada equipo? No lo s,experimenta.
Scrum dice que el equipo selecciona cuanto trabajo incluir en
un sprint. Entonces, Cunto deben incluir? No lo s,experimenta. Kanban dice que debemos limitar en trabajo en curso. Entonces,
Cul debe ser ese lmite? No lo s, experimenta.
Como he mencionado con anterioridad, Kanban impone menoslimitaciones que Scrum. Esto significa menos parmetros sobre los que preocuparse, pero ms mandos que girar. Esto puede ser tanto unaventaja como una desventaja dependiendo del contexto. Cuando abres el
cuadro de dilogo de configuracin de una herramienta de software,prefieres tener 3 o 100 opciones que ajustar? Probablemente unacantidad entre ambas. Depende de cunto necesites ajustar el software atus necesidades y cmo de bien conozcas la herramienta.
Digamos que reducimos el lmite de trabajo en curso, basndonos en lahiptesis de que esto va a mejorar nuestro proceso. Observamos cmootros factores como la capacidad, el lead time, la calidad, y la predecibilidad evolucionan. Sacamos conclusiones de los resultados yajustamos algunas cosas ms, mejorando continuamente nuestroproceso.Hay diferentes trminos para referirse a este proceso. Kaizen (mejoracontinua en terminologa Lean), Inspeccin y Adaptacin (enterminologa Scrum), control emprico de procesos o, por qu no, ElMtodo Cientfico.
El elemento ms crtico de este proceso es el ciclo de retroalimentacin,el feedback. Cambia algo => Observa cmo funciona => Aprende deello => Cambia algo de nuevo. En general, lo que buscamos es obtener
feedback en ciclos lo ms cortos posibles, de manera que podamosadaptar nuestro proceso rpidamente.
En Scrum el ciclo bsico de obtencin defeedbackes el sprint. Existenotros, sin embargo. Especialmente si combinas Scrum con XP (eXtremeprogramming):
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
36/123
20 |KANBAN Y SCRUMOBTENIENDO LO MEJOR DE AMBOS
20
Cuando se realizan correctamente, Scrum + XP nos proporcionan unbuen puado de ciclos defeedbackextremadamente valiosos.
El ciclo de feedback ms interno, la programacin en parejas,proporciona retroalimentacin en unos pocos segundos. Los errores sondetectados y corregidos en segundos desde que ocurren (He!, no sesupone que esa variable debe valer 3?). Este es el ciclo defeedbackdeEstamos construyendo bien las cosas?.
El ciclo defeedbackms externo, el sprint, nos proporciona un ciclo deretroalimentacin de unas cuantas semanas. Este el ciclo defeedbackdeEstamos construyendo las cosas adecuadas?
Y en Kanban, que? Bueno, en primer lugar, puedes (y seguramentedebes) poner todos los anteriores ciclos de feedback en tus proyectosuses o no Kanban. Lo que Kanban te proporciona es una serie demtricas en tiempo real muy tiles.
Lead time medio: Actualizado cada vez que un elementoalcanza el nivel de hecho (o como quiera que llames a tucolumna ms a la derecha).
Cuellos de Botella: Un sntoma tpico es que la columna X estabarrotada de elementos mientras que la columna X+1 estvaca. Busca burbujas de aire en tu panel.
Lo mejor de las mtricas en tiempo real es que t puedes elegir lalongitud de tu ciclo de feedback, basndote en con qu frecuenciaquieres analizar estas mtricas e introducir cambios. Un ciclo demasiadolargo de retroalimentacin significa que la mejora de tu proceso serlenta. Uno demasiado corto significa que tu proceso no podra no tenertiempo para estabilizarse entre cambios, lo que puede producir
desperdicio de esfuerzos.
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
37/123
AMBOS SON EMPRICOS | 21
21
De hecho, la longitud del ciclo de retroalimentacin en s misma es unode los aspectos con los que puedes experimentar en una especie demeta-ciclo delfeedback. OK, es suficiente por ahora.
Ejemplo: Experimentando con los lmites para eltrabajo en curso en Kanban
Uno de los tpicos puntos de ajuste de Kanban es el lmite de trabajoen curso. Cmo sabemos si lo estamos estableciendo correctamente?
Digamos que tenemos un equipo de 4 personas y que decidimoscomenzar con un lmite para el trabajo en curso de 1.
En cuanto comencemos a trabajar en un elemento, no podremoscomenzar ninguno nuevo hasta que el primer elemento est Hecho. Enconsecuencia concluiremos el primer elemento rpidamente.
Excelente!, pero resulta que habitualmente no es factible que 4personas trabajen en el mismo elemento (al menos en el contexto de este
ejemplo), entonces tenemos gente mirando. Si esto solo ocurre de tantoen cuanto no ser un problema, pero si esta situacin se da conregularidad, la consecuencia es que el lead time medio se incrementar.Bsicamente, un trabajo en curso de 1 significa que los elementospasaran por el estado En curso realmente rpido una vez llegan a estasituacin, pero permanecern en estado Pendiente ms tiempo delnecesario, de manera que el lead time a lo largo del ciclo de trabajocompleto ser innecesariamente alto.
Entonces si un trabajo en curso de 1 es demasiado bajo, por qu noincrementarlo a 8?
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
38/123
22 |KANBAN Y SCRUMOBTENIENDO LO MEJOR DE AMBOS
22
Esto funciona mejor durante algn tiempo. Hemos descubierto que, de
media, trabajando en parejas realizamos el trabajo ms rpido. De estamanera, en un equipo de cuatro personas, habitualmente, tendremos 2elementos en curso en un instante dado. El trabajo en curso de 8 es soloun lmite superior, luego tener menos elementos en progreso es correcto!
Imaginemos ahora, sin embargo que encontramos un problema con elservidor de integracin, de tal manera que no podemos completartotalmente ningn elemento (nuestra definicin de Hecho incluyeintegracin). Estas cosas pasan, no?
Como no podemos completar los elementos D o E, comenzamos atrabajar en el elemento F. No podemos integrar ninguno de estostampoco, luego cogeremos un nuevo elemento G. Tras un tiempo
alcanzaremos nuestro lmite Kanban 8 elementos En curso.
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
39/123
AMBOS SON EMPRICOS | 23
23
En este punto, ya no podemos coger ningn elemento ms. He, mejor
arreglemos ese maldito servidor de integracin! El lmite para el trabajoen curso nos impulsa a reaccionar y corregir el cuello de botella en lugarde seguir acumulando un montn de trabajo sin terminar.
Esto est bien. Pero si el lmite de trabajo en curso hubiese sido 4,habramos reaccionado mucho antes, de este modo tendramos un mejorlead time medio. Medimos nuestro lead time medio y continuamenteoptimizamos nuestro lmite de trabajo en curso para optimizar el leadtime.
Tras un periodo de tiempo podramos encontrar que los elementos seacumulan en la columna Pendiente. Quizs es el momento de aadirun lmite de trabajo en curso aqu tambin.
En cualquier caso, por qu necesitamos una columna Pendiente?.Bueno, si el cliente estuviese siempre disponible para decir al equipo
que hacer cada vez que preguntase, la columna Pendiente, no seranecesaria. Pero en el caso de que el cliente est a veces no disponible, la
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
40/123
24 |KANBAN Y SCRUMOBTENIENDO LO MEJOR DE AMBOS
24
columna Pendiente da al equipo un pequeo buffer del que cogertrabajo a medio plazo.
Experimenta o, como los Scrumistas dicen, Inspeccin y Adaptacin.
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
41/123
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
42/123
26 |KANBAN Y SCRUMOBTENIENDO LO MEJOR DE AMBOS
26
La respuesta de Kanban podra decir Aade con libertad E a la columnaPendiente pero hay un lmite de 2 para esta columna, en consecuenciatendrs que quitar C o D. Ahora estamos trabajando en A y B, pero tan pronto como tengamos capacidad disponible cogeremos el primer
elemento de la columna Pendiente.
El tiempo de respuesta (cunto tiempo pasa hasta que respondemos acambios de prioridades) de un equipo Kanban es tan largo como eltiempo que trascurre hasta que tenemos capacidad disponible, siguiendoel principio general de un elemento sale = un elemento entra (segnlos lmites para el trabajo en curso).
En Scrum, el tiempo de respuesta medio es la mitad de la duracin del
Sprint.En Scrum, el dueo del producto no puede tocar el tablero Scrum unavez el equipo se ha comprometido a completar un conjunto de elementosen la iteracin. En Kanban t tienes que establecer tu propias reglassobre quin puede cambiar qu en el tablero. Tpicamente el dueo del producto controla una columna del tipo Pendiente, Listo,Propuesto, Pila de Producto en la parte ms a la izquierda en elpanel, en la que l puede hacer todos los cambios que desee.
Sin embargo, estas dos aproximaciones no son excluyentes entre s. Unequipo Scrum podra decidir permitir al dueo del producto cambiarprioridades a mitad de sprint. Y un equipo Kanbanpodra decidir aadirrestricciones sobre cuando las prioridades pueden ser cambiadas. Unequipo Kanban puede incluso decidir utilizar iteraciones limitadas en eltiempo y con compromisos prefijados, exactamente igual que Scrum.
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
43/123
27
8El tablero sprint se limpia entreiteracionesUn tablero Scrum suele tener un aspecto similar a este durante lasdiferentes etapas de un sprint.
Cuando se finaliza un sprint, se limpia el tablero - todos los elementosson eliminados. Se inicia un nuevo sprint y tras la reunin deplanificacin del sprint tendremos un nuevo tablero Scrum, con nuevos
elementos en la primera columna. Tcnicamente esto es una prdida detiempo, pero para equipos Scrum experimentados no suele llevar mucho,y el proceso de limpiar el tablero puede dar una grata sensacin de logroy cierre. Es algo as como lavar los platos tras la cena - hacerlo resultapesado pero sienta bien al finalizar.
En Kanban, el tablero normalmente es algo persistente - no se necesitalimpiarlo y volver a empezar.
Scrum: Primer da de sprint Scrum: Mitad de sprint Scrum: ltimo da de sprint
Kanban: Cualquier da
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
44/123
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
45/123
29
9Scrum prescribe equipos multi-funcionalesUn tablero Scrum es propiedad de solamente un equipo Scrum. Unequipo Scrum es multi-funcional, contiene todos los conocimientosnecesarios para completar todos los elementos de la iteracin. Un
tablero Scrum suele ser visible para cualquiera que est interesado, peroslo el equipo Scrum al que pertenece puede editarlo - es su herramientapara administrar su compromiso para esta iteracin.
En Kanban, los equipos multi-funcionales son opcionales, y un tablerono necesita estar en manos de un equipo especfico. Un tablero estrelacionado con un flujo de trabajo, no necesariamente con un equipo.
Tablero Scrum
EquipodeScrum
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
46/123
30 |KANBAN Y SCRUMOBTENIENDO LO MEJOR DE AMBOS
30
He aqu dos ejemplos:
Ejemplo 1: Todo el tablero est al servicio de un equipo multi-funcional. Justo como en Scrum.
Ejemplo 2: El dueo de producto establece las prioridades en lacolumna 1. Un equipo de desarrollo multi-funcional realiza el desarrollo(columna 2) y prueba (columna 3). La puesta en produccin (columna 4)
es realizada por un equipo de especialistas. Existe un ligerosolapamiento de competencias, de modo que si el equipo de puesta en produccin se convierte en un cuello de botella uno de losdesarrolladores les ayudar.As, en Kanban es necesario establecer algunas reglas bsicas para quinusa el tablero y cmo, luego se experimenta con las normas paraoptimizar el flujo.
Tablero Kanban ejemplo Tablero Kanban ejemplo 2
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
47/123
31
10Los elementos de la pila de productodeben caber en un sprintAmbos Scrum y Kanban se basan en el desarrollo incremental, porejemplo, descomponer el trabajo en trozos ms pequeos.
Un equipo Scrum slo se comprometer con los elementos que creenque pueden terminar en una iteracin (basado en la definicin de"Hecho"). Si un elemento es demasiado grande para caber en un sprint,el equipo y el propietario del producto intentarn encontrar la manera de partirlo en pedazos ms pequeos hasta que se pueda abordar en unsprint. Si los elementos tienden a ser grandes, las iteraciones debern serms largas (aunque generalmente no ms de 4 semanas).
Los equipos de Kanban tratan de minimizar el tiempo de entrega y elnivel de flujo, por lo que, indirectamente, se crea un incentivo paradescomponer los elementos en pedazos relativamente pequeos. Pero nohay ninguna norma explcita que indique que los elementos deben ser losuficientemente pequeos como para caber en un intervalo de tiempoespecfico. En el mismo tablero podra haber un elemento que necesitaun mes para terminarse y otro elemento que necesita un da.
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
48/123
32 |KANBAN Y SCRUMOBTENIENDO LO MEJOR DE AMBOS
32
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
49/123
33
11Scrum prescribela estimacin y lavelocidadEn Scrum, los equipos tienen que estimar el tamao relativo (= cantidadde trabajo) de cada elemento al que se comprometen. Sumando eltamao de cada elemento completado al final de cada sprint, obtenemos
la velocidad. La velocidad es una medida de la capacidad - la cantidadde cosas que podemos ofrecer por Sprint. He aqu un ejemplo de unequipo con una velocidad media de 8.
Saber que la velocidad media es de 8 es bueno, porque entoncespodemos hacer predicciones realistas sobre los elementos que se puedencompletar en los prximos sprints, y por lo tanto hacer planes de entregarealistas.
En Kanban, no se prescribe la estimacin. As que si necesitas
comprometerte necesitas decidir la forma de garantizar la previsibilidad.
Algunos equipos optan por hacer estimaciones y medir la velocidadcomo en Scrum. Otros equipos eligen omitir la estimacin, pero tratande descomponer cada elemento en partes de aproximadamente el mismotamao -entonces pueden medir la velocidad simplemente en funcin decuntos elementos se completan por unidad de tiempo (por ejemplo, porsemana).
Algunos equipos agrupan los elementos en MMF's (caractersticasmnimas de comercializacin) y miden el tiempo de entrega promediopor MMF, y lo usan para establecer SLA (acuerdos de nivel de servicio,
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
50/123
34 |KANBAN Y SCRUMOBTENIENDO LO MEJOR DE AMBOS
34
en ingls service-level agreements) - por ejemplo, "cuando noscomprometemos con un MMF siempre ser entregado en 15 das ".
Hay todo tipo de tcnicas interesantes para el estilo de planificacin de
entregas y gestin de compromisos de Kanban- pero no se prescribeninguna tcnica especfica, as que adelante, googlea y prueba diferentestcnicas hasta que encuentres una que se adapte a su contexto.Probablemente veremos algunas "mejores prcticas" emerger con eltiempo.
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
51/123
35
12Ambos permiten trabajar en mltiplesproductos simultneamenteEn Scrum, la Pila de Producto es un nombre un tanto desacertado puesimplica que todos los tems deben pertenecer a un mismo producto.Aqu vemos dos productos, uno verde y el otro amarillo, cada uno con
su respectiva pila y su respectivo equipo:
Que pasa si tenemos un slo equipo para varios productos? Bien, pensemos en la Pila de Producto ms bien como una Pila de Equipo.Lista las prioridades para las siguientes iteraciones del equipo (oconjunto de equipos) en particular. De esta forma, si un equipo mantiene
ms de un producto, debe fusionar ambos productos en una sola lista.Esto nos obliga a priorizar entre productos, lo cual puede resultar til enalgunos casos. Hay varias formas de hacer esto en la prctica:
Una estrategia sera hacer que el equipo se enfoque en un slo productodurante el sprint:
ProductoVerde
ProductoAmarillo
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
52/123
36 |KANBAN Y SCRUMOBTENIENDO LO MEJOR DE AMBOS
36
Otra estrategia sera hacer que el equipo trabaje en la funcionalidad deambos productos cada sprint:
Es lo mismo en el caso de Kanban. Podemos tener varios productosfluyendo por el mismo tablero. Tal vez podemos distinguirlos utilizandotarjetas de diferentes colores:
... o mediante distintas pistas o calles (swinlanes) :
Producto Verde:
Producto Amarillo:
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
53/123
37
13Ambos son Lean y gilesNo voy a revisar aqu el Pensamiento 'Lean', ni el Manifiesto gil. Perose puede generalizar que tanto Scrum como Kanban estn bien alineadoscon los valores y principios de stos.
Por ejemplo:
Tanto Scrum como Kanban son sistemas de planificacin tipo"Pull", principio de gestin de inventario 'Just In Time' (JIT) propiode Lean. Esto significa que el equipo elige cundo y cunto trabajoacometer. Ellos (los componentes del equipo) "tiran" del trabajocuando estn listos, en contraposicin a que desde el exterior se"empuje" al equipo a hacerlo. Al igual que una impresora tira de lasiguiente pgina solo cuando esta lista para imprimir en ella (aunquetenga hojas de papel en la bandeja).
Scrum y Kanban se basan en procesos de optimizacin continuosy empricos, que se corresponden con el principio Kaizen de Lean.
Scrum y Kanban dan ms importancia a la respuesta al cambioque al seguimiento de un plan (aunque Kanban permite,tpicamente, una respuesta ms rpida que Scrum). Uno de loscuatro principios del manifiesto gil.
...y mas.Desde un determinado punto de vista, Scrum se puede ver como no-tan-lean, ya que contempla agrupar tareas por lotes dentro de iteraciones detiempo prefijado. Pero eso depende de la longitud de tu iteracin, ytambin de con qu se compare. En un proceso ms tradicional, en elque quizs se integren versiones unas 2-4 veces al ao, un equipo Scrumproduciendo cdigo entregable cada 2 semanas se puede considerar muyLean.
Por consiguiente, si haces iteraciones cada vez ms cortas,esencialmente te ests aproximando a Kanban. Una vez que se empieza
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
54/123
38 |KANBAN Y SCRUMOBTENIENDO LO MEJOR DE AMBOS
38
a hablar de hacer durar la iteracin menos de una semana, se deberaconsiderar abandonar definitivamente las iteraciones a tiempo cerrado.
Ya lo he dicho antes y lo seguir diciendo: Experimenta hasta queencuentres algo que te funcione! y entonces contina experimentando.
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
55/123
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
56/123
40 |KANBAN Y SCRUMOBTENIENDO LO MEJOR DE AMBOS
40
Siempre toma las tareas en rojo, si las hay.
En Scrum, la pila de producto tambin se puede usar al estilo Kanban.
Podemos limitar su tamao y crear las reglas de decisin sobre cmo sedebera priorizar.
En Scrum se establecen reuniones diarias
Un equipo Scrum tiene una reunin corta (de aproximadamente 15minutos) cada da, a la misma hora y en el mismo lugar. El objeto deestas reuniones es compartir informacin sobre lo que est pasando,
planificar el da de trabajo actual e identificar cualquier problemasignificativo. El trmino que se emplea a veces en ingls, 'daily standup',refleja el hecho de que normalmente se celebra de pie (para que seabreve y mantener un nivel alto de energa).
Las reuniones diarias no se utilizan en Kanban, pero la mayora de losequipos Kanban parece que lo hacen de todos modos. Es una grantcnica, con independencia del proceso que utilices.
En Scrum, este formato de reunin est muy orientado a la persona.Cada miembro del equipo va haciendo su reporte uno a uno. Muchosequipos Kanban utilizan un formato ms orientado al panel, poniendo elfoco en los cuellos de botella y otros problemas visibles. Esta ltimaaproximacin es ms escalable. Si tienes 4 equipos compartiendo elmismo panel y haciendo sus reuniones diarias juntas, puede que no seanecesario tener que escuchar hablar a cada uno en tanto y en cuanto nosenfoquemos en las partes que son cuellos de botella del panel.
En Scrum se usan diagramas de Burndown
Un grfico burndown representa,diariamente, la cantidad detrabajo restante en la iteracinactual.
La unidad del eje-Y es la mismaque la utilizada en las tareas delsprint. Tpicamente, horas o das
(si el equipo convierte la pila entareas) o puntos de historia (si el
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
57/123
DIFERENCIAS MENORES | 41
41
equipo no lo hace). Existen muchas variaciones de esto.
En Scrum, los grficos burndown se usan como herramienta primordialpara el seguimiento del progreso de una iteracin.
Algunos equipos tambin utilizan grficos burndown de versin quesigue el mismo formato pero a nivel de versin - tpicamente muestrancuantos puntos de historia quedan pendientes en la pila despus de cadasprint.
El principal propsito de un grfico Burndown es encontrar, fcilmentey tan pronto como sea posible, si nos encontramos avanzados oretrasados respecto a planificacin para poder adaptarnos.
En Kanban, no se prescriben grficos burndown. De hecho, no existeningn tipo particular de grfico. Pero, desde luego que se permiteutilizar cualquier tipo de grfico que se quiera (incluyendo losburndowns).
A continuacin se muestra un ejemplo de Diagrama de FlujoAcumulativo. Este tipo de grficos representan finamente la suavidaddel flujo y cmo el WIP afecta a tu plazo de entrega.
La flecha horizontal nos muestra que las tareas aadidas a la pila el da 4
costaron una media de 6 das en llegar a produccin. Aproximadamentela mitad de ese tiempo fueron Test. Podemos ver que si se limitramos
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
58/123
42 |KANBAN Y SCRUMOBTENIENDO LO MEJOR DE AMBOS
42
el WIP en Test y Pila, reduciramos significativamente el plazo deentrega total.
La pendiente del rea azul-oscura nos muestra la velocidad (por
ejemplo, nmero de tareas desarrolladas al da). Con el tiempo podemosver como velocidades mayores reducen el plazo de entrega, mientrasque un mayor WIP lo incrementa.
La mayora de las organizaciones quieren tener realizado el trabajo msrpido (= reducir el plazo de entrega). Desafortunadamente muchas caenen la trampa de asumir que esto significa contratar ms personas otrabajar horas extras. Normalmente la forma ms efectiva de hacer el
trabajo ms rpidamente es suavizar el flujo y limitar el trabajo a lacapacidad. No aadir ms gente o trabajar ms duro. Este tipo dediagrama muestra por qu. Y de este modo se incrementa laprobabilidad de que el equipo y la gerencia colaboren de forma efectiva.
Esto se ve de forma an ms clara si distinguimos entre estados 'a cola'(como por ejemplo "esperando para test") y estados de 'trabajo' (como por ejemplo "Testeando"). Queremos, minimizar de forma absoluta elnmero de actividades esperando 'a cola'. Y el Diagrama de Flujo
Acumulativo ayuda a proporcionar los incentivos adecuados para esto.
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
59/123
43
15El tablero Scrum vs. el tablero Kanban un ejemplo menos trivialEn Scrum, la pila de sprint es slo una parte de la foto - la parte quemuestra lo que est haciendo el equipo durante el sprint actual. La otraparte es la pila de producto - la lista de cosas que el dueo del producto
quiere tener hecho en futuros sprints.
El dueo del producto puede ver pero no tocar la pila de sprint. Puedecambiar la pila de producto en cualquier momento, pero los cambios notendrn efecto (es decir, no afectarn al trabajo que se est haciendo)hasta el siguiente sprint.
Cuando se hace el sprint, el equipo "facilita el cdigo potencialmenteentregable" al dueo del producto. De este modo, cundo el equipofinaliza el sprint lo revisa y, con orgullo, muestra las caractersticas A,B, C y D al dueo del producto. El dueo del producto puede decidir
ahora si quiere o no entregar el sprint. Esta ltima parte - el hecho deentregar el producto - no suele estar incluido en el sprint, y por lo tantono es visible en la pila de sprint.
En este escenario, un tablero Kanban podra ser algo como esto:
rode(e
te
Comprometido En curso Terminado :o)
B
C
A
D
Pila de sprintE
F
GH
E
F
G
H IJ L
KM
Pila deproducto
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
60/123
44 |KANBAN Y SCRUMOBTENIENDO LO MEJOR DE AMBOS
44
Ahora, el flujo de trabajo completo se encuentra en el mismo tablero -no slo estamos mirando lo que un equipo Scrum est haciendo en unaiteracin.
En el ejemplo anterior la columna 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. Porlo tanto, slo puede haber 2 elementos de prioridad alta en un momentodado. Cada vez que el equipo est listo para comenzar a trabajar en unnuevo elemento tendr que tomar el primer elemento de la columna"Seleccionado". El dueo del producto puede hacer cambios en lascolumnas Pila y Seleccionado en cualquier momento, pero no en lasotras columnas.
La columna "Des" (dividida en dos subcolumnas) muestra lo que se estdesarrollando, con un lmite Kanban de 3. En trminos de red, el lmiteKanban corresponde al "ancho de banda y el tiempo de entregacorresponde a "ping" o tiempo de respuesta.
Por qu hemos dividido la columna "Des" en dos subcolumnas "Encurso" y "Terminado"? Es para dar al equipo de produccin laoportunidad de conocer los elementos que pueden arrastrar pull aproduccin.
Seleccionado Desarrollar
Terminado
B
C
A
IL
K
Pila Produccin!En curso
R
FLUJO
Implementar
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
61/123
EL TABLERO SCRUM VS EL TABLERO KANBAN | 45
45
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,significa que habr exceso de capacidad, los desarrolladores podrancomenzar un nuevo elemento, pero no estn autorizados a causa dellmite Kanban. Esto les da un fuerte incentivo para concentrar susesfuerzos y ayudar a poner cosas en produccin, para borrar de lacolumna "Terminado" y maximizar el flujo. Este efecto es agradable yprogresivo - a ms cosas en "Terminado", menos cosas se permiten Encurso" lo que ayuda a centrar la atencin del equipo en las cosas
adecuadas.
Flujo de una sola pieza
El flujo de una sola pieza es una especie de escenario de "flujo perfecto", donde un elemento fluye a travs del tablero sin quedaratrapado en una cola. Esto significa que en cada momento hay alguien
trabajando en ese elemento. Aqu puedes ver cmo el tablero podrarepresentar este caso:
Des
Terminado
B
C
A
3En curso
Seleccionado 2Des 3
Terminado
B A
Pila En produccin
:o)En curso
X
R
FLUJO
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
62/123
46 |KANBAN Y SCRUMOBTENIENDO LO MEJOR DE AMBOS
46
B se est desarrollando en este momento, A se ha puesto en produccinen este momento. Cada vez que el equipo est listo para el siguiente
elemento pregunta al dueo del producto qu es lo ms importante yobtiene una respuesta. Si este escenario ideal persiste podemosdeshacernos de las dos colas "Pila" y "Seleccionado" y tener un tiempode entrega muy corto!
Cory Ladas lo cuenta muy bien: "El proceso ideal de planificacin deltrabajo siempre debe proporcionar al equipo de desarrollo lo msadecuado para continuar, ni ms ni menos".
Los lmites del trabajo en curso (WIP) estn ah para evitar problemasantes de que aparezcan. As, si las cosas estn fluyendo sin problemas,los lmites del trabajo en curso (WIP) no son realmente utilizados.
Un da en el pas de Kanban
Selecccionado Desarrollar
Terminado
A BG
D
Pila 22
Produccin!En curso
Implementar
CF
H I
1
SelecccionadoDesarrollar
Terminado
Pila 22
Produccin!En curso
Implementar1
A
BG CF D
H I
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
63/123
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
64/123
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
65/123
EL TABLERO SCRUM VS EL TABLERO KANBAN | 49
49
El tablero Kanban tiene que tener este aspecto?
No, el tablero anterior fue solo un ejemplo.
Lo nico que prescribe Kanban es que el flujo de trabajo debe ser visual,
y que el trabajo en curso debe estar limitado. El objetivo es crear unflujo suave a travs del sistema y minimizar el tiempo de entrega. Por lotanto, necesitas plantearte regularmente cuestiones tales como:
Qu columnas deberamos tener?
Cada columna representa un estado del flujo de trabajo, o una cola(buffer) entre dos estados del flujo de trabajo. Empieza de forma sencillay aade nuevas columnas cuando lo necesites.
Selecccionado
Desarrollar
TerminadoPila 22 Produccin!En curso
Implementar1
C
D
G
B
A
FH I
J
K
L1"
0""
$,,,/.##$"
!%#,
SelecccionadoDesarrollar
Terminado
Pila 22
Produccin!En curso
Implementar1
%#
...
MH
JL
R
C
DGB
A
F
I K
1'!0
12
(01-0
/++.
,/2!
.+/.,++/.10.0
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
66/123
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
67/123
51
16Resumen de Scrum vs KanbanParecidos
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 Kanban
Las iteraciones deben ser de
tiempo fijo.
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 tiempopre-fijado.
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
68/123
52 |KANBAN Y SCRUMOBTENIENDO LO MEJOR DE AMBOS
52
El equipo asume un compromiso de
trabajo por iteracin.El compromiso es opcional.
La mtrica por defecto para laplanificacin y la mejora del proceso
es la Velocidad.
La mtrica por defecto para la
planificacin y la mejora del procesoes el Lead Time (tiempo de entrega
o tiempo medio que tarda una
peticin en salir del ciclo)
Los equipos deben ser multi-
funcionales.
Los equipos pueden ser multi-
funcionales o especializados.
Las funcionalidades deben dividirse
en partes que puedan completarse
en un sprint.
No hay ninguna prescripcin en
cuanto al tamao de las divisiones.
Deben emplearse grficos
Burndown.
No se prescriben diagramas de
seguimiento concretos.
Se emplea una limitacin WIP
indirecta (por sprint).
Se emplea una limitacin WIP
directa (marcada por el estado del
trabajo).
Se deben realizar estimaciones. Las estimaciones son opcionales.
No se pueden aadir tareas enmedio de una iteracin.
Siempre que haya capacidad
disponible, se pueden aadirtareas.
La pila del sprint pertenece a un
equipo determinado.
Varios equipos o personas pueden
compartir la misma pizarra
Kanban.
Se prescriben 3 roles
(PP/SM/Equipo).No hay roles prescritos.
En cada sprint se limpia el tablero
de seguimiento. El tablero Kanban es persistente.
La pila del producto debe estar
priorizada.La priorizacin es opcional.
Ala. Esto es todo. Ahora ya conoces las diferencias.
Sin embargo, an no ha terminado, ahora es el momento de la mejor
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
69/123
EL TABLERO SCRUM VS EL TABLERO KANBAN | 53
53
parte!. Clzate las botas, porque es hora de ir a las trincheras conMattias para ver cmo se pone esto en prctica!
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
70/123
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
71/123
55
Parte II Caso de estudio
Kanban en la vida real
Esta es la historia de cmo hemos aprendido a mejorar usando Kanban.
Cuando empezamos no haba mucha informacin, y el Dr. Google nos
dej con las manos vacas. Hoy en da Kanban est evolucionando
satisfactoriamente y hay un cuerpo de conocimiento incipiente.
Recomiendo echar un vistazo al trabajo de David Anderson, por
ejemplo a "classes of service". As que aqu viene la primera (y ltima)
advertencia (lo prometo!). Independientemente de la solucin que
vayas a implementar, asegrate de tratar sus problemas especficos.
Una vez dicho, vamos con nuestra historia.
/Mattias Skarin
Ideas Mercado En desarrollo
Carrito
Cliente
Prueba Produccin
Historia
Login
Invitar Email
GUI*
Retroceder
Servicio
* Graphical User Interface: Interfaz Grfica de Usuario
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
72/123
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
73/123
57
17La naturaleza de las operacionestcnicasSi alguna vez has estado en un servicio de soporte 24/7, tendrs una ideaclara de la responsabilidad que se siente al gestionar un entorno deproduccin. Se espera que resuelvas la situacin en medio de la noche,
sin importar si el problema era por tu culpa o no. Nadie lo sabe, por esote llaman. Es un reto complicado porque t no eres el fabricante delhardware, los drivers, el sistema operativo ni el software del usuario. Amenudo tus opciones se limitan a acotar el problema o su impacto, y aregistrar la informacin necesaria para poder repetir el error, de maneraque la persona responsable pueda solucionar el problema del que tu hassido testigo.
La respuesta y la capacidad para resolver problemas son claves, siemprecon velocidad y precisin.
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
74/123
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
75/123
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
76/123
60 |KANBAN Y SCRUMOBTENIENDO LO MEJOR DE AMBOS
60
Adems, el progreso en los equipos de desarrollo significaba unaumento de las peticiones a los gerentes para echar una mano en elanlisis 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.El equipo de gerentes se dio cuenta de que necesitaban actuar antes deque la situacin se volviera inmanejable.
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
77/123
61
19Por dnde empezamos?Una buena forma de empezar era preguntar a los equipos de desarrollo,porque eran los clientes del grupo de Operaciones.El equipo de operaciones, visto por los
desarrolladoresLes pregunt; "qu tres cosas os vienen a la cabeza cuando pensis en'Operaciones'?". Las respuestas ms comunes fueron:
Conocimiento variable Su sistema de workflow
apesta
Muy competentes cuando se trata
de infraestructuraQu estn haciendo los
chicos?Ellos quieren ayudar, pero en
realidad es difcil obtener ayudaNecesito muchos correos
electrnicos para hacer cosas
simplesLos proyectos duran demasiado Difciles de contactar
En resumen, as era cmo los desarrolladores vean al equipo deOperacin. Comparmoslo con la visin de Desarrollo que tena elequipo de Operacin:
Desarrollo, visto desde el equipo de operaciones
61
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
78/123
62 |KANBAN Y SCRUMOBTENIENDO LO MEJOR DE AMBOS
62
Por qu no utilizis las ventajas que os ofrecen las plataformas?
Hagamos de la distribucin algo menos pesado!
Vuestra baja calidad nos afecta!
"Tienen que cambiar" - era el tema comn en las quejas de ambosequipos. Obviamente, debamos cambiar ese esquema mental siqueramos avanzar en la resolucin de los problemas comunes. Por lomenos, "muy competentes cuando se trata de infraestructura" indicabaconfianza en las capacidades y me haca pensar que esa mentalidad de"nosotros contra ellos"poda arreglarse si se creaban las condiciones detrabajo adecuadas. Una opcin viable poda ser eliminar el sobre-
esfuerzo y concentrarnos en la calidad.
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
79/123
63
20Iniciando la marchaAs que necesitbamos iniciar la marcha, pero por dnde empezamos?La nico cierto que sabamos es: el sitio donde empecemos no serdonde terminemos.
Mi experiencia es la de un desarrollador, as que seguramente saba muypoco sobre la naturaleza del trabajo de Operaciones. Y no era cuestinde entrar a lo loco y comenzar a cambiar cosas. Necesitaba un enfoquemenos frontal que an as nos enseara las cosas relevantes, descartaralas no relevantes y fuera fcil de aprender.
Los candidatos eran:
1. Scrum - estaba funcionando bien en equipos de desarrollo.2. Kanban - era nuevo y no estaba probado, aunque encaja bien con
los principios Lean que se echaban en falta.
En discusiones con los gerentes los principios de Kanban y Leanparecan encajar con los problemas que estbamos intentando resolver.Desde su punto de vista los sprints no se adaptaran muy bien ya quehacan repriorizacin de forma diaria.
Por lo tanto Kanban pareca el punto de partida ms lgico, inclusoaunque fuera algo nuevo para todos nosotros.
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
80/123
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
81/123
65
21Puesta en marcha de los equiposCmo poner en marcha los equipos? No haba ningn manual quedijera cmo hacerlo. Y hacerlo mal poda ser muy arriesgado. Aparte de perder las mejoras, tenamos que tratar con una plataforma deproduccin con personal altamente especializado y cualificado; difcilesde reemplazar. Dejarlos de lado era una idea muuuy mala.
Deberamos simplemente ponernos en marcha? Asumir lasconsecuencias segn vayan surgiendo? O bien, hacer primero un taller?
Era obvio para nosotros - Hacer el taller, verdad? Pero cmo?
Era un reto conseguir que todo el equipo de soporte participara en untaller (Quin contestar al telfono si alguien llama?). Al final
decidimos hacer un taller de medio da, y mantenerlo sencillo y basadoen ejercicios.
El taller
Uno de los beneficios del taller era que ayudara a poner de manifiestocuanto antes nuestros problemas. Pero adems proporcion un ambientede alta confianza donde las implicaciones podan ser discutidasdirectamente con los miembros del equipo. Porque, seamos sinceros, no
todo el mundo era demasiado entusiasta acerca de cambiar la actualforma de trabajo. Pero la mayora de los miembros del equipo estabanabiertos a intentarlo, as que se llev a cabo un taller de demostracin delos principios ms importantes y se hizo una simulacin a escala deKanban.
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
82/123
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
83/123
67
22Dirigindonos a los involucradosEra muy probable que otras partes interesadas (soporte, clientes, otrosequipos, ...) se vieran afectadas por la aplicacin de Kanban. Aunque loscambios seran para mejor, significara que el equipo comenzara a decir"no" al trabajo que no podan completar, a defender la calidad, y aeliminar tareas de baja prioridad de la pila del equipo.A pesar de ello, tener una discusin previa siempre es una buena idea.
Los interesados ms cercanos eran la primera lnea de soporte y losgerentes de departamento. Como haban participado en el taller, ya eranpartidarios de seguir adelante. Lo mismo para los equipos de desarrollo(que esperaban en mayor o menor medida las mejoras). Pero, para unequipo, el equipo de soporte, las cosas eran diferentes. Su problema msimportante era que estaban sobrecargados de trabajo. Adems, ellosgestionaban las solicitudes de los clientes y la empresa se haba
comprometido a responder a todas las solicitudes.
Ahora esto era muy probable que cambiara si aplicbamos Kanban y secomenzbamos a cumplir los lmites de WIP (trabajo en curso). As quehicimos una visita a los principales interesados para presentarlesnuestras intenciones, beneficios esperados, y posibles consecuencias.
Para mi alivio, nuestras ideas fueron muy bien acogidas, a veces con unaobservacin: "estupendo si finalmente podemos dejar estos asuntos en
paz".
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
84/123
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
85/123
69
23Construyendo el primer tableroUna buena manera de comenzar la construccin de un tablero deKanban es haciendo un mapa de la cadena de valor (value stream map).Se trata bsicamente de una visualizacin de la cadena de valor yproporciona la comprensin de los estados de los trabajos, el flujo y eltiempo a en el sistema (tiempo del ciclo).
Pero empezamos por algo mucho ms simple; un tablero de ejemploKanban dibujado en papel junto con el gerente. Revisado un par deveces y luego nos pusimos en marcha. Las cuestiones que surgieron enesta etapa incluyen:
Qu tipos de trabajo tenemos? Quin los maneja? Debemos compartir la responsabilidad entre los diferentes tiposde trabajo? Cmo podemos hacer frente a la responsabilidad compartidateniendo en cuenta que tenemos conocimientos especializados?
Dado que para los diferentes tipos de trabajo haba acuerdos de nivel deservicios diferentes, pareca natural permitir que cada equipo llevara elcontrol de su propio tablero. Ellos mismos hicieron las filas y columnas.
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
86/123
70 |KANBAN Y SCRUMOBTENIENDO LO MEJOR DE AMBOS
70
La siguiente gran decisin era si utilizar o no una responsabilidadcompartida entre los diferentes tipos de trabajo.
"Debemos dejar que una parte fija del equipo trate con las preguntas
directas (trabajo reactivo) y dejar que el resto del equipo se centre enlos proyectos (trabajo proactivo)?"
Decidimos en un primer momento probar la responsabilidad compartida.Una razn fundamental era que habamos identificado que la auto-organizacin y el crecimiento de los miembros del equipo eranesenciales para el crecimiento sostenido. El inconveniente de estadecisin eran las potenciales interrupciones para todo el mundo, peroesta era la mejor solucin que pensamos para comenzar.
Una pequea nota al margen: cuando realizamos el taller los equipos seorganizaron solos para solucionar este problema. Dejaron que unapersona a manejara las solicitudes inmediatas y el resto las cuestionesms extensas.
El primer modelo Kanban
A continuacin se muestra el modelo bsico que utilizamos paraKanban. Tenga en cuenta que el equipo decidi poner el flujo del producto hacia arriba (como burbujas en el agua) en lugar de usar elmodelo de flujo ms tpico de izquierda a derecha.
Figura 2. Este es el primer modelo de Kanban. Prioridades de
ejecucin de izquierda a derecha, flujo de ejecucin hacia arriba.
Trabajos en curso contados como el nmero total de tareas en la
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
87/123
CONSTRUYENDO EL PRIMER TABLN | 71
71
lnea de trabajo en curso (con crculo rojo). El modelo est
influenciado por las experiencias transmitidas por Linda Cook.
Figura 3. Primer tablero Kanban para el equipo de administracin
de sistemas.
Filas utilizadas:
Estado del flujo de trabajo (fila) Como lo definimosBacklog (Pila de producto) Historias que el gerente decide que
son necesarias.Listo para WIP Historias estimadas y divididas en
tareas con una duracin mxima de8 horas.
Trabajo en curso Fila que contena un lmite para eltrabajo en curso. Empezamos con unlmite de 2 X tamao del equipo -1(-1 para colaboracin). As, un
equipo de 4 personas tendra unlmite de 7.
Hecho Ejecutable por el usuario.
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
88/123
72 |KANBAN Y SCRUMOBTENIENDO LO MEJOR DE AMBOS
72
Columnas utilizadas:
Tipo de trabajo Como lo definimosRelease (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 elhardware del entorno de pruebas.
Proyecto B Otro proyecto largo
No todos los tableros Kanban tenan la misma apariencia. Todoscomenzaron con un boceto simple y evolucionaron por el camino.
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
89/123
73
24Estableciendo el primer lmite de WIPNuestro primer lmite de WIP (trabajo en curso) era bastante generoso.Supusimos que mediante la visualizacin del flujo veramos yexperimentaramos lo que iba sucediendo y que era poco probable quefuramos capaces de adivinar el lmite ptimo desde el principio. Segn pasara el tiempo, ajustaramos los lmites de WIP cada vez queencontrramos una buena razn para ello (slo haca falta apuntarlo enel tablero).
El primer lmite WIP que usamos fue 2n-1 donde n era el nmero demiembros del equipo y -1 un modo de potenciar la cooperacin. Porqu decidimos este lmite? Simplemente, porque no tenamos una ideamejor J. Adems, pareca algo poco controvertido para empezar. Lafrmula proporcionaba una explicacin simple y lgica para cualquieraque intentara cargar ms trabajo al equipo: ...si cada miembro del
equipo slo puede trabajar en un mximo de dos cosas a la vez, unaactiva y otra en espera... cmo crees que pueden aceptar ms?".Mirando ahora hacia atrs, cualquier lmite generoso habra funcionado para un equipo novato. Monitorizando el tablero Kanban es sencillodescubrir los lmites correctos sobre la marcha.
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
90/123
74 |KANBAN Y SCRUMOBTENIENDO LO MEJOR DE AMBOS
74
Figura 4. Cmo aplicbamos el lmite de WIP para el equipo de
DBA y administracin de sistemas, con un lmite por cada tipo de
trabajo
Pronto descubrimos que no era til definir el lmite WIP en puntos dehistoria porque era difcil de controlar. El nico lmite suficientementesencillo 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 sesobrepasaba.
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
91/123
75
25Respetando el lmite WIPAunque respetar el lmite WIP establecido suena fcil en teora, es unatarea difcil de conseguir en la prctica, porque siempre significa decirno en algn momento. Pusimos en prctica diferentes aproximacionespara conseguir esto.
Discutir frente al tablero
Cada vez que se descubra una violacin de los lmites WIP llevbamosa las partes interesadas ante el tablero Kanban y les preguntbamos qu pretendan conseguir. Al principio, la razn ms habitual para esasviolaciones era simple inexperiencia. En algunos casos nos encontramoscon perspectivas diferentes sobre la priorizacin, siendo tpicos los casos
de especialistas trabajando sobre su rea especfica. Estas fueron lasnicas ocasiones en que experimentamos alguna friccin, porque lamayora de las veces estas violaciones se solucionaban all mismodiscutindolo a la vista del tablero.
Creando una seccin de sobrecarga
Cuando decir no supona demasiada confrontacin, y eliminarelementos del tablero era complicado, movamos los elementos demenor prioridad a una seccin de sobrecarga en el tablero, all dondelos lmites WIP se haban sobrepasado. Dos reglas aplicaban a las tareasen sobrecarga:
1. No han sido olvidadas. En cuanto tengamos tiempo lastrataremos.
2. Si las abandonamos, sers informado.
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
92/123
76 |KANBAN Y SCRUMOBTENIENDO LO MEJOR DE AMBOS
76
Justo pasadas dos semanas se haca obvio que los elementos desobrecarga incluso ni se trataran nunca, de forma que con el apoyo deljefe de equipo finalmente se podran quitar.
Figura 5. Boceto del tablero Kanban para el equipo de soporte, con
la seccin de sobrecarga en la ltima columna.
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
93/123
77
26Qu tareas llevar al tablero?Pronto tomamos la decisin de no incluir todo el trabajo hecho por elequipo en el tablero. Monitorizar cosas como una llamada telefnica otomar un caf convertira el Kanban en un monstruo administrativo.
Estbamos aqu para resolver problemas, no para crearlos J. As quedecidimos slo poner en el tablero las tareas con tamao mayor de unahora. Todo lo menor de una hora se consideraba ruido blanco.
El lmite de 1h realmente funcion bastante bien, y fue de las pocascosas que permanecieron sin cambios a lo largo del tiempo (tuvimos querevisar nuestras previsiones acerca del impacto que el ruido de fondotena, pero hablaremos de eso ms tarde).
Figura 6. Comenzamos por sumir que la capacidad total era
principalmente ocupada en dos tipos de trabajo; grande
(proyectos) y pequeos (soporte). El seguimiento de la velocidad
en proyectos nos poda dar pistas acerca de la fecha de entrega si
era necesario. Siempre contbamos con que el ruido blanco
(pequeo soporte menor de 1h, reuniones, caf, ayudar a los
colegas) estara por ah de todos modos.
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
94/123
8/6/2019 KanbanVsScrum Caste Llano FINAL-Printed
95/123
79
27Cmo estimar?Este es un tema siempre recurrente y realmente hay ms de unarespuesta correcta: Estimar regularmente.
Estimar cuando se necesita.
Usar estimaciones en das ideales o en puntos de historia.
Las estimaciones son inciertas, usa tallas de camiseta (S-
pequea, M-media, L-grande)
No estimes, o estima slo cuando exista un coste asociado alretraso que lo justifique.
Ligeramente influidos por Scrum