Manual Te GP Agiles

MANUAL
GESTIÓN DE
PROYECTOS
ÁGILES
European Open Business School

MANUAL GESTIÓN DE PROYECTOS ÁGILES
INDICE
1. GESTIÓN DE PROYECTOS ....................................................................................................... 3
1.1. Metodologías y herramientas de gestión de proyectos. .............................................. 3
1.2. Herramientas para gestión de proyectos .................................................................... 29
1.3. Diferentes metodologías de gestión ágil de proyectos. (Comparativa) ...................... 39
1.4. Agile thinking. Introducción a la filosofía e idiosincrasia del pensamiento ágil.......... 56
1.5. Ideación ágil. Creatividad e innovación aplicada al agilismo ...................................... 82
2. Gestión de Proyectos Ágiles con Scrum ............................................................................ 105
2.1. Introducción a la gestión de proyectos Scrum .......................................................... 105
2.2. Roles y artefactos en Scrum ...................................................................................... 122
2.3. Aplicación práctica de un ciclo de scrum .................................................................. 140
2.4. Buenas prácticas de la gestión con Scrum ................................................................ 160
3. Gestión de Proyectos Ágiles con Kanban y XP .................................................................. 179
3.1. Kanban I. WIP, processos pull y flujo ........................................................................ 179
3.2. Kanban II. Equipos y proyectos. Gestión evolutiva del cambio ................................ 202
3.3. Kanban III. Mastering Kanban ................................................................................... 229
3.4. Programación externa (XP) ....................................................................................... 265
European Open Business School 2

1. GESTIÓN DE PROYECTOS
1.1. Metodologías y herramientas de gestión de
proyectos.
1.1.1. INTRODUCCIÓN A LA GESTIÓN DE PROYECTOS
Como ya sabéis, este es el módulo de Gestión de Proyectos. Todas las áreas de

conocimiento son importantes en el ámbito empresarial, pero si podemos destacar alguna por
una ligera ventaja sobre el resto, sin duda la gestión de proyectos podría ser una de esas áreas
de conocimiento.
En el ámbito empresarial, y en la vida también, queramos o no, estamos habituados a

gestionar proyectos, aunque en algunos casos ni tan siquiera nos percatemos de que nos
estamos enfrentando a la gestión de un proyecto en sí mismo.
Planificar un largo viaje en coche, puede considerarse un proyecto en sí mismo y, por

lo tanto, debemos gestionarlo como tal para alcanzar con éxito nuestro objetivo (llegar al
destino). Para continuar con el ejemplo, voy a mencionar algunas tareas que debemos hacer:
marcar objetivo (destino) en tiempo y forma: día, hora de llegada… planificar la ruta, juntar al
equipo (conductor) y acompañantes, garantizar los recursos económicos (gasolina, comida,
etc.), evaluar la ruta y decidir dónde hacer las paradas intermedias (selección destino, reserva
de alojamiento, etc.), prever posibles incertidumbres (climatología, pinchazo, etc.), y asegurar
los medios disponibles para el viaje (coche, gps, móvil).
Espero que se haya entendido el concepto. Obviamente, para los conductores

experimentados, gestionar un viaje de este tipo puede resultar más o menos sencillo, pero
imagina por un momento que eres un conductor novel (recién obtenido tu licencia para
conducir) y te enfrentas a tu primer viaje de 1000km de distancia.
La gestión de proyectos se lleva realizando desde que el hombre es hombre. Se

plantean alcanzar ciertos objetivos y requiere para ello tener en cuenta multitud de
elementos.

Una de las primeras constancias de la aplicación de gestión de proyectos

(documentados de alguna manera) son las pirámides de Egipto. Como todos sabemos, son
obras colosales, con un plazo de ejecución de la obra de quizás 2 o 3 décadas de trabajo, que
implicaban a miles de trabajadores, recursos (piedra, alimentación trabajadores,
herramientas), etc.
Otros ejemplos, a lo largo de la historia, pueden ser también obras más o menos
reconocidas, como el Coliseo Romano, la implantación de la red ferroviaria en USA o el viaje a
la luna. Son proyectos en los que, si recapacitamos un poco, podemos darnos cuenta de su
enorme magnitud y de las implicaciones que requerirán en cuanto a planificación, recursos,
imprevistos, resultados esperados, etc.
Como todo, las metodologías de gestión de proyectos han evolucionado a lo largo de la

historia. Lo que se conoce como metodología de gestión de proyectos propiamente dicha
comenzó a usarse en la década de los 50.
Una de las primeras constancias que tenemos proviene del ejército estadounidense.
Esta organización, con el objetivo de alcanzar el éxito en los proyectos que iniciaba, comenzó a
desarrollar metodologías que les ayudasen a controlar los proyectos, su evolución y los
resultados obtenidos (coste, plazo, resultados).
En la actualidad, multitud de aspectos han cambiado desde los inicios de la gestión de

proyectos, las tecnologías permiten gestionar proyectos más rápidamente (informática
principalmente), los equipos son multidisciplinares y en multitud de ocasiones des-localizados.
Así mismo las incertidumbres a las que se enfrentan los proyectos son cada vez más
inesperadas (cambios en las demandas del cliente/usuario, riesgos macroeconómicos, cambios
regulatorios, etc.)
La irrupción de la tecnología y los cambios en el paradigma del trabajo (relación

empresa-empleados-freelances) también han implicado una evolución en la gestión de
proyectos.

Todo ello tiene implicaciones directas a la hora de afrontar cualquier tipo de proyecto
en el seno de una corporación y/o de una startup.
He preparado esta clase siguiendo un hilo conductor que nos permita ir

introduciéndonos poco a poco en la materia en cuestión. En un primer acercamiento
trabajaremos sobre el perfil del Gestor de Proyecto (PM de sus siglas en inglés) y que
conocimientos debe tener para poder gestionar un proyecto correctamente. Dentro de ese
capítulo, también trabajaremos con una herramienta muy sencilla, que te permitirá evaluar a
un persona y conocer si es el perfil idóneo para gestionar un proyecto. Además, esta
herramienta también sirve para autoevaluarnos.
Seguiremos la clase trabajando ya sobre la gestión de proyectos. Haremos una

introducción a los conceptos básicos sobre la gestión de proyectos. Continuaremos conociendo
las distintas metodologías existentes para gestionar proyectos, todas ellas relacionadas con el
ámbito empresarial. A continuación trabajaremos sobre el conocimiento de las diferencias
entre las metodologías tradicionales y las metodologías ágiles y su principal diferencia.
Dentro de este capítulo, os explicaré que diferencia hay entre desarrollo en cascada y
desarrollo ágil para, a continuación, ver como aplican las empresas y startups las metodologías
ágiles.
Posteriormente, trataremos las herramientas más habituales para gestionar proyectos y, por
último, veremos algunas recomendaciones y errores habituales a la hora de gestionar
proyectos empresariales.
He intentado por todos los medios que está clase sea bastante práctica, a pesar de que el
contenido es bastante teórico. Espero que te resulte interesante.
Antes de comenzar ya de lleno con el contenido de la clase, si me permites una

recomendación, te comento que, en mis 12 años de experiencia gestionando empresas y
proyectos empresariales (lo que se conoce hoy en día como startups), he aprendido que una
correcta gestión de proyectos es un factor determinante para alcanzar el éxito del proyecto.

Profesionales con un alto conocimiento técnico (digamos, por ejemplo, programación) pero
con unas capacidades deficientes para gestionar proyectos, tendrán mil veces más problemas
para desarrollar un proyecto correctamente frente a un profesional, con quizás menos
conocimiento técnico (programación) pero con una buena capacidad para gestionar el
proyecto y las dificultades que surgirán por el camino.
Esto lo leí hace muchos años en el libro “Como hacer amigos e influir sobre las personas” de
Dale Carnegie (os lo recomiendo 100%) y cada vez estoy más de acuerdo con aquella
afirmación. La experiencia me ha demostrado que es una afirmación 100% real.
Espero que te resulte interesante y puedas conocer las metodologías existentes y que puedas
aplicarlo con criterio a tus proyectos actuales y futuros en el ámbito empresarial.

1.1.2. BÁSICOS PARA GESTIÓN DE PROYECTOS
Hay varios aspectos que considero de vital importancia para gestionar un proyecto con
éxito. Obviamente, la elección de la metodología de gestión del proyecto es un factor
fundamental.
Otro factor fundamental para la consecución de los objetivos del proyecto es la

elección del gestor del mismo. En este capítulo veremos los aspectos a tener en cuenta para
una buena elección del PM en el ámbito profesional y empresarial.
Para ser un buen profesional y gestionar con éxito un proyecto empresarial, es

necesario contar con una buena combinación de diferentes competencias personales,
experiencia, aptitudes y conocimientos técnicos, además por supuesto, de conocer la
metodología que se va a aplicar para gestionar el proyecto en cuestión.
Reflexión del profesor:
Me gustaría hacer un inciso en este tema. A lo largo de los años he conocido multitud
de proyectos empresariales en diversos sectores en general pero especialmente los
relacionados con Internet.
A su vez, he conocido multitud de profesionales, muy buenos en su ámbito de

conocimiento (ingenieros, gestores hospitalarios, turismo, etc.), con un conocimiento técnico
muy amplio y una experiencia contrastada, y que, a la hora de implantar un canal online para
su negocio (una landing page, una web de presencia, una página más compleja: gestión de
documentos y/o procesos o incluso desarrollar una app determinada), han fracasado
estrepitosamente: demora en la implantación del proyecto, sobrecoste, no alcanzan los
objetivos marcados.
¿A qué se debe esto? Bajo mi juicio, se debe principalmente a que no tienen

conocimientos (técnicos) y de gestión suficientes sobre ese proyecto en cuestión.
Para implantar cualquier solución en Internet es necesario controlar o conocer

multitud de áreas: ecosistema de Internet, desarrollo soft/web, marketing online, etc

Tener elevados conocimientos técnicos en tu área de expertise no te ayudara en nada

a la hora de implantar un nuevo canal de comercialización en Internet para esa área. Para ese
trabajo, se requiere un conocimiento en gestión de proyectos en ese ámbito y un
conocimiento técnico que si no tienes, va a dificultar en gran medida la implantación y
desarrollo de dicho proyecto.
Un ejemplo sencillo: a nadie en su sano juicio, sin conocimientos mecánicos, se le

ocurre ponerse a cambiar el embrague de un camión, ¿verdad? Necesitarías tener
conocimientos sobre mecánica, necesitarías tener las herramientas y el lugar de trabajo
adecuado, tener la experiencia adecuada en reparación de camiones y, además, deberías
afrontar el proyecto con una correcta planificación (específica sobre procesos de reparación).
De no hacerlo así, es altamente probable que cometas errores y que no puedas alcanzar el
objetivo del proyecto (reparación del camión).
Tras esta reflexión, como decíamos antes, un PM debe ser el líder que gestione el
proyecto empresarial en cuestión. Para ello, debe tener algunas competencias y aptitudes
básicas que le permitan gestionar todas las variables con garantías.
Para entrar en materia, vamos a ver las competencias básicas que debe poseer un PM:
 Tolerancia al estrés. Me parece fundamental. Cualquier persona excesivamente

nerviosa o que no sea tolerante al estrés, va a sufrir mucho a la hora de gestionar
un proyecto en condiciones óptimas. Los cambios, exigencias del cliente, presiones
(internas [compañeros, superiores..] y/o externas [proveedores, regulatorios,
prensa, etc.]) pueden influir negativamente en el PM. La capacidad de soportar el
estrés y mostrarse tranquilo en situaciones comprometidas es un factor
fundamental.
 Organización. La gestión de cualquier proyecto implica tratar diversas tareas,
muchas de ellas en paralelo. Las tareas administrativas también son una carga a
tener en cuenta. Un buen PM debe ser organizado para poder gestionar
correctamente las tareas así como para delegar las correspondientes cuando sea
necesario.
 Liderazgo. Como en cualquier ámbito profesional, en la gestión de proyectos
empresariales no iba a ser menos. El liderazgo del PM es fundamental para guiar al
equipo (interno/externo) en la dirección correcta, delegando las tareas y
responsabilidades oportunas en cada uno de los integrantes, dirigiendo el proyecto
hacia el objetivo marcado y motivando al equipo en situaciones comprometidas.
 Comunicación. El PM debe controlar los elementos básicos de la comunicación para
poder transmitir correctamente los mensajes hacia todos los interlocutores
involucrados en el proyecto. Para ello debe ser capaz de transmitir conceptos y
objetivos claramente.
 Empatía. El PM debe ser capaz de ponerse en lugar de terceros para conocer sus
necesidades, frustraciones y dificultades con el proyecto. Esta capacidad es muy
relevante de cara sobre todo a resolver conflictos que puedan surgir en la dirección
del proyecto.

 Experiencia y conocimiento técnico. Un conocimiento del área relacionada con el

proyecto a gestionar es vital. Una persona sin conocimiento en Ingeniería Civil lo va
a tener realmente complicado para gestionar con éxito un proyecto de construcción
de un puente. Esto es aplicable para cualquier proyecto empresarial, ya sea una
corporación y/o una startup. Si no tienes conocimientos sobre Fintech, BigData o
sobre Comercialización, al PM le va a resultar bastante más difícil gestionar
correctamente el proyecto relacionado con esa área de conocimiento. La
experiencia también es otro factor relevante a tener en cuenta en el perfil de un
PM. La experiencia adquirida en la gestión de otros proyectos (no tiene que ser
directamente en el área del proyecto actual) es un plus a tener en cuenta.
 Delegar. Ningún PM puede afrontar un proyecto solo. Saber delegar es una
capacidad muy difícil de conseguir, requiere años de experiencia (cometer multitud
de errores) para controlar una habilidad vital para cualquier proyecto empresarial.
 Confianza. La confianza es una parte fundamental en la gestión eficaz de los
proyectos. Un PM debe ser capaz de confiar en su equipo a la vez que transmitir
confianza a los interlocutores con interés en el proyecto (jefes, superiores, clientes,
proveedores).
 Trabajo por objetivos. El PM debe estar habituado a trabajar por objetivos. Para ello
debe conocer los básicos para generar objetivos (SMART), pudiendo así poder
evaluar el desempeño del proyecto en función de los objetivos marcados. Además,
debe ser capaz de evaluar si los objetivos en si mismo son correctos según el
proyecto en cuestión.
 Resolutivo. Un buen PM no puede demorar decisiones por falta de toma de
decisiones. Para una correcta gestión del proyecto empresarial, la toma de
decisiones es fundamental. Para ello el PM debe ser capaz de tomar decisiones
rápidas, fundamentadas y defendibles aunque en algunas ocasiones no disponga de
toda la información necesaria.
 Orientado a Cliente. Todos los proyectos tienen un cliente, ya sea interno o
externo. Un buen PM nunca puede obviar las necesidades del cliente que, como es
obvio, tienen una influencia destacable en los objetivos del proyecto.
Fuente Listado: Elaboración propia y APM (Association for project management)
Reflexión del alumno. ¿Eres el indicado para gestionar tu startup?
¿Eres la persona idónea para gestionar con éxito el proyecto que te han encargado en
la empresa? ¿Eres la persona ideal para comandar tu startup?
En Google, como muchos quizás podáis saber, Sergei y Larry fueron los creadores de la
empresa, pero rápidamente contrataron a un directivo para dirigir (gestionar) los inicios de la
empresa.
Es sin duda, uno de muchos de los movimientos más inteligentes que puede hacer un
impulsor de un negocio. En aquella época, Sergei y Larry eran muy jóvenes, técnicamente muy
cualificados pero con ningún conocimiento (ni experiencia) en cuanto a gestión de una

empresa y muchos menos en cuanto a la gestión de la inversión que comenzó a llegar a la

empresa al poco tiempo de fundarla (100.000 € del 1r cheque y 25 millones al año de haber
sido fundada).
Tanto Sergei como Larry tenían la visión para llevar a Google a ser uno de los mejores
buscadores de la época pero también supieron ver su desconocimiento en gestión y se dejaron
guiar por un profesional
Nota: Es cierto que a veces estas decisiones vienen impuestas por los inversores.
El objetivo de este repaso sobre los inicios de Google era para despertar, en el
emprendedor o impulsor de una startup, la cuestión sobre si es la persona idónea o no para su
proyecto empresarial.
Quizás no seas el más adecuado, y es altamente posible que no dispongas de los

recursos de Google para contratar a un profesional, pero sabiendo tus debilidades, si podrás
formarte y trabajar para mejorar aspectos relevantes en gestión de proyectos.

Herramienta propuesta por el profesor
Tal y como veíamos antes, los PM deben poseer determinadas cualidades. Bien estés
trabajando en una corporación o gran empresa y debas escoger un PM para un proyecto
determinado, o bien seas el CEO de una startup y quieras evaluar a un posible candidato para
gestionar un proyecto de tu empresa, te recomiendo la siguiente herramienta.
Rueda de Competencias Clave: es una herramienta muy sencilla y que resulta muy útil
para, de un vistazo rápido, evaluar las cualidades de una persona.
Se trata de la imagen que ves a continuación, un círculo numerado con 12 apartados:
¿Cómo funciona? Muy sencillo, a la hora de evaluar a una persona (o a nosotros mismos),
seguimos los siguientes pasos:
 Elaboramos un listado de 12 cualidades (actitudes, aptitudes, conocimiento,

etc.) que consideramos importantes para el puesto en cuestión: “Gestor de
Proyecto” (Un ejemplo es el listado anterior).
 Podemos ordenar el listado por orden de importancia.
 Colocamos los ítems en cada uno de los recuadros.
 Evaluamos el ítem oportuno con la persona. Para evaluar el ítem en cuestión
hay multitud de alternativas: entrevista personal, role playing, examen de

conocimientos, test, etc. En función de nuestras posibilidades, usaremos una u

otra técnica.
 En función de la valoración que obtenga la persona en cada ítem, trasladamos el
resultado al diagrama.
 Al finalizar el análisis, podemos unir los puntos (puntuaciones) y obtener como
resultado un diagrama que nos mostrara de manera visual las capacidades de la
persona en cuestión. Viendo rápidamente el diagrama podemos entender en
qué áreas esa persona es mejor o, por el contrario, en cuales debe mejorar.
Nota: Este procedimiento, podemos hacerlo nosotros mismos para auto-evaluarnos y conocer
nuestras capacidades de cara a gestionar un proyecto empresarial (nuestra startup, por
ejemplo).
Aviso! Recalcar que NO quiero menospreciar técnicas mucho más elaboradas para evaluar la
valía de una persona para un puesto determinado. El estudio de las personas por parte de los
departamentos de recursos humanos han evolucionado mucho y cada vez los recruiters tienen
más herramientas y técnicas de gran utilidad para conocer en profundidad a los candidatos.
Descargar vídeo
Un MP debe tener en cuenta multitud de aspectos para gestionar con éxito un

proyecto en el ámbito empresarial.
Estos aspectos se pueden encontrar en el denominado “Triángulo de Gestión de

Proyectos”. Dicho triangulo toma como aspectos clave de cualquier proyecto los siguientes
ítems: Coste, Alcance, Tiempo y Calidad.
Básicamente, lo que se intenta transmitir a través de esta imagen, es que el PM debe

tener en cuenta que cualquier cambio en alguno de esos ítems, implicara un cambio en alguno
de los otros parámetros.

Para que podáis entender mejor los ítems del triángulo, analizamos con más detalle qué se
considera en cada una de ellas:
 Tiempo: se refiere a la cantidad de tiempo disponible para completar el proyecto.

La mayoría de los proyectos tienen una fecha límite para la que el proyecto deberá
estar concluido. Además, el proyecto posiblemente disponga de una serie de hitos
intermedios (o puntos intermedios de control) por cumplir en cuanto a fechas.
 Coste: se refiere al presupuesto del proyecto. El coste no solo es económico, puede
ser de personas, equipamiento, material o consumibles, instalaciones….
 Alcance: se refiere a lo que se debe hacer para producir el resultado final del
proyecto. Es decir, los objetivos que se esperan conseguir al desarrollar el proyecto
a gestionar.
A continuación, podéis encontrar las reglas que debéis tener en cuenta para “utilizar el
triángulo:
 En un primer momento, hay que identificar el alcance del proyecto, es decir,

cuáles son los requerimientos a satisfacer en el proyecto. Con base en esta
información podemos determinar cuántos recursos (gente, herramientas,
presupuesto) necesitamos para poder desarrollarlo. Pero esto dependerá del
tiempo que se requiera para completar el proyecto; si tenemos disponibilidad de
recursos, podremos reducir el tiempo; si no hay presión de tiempo, entonces
podremos disponer de menos personal y recursos para poder completarlo; o si se
nos da flexibilidad en cuanto al alcance a cubrir, entonces podremos reducir
tiempos y/o recursos para el proyecto.
 Determinar los tiempos y costes es una tarea de por sí complicada, pero debes
dedicarle tiempo porque si decides aceptar una fecha límite con recursos
limitados con un objetivo o alcance no negociable, entonces te vas a encontrar
con problemas después.
 Debes ser consciente de que un lado del triángulo no puede ser modificado sin
impactar a los otros, por lo que debemos buscar un balanceo de acuerdo a los
recursos con los que contamos.
 Para conseguir ese buen balance intenta no tener más de dos restricciones
elevadas (por ejemplo, un gerente siempre va a pedir calidad elevada, tiempo
mínimo y costes bajos pero, como gestor del proyecto, tenemos que poner

siempre la perspectiva correcta y planear tomando en cuenta este triángulo,

buscando siempre el mayor equilibrio posible).
 Un cliente en el proyecto nos puede restringir dos de los tres parámetros, pero
nunca los tres. Cuando inicies un proyecto ten claro esta premisa a la hora de
negociar resultados, plazos y costes.
Círculos
Relacionado con el triángulo anterior, os incluyo una infografía que circula por las
redes sociales que representa muy bien el concepto del triángulo. Esta infografía está pensada
desde el punto de vista de una relación entre empresa-cliente con un proyecto entre manos.
Como podéis observar, solo se pueden obtener proyectos en función de dos características
principales, la unión de los tres círculos (y el cuarto) dan como resultado utopías.
Descargar vídeo

Conoceremos en este capítulo las distintas metodologías y herramientas disponibles

para gestionar proyectos.
Todas ellas, en mayor o menor medida, están orientadas a proyectos empresariales y

son de aplicación, tanto para un proyecto complejo como la gestión de una empresa, la
creación de un nuevo producto, el desarrollo de un servicio, o bien el establecimiento de una
startup (que puede ser entendido como la creación o el desarrollo de un producto/servicio en
sí mismo).
Antes de entrar en materia, vamos a conocer la definición formal de “proyecto”:
 "Un proyecto (empresa, startup, producto y/o servicio) es un conjunto de

actividades y recursos con relación de dependencia entre ellas."
La Gestión de un Proyecto son las tareas encaminadas a diseñar una planificación

inicial del proyecto en cuestión, teniendo en cuenta los recursos disponibles (personas,
económicos, bienes de equipo, materiales, herramientas…internos/externos), requisitos
(metas, plazos, calidad…) de forma que se diseñan unas tareas (interrelacionadas entre si) para
alcanzar los objetivos deseados (resultado final).
Por lo tanto, para una correcta Gestión de un Proyecto, las personas involucradas
(Gestor Proyecto) deben poseer una experiencia y conocimientos (habilidades, aptitudes y
actitudes) acordes al proyecto a desarrollar (tanto conocimientos técnicos y de gestión, tal y
como comentamos en el capítulo anterior.)
Un ejemplo sencillo: La organización de una mudanza. Pueden parecer proyectos

sencillos de gestionar pero todos sabemos que al final pueden convertirse en autenticas
pesadillas (mala gestión) si no se afrontan correctamente. Para la gestión del proyecto
(Mudanza) todos somos conscientes de que debemos gestionar el método de transporte,
debemos gestionar las personas (amigos, familia y/o mozos) para el movimiento de los bultos.
Previamente, debemos haber empaquetado todos los elementos a transportar, debemos tener
identificado un sitio a donde llevar los elementos (nueva oficina), que implica disponer de dos

lugares alquilados a la vez. Si hay retrasos en la mudanza, implicaría un sobrecoste el pagar 2

mensualidades para el mismo mes o la perdida de la fianza por dejar tarde la anterior oficina.
La recomendación del profesor
A mayor inversión para llevar a cabo el proyecto o a mayor desconocimiento sobre la

materia en cuestión sobre el proyecto, más dificultad conlleva la Gestión de dicho Proyecto.
El establecimiento de una startup, el lanzamiento de un nuevo producto y/o Unidad de

Negocio, el desarrollo de una nueva web, el desarrollo de una app y la subcontratación de una
campaña de marketing son claros ejemplos de proyectos que gestionados incorrectamente y/o
por la persona incorrecta (generalmente con conocimientos reducidos sobre la materia en
cuestión) derivan en resultados nefastos.
He visto multitud de proyectos (sobre todo aquellos con un componente TIC, web y/o
soft) que se dilatan en el tiempo, aumentan los costes o bien no se alcanzan los requisitos
deseados porque no se ha gestionado correctamente.
Una correcta Gestión del Proyecto en cuestión puede suponer la diferencia entre un
proyecto fracasado y/o una empresa de éxito.
Metodologías para gestión de proyectos
Las metodologías de gestión de proyectos son marcos (sistema procedimentado) de

referencia que permiten estructurar los distintos elementos que conforman el proyecto
siguiendo unos criterios conocidos por todos los miembros involucrados.
El objetivo principal que persigue una metodología aplicada a un proyecto en cuestión

(gestión de una empresa, establecimiento de una startup, desarrollo de un producto y/o
servicio) es alcanzar los objetivos establecidos al inicio del proyecto, que generalmente se
corresponden con: plazos, calidad y presupuesto.
Hoy en día, la gestión de proyectos y por ende, la aplicación de una metodología

(distinta en función del proyecto), es una realidad contrastada. Ya no solo las grandes

empresas aplican este tipo de metodologías sino que startups y freelances aplican distintas
metodologías en función de las necesidades del proyecto para alcanzar los objetivos
necesarios.
Veremos, a lo largo del capítulo, distintas metodologías existentes, todas ellas, en

mayor o menor medida, orientadas al mundo empresarial. Posteriormente, trataremos la
diferencia entre Gestión de Proyectos Tradicional y Gestión de Proyectos Agile para, a
continuación, ver distintas herramientas disponibles, basadas en distintas metodologías, que
podremos usar para aplicar directamente a un proyecto en cuestión.
A continuación, veremos varias metodologías que son utilizadas para gestionar

proyectos. Cada metodología tiene sus peculiaridades y está pensando para un tipo de
proyectos específicos. No pretendo entrar mucho en detalle en todas las metodologías
expuestas (salvo Agile aplicado a la empresa) puesto que cada metodología requiere de un
estudio pormenorizado que se excede con mucho del contenido para este módulo, en
concreto, y para el máster, en general.
¡Ser experto en una metodología determinada puede llevarte años de entrenamiento!
Ejemplo Lenguajes programación
Como posiblemente ya sepas, existen distintos lenguajes de programación. Cada

lenguaje de programación se usa en función de las necesidades del desarrollo en cuestión.
Por ejemplo, Java es muy usado en sistemas operativos, C es altamente recomendado

para hardware, C++ está más orientado a un entorno industrial o como el conocido PHP, usado
en multitud de webs (wordpress).
Pues bien, las metodologías de gestión de proyectos son iguales. Hay multitud de ellas
y cada una está pensada para un cometido determinado. Por ejemplo, Scrum esta ideado para
desarrollos informáticos (sistemas, apps, webs) al igual que Agile, que además también
permite desarrollos físicos (productos).
Descargar vídeo

Prince2
PRojects IN Controlled Environments (PRINCE), es un método de gestión de proyectos

que cubre la administración, control y organización del mismo.
Su historia se remonta a 1989 en Reino Unido, tras su publicación rápidamente se

convierte en estándar para todos los proyectos de sistemas de información del gobierno. En la
actualidad es un sistema que se usa en multitud de países, ya sea en entidades públicas así
como en empresas privadas, por citar algunos ejemplos: Reino Unido, Canadá, Nigeria, British
Airways, DHL, Rabobank, ONU, Banco Mundial, y muchos más.
La metodología Prince2 se puede aplicar en proyectos de toda índole: Desarrollo de

software, Construcción, Explotación Infraestructuras, etc.
Prince2 propone una metodología que busca en todo momento la justificación y

avance del proyecto, mediante la identificación y supervisión de diversas áreas, organizadas
por familias: calidad, cambio, roles proyecto, planes, riesgo, progreso proyecto y viabilidad.
Además, bajo una metodología Prince2 se elabora un manual de gestión del proyecto
en cuestión para que todos los involucrados hablen el mismo idioma.
A mayores, esta metodología correctamente implantada, mejora la colaboración, la

comunicación y el control de la organización en diversas áreas.
Este método fue, en sus inicios, desarrollado únicamente para proyectos TIC aunque la
última versión, Prince2, es compatible con la gestión de todo tipo de proyectos y, en general,
es una metodología muy aplicada por Administraciones Públicas. Dichas entidades sienten la
necesidad de estandarizar la gestión de sus proyectos desde la particular posición de una
administración y de su especial relación con una empresa privada externa, que actúan en
representación de la administración como “dirección integrada de proyecto”.

Algunos beneficios de Prince2:
 Administrar el proyecto en cuestión para que la organización mantenga un

seguimiento entre los costes esperados y los beneficios del proyecto en cuestión.
 Roles y responsabilidades claras, para que todos los involucrados conozcan lo que
se espera de ellos.
 Planes orientados al producto que aseguran que la empresa y los usuarios pueden
definir claramente que resultados esperan del proyecto.
 Informes claros y concisos para cada nivel de gestión del proyecto.
 Un procedimiento para asegurar que los no se introducen cambios en el proyecto
sin control y supervisión oportuna
 Un proceso para garantizar el aprendizaje validado a lo largo del proyecto
Vídeo Explicación Prince2 (Cupcakes) – Ingles – 3,29 min.
Vídeo Explicación Prince2 (Esquematica) – 2,53 min.
Vídeo explicativo Prince2 en 1 min (Inglés) 1,38 min.
Lean Six Sigma
Altos porcentajes de beneficios empresariales pueden perderse por el camino debido a

los desperdicios que se producen en procesos de fabricación. Además, muchas empresas
invierten tiempo y dinero en desarrollos de productos sin estar seguras de que el cliente
comprara determinado producto/servicio o estará dispuesto a pagar un incremento por
determinada funcionalidad.
Bajo estas dos premisas anteriores, el fundador de Toyota, su hijo y el director Taiichi
Ohno (Toyota), generaron un sistema de producción que les permitiese solventar dichas
dificultades.
Inicialmente, conocido como JIT (just in time) ha evolucionado al más conocido hoy en
día como Lean Manufacturing. Posteriormente, en un ambiente industrial se le añadió la
predicción de errores.

La filosofía Lean se basa principalmente en la reducción y/o eliminación de residuos y

actividades que no agregan valor al cliente. Six Sigma se centra en la reducción de errores. Es
por ello que Lean se basa principalmente en la rapidez, agilidad y reducción de actividades no
necesarias. Six Sigma se basa en calcular y aumentar la fiabilidad de la organización en sí
misma.
Debido a la búsqueda continua por parte de las empresas del beneficio (aumento
ingresos, reducción costes), Lean Six Sigma se ha popularizado tanto en la industria como en el
desarrollo de servicios e incluso gobiernos.
En la actualidad, se pueden encontrar ejemplos de aplicación de Lean Six Sigma (Lean

Manufacturing) en todo tipo de sectores: Minería, Energía, Logística, Transporte, Educación,
etc.
Algunos beneficios de Lean Six Sigma
 Aumento eficiencia de proceso y niveles de calidad.

 Aumento productividad y reducción existencias.
 Reducción costes de producción.
 Maximización del beneficio operativo.
 Satisfacer las necesidades de los clientes.
 Control total sobre los flujos del proceso.
 Organización innovadora y flexible.
 Plazos más reducidos.
 Optimización de resultados en organizaciones sin ánimo de lucro.
Vídeo Explicación Lean Six Sigma (Esquema) – Inglés – 2,15 min.
Scrum
Scrum es una metodología ágil para desarrollar productos complejos. Inicialmente, su

uso estaba orientado a proyectos de software y tecnología. Su flexibilidad y amplio enfoque
permiten usar esta metodología en proyectos con una alta incertidumbre y necesidad de
adaptación rápida y flexible.

Nonaka y Takeuchi (ambos profesores universitarios) crearon su metodología

basándose principalmente en el estudio de cómo empresas (NEC, Epson, HP…) desarrollaban
nuevos productos.
Esta metodología, se basa en varios componentes interconectados, denominados

“Equipos Scrum” con sus roles, eventos y reglas asociadas. Cada componente, dentro de la
metodología, sirve a un propósito específico. Scrum se basa en la teoría del control empírico
del proceso, asumiendo que el conocimiento proviene de la experiencia (ensayo prueba-error)
y la toma de decisiones se basa en lo que se conoce.
La metodología, explicado de forma muy resumida, se basa en “sprints” que, por

norma general, tienen una duración de 1 a 4 semanas, el equipo genera una funcionalidad
(incremental) en el proyecto (hardware/software). Las funcionalidades que deben
desarrollarse han sido trabajadas y validadas antes. Así se evitan desarrollos largos, que
implican mayores riesgos al desconocer el resultado del trabajo realizado en un periodo lejano
en el tiempo.
La metodología Scrum debe su popularidad a las necesidades de las personas y los

equipos para asumir la responsabilidad, colaborar, desarrollarse, entregar el resultado y dar lo
mejor de sí mismos para los destinatarios de su trabajo.
Algunos beneficios de Scrum:
Flexibilidad.
Reducción del coste.
Entregas más rápidas.
Transparencia en el estado y progreso del proyecto
Menos gastos generales para protocolos y planes.
Constantemente buscando mejoras en el proceso y enfoque.

Vídeo Explicación Scrum (Dibujos) – Inglés – 2,15 min.
Vídeo explicación Scrum (Esquema) – Inglés – 7,51 min.
Agile – Agile Project Management
Como espero que compartas conmigo, creo que no me equivoco si digo que vivimos en
una sociedad donde los cambios suceden cada vez con más rapidez. Estos cambios en la
sociedad moderna, viene impulsados, entre otros, por la implantación de la tecnología.
Para muestra las siguientes fotos:
Aquí mostramos como, en 20 años, se ha desarrollado tanto la tecnología que

podemos llevar en la palma de la mano tantas soluciones tecnológicas que equivalen a 8
aparatos.
Estos cambios, como es lógico, también afectan a las empresas. Por lo tanto, las
empresas necesitan un enfoque más flexible que les permita adaptarse más rápidamente a las
necesidades cambiantes de la sociedad (sus clientes).

La metodología Agile es un conjunto de técnicas y herramientas especialmente ideada

para el desarrollo de proyectos que precisan de una especial rapidez y flexibilidad en su
proceso.
El desarrollo de proyectos, siguiendo la metodología ágil, se basa en el desarrollo del

proyecto en cuestión mediante su división en partes más pequeñas, llamadas iteraciones. Cada
iteración es diseñada y revisada por el equipo del proyecto, que podría incluir: desarrolladores,
técnicos, negocio e incluso clientes. Los resultados (aprendizaje) obtenidos de la observación
del comportamiento de la iteración en cuestión son usados para decidir que rumbo seguir en
la siguiente iteración.
La metodología Agile es útil en multitud de áreas: desarrollo de software, innovación,

marketing, publicidad, desarrollo de productos, diseño de servicios, Internet, etc. Muchas
empresas están aplicando Agile para el desarrollo de productos y servicios: Google, Apple,
Spotify,…
Cabe destacar que la implantación de metodologías agiles (agile) en empresas que ya

disponen de otras metodologías de gestión de proyectos (tradicionales) suele resultar
complicada ya que se considera que dicha metodología (Agile) asume muchos riesgos. Es por
ello que es necesario una metodología Agile pero bien fundamentada, que se conoce como
Agile Project Management.
Los principios de la metodología Agile
 Centrarse en las necesidades del negocio

 Entrega a tiempo
 Colaboración
 Nunca comprometer la calidad
 Desarrollar producto (empresa, startup y/o servicio) añadiendo
funcionalidades incrementales, sobre unos requerimientos bien definidos
 Desarrollo iterativo
 Comunicación fluida
 Agile aplicado al desarrollo de negocio permite disponer de ventaja
competitiva para cualquier empresa.
 Uso de métricas relevantes

Algunos beneficios de Agile:
 Desarrollo de la solución con los usuarios

 Menos probabilidades de desarrollar la solución equivocada
 La solución final satisface los requerimientos de usuarios y empresas
 La implementación se ejecutará fase a fase (funcionalidad)
 Mayor retorno sobre la inversión (ROI)
Los 8 principios Agile:
 Nuestra prioridad es satisfacer al cliente entregando producto/servicio de calidad

a la mayor brevedad posible.
 Los cambios en los requisitos del proyecto no son mal vistos. La metodología Agile
acepta esos cambios y los convierte en ventajas competitivas frente al cliente,
adaptándose más rápido a sus necesidades.
 Entregando resultados con frecuencia y mediante los ciclos (tiempo) más corto
posible, días mejor que semanas, semanas mejor que meses.
 Desarrolladores de producto (software/hardware) deben trabajar conjuntamente
con desarrolladores de negocio (ventas, marketing…).
 La mejor manera de compartir información es cara a cara (trabajadores, empresa-
cliente).
 Producto que funciona es la mejor manera de comprobar el progreso.
 Atención cuidad por la calidad del producto/servicio aumenta la agilidad.
 Búsqueda continúa de la simplicidad por encima de todas las cosas.
Gestión de Proyectos: Tradicional vs Agile
Introducción
La revolución industrial, entre muchas otras cosas, supuso la división del trabajo por
tareas, todas ellas, perfectamente diseñadas para encajar con la tarea siguiente en la cadena
de montaje.
Es un magnifico sistema cuando los resultados son conocidos de antemano y cuando

es necesario mejorar la eficiencia y eficacia lo máximo posible.

Esta división del trabajo se basa principalmente sobre una premisa: ESTABILIDAD y
PREDICCIÓN
Volviendo a la cadena de montaje, es conocido el estado en el que recibiremos el ítem

(PREDICCIÓN) del puesto anterior, las cosas estarán en su sitio y la tarea debe ser realizada
siguiendo un orden definido (ESTABILIDAD). Es imprescindible que la tarea se haga según los
estándares oportunos para que el siguiente puesto pueda realizar su tarea sobre el ítem en
cuestión de manera óptima.
A todos se nos viene a la cabeza una cadena de montaje moderna, donde un operario
realiza una tarea más o menos repetitiva sobre unos ítems que recibe siempre en un estado
definido.
Esa misma metodología (trabajo en cadena) se aplicó al mundo de las empresas

durante muchos años. Francamente, ahora sabemos que los resultados podrían haber sido
mucho mejores si hubiésemos aplicado otras metodologías de gestión de proyectos.
Desarrollo en Cascada vs Desarrollo Ágil
Como veíamos antes, la división del trabajo por fases y tareas definidas es un sistema
muy robusto cuando todos los condicionantes permanecen dentro de una estabilidad
determinada.
Como bien sabes, un fallo en una fase y/o tarea determinada en un punto concreto de
la cadena de producción tiene una influencia directa en todos los puestos siguientes de la
cadena de montaje.
Pero, ¿y qué pasa si no podemos contar con un entorno estable y predictivo? Si

estamos gestionando un proyecto donde los inputs para nuestro trabajo no permanecen
estables, sino que incluso van cambiando según va avanzando el proyecto, e incluso, si los
ítems no es posible predecir cuales serán, estamos ante una situación de incertidumbre total
que afectara precisamente sobre la línea de flotación de nuestra gestión.

Necesitamos pues metodologías que nos permitan introducir el ítem “incertidumbre”

en nuestra gestión y es aquí donde surgen las metodologías Agiles.
Con el objetivo de facilitar una metodología de gestión diferente para solventar los
principales problemas de la gestión tradicional de proyectos, un nuevo grupo de metodologías
ha surgido y se han estructurado en los últimos años.
Estos nuevos métodos buscan un justo equilibrio entre la no-existencia de procesos y

el exceso de los mismos. Los métodos ágiles cambian significativamente muchos de los
parámetros que definen la gestión tradicional de proyectos como por ejemplo:
 Los métodos ágiles son adaptables en lugar de predictivos. Los métodos

tradicionales tienden a intentar planear una parte grande del proceso en gran
detalle para un plazo largo de tiempo, eso funciona bien hasta que aparecen los
imprevistos. Los métodos tradicionales responde a su naturaleza para resistirse al
cambio. Sin embargo, en los métodos ágiles, el cambio es bienvenido. Intentan ser
metodologías que adaptan sus procesos y crecen con el cambio.
 Los métodos ágiles están orientados a las personas en lugar de al proceso. La meta
de los métodos tradicionales es definir un proceso que funcionará bien con
cualquiera que lo use, sin embargo los métodos ágiles afirman que ningún proceso
podrá maquillar las habilidades del equipo de modo que el papel del proceso es
apoyar al equipo en su trabajo.
Descargar vídeo

Empresas y Startups aplicando Lean & Agile
Tal y como veíamos antes, los proyectos se basan en determinados ítems (información,
entorno, recursos, tiempo, presupuesto, etc.) que se preveían estables.
Sobre todo en el entorno empresarial esto ha cambiado, principalmente por dos

motivos:
 El cliente ha cambiado y cambia muy rápido.

 Surgen nuevos modelos de negocio.
Estamos ante un cliente que no se comporta igual que hace 2 años y mucho menos
igual que hace 5 años. El cambio en los hábitos del consumidor evoluciona y se prevé que cada
vez suceda con más rapidez, gracias principalmente a la incursión de la tecnología.
Por supuesto, los modelos de negocios de las empresas y startups también han
evolucionado.
Quizás te suene el caso de AirBnb, la plataforma líder a nivel mundial en alquiler de

alojamientos. Esta empresa tecnológica (recordar que no tiene ni una sola habitación para
alquiler en propiedad), está valorada en 25.000 millones USD, 4000 millones USD más que la
empresa Marriott International (con presencia mundial, más de 5000 hoteles, 1,1 millones
habitaciones, más de 151.000 empleados, con marcas reconocidas como Ritz).
Reflexión: Quien le iba a decir a Marriott Internacional hace unos años que una página
web sin habitaciones en propiedad seria su competencia y que además, le superaría en
valoración. Seguramente nadie pensaría que eso era posible. Todo reside en el modelo de
negocio de Airbnb y el cambio en las reglas de juego.
Y como todos sabemos, las empresas (y startups) hacen productos (o entregan

servicios) para que los clientes los compren y además, deben protegerse de la competencia y
el entorno.

Ejemplo Kodak
Un claro ejemplo de NO adaptabilidad a los cambios que surgen en el mercado fue la

empresa mundialmente conocida Kodak. Dedicada a todo lo relacionado con la imagen: Cine y
Cámaras principalmente. Debido al cambio en su sector y su falta de adaptación, su volumen
de negocio cayó drásticamente, sobre todo en lo relacionado con la venta de películas para
fotografías. En 2012 solicito el concurso de acreedores (Ley de Quiebras USA) para reorganizar
su negocio y sobrevivir a su crisis de resultados.
Por lo tanto, si damos por valido que el cliente cambia muy rápido y el entorno
también, las empresas (y startups) deben adaptar nuevas metodologías que les permitan
lanzar nuevos proyectos adaptados a las necesidades de los clientes. Es aquí donde surgen las
metodologías Agile y Lean (Lean Startup)
Ejemplo DollarShaveClub
Un ejemplo de creación de nuevos modelos de negocio es Dollar Shave Club. Esta

startup, basa su novedoso modelo de negocio en que mediante el pago de una cuota mensual,
la empresa envía al cliente un paquete con todo lo necesario para afeitarse durante un mes
(disponen de diversos packs en función de las necesidades.)
Por lo tanto, han pasado de un modelo de negocio bajo demanda (el usuario acudía a
un punto de venta para comprar los recambios de la maquinilla) a un modelo de suscripción,
donde el usuario, mediante un pago recurrente, recibe cómodamente en su domicilio lo
necesario para su afeitado. Ese sustancial cambio, permite a la startup disponer de un modelo
de ingresos recurrente y predecible (conocen datos del cliente y su carencia para comprar
maquinillas). También permite un ahorro en publicidad y un ahorro en distribución e
intermediarios.
Esta startup, ha sido adquirida recientemente por Unilever, para explotar su base de
datos y para plantarle cara a su competidor: Gillete
Descargar vídeo
Material de Apoyo: Wikispeed. Construir un coche aplicando Agile, Lean & Scrum

1.2. Herramientas para gestión de proyectos
Una vez hemos conocido las distintas metodologías disponibles para la gestión de
proyectos empresariales, vamos a entrar ahora en la parte más práctica. En función de la
metodología que escojamos para gestionar nuestro proyecto empresarial, debemos conocer
las distintas herramientas existentes y escoger la más adecuada para nuestro proyecto.
Diferencia entre Herramienta y Metodología
Uno de los objetivos de cualquier clase (y profesor) es que el alumno aprenda sobre un
tema concreto pero también que aprenda a desenvolverse en el futuro por su cuenta. A lo
largo de estos años, me he encontrado con multitud de profesionales, que dentro del área de
gestión de proyectos, no sabían diferenciar correctamente entre técnicas, herramientas y
metodologías.
 Metodología: (aplicado a gestión de proyectos empresariales): conjunto de métodos,

conocimientos y procedimientos que nos permiten resolver y/o gestionar un proyecto
empresarial en determinadas condiciones. Dicha metodología, para tener éxito en su
implementación, entre otras cosas, debe ser conocida por las personas expuestas a
dicha metodología.
 Herramientas: (aplicado a la gestión de proyectos empresariales): tanto técnicas o

procedimientos específicos como elementos de software que permiten al PM
gestionar las actividades y la información relativa un proyecto en cuestión. Para ser
considerara una buena herramienta, debe facilitar el trabajo y facilitar la toma de
decisiones por parte del PM.
Herramientas más conocidas
Work Breakdown Structure
El diagrama WNS tiene forma de árbol invertido. En dicho diagrama se va desglosando

cada actividad necesaria para el proyecto, empezando por el objetivo en el que sería el primer
nivel, el “tronco” del árbol.

Las diferentes actividades necesarias para alcanzar el objetivo se van definiendo en

subdivisiones dependientes unas de otras (las ”ramas”). De esta forma es más sencillo detallar
tareas y costes, así como predecir resultados.
Diagrama de Gantt
El diagrama de Gantt es una herramienta de gestión de proyectos empresariales muy

conocida. En dicha herramienta se reflejan las actividades en las que el proyecto se basa,
adscritas siempre a una variable tiempo para un trabajo ordenado.
Diagrama de Pert
PERT es otra herramienta de planificación de proyectos empresariales que resulta muy

útil cuando el proyecto consta de muchas actividades que discurren en paralelo y de forma
secuencial. Este método trabaja con distintas probabilidades asociadas a la variable tiempo.

PDCA (Plan, Do, Check, Act)
PDCA es una herramienta de gestión de proyectos de uso muy extendido que se

articula en torno a cuatro pasos, que deben ser aplicados de forma cíclica, es decir, al acabar el
último se deberá volver al primero, para conseguir los resultados deseados. De esta forma
todas las actividades se re-evalúan de forma periódica y se consigue mejorar. Se trata de una
herramienta muy usada en los proceso Lean y Agile.
Matriz Responsabilidades (RAM)
Esta herramienta se utiliza junto con la estructura de desglose de trabajo y sirve para
definir el departamento y la persona responsable de alcanzar unos resultados determinados
en función de la información contenida en la matriz.

Kanban - Tarjetas
Se trata de una técnica visual que se utiliza para conocer el estado de avance de
diversas tareas. Esta técnica se creó en Toyota, y se utiliza para controlar el avance del trabajo,
como puedes imaginar, más orientado a una cadena de producción.
Kanban no es una técnica especifica dentro de la filosofía Agile, si no que es una

herramienta (visual) que permite conocer el estado de los proyectos. En los últimos años se
viene introduciendo esta herramienta en la gestión de proyectos mediante metodología Scrum
y/o Agile.

Project Dashboard (KPI)
Esta herramienta es útil, principalmente, para optimizar el factor tiempo. El Project

Manager tiene que conocer en todo momento el estado del proyecto, sin embargo, estar al
tanto de tantas variables, sobre todo cuando se trata de proyectos complejos o de gran
magnitud, es de gran magnitud no resulta sencillo e implica una importante inversión en
tiempo.
Un Project Dashboard debe resumir las principales variables de un proyecto en un

único panel, que permita al PM conocer de manera rápida y cómoda el avance del proyecto. Si
hablamos de un panel visual mejor, pero también podemos basarnos en una tabla con los
principales indicadores del estado de avance del proyecto (KPI).
Tipos por funcionamiento
Tras ver anteriormente distintas herramientas que podemos usar para gestionar
nuestros proyectos empresariales, veremos a continuación algunos ejemplos de aplicaciones y
suites (herramientas digitales) que podemos usar para gestionar nuestro proyecto
empresarial.
Objetivos y Focus
Antes de ver las herramientas disponibles, me gustaría aportar 2 detalles que considero
fundamentales a la hora de gestionar nuestros proyectos empresariales con una herramienta
de gestión:

 Objetivo: no debemos olvidar que estamos gestionando un proyecto empresarial.

Ese es el único objetivo que debemos tener en mente. Por eso, a la hora de escoger
una aplicación o suite que nos ayude en la gestión de nuestro proyecto empresarial
debemos tener en mente que lo importante es el proyecto y para nada la suite en si
misma. No perdamos el foco.
 Utilidad: la suite escogida debe ser cómoda y practica para los integrantes del
proyecto. De nada sirve que la suite tenga mil funcionalidades y que eso implique
más dificultad para el usuario y que por ello, dificulte todavía más su tarea.
Colaboración
Entramos en materia en lo que a sistemas para gestión de proyectos se refiere. No

querría desgranar las distintas herramientas informáticas disponibles sin comentar una
característica que considero vital hoy en día para que cualquier aplicación pueda ser
implantada con éxito en cualquier empresa y/o startup.
Ya estemos hablando de una startup unipersonal (1 persona), de una micropyme (2-3

empleados), pyme (hasta 50 empleados) o de grandes empresas, en todos los proyectos
participan al menos dos figuras: empresa y cliente. Si después añadimos proveedores,
colaboradores y/o empleados, el número comienza a crecer.
Es por ello, que una característica de vital importancia hoy en día es la colaboración
(en línea y en directo) de las distintas personas que tienen influencia en el devenir del
proyecto.
Ejemplo: Bitrix
Aplicaciones nativas
Una aplicación que encaja con esta categoría es Microsoft Enterprise Project
Management. Esta herramienta, dispone de un software que debe ser instalado en el propio

ordenador del usuario para así poder usarla. Se trata de una herramienta muy potente, que
tras una implantación (generalmente con un coste elevado y realizada por expertos) permite
gestionar todos los aspectos relevantes de un proyecto y/o empresa.
Más información: aquí
Suites
Capítulo aparte merecen soluciones englobadas dentro de una suite completa.

Podemos destacar principalmente a dos de ellas:
 Google Suite y sus herramientas: Google es una multinacional de sobra conocida, y

como muchos quizás conozcáis, ofrece diversas soluciones online para el usuario
(incluida la empresa) con sus soluciones de correo como punta de lanza.
Herramientas conectadas entre ellas, almacenadas en la nube que permiten a los

equipos trabajar y colaborar sobre distintos proyectos. No dispone de aplicaciones
propiamente dicha para gestionar proyectos, pero para según que proyectos, pueden ser
soluciones válidas.
La conexión entre su correo electrónico, calendar (compartido con otros usuarios), su

sistema de almacenaje en la nube (drive) y google docs permite a un equipo determinado
poder gestionar un proyecto empresarial en la nube de manera más o menos sencilla.
 SAP: SAP es una multinacional alemana que ofrece multitud de soluciones en cuanto a
software de gestión y de gestión de proyectos. Es una empresa referente en su sector,
siendo su nombre (SAP) asociado a sistemas de gestión empresarial que a su vez
generan especialización en distintos profesionales.
Puedes obtener más información aquí.
SaaS + mobile App

Para poder aplicar metodologías Agile y Lean para la gestión de proyectos

empresariales, lo más recomendable es que dichas herramientas sean lo más visuales posibles.
Hay multitud de herramientas, y cada una de ellas tiene sus peculiaridades en función
de las necesidades del proyecto a gestionar.
Si me permitís, en mi caso particular, yo veo imprescindible que sea una herramienta

colaborativa (obvio) y, además, que disponga de una buena App.
Muchas de estas aplicaciones tienen funcionalidades en la web que trabajando desde

una pantalla del móvil en un entorno web no funcionan nada bien, por ello, la aplicación nativa
para nuestro móvil es importante.
Si además dispone de sistema offline para poder trabajar sin conexión a Internet (no
hay nada más molesto que tener que trabajar y no poder hacerlo por no disponer de conexión
a Internet) pues entonces ya es la solución perfecta.
Una cuarta cualidad de la aplicación, quizás una de las más importantes, es que resulte
sencilla de implantar, sencilla de usar y que la curva de aprendizaje para adaptarse a la
aplicación sea muy rápida. No hay nada peor como escoger una aplicación determinada y que
resulte una complicación añadida para tu equipo. Eso conllevara frustración y dejadez a la hora
de gestionar sus tareas en la herramienta en cuestión.
No hay nada peor como creer que una herramienta está actualidad con la última
información sobre el desarrollo del proyecto en cuestión y encontrarte con que realmente no
es así. O peor aún, tomar decisiones pensando que si lo está.
Aplicaciones de este tipo hay muchas, cada vez más.
Alguna de ellas:
 LeanKit

 KanbanFlow
 Agile Zen
 Trello
Puedes hacer una búsqueda específica para tu propia empresa y/o startup, según tus
necesidades aquí.
Recomendaciones y Errores al gestionar proyectos empresariales
Antes de que te sumerjas de lleno en el apasionante mundo de la gestión de proyectos

empresariales, me gustaría cerrar esta clase con varios consejos que considero pueden serte
de utilidad en el día a día de la empresa. Como siempre, hay algunos “must do” que se van
descubriendo a base de la experiencia, principalmente a base de equivocarse :-)
También hay algunos errores, que al igual que las recomendaciones, se van aprendiendo a
base de cometerlos.
Espero poder trasladarte con estas recomendaciones algunos tips útiles para que puedas
aplicar en tus proyectos.
Recomendaciones para gestionar proyectos empresariales con éxito
 Escoger una metodología correcta para el proyecto en cuestión.

 Escoger una herramienta (Nativa, SaaS …) pensada para la metodología que vas a
aplicar.
 Alinea a tu equipo con el proyecto en cuestión, con la metodología y la herramienta
que vais a aplicar.
 Define los roles de tu equipo. Asegúrate de que todos lo han entendido.
 Forma a tu equipo en lo que haga falta: conocimiento técnico, conocimiento
teórico/practico sobre la metodología y/o bien uso de la herramienta de gestión.
 Identifica tareas y/o hitos críticos.
 Evita multitareas.
 Evita la parálisis por análisis.
 Evita quedarte parado en los detalles menores.
 Documenta los avances del proyecto.

Errores habituales a la hora de gestionar proyectos empresariales.
 No definir claramente los objetivos finales del proyecto, los objetivos intermedios y
los objetivos para cada miembro del equipo.
 Definir erróneamente las fases, tareas y recursos necesarios para la ejecución del
proyecto.
 No permitir cambios a lo largo de la vida del proyecto.
 Solo analizar resultados al final del proyecto.
 Pensar en el equipo casi como un ítem más del proyecto y no como una parte
fundamental del proyecto.
 No disponer de un canal de comunicación fluido y eficaz entre los miembros del
equipo así como con externos (proveedores...).

1.3. Diferentes metodologías de gestión ágil de

proyectos. (Comparativa)
1.3.1. INTRODUCCIÓN
Las metodologías de gestión de proyectos comenzaron a gestarse como tal en los años
50, en el ejército estadounidense, con el objetivo de intentar reducir el volumen de proyectos
que se descontrolaban y ayudar a solventar problemas comunes que se habían identificado en
relación a:
 Exceso de carga de trabajo planificada o en proceso.

 Costes que superan el presupuesto inicial.
 Problemas en la calidad, valor o utilidad del resultado final.
Actualmente, nos encontramos en una era 3.0 en la que la organización del trabajo por
proyectos se está convirtiendo en una realidad cada día mas presente en las empresas. Este
tipo de organización requiere de formas de gestión y colaboración nuevas para poder
favorecer las nuevas formas de implementar. Por ejemplo, un responsable de proyecto no
tiene un estatus jerárquico específico pero constantemente se ve obligado a negociar sin
poder emplear una autoridad ligada al estatus. Consecuentemente es uno de los primeros
responsables de la empresa que debe desarrollar sus competencias de gestión transversal.
Como veremos a lo largo del capítulo, la gestión de proyectos puede ser predictiva o
ágil y, como ocurre en cualquier disciplina, existen defensores de una y de otra. La decisión
final de cuál elegir dependerá de varios factores pero uno de los más importantes es la
prioridad final para el proyecto ya que como veréis a continuación, mientras que la
metodología predictiva le otorga más importancia a los procesos, los métodos ágiles
consideran que el valor o utilidad final del resultado que se quiere obtener es lo más
importante.
Poco a poco iremos conociendo en el contenido, objetivos y parámetros de actuación

generales de ambas metodologías.

1.3.2. GESTIÓN TRADICIONAL DE PROYECTOS
Históricamente, las organizaciones se han gestionado de acuerdo a principios

Tayloristas (podéis encontrar información aquí) de división y especialización del trabajo por
departamentos o funciones diferenciadas. Se asienta bajo las siguientes premisas:
 Estabilidad del entorno. Considera que todos los proyectos tienen

características y comportamientos regulares, guiados por un patrón,
desarrollados en un entorno estático y predecible.
 Carácter predictivo, en el sentido de que se define al detalle el resultado que se
quiere conseguir. Lo importante son los procesos, no el valor final del
producto, de forma que los esfuerzos se orientan a cumplir en términos de
tiempo, costes y recursos. Siendo sus principales valores la planificación y el
control.
Su principio general se basa en que “la forma más eficiente de desarrollar un trabajo es
hacerlo bien a la primera”, pero la realidad nos dice que esto solo es posible si se puede
conocer al detalle el resultado que se quiere obtener y se trabaja en un entorno estable.

Diferentes metodologías de la gestión tradicional de proyectos
PMP
PMP es un estándar de actuación para la administración de proyectos que ha sido

desarrollado por el Project Management Institute (PMI) y que comprende dos grandes
secciones:
 La primera sobre los procesos y contextos de un proyecto.

 La segunda sobre las áreas de conocimiento específico para la gestión de un
proyecto.
La Guía del PMBOK (instrumento de regulación y funcionamiento del PMP) es el

estándar de gestión de proyectos tradicionales más usado ya que reúne una colección de
procesos y conocimiento aceptados como las mejores prácticas dentro de la gestión de
proyectos.
El PMBOK es un estándar reconocido internacionalmente (IEEE Std 1490-2003) que

provee los fundamentos de la gestión de proyectos que son aplicables a un amplio rango de
proyectos, incluyendo construcción, software, ingeniería, etc., teniendo como base el
reconocimiento de 5 grupos de procesos básicos y 9 áreas de conocimiento comunes a casi
todos los proyectos.
Los 5 grupos básicos de procesos son:
 Iniciación: Define y autoriza el proyecto o una fase del mismo. Está formado por dos
procesos.
 Planificación: Define y refina los objetivos y planifica el curso de acción requerido
para lograr los objetivos y el alcance pretendido del proyecto. Está formado por
veinte procesos.
 Ejecución: Compuesto por aquellos procesos realizados para completar el trabajo
definido en el plan a fin de cumplir con las especificaciones del mismo. Implica
coordinar personas y recursos, así como integrar y realizar actividades del proyecto
en conformidad con el plan para la dirección del proyecto. Está formado por ocho
procesos.
 Seguimiento y Control: Mide, supervisa y regula el progreso y desempeño del
proyecto para identificar áreas en las que el plan requiera cambios. Está formado

por diez procesos.

 Cierre: Formaliza la aceptación del producto, servicio o resultado, y termina
ordenadamente el proyecto o una fase del mismo. Está formado por dos procesos.
Las nueve áreas del conocimiento mencionadas en el PMBOK son:
 Gestión de la integración del proyecto: Incluye los procesos y actividades

necesarios para identificar, definir, combinar, unificar y coordinar los diversos
procesos y actividades de la dirección de proyectos dentro de los grupos de
procesos de dirección de proyectos.
 Gestión del alcance del proyecto: Incluye los procesos necesarios para garantizar
que el proyecto incluya todo (y únicamente todo) el trabajo requerido para
completarla con éxito.
 Gestión del tiempo del proyecto: Incluye los procesos requeridos para administrar
la finalización del proyecto a tiempo.
 Gestión de los costos del proyecto: Incluye los procesos involucrados en estimar,
presupuestar y controlar los costos de modo que se complete el proyecto dentro
del presupuesto aprobado.
 Gestión de la calidad del proyecto: Incluye los procesos y actividades de la
organización ejecutante que determinan responsabilidades, objetivos y políticas
de calidad a fin de que el proyecto satisfaga las necesidades por la cuales fue
emprendido.
 Gestión de los recursos humanos del proyecto: Incluye los procesos que
organizan, gestionan y conducen el equipo del proyecto.
 Gestión de las comunicaciones del proyecto: Incluye los procesos requeridos para
garantizar que la generación, la recopilación, la distribución, el almacenamiento,
la recuperación y la disposición final de la información del proyecto sean
adecuados, oportunos y entregada a quien corresponda (interesados del proyecto
o stakeholders).
 Gestión de los riesgos del proyecto: Incluye los procesos relacionados con llevar a
cabo la planificación de la gestión, identificación, el análisis, la planificación de
respuesta a los riesgos, así como su monitoreo y control en un proyecto...
 Gestión de las adquisiciones del proyecto: Incluye los procesos de compra o
adquisición de los productos, servicios o resultados que es necesario obtener
fuera del equipo del proyecto.

ITIL
La Biblioteca de Infraestructura de Tecnologías de Información, frecuentemente

abreviada ITIL (Information Technology Infrastructure Library), es un conjunto de conceptos y
prácticas para la gestión de servicios de tecnologías de la información, el desarrollo de
tecnologías de la información y las operaciones relacionadas con la misma.
ITIL es una buena metodología porque da descripciones detalladas de un extenso

conjunto de procedimientos de gestión ideados para ayudar a las organizaciones a lograr
calidad y eficiencia en las operaciones de TI. Estos procedimientos son independientes del
proveedor y han sido desarrollados para servir como guía que abarque toda infraestructura,
desarrollo y operaciones de TI.
Aunque se desarrolló durante los años 80, ITIL no fue ampliamente adoptada hasta
mediados de los años 90. Esta mayor adopción y conocimiento ha llevado a varios estándares,
incluyendo ISO/IEC 20000, que es una norma internacional cubriendo los elementos de gestión
de servicios de IT de ITIL. Los estándares de calificación ITIL son gestionados por la ITIL
Certification Management Board (ICMB) que agrupa a la OGC, a itSMF International y a los dos
Institutos Examinadores existentes: EXIN (con sede en los Países Bajos) e ISEB (con sede en el
Reino Unido).
PRINCE Y PRINCE 2
PRojects IN Controlled Environments (PRINCE), es un método de gestión de proyectos

que cubre la administración, control y organización del mismo. En 1989, se publica y
rápidamente se convierte en el estándar del Reino Unido para todos los proyectos de sistemas
de información del gobierno.
Las características principales de PRINCE son:
 Una estructura de gestión definida

 Un sistema de planes de dotación de recursos y problemas técnicos
 Un conjunto de procedimientos de control
 Un enfoque sobre los productos, prestaciones para el cliente y prestaciones del
proyecto

Se basa en 6 principios básicos que contribuyen al éxito de cualquier proyecto:
 Elaboración de un business case

 Desarrollo de planes
 Progreso
 Organización
 Riesgo
 Calidad
Este método fue inicialmente desarrollado solo para proyectos TIC aunque la última
versión, PRINCE2, es compatible con la gestión de todo tipo de proyectos. En general, se trata
de una metodología muy aplicada para aquellas administraciones públicas que sienten la
necesidad de estandarizar la gestión de sus proyectos desde su posición. Además, pueden
complementar su trabajo con una empresa privada externa de “dirección integrada de
proyecto” que actúe en nombre y representación de la administración.
Los errores más comunes del fracaso de un proyecto
Analizar los errores más habituales que impiden que los proyectos lleguen a buen
término y que no se ajusten a lo esperado en términos de resultado, plazo o rentabilidad nos
ayudará a elegir correctamente la metodología a aplicar.
Los errores más habituales son:
 No definir claramente los objetivos del proyecto: Una de las principales causas del
fracaso de los proyectos es la falta de objetivos claros, medibles y alcanzables. Es
necesario saber qué se quiere conseguir para poder dirigir convenientemente los
esfuerzos de todas las partes implicadas. Además, es fundamental en este proceso
la gestión de las expectativas del cliente, ya sea interno o experto, para asegurarse
de que los objetivos fijados están alineados con lo que realmente espera obtener y
garantizar así su satisfacción con el resultado del proyecto.
 Planificar de forma errónea las fases, tareas y recursos necesarios para la ejecución
del proyecto: En esta planificación es imprescindible ser realista y, para ello, la
experiencia acumulada juega un papel fundamental para evitar subestimar las
necesidades de recursos o los plazos necesarios para la ejecución de cada una de las

tareas. Además, deben definirse hitos que sirvan como referencia de la evolución
del proyecto y faciliten su posterior seguimiento. Todo ello sin perder la visión
global del proyecto. Una planificación adecuada permite a los miembros del equipo
conocer con anticipación los próximos pasos a seguir para evitar retrasos y tiempos
muertos.
 No utilizar la metodología adecuada: Cada tipo de proyecto (en función del sector,
tamaño, tipo de cliente, etc.) requiere una organización diferente que viene ligada a
una metodología de gestión de proyectos concreta que determinará la forma de
trabajar, los roles y responsabilidades en la organización, el sistema de seguimiento,
etc. No elegir una metodología y esperar que la organización aparezca de forma
espontánea es un error.
 Analizar los resultados al final del proyecto: Hay que analizar periódicamente el
grado de avance, los resultados parciales, los hitos alcanzados y el cumplimiento de
la planificación prevista con herramientas de análisis adecuadas que nos den la
información necesaria en tiempo real para la valoración del proyecto y la toma de
las decisiones necesarias. Así, podremos identificar y corregir posibles errores.
 Pensar en el equipo como un actor secundario del proyecto: En ocasiones, se tiende
a considerar que el proyecto en sí mismo, la metodología utilizada y la planificación
son elementos suficientes para asegurar el éxito de un proyecto,
independientemente de las personas que lo ejecuten. Si los miembros del equipo
no tienen la cualificación necesaria para las tareas encomendadas, no se sienten
parte fundamental del proyecto y no están alineados ni comprometidos con un
mismo objetivo o no se gestionan adecuadamente los posibles conflictos que
puedan surgir en las relaciones personales, el fracaso del proyecto está garantizado.
 Entender el proyecto como algo estático y aislado: Si el proyecto no se maneja
durante su ejecución como un elemento dinámico que debe asumir y gestionar los
cambios internos o externos que aparezcan, será imposible reaccionar a tiempo y
alcanzar los objetivos previstos.
Herramientas más habituales en la gestión tradicional de proyectos
Se entiende como herramientas de gestión de proyectos o software de administración

de proyectos a los distintos tipos de software utilizados para la planificación de proyectos,
manejo y control de presupuesto, asignación de recursos, colaboración, comunicación, manejo
de la calidad y documentación o administración de sistemas, etc.
Existen diferentes canales y diferentes tipos de software. Una primera aproximación

dependerá del modo de descarga y empleo:

Escritorio:
El software de administración de proyectos se puede poner en ejecución como

programa que funcione en el escritorio de cada usuario de tal forma que proporcione una
sencilla y fácil de experiencia de uso.
Las aplicaciones de escritorio almacenan tradicionalmente sus datos en un archivo,

aunque algunas tienen la capacidad de permitir colaborar con otros usuarios o almacenar sus
datos en una base de datos central.
Algunos de los más usados son Project Planner o Gantt.
Basado en la web:
El software de la administración de proyectos se puede poner en ejecución con una

aplicación web, accediendo a través de una Intranet o de una Extranet usando un web
browser. Esto tiene varias ventajas:
 Se puede acceder desde cualquier ordenador sin la instalación de software.

 Facilidad del control de acceso.
 Multiusuario.
 Solamente una instalación/versión de software para mantener.
Personal:
Una aplicación personal para la administración de proyectos es aquella usada para

manejar proyectos más pequeños o incluso la gestión personal de proyectos. Son bastante
parecidas a los sistemas de un solo usuario, aunque el software personal de la administración
de proyectos utiliza interfaces más simples.
Una de mis favoritas es ASANA.
De colaboración:
Un sistema de colaboración se diseña para apoyar a usuarios múltiples que pueden

modificar diversas secciones del plan en cualquier momento como, por ejemplo, poniendo al
día las áreas de las cuales ellos son responsables personalmente de tal manera que esas
modificaciones quedan integradas dentro del plan general. Las herramientas basadas en la
web, incluyendo extranets, caen generalmente en esta categoría, pero tienen la limitación de
que pueden ser utilizadas solamente cuando el usuario tiene acceso activo de Internet.

Multi-Usuarios o corporativos:
Existen herramientas informáticas que centralizan la información encontrada en los

proyectos que realiza la empresa, siendo en definitiva una Oficina de Administración y Control
de Proyectos (PMO), pero virtual, y en ella los ejecutivos deben planificar, administrar,
gestionar y controlar los proyectos, lo que les permite de manera constante conocer la
situación real de cada proyecto, controlando los avances, la documentación pertinente, las
tareas y subtareas desarrolladas, los costos relacionados, coordinando acciones y procesos,
todo ello de manera remota, activa y sin mayores costos para la organización.
NOTA: cotillea algunas de las últimas versiones para hacer Gantt usando el cloud o para hacer
gantts y compartirlos con un equipo. Te dejo unos links:
 Appvita
 Gantto

1.3.3. GESTIÓN ÁGIL DE PROYECTOS
Como una reacción a estas metodologías tradicionales y con el objetivo de facilitar un

marco de actuación diferente para solventar los principales problemas sobrevenidos de la
gestión tradicional de proyectos, un nuevo grupo de metodologías ha surgido y se ha
estructurado en los últimos años.
Durante algún tiempo se conocían como metodologías ligeras aunque el término

aceptado actualmente es el de metodologías ágiles.
Para mucha gente, el encanto de estas metodologías ágiles es su reacción flexible ante
la burocracia de las metodologías tradicionales ya que estos nuevos métodos buscan un justo
equilibrio entre la no-existencia de procesos y el exceso de los mismos. El resultado de todo
esto es que, en general y como filosofía de base, los métodos ágiles cambian
significativamente muchos de los parámetros que definen la gestión tradicional de proyectos
como por ejemplo:
 Los métodos ágiles son adaptables en lugar de predictivos. Los métodos

tradicionales tienden a intentar planear una parte grande del proceso en gran

detalle para un plazo largo de tiempo y esto funciona bien hasta que las cosas
cambian, así que su naturaleza es resistirse al cambio. Para los métodos ágiles, no
obstante, el cambio es bienvenido. Intentan ser procesos que se adaptan y crecen
en el cambio, incluso al punto de cambiarse ellos mismos.
 Los métodos ágiles están orientados a las personas en lugar de al proceso. La meta
de los métodos tradicionales es definir un proceso que funcionará bien con
cualquiera que lo use. Sin embargo, los métodos ágiles afirman que ningún proceso
podrá maquillar las habilidades del equipo de modo que el papel del proceso es
apoyar al equipo en su trabajo. Explícitamente puntualizan el trabajar a favor de la
naturaleza humana en lugar de en su contra y enfatizan que el trabajo debe ser una
actividad agradable.
No voy a entrar en demasiado detalle en este momento ya que a lo largo del postgrado
ahondareis más en estas diferencias para que podáis discernir con claridad lo que es un
proceso adaptable y centrado en las personas, sus beneficios, desventajas, etc.
Para la gestión ágil de proyectos siempre es más que aconsejable trabajar con
herramientas visuales localizadas y físicas para el equipo, sobre todo al empezar a trabajar con
este tipo de metodologías para así generar una rutina y compromiso con el equipo. Pero si
bien esto es cierto, en ocasiones veréis que es necesario aplicar herramientas online ya que
contamos con equipos deslocalizados, etc.
A continuación, y a modo de “aperitivo”, os dejo algunas herramientas de gestión de

proyectos aplicando agile que ya podéis ir “cotilleando” (a medida que ahondéis en las
diferentes metodologías en cada unidad iréis viendo diferentes herramientas). Son:
 VersionOne
 Scrumblr mirad aquí la demo: http://scrumblr.ca/demo
 Banana Scrum
 Scrum Desk
 VirtualKanban
 Trello

1.3.4. CÓMO HACER LA ELECCIÓN ADECUADA ENTRE METODOLOGÍAS

TRADICIONALES Y METODOLOGÍAS ÁGILES
Existen diferentes factores que nos marcan el contexto de un proyecto. Para esta
unidad, como modo introductorio a las posteriores, veremos en un contexto genérico qué
debemos tener en cuenta y cómo se enfrentan cada uno de los marcos de trabajo propuestos
a las situaciones normales de cualquier proyecto para que pueda serviros como referencia
base.
Conceptos comunes entre las metodologías tradicionales y las ágiles
 Hitos externos (normalmente de cambio) que condicionan las entregas.

 Dependencias funcionales y técnicas.
 El triángulo de la gestión de proyectos: tiempo-coste-alcance (calidad).
Conceptos de separación entre las metodologías tradicionales y las ágiles:
La forma de gestionar la incertidumbre:
Existen diversos modos de definir la incertidumbre. Uno de ellos es “aquel conjunto de

realidades que tienden a sacarnos de nuestra área de confort, porque no responden a nuestras
rutinas organizativas o personales” y otro es “estado del observador en el que no puede
establecer predicciones con absoluta certeza”.
En el día a día de la gestión de proyectos de cualquier índole lo normal es tener

muchos cambios a lo largo del proceso. El problema no debe ir centrado a que eso no ocurra
sino a "¿qué hacemos al respecto?".
Una forma de enfrentarnos a la situación es tratar los objetivos cambiantes como el

resultado de una mala toma de los mismos. La idea detrás de la toma de objetivos es conseguir
un cuadro totalmente inteligible de los requisitos del cliente antes de empezar a construir el
producto, conseguir la firma del cliente sobre estos requisitos y entonces preparar
procedimientos que limiten los cambios después de la firma. Un problema con esto es que el
simple hecho de tratar de entender las opciones para los requisitos es duro. Es aún más duro
porque la organización normalmente no proporciona la información de los costes, por lo que el
cliente termina solicitando algo que no se puede cotizar con exactitud y sin una buena idea del
coste, ¿cómo puede el cliente decidir si quiere pagar por ese pedido?
La estimación es difícil por esta y otras muchas razones. En parte porque el desarrollo
es una actividad de diseño, difícil de planear y costear, en parte porque los materiales básicos
cambian rápidamente, en parte por lo mucho que depende de los individuos involucrados, ya
que los individuos son difíciles de predecir y cuantificar.

Por todo ello es importante comprender que ante un mismo o similar contexto, cada
metodología se enfrenta de forma diferente a la situación. En el cuadro anexo podéis ver
algunas notas como referencia:
La gestión del cambio:
Una de las partes más difíciles en un proyecto es saber con precisión dónde nos
encontramos y, teniendo en cuenta a donde queremos ir, queé cosas podemos encontrarnos
en el camino. Necesitamos un mecanismo de retroalimentación que pueda decirnos con
precisión cuál es la situación del proyecto a intervalos frecuentes.
La llave para obtener esta retroalimentación constante es el desarrollo iterativo, ya

que implica producir frecuentemente versiones funcionales del producto/servicio final que nos
vayan marcando la pauta y sirviendo como referencia de la realidad, ya que cuando el
cliente/usuario realmente se siente delante del producto, lo use y trabaje con él, entonces los
fallos se vuelven visibles.
El decidir la necesidad o no de esta adaptación al cambio para el equipo y el producto

a lo largo del ciclo productivo será una de las cuestiones a tener en cuenta para decidir la
metodología a aplicar durante el proceso.
A modo de resumen, puedes ver en este cuadro cómo reaccionan ante el cambio las
metodologías agiles y las tradicionales:

La gestión de los equipos:
Una parte clave de la noción taylorista es que es necesario establecer ciertos procesos
estandarizados de tal forma que el producto funcione independientemente del equipo que
ejecute el proyecto. A lo largo de la historia reciente, nos hemos dado cuenta de que cada vez
es más importante retener y comprometer equipos de valor dentro de la compañía ya que
esto será en gran parte lo que nos haga competitivos en el mercado.
Una vez consideramos esto como principio, entendemos que cuando contratamos a
alguien en nuestro equipo es porque entendemos que esa persona es la mejor y más
cualificada para ejecutar el trabajo y, por tanto, también para, en muchos casos, decidir cómo
dirigir su trabajo técnico. La noción Taylorista de un departamento de planificación separado
que decide de forma independiente cómo hacer las cosas solo funciona si los planificadores
entienden mejor cómo hacer bien el trabajo que aquellos que lo hacen.

El enfoque del proceso:
La orientación del proceso a las personas se manifiesta de varias maneras diferentes

en los procesos ágiles. Uno de los elementos clave para ello es la aceptación de un proceso en
lugar de la imposición de un proceso.
A menudo, los procesos se imponen desde la gerencia y esto suele provocar rechazo
por parte del equipo, particularmente cuando la gerencia ha estado fuera del desarrollo activo
desde hace tiempo y parte de sus planteamientos están obsoletos en la práctica. Una razón
importante para esto es el ritmo del cambio de tecnología en nuestra industria. Después de
unos años, el conocimiento técnico se vuelve obsoleto. Esta vida media de habilidades técnicas
no tiene parangón en cualquier otra industria. Incluso los técnicos tienen que reconocer que
entrar a la gerencia significa que sus habilidades técnicas se marchitarán rápidamente. Los ex
desarrolladores necesitan reconocer que sus habilidades técnicas desaparecerán rápidamente
y necesitan confiar en los desarrolladores actuales y, en cierto modo, depende de ellos.
Aceptar este proceso requiere compromiso con el resultado final del proyecto y, como tal, se
requiere de la participación activa de todo el equipo.
Los miembros del equipo deben poder tomar todas las decisiones técnicas. Vais a ver
que en XP se llega al corazón de esta teoría cuando en su proceso de planeación establece que
solo los desarrolladores pueden estimar cuánto tiempo llevará hacer un trabajo. Tal liderazgo
técnico es un gran cambio para muchas personas en posiciones gerenciales ya que implica
compartir una responsabilidad donde ejecutores y gerencia tienen un mismo lugar en la
dirección del proyecto.

Conclusión
Gran parte de la ventaja de los métodos ágiles es su peso ligero y el hecho de que son
flexibles ante entornos con requisitos volátiles y cambiantes. Pero también debemos ser
conscientes de algunas limitaciones y restos como por ejemplo, poder aplicar este tipo de
metodologías en entornos mas grandes (hasta ahora, siempre han venido a ser usados en
equipos pequeños o pilotos dentro de una organización) y de cómo incorporar a clientes,
directivos y proveedores en el proceso.
Como conclusión general y a modo de recordatorio de la unidad, os dejo los siguientes

consejos:
Gestión tradicional de proyectos:
 El modelado es esencial.
 Roles específicos y muy jerárquicos.
 La relación se ciñe a lo establecido en el contrato.
 El cliente solo da feedback, no interactúa habitualmente con todo el equipo.
 El equipo: orientados al plan.
 Confianza: conocimiento explicito documentado.
 Son más efectivas en proyectos grandes con equipos complejos.
 La arquitectura sirve al inicio del proyecto para definirlo.
 El énfasis está en la definición del proceso (roles, actividades, entregables y
artefactos).
 Lo ideal es que no ocurran grandes cambios.

Gestión ágil de proyectos:
 Pocos artefactos: el modelado es prescindible

 Pocos roles (más genéricos y flexibles)
 No existe un contrato tradicional, es flexible (marco)
 El cliente es parte del proceso de forma continuada
 El equipo: colaborativo, unido, ágil
 Confianza: conocimiento tácito e interpersonal
 Orientada a proyectos pequeños o de corta duración (entregas frecuentes) o con
equipos de no más de 10 personas
 La arquitectura se va definiendo a lo largo del proyecto
 Énfasis en el equipo y en las personas Aceptación del cambio como parte del
proceso.

1.4. Agile thinking. Introducción a la filosofía e

idiosincrasia del pensamiento ágil
1.4.1. CONTEXTO
Inmersos en pleno siglo XXI, nos encontramos ante un mundo globalizado y en

constante cambio, que sin embargo continua operando en su mayoría bajo las directrices de
trabajo del siglo pasado. Modelos de Gestión empresarial y de Proyectos heredados basados
en las premisas de la sociedad industrial, cuyo interés principal fue y será la mejora continua y
la optimización de procesos y tareas en busca de la eficiencia operacional.
El pilar de sustento de este sistema es la planificación y previsión de hechos factibles

de acontecer. Siempre hay una estrategia de respuesta clara: ante el suceso X suele ser mejor
utilizar la estrategia de respuesta A, B o C basadas en la experiencia previa acumulada que ha
identificado los sucesos similares o idénticos en el pasado preparándonos para preveer que no
acontezcan de nuevo o conocer la estrategia de respuesta prestablecida. Sin embargo, en el
mundo de los negocios actual, no existen planteamientos que siempre funcionen.
“Predecir es muy difícil, especialmente el futuro“
Niels Bohr,1922
(Premio Nobel de física)
En pocas palabras, el consumidor ha evolucionado hacia un perfil de experto,

concebido por el hecho de disponer toda la información en la red a un click: reclamamos lo
que queremos, somos jueces implacables. Ello ha desembocado en un estado actual de
inestabilidad donde se evidencia la falta de diferenciación y la necesidad de cambio en el
management de las empresas.
Hoy en día, trabajamos en un entorno de completa incertidumbre, lo que implica que

debemos ser creativos e idear nuevas estrategias para nuevas situaciones y esforzarnos en ser
diferentes, no mejores (lo que por supuesto no quita conocer las que se suelen utilizar en
circunstancias similares). Debemos resolver los problemas en el desarrollo de los proyectos
intentando maximizar el éxito o probabilidad de éxito de los mismos.

Si atendemos al Informe de CHAOS 2009 podemos ver como solo el 32% de los
proyectos son exitosos, mientras que un 24% son fallidos y un 44% son modificados. Como
conclusiones aparecen:
 Por un lado, la necesidad de asumir la cultura del fallo o error, sabiendo que por
mas que nos preparemos podemos no tener éxito. Es decir, asumir que será
necesario comenzar de nuevo; “Europeans must accept that success in the tech
startup world comes through trial and error. Europeans prefer great plans that
don't fail. But that is not how Google, Facebook, Amazon, Apple were born.” –
fragmento entrevista Martin Varsavsky FORTUNE.
 Por otro lado, vemos cómo nos debemos sentir cómodos y poner medios para ser
capaces de cambiar y alterar los proyectos, ya que de una u otra puede suceder, y
para mejorar este hecho, busquemos una construcción de líneas de tiempo y
espacios de trabajo distinta.
Como resultado a estas situaciones planteadas, empiezan a aparecer nuevas prácticas

y metodologías amparadas en conceptos abstractos (liderazgo, creatividad, innovación...)
implementadas en cierta medida en grandes compañías.
Dichas metodologías se construyen bajo la antítesis de 2 supuestos del modelo de

gestión que se están viniendo abajo:
 El conocimiento es estático y se mide por cantidad: tradicionalmente se realizaban

largos procesos de recogida de requerimientos focalizados en la obtención de datos
cuantitativos para generar una sólida base de conocimiento con la que afrontar el
proyecto/gestión empresa. Además, está en rara ocasión de actualizaba o replanteaba,
sino que se pasaba a siguientes fases, otorgándole validez en el tiempo.

Actualmente somos conscientes de que el conocimiento fluye y de que la importancia

reside no en la cantidad sino la calidad, y en como hacer uso de ella.
Hablando estrictamente de proyectos de software, podríamos decir que hemos

comprendido por fin que el cliente va descubriendo lo que quiere, durante el proceso, y los
desarrolladores van descubriendo como solucionarlo. Por ello, es fundamental integrarle en las
distintas fases y realizar toma de requerimientos intermedio, actualizando nuestra visión y
comprensión del proyecto según avanza en el tiempo y alcanzamos ciertos hitos. Debemos
buscar nuevas formas de gestionar proyectos basadas en la ENTREGA CONTINUA Y FRECUENTE
DE VALOR AL CLIENTE.
 - Las estructuras jerárquicas y estancas: las jerarquías, tal y como hoy las entendemos,
surgieron para resolver dos problemas clave de la Era Industrial: la eficiencia y la
escalabilidad. La producción masiva -ya fuera en la industria pesada a inicios de siglo o
a finales de los años 90 en la denominada “industria del software”- exigía un ejército
ordenado que cumpliese fielmente las órdenes de sus superiores.
Sin embargo, como hemos visto, las circunstancias que nos rodean han cambiado por
completo. La eficiencia y la escalabilidad han dejado de ser centrales y han sido sustituidos por
nuevos valores como la colaboración, el compromiso, la transparencia, la creatividad y la
innovación, con objeto de adaptarse a los nuevos tiempos y los nuevos usuarios. Por ello,
podemos decir que nos estamos adentrando en la Era de la Colaboración, rodeados por un
océano de información que nadie es capaz de manejar, creando interrelaciones tan complejas
que difícilmente podemos gestionar, e intentando seguir el ritmo de una realidad que cada día

se hace mas transparente, participativa y global. Este no es ya un mundo de cosas, sino un

mundo de conversaciones.
Fuente: Thinkers Co.
El contexto anteriormente planteado realiza un nuevo dibujo de situación en el que

todas las industrias conocidas están intentando encontrar una reformulación de su
funcionamiento actual. Dentro de la industria del desarrollo del software se materializa en la
aparición del término “ágil”, introduciendo un doble debate entre los líderes y gerentes de
proyectos en si, por un lado, las metodologías ágiles son o no una nueva manera de hacer las
cosas y si, por otro, hecha por la borda toda la teoría tradicional de gerencia de proyectos que
ha madurado en estos últimos años.
Realizando una pequeña parada se debe puntualizar que tanto el agilismo como otras
filosofías y metodologías dentro y fuera del mundo del software (diseño, innovación,
negocios..) no han aparecido porque sí, si no que suelen ser la evolución y puesta en relevancia
de praxis ya realizadas en pequeños ámbitos que han resultado más óptimas y válidas que las
tradicionales en el tiempo actual. A su vez, asumir este hecho, no es renegar por completo de
la modelización de gestión de proyectos de antaño, sino que en cada caso se deberá evaluar la
idiosincrasia del mismo para ver que se adecua mas, así como pueden ser complementarias.
Realizada esta especificación, me gustaría focalizarme en el primer punto ¿es nuevo el

término “ágil”? Si realizamos una investigación no muy extensa, se puede encontrar que, más
allá del año 2001 en el que se desarrolló el lanzamiento del Manifesto Ágil, no ha sido muy
utilizado como pensamiento o metodología de hacer las cosas..

Desde entonces el movimiento agilista trata de favorecer un cambio de mentalidad en

el sector del desarrollo del software y en otros cada vez más, basado fundamentalmente en los
valores y principios que emanan del Manifiesto Ágil, de la definición de XP (programación
extrema) o el Lean Software Development. (conceptos que iréis conociendo a medida que
vayamos adentrándonos en el contenido del postgrado) Sin embargo podemos, por varias vías,
echar un paso atrás y analizar los orígenes con anterioridad a este hito:
 A nivel metodológico podemos encontrar raíces de estas praxis “ligeras” o “ágiles”

por mediados de los 80, en Japón. En 1986 Ikujiro Nonaka publicó en la Harvard
Business Review “The New New Product Development Game” o "el nuevo juego de
desarrollo de nuevos productos", un nuevo enfoque para gestionar el desarrollo de
nuevos productos en la industria manufacturera y, especialmente, en la automotríz.
El señor Nonaka es considerado el abuelo de SCRUM ya que su invención fue la
inspiración para que Jeff Sutherland idease SCRUM en 1993 para desarrollos de
software, avalados en el propio blog de Jeff Sutherland con reseñas obvias y
reconocimiento a NonaKa.
 El término de desarrollo de software Lean tiene origen en un libro del mismo

nombre, escrito por Mary Poppendieck y Tom Poppendieck. La metodología de
desarrollo de software Lean es una translación de los principios y prácticas de Lean
Manufacturing (concebida en Japón por Taiichi Ohno, director y consultor de la
empresa Toyota en los años 30-40) hacia el dominio del desarrollo de software.
Por tanto vemos cómo, a semejanza de otras disciplinas y áreas, muchas de las
premisas hoy validadas y utilizadas provienen del mundo del automóvil y su traslación a otros
sectores. Partiendo de esos orígenes podemos encontrar que ya a partir de 1990 con
anterioridad al Manifesto Ágil comienza a madurarse el concepto de desarrollos ágiles dentro
de la industria del software y ya para su firma en 2001 existen publicaciones relevantes:
 Planning Extreme Programming, Kent Beck and Martin Fowler, Addison-Wesley

Professional, 2000.
 Extreme Programming Installed, Ron Jeffries, Ann Anderson, and Chet Hendrickson,
Addison-Wesley Professional, 2000.
 Agile Software Development with Scrum, Ken Schwaber and Mike Beedle, Prentice
Hall, 2001.

Así mismo desde 2001 comienza un auge en el movimiento, impulsado por nuevas
publicaciones:
 User Stories Applied, Mike Cohn, Addison-Wesley Professional, 2004.

 Agile Software Development Principles, Patterns, and Practices, Robert C. Martin,
Prentice Hall, 2002.
 Test Driven Development: A Practical Guide, David Astels, Prentice Hall Ptr, 2003.
 Agile & Iterative Software Development A Manager's Guide, Craig Larman, Addison-
Wesley, 2004.
Recapitulando podemos apreciar como, en su conjunto, el agilismo se trata de una

maduración de casi 30 años, en los que en los 20 últimos se han gestado unos conocimientos
focalizados en la mejora y búsqueda de nuevos enfoques en los procesos de desarrollo de
nuevos productos y software. Ello ha desembocado en una renovación y actualización sólida
en los últimos 11 años orientada a redefinir la manera de desarrollar y manejar proyectos de
desarrollo de software basado en dichos enfoques.
Para su correcta comprensión es necesario comprender la terminología de “industria

del software” y sus similitudes con el mundo de la industria tradicional, del cual ha embebido
los principios que han conformado lo que es hoy en día: una filosofía y praxis integrada en
muchas empresas con años de experiencia y casos de éxitos demostrados en
implementaciones ágiles. A su vez, comenzamos a identificar una “horda” de consultores con
importantes horas de proyectos ágiles sobre sus hombros apoyada por herramientas diversas
tales como libros, foros, eventos, blogs, canales, certificaciones…
Todo ello conforma el denominado término “ágil” una corriente de conocimientos que
está marcando un cambio en la manera de gestionar los proyectos, comenzando a salir incluso
más allá de la industria del software.

1.4.3. EL MANIFIESTO ÁGIL
El 17 de febrero 2001 diecisiete críticos de los modelos de mejora del desarrollo de

software basados en procesos, convocados por Kent Beck -quien había publicado un par de
años antes Extreme Programming Explained, libro en el que exponía una nueva metodología
denominada Extreme Programming-, se reunieron en Snowbird (Utah) para tratar sobre
técnicas y procesos para desarrollar software. En la reunión se acuñó el término “Métodos
Ágiles” para definir a los métodos que estaban surgiendo como alternativa a las metodologías
formales (CMMI, SPICE) a las que consideraban excesivamente “pesadas” y rígidas por su
carácter normativo y fuerte dependencia de planificaciones detalladas previas al desarrollo.
Los integrantes de la reunión resumieron los principios sobre los que se basan los
métodos alternativos en cuatro postulados, lo que ha quedado denominado como Manifiesto
Ágil.
Hasta 2005 han sido frecuentes las posturas radicales entre los defensores de los
modelos de procesos y los defensores de modelos ágiles, quizá más ocupados en descalificar al
otro que en estudiar sus métodos y conocerlos para mejorar los propios.
En el Manifiesto Ágil, firmado por Kent Beck, Mike Beedle, Arie van Bennekum, Alistair
Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt,
Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff
Sutherland y Dave Thomas, se expone que:
“Estamos poniendo al descubierto mejores métodos para desarrollar software,

haciéndolo y ayudando a otros a que lo hagan. Con este trabajo hemos llegado a valorar:
 A los individuos y su interacción, por encima de los procesos y las herramientas.

 El software que funciona, por encima de la documentación exhaustiva.
 La colaboración con el cliente, por encima de la negociación contractual.
 La respuesta al cambio, por encima del seguimiento de un plan.
Aunque hay valor en los elementos de la derecha, valoramos más los de la izquierda.”
Fuente: Agile Manifesto

Valores Manifiesto Ágil
1.Valorar más a los individuos y su interacción que a los procesos y las herramientas:
se trata del principio más importante del Manifesto. Conscientes de la necesidad de los
procesos como guía operación y de las herramientas como mejora de la eficiencia, no se puede
entender un desarrollo sin las personas y sin su conocimiento técnico y actitud adecuada. Sin
ellos no se producen resultados.
Con teorías de recursos humanos en las que las empresas predican que sus empleados
son lo más importante, la realidad es que a finales del siglo XX e inicios del XXI la maximización
del uso de la reingeniería de procesos ha dotado a estos de una relevancia principal en
búsqueda de la optimización y eficacia, poniendo en un segundo plano a las personas. Sin
embargo, gran parte de su valor se debe al conocimiento y al talento de las personas implícitas
en los procesos, ya que sin ellos carecen de propio sentido.
Por ello, entendiendo los procesos como una ayuda y un soporte para guiar el trabajo,
estos deben adaptarse a la organización, a los equipos y a las personas; y nunca al revés. La
defensa a ultranza de los procesos lleva a postular que con ellos se pueden conseguir
resultados extraordinarios con personas mediocres, y lo cierto es que este principio es
peligroso cuando los trabajos necesitan creatividad e innovación.
2. Valorar más el software que funciona que la documentación exhaustiva: pudiendo

parecer que este principio recela de la documentación, no debe entenderse de dicha manera,
sino que intenta recolocarla en su lugar. Los documentos permiten la transferencia de
conocimiento y sirven como registro histórico, si bien encontramos como en el mundo de la
empresa ha dado lugar a la idiosincrasia de primar la documentación por encima del objetivo
final del trabajo realizado. Ejemplo de ello es el uso e integración de la ISO y sus
procedimientos en nuestro tejido empresarial, burocracia en vez de eficacia.
Cuando especifica software que funciona, se trata de la realización de prototipos,

partes elaboradas del sistema cuanto antes que permitan evaluar el comportamiento de
funcionalidades esperadas, produciendo una retroalimentación estimulante que puede
acarrear la limpieza de errores y generación de nuevas ideas imposibles de concebir al inicio.
Los documentos no pueden sustituir, ni pueden ofrecer la riqueza y generación de

valor que se logra a través de la comunicación directa entre las personas y de la interacción

con los prototipos. Por eso, siempre que sea posible debe preferirse y reducir al mínimo
indispensable el uso de documentación, que genera trabajo que no aporta un valor directo al
producto.
Si la organización y los equipos se comunican a través de documentos, además de

perder la riqueza que da la interacción con el producto, estos documentos se acaban
empleando de forma defensiva como barricadas ante departamentos o personas.
3. Valorar más la colaboración con el cliente que la negociación contractual: las

prácticas tradicionales en su búsqueda de optimizar, presentan los proyectos parametrizados
bajo ejemplos anteriormente realizados, desarrollando procedimientos ya validados. El cliente
sabe lo que espera y se le presenta un modo de consecución de ese objetivo.
Por contrapartida, en según que sectores o casos, se aprecia que cada proyecto tiene
una idiosincrasia individual, difícilmente comprensible en sus inicios.
Las prácticas ágiles están especialmente indicadas para proyectos difíciles de definir
con detalle en el principio, o que si se definieran así tendrían al final menos valor que si se van
enriqueciendo con retro-información continua durante el desarrollo. También para los casos
en los que los requisitos van a ser muy inestables por la velocidad del entorno de negocio, una
constante dentro de la incertidumbre de algunos sectores en los que se opera en la actualidad.
Para el desarrollo ágil el valor del resultado no es consecuencia de haber controlado

una ejecución conforme a procesos, sino de haber sido implementado directamente sobre el
producto/servicio a desarrollar. Un contrato no aporta valor al producto. Es una formalidad
que establece líneas divisorias entre responsabilidades, que fija los referentes para posibles
disputas contractuales entre cliente y proveedor.
En el desarrollo ágil el cliente es un miembro más del equipo, que se integra y colabora
en el grupo de trabajo. Los modelos de contrato por obra no encajan, sino que debemos
buscar nuevos modelos que encajen con las premisas de flexibilidad y responsabilidad
compartida

4 Valorar más la respuesta al cambio que el seguimiento de un plan: para un modelo

de desarrollo que surge de entornos inestables, que tienen como factor inherente al cambio y
la evolución rápida y continua, resulta mucho más valiosa la capacidad de respuesta que la de
seguimiento y aseguramiento de planes pre-establecidos. Los principales valores de la gestión
ágil son la anticipación y la adaptación; diferentes a los de la gestión de proyectos ortodoxa:
planificación y control para evitar desviaciones sobre el plan. Comprendemos la cultura del
fallo y la abrazamos, siendo conscientes de las complicaciones que pueden surgir,
preparándonos en consecuencia para hacerles frente.
Tras los cuatro valores descritos, los firmantes redactaron los siguientes, como los 12
principios que de ellos se derivan:
 Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y

continua de software con valor.
 Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo.
Los procesos ágiles aprovechan el cambio para proporcionar ventaja competitiva
al cliente.
 Entregamos software funcional frecuentemente, entre dos semanas y dos meses,
con preferencia al periodo de tiempo más corto posible.
 Los responsables de negocio y los desarrolladores trabajamos juntos de forma
cotidiana durante todo el proyecto.
 Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el
entorno y el apoyo que necesitan y confiarles la ejecución del trabajo.
 El método más eficiente y efectivo de comunicar información al equipo de
desarrollo y entre sus miembros es la conversación cara a cara.
 El software funcionando es la medida principal de progreso.
 Los procesos ágiles promueven el desarrollo sostenible. Los promotores,
desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante
de forma indefinida.
 La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.
 La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es
esencial.
 Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-
organizados.
 A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a
continuación ajustar y perfeccionar su comportamiento en consecuencia.

1.4.4. REPLANTEAMIENTO DEL STATUS QUO – APRENDER A DESAPRENDER
Como se deriva del Manifiesto Ágil, las metodologías ágiles son una nueva filosofía de
gestión de proyectos e iniciativas, que favorece la entrega de valor desde el inicio del proyecto.
Se basan en una serie de principios y valores que cambian la forma de relacionarse entre los
integrantes del equipo, así como con el cliente y que están dando excelentes resultados en
centenares de empresas de todo el mundo.
Las interacciones entre las personas y la flexibilidad para incorporar cambios, son
esenciales. El foco es ser capaz de entregar un resultado al cliente lo antes posible, sobre el
que seguir construyendo y refinando mediante iteraciones cortas. Siempre confiando en el
equipo, autoorganizándose y colaborando.
La comprensión del Manifiesto y sus metodologías derivadas (Scrum, Kanban...) a nivel

individual no entraña mucho misterio. Si bien la complejidad de la puesta en marcha dentro de
nuestra propia idiosincrasia, así como dentro de una organización, es una ardua labor que pasa
por la necesidad de desaprender ciertos valores y replantearse el Status Quo en profundidad.
Es decir, antes de su puesta en funcionamiento debemos realizar un “change of mind” que
pasa por adoptar e interiorizar unas pautas de pensamiento y actuación:
 De la jerarquía a la redarquía
 Del trabajo individual a la participación en un equipo
 De la planificación lineal a la iteración
 Del pensamiento analítico a la actitud reflexiva
 Del cliente pasivo al cliente activo
 De la documentación escrita y laboriosa al Visual Thinking
De la jerarquía al poder de grupo
“Cuanto más poder le des a un solo individuo frente a la complejidad y la

incertidumbre, más probable será que tome malas decisiones. Como consecuencia, hoy en día
hay muy buenas razones para que las empresas traten de pensar más allá de la jerarquía”.
James Surowiecki, 2004
La jerarquía es el “orden de los elementos de una serie según su valor” y “puede

aplicarse a personas, animales o cosas”.
Si entramos en el contexto de las organizaciones, podemos afinar bastante más la

definición: el concepto de jerarquía se utiliza para designar la cadena de mando que comienza
con los gestores de alta dirección y sigue hasta los trabajadores no-gestores, pasando,
sucesivamente, por todos los niveles de la estructura organizativa. En definitiva, a nivel de
proyectos o áreas en la empresa, hablamos de grupos de trabajo en los que hay una cabeza
que piensa y el resto ejecuta, desarrollando estructuras excepcionalmente rígidas y verticales,
con muchos niveles estancos que no se comunican apenas entre sí. Esta organización del

desarrollo del trabajo surgió en base a la búsqueda de la eficiencia, si bien el mayor problema
es su propia idiosincrasia basada en la gestación de las órdenes principales y estrategia en la
parte alta de la jerarquía descendiendo a lo largo de la cadena, permitiendo mínimas
adaptaciones. Además, a semejanza de su analogía con el ejército, se enorgullece de la
capacidad de los soldados de ejecutar las órdenes sin cuestionarlas ni pensar.
Patrón único de sesgo de las empresas en el siglo XX, la necesidad del mercado actual
basado en una incertidumbre desconocida hasta el momento, ha ocasionado la búsqueda de
nuevos modelos de definición de ciertas líneas estratégicas que permitan formas más flexibles
y ágiles de interpretar la estrategia en cada punto de la cadena de mando. Los nuevos espacios
de comunicación -los blogs, wikis y redes sociales- están teniendo un impacto real y tangible
en el seno de las organizaciones. Por último, el impulso de las nuevas generaciones,
acostumbradas a aprender, procesar la información, colaborar y, en definitiva, hacer las cosas
de forma diferente a las generaciones anteriores, está ocasionando una translación en el
sentido de entender el poder y las relaciones personales.
En definitiva, está emergiendo un nuevo orden para dar respuesta a los retos actuales:
la redarquía.

Jerarquía vs. redarquía
La jerarquía es un orden impuesto (de arriba abajo) que establece las relaciones de
autoridad y poder formal entre superiores y subordinados en el seno de las organizaciones
tradicionales. La redarquía, en cambio, es un orden emergente (de abajo arriba) que surge
como resultado de las relaciones de participación y los flujos de actividad generados en los
entornos colaborativos.
Las bases de la redarquía se construyen en torno a la aparición de redes de

colaboración, basadas en el valor añadido de las personas, la autenticidad y la confianza,
fundamentada en el reconocimiento y la autoestima de sus miembros. Ello permite que la
actividad se traslade, de forma natural, a los nodos en los que realmente se está aportando
valor a la organización o equipo.
Se trata, en pocas palabras, de pasar de un encasillamiento del individuo en su lugar de

trabajo y en sus funciones, a permitir una transmisión de conocimiento y de generación de
relaciones entre las personas. En definitiva, entender la fuerza de la era de la colaboración,
construida desde el individuo y sus capacidades de relacionarse con diferentes agentes, desde
próximos a más lejanos, acordes a sus propias necesidades, tanto puntuales como a largo
plazo.
A su vez, es muy importante comprender que este nuevo orden no viene para acabar
definitivamente con las jerarquías, sino que se trata de complementarlas y mejorarlas,
dotándolas de transparencia y eficacia para aprovechar al máximo el potencial de los
individuos. Se trata de proporcionar y generar sistemas capaces de resolver los problemas
complejos. No se trata, por tanto, de dos modelos excluyentes, sino de dos estructuras
complementarias.
Del trabajo individual a la participación en un equipo
Al final, la colaboración se trata de un tema cultural intrínseco en la persona, actitudes

y hábitos que se pueden tener la suerte de predisponer o, en su defecto, la capacidad de
modelarse, lo que implica que no será ni fácil ni rápido… pero sin duda es como hemos visto el
pan nuestro de cada día en la época en la que vivimos. COLABORAR ES VITAL y debe surgir de
la auto-reflexión y evaluación propia, ya que se trata de una opción, nunca debe ser una
obligación, porque entonces no funcionará.

Un concepto muy interesante que refuta la fortaleza del equipo frente al individuo es
la ZDP (Zona de Desarrollo Próximo) introducido por Lev Vygotski en 1931: la distancia entre el
nivel de desarrollo efectivo del alumno (aquello que es capaz de hacer por sí solo) y el nivel de
desarrollo potencial (aquello que sería capaz de hacer con la ayuda de un adulto o un
compañero más capaz).
Extrapolado de la educación infantil a niveles de adultos, sigue siendo vigente. De

hecho, solemos aplicarlo pero siempre dentro de nuestro campo de conocimiento (buscamos
aquel que sabe más que yo). Sin embargo en esta época de problemas complejos, debemos
romper también barreras de manera mucho más horizontal saliéndonos de nuestro campo de
acción, pues ya se nos queda pequeño para entender las realidades actuales. Debemos
comenzar a hablar de la necesidad de crear equipos INTERDISCIPLINARES, es decir, equipos
con diversos perfiles profesionales o de conocimiento.
El matiz de interdisciplinaridad, en detrimento de multidisciplinaridad es sutil, pero de

gran relevancia.
 Un equipo multidisciplinar es aquel que reparte tareas y cada uno realiza las de su
especialidad sin entrar en detalle en las otras, asumiendo la responsabilidad de
aquello en lo que ha sido parte activa.
 Un equipo interdisciplinar es aquel que no aboga por la realización de tareas, sino
por la consecución de un fin mayor (objetivo proyecto) y todos ponen su
experiencia y esfuerzo al servicio del equipo, compartiendo el riesgo y los éxitos de
todas las fases y tareas, sea cual sea su participación en las mismas.
Para entender las dinámicas de grupos y la participación como agentes activos de las
mismas, debemos ser conscientes de los principios básicos asociados a las mismas así como
sus barreras o problemáticas.

Los principios básicos:
 Los grupos son complejos, y su complejidad crece de forma exponencial con el

tamaño: en un grupo de 10 personas hay 45 conexiones, pero en un grupo de 36
hay más de 600… no se pueden tratar igual. El dimensionamiento de un equipo
puede ir a favor o en contra nuestro, debemos ser conscientes de que hay unos
límites a partir de los cuales el grupo pierde su propia eficacia según el objetivo a
alcanzar.
 Lo importante no son las personas, sino las relaciones que se establecen entre
ellas: aun teniendo en cuenta la complejidad y número de individuos, el éxito del
mismo no se basa en dicha cifra, sino en la calidad y cantidad de conexiones entre
ellos.
 Tendemos a pensar de forma individual antes que como grupo: solemos enfocar
los problemas como individuo, sin contar con el grupo (ni lo que representa ni sus
particularidades). Debemos de dejar de pensar como individuos y pensar de una
forma más holística sintiéndonos parte de algo más grande que nosotros mismos,
queriendo apoyar para que funcione. Si no disponemos de ese alineamiento, la
colaboración será complicada.
 Las herramientas en sí no son catalizadores de la colaboración: videoconferencias

interminables, conferencias telefónicas que parecen conversaciones de besugo,
cadenas de emails kilométricas, documentos con 5 niveles de comentarios… no
ayudan mucho a colaborar. Por el mero hecho de usar herramientas no se produce
mágicamente la colaboración, sino que se trata de cómo hacemos uso de ellas.
 Es necesario disponer de individuos conectores (cabezas puente): en pro de

desarrollar esas conexiones, que son la base de la colaboración, debemos buscar e
incorporar esas personas con una capacidad innata para salvar las diferencias y
agrupar en torno a ellas equipos que abrazan la colaboración como algo natural,
siempre poniéndose a disposición de los demás. Es complejo identificarlas, pero sin
su presencia, el grupo no funciona a semejanza de la vida real (todos tenemos el
amigo/s conector).
 Debemos dejar a un lado la seriedad: aunque parezca trivial remarcar este punto,
debemos comprender que la colaboración surge en ambientes positivos y
distendidos. El pasarlo bien nos predispone a una actitud mental más abierta y
participativa. Ello debe plasmarse tanto en dinámicas como en espacios (oficinas
Google).

Las barreras o problemas para la colaboración
En su mayoría surgen de las propias personas y disponen de un carácter humano:
 Falta de confianza o respeto: para actuar en un equipo debemos respetarnos a

nosotros mismos y respetar a los demás. Debemos ser capaces de generar lazos de
confianza permitiendo compartir riesgos. Si no me fío de tu labor ni tú de la mía, no
haremos más que ponernos piedras en el camino. Necesitamos saber que si yo me
caigo tú me cogerás.
 Cultura de competencia: debemos evitar actitudes internas o presiones externas de

competencia entre los individuos. Se debe instaurar dinámicas WIN-WIN siendo
conscientes que todos aportamos y que todos remamos juntos para mover el
barco.
 Prioridades diferentes y no alineadas: si no miramos todos en la misma dirección el

barco no avanzara aunque todos rememos. Debemos generar espacios de dialogo
donde clarificar y alinear el equipo, ya que si dejamos cosas por supuestas, cada
uno las puede entender a su manera e ir en direcciones opuestas.
 Organigramas jerarquizados y cerrados: como hemos visto con anterioridad,

debemos hablar de jefes de equipo y jerarquías. Es hora de hablar de liderazgo
compartido y responsabilidades conjuntas. A su vez el equipo debe ser abierto en
pro de buscar fuera aquello que pudiéramos necesitar.
 Ego: una premisa de la dinámica de grupos es la humildad, no sentirse más que

nadie, sino todos en un mismo nivel.
De la planificación lineal a la iteración
En un modelo tradicional de gestión de proyectos es extremadamente importante que

la definición de toda la organización interna y operaciones sean extremadamente eficientes y
estén diseñadas con extremo cuidado. La consecuencia es la disposición de unos procesos muy
definidos y claros (que suelen desembocar en la temida burocracia) que priman por encima del
resultado final (entregable al cliente).

Si atendemos a uno de los modelos más usados en desarrollo encontramos el modelo

en cascada definido por 5 áreas consecutivas y, que atendiendo al management tradicional,
predispone un modelo homogéneo para todos los proyectos.
Modelo de desarrollo en cascada
Obviamente es deseable cierto nivel de eficiencia operacional, pero sin embargo en el

modelo, podemos apreciar la importancia de las operaciones internas en detrimento del
contexto externo. Confiamos en la aplicación de la modelización que, como consecuencia de
una correcta ejecución y puesta en marcha del mismo, dará como salida el resultado esperado.
Si volvemos al apartado de “Contexto” recordaremos que solo el 32% de los proyectos

son exitosos. Este hecho se debe a la carencia de adaptabilidad a cambios externos así como a
no primar el objetivo final: satisfacer al cliente. La aplicación del proceso no permite encontrar
errores en la definición de requerimientos o necesidades del cliente hasta las últimas fases del
mismo, determinando en ocasiones que el esfuerzo de semanas realizado por el equipo de
desarrolladores mediante “una aplicación de proceso de desarrollo de proyecto” correcto sea
ineficiente y no operativo, no teniendo ningún valor.
El secreto del éxito que el Desarrollo Ágil de Software ha tenido consistentemente en

la última década consiste en sus numerosos y rápidos ciclos de retroalimentación diseñados
para validar supuestos, sincronizar expectativas y validar la concretización del valor solicitado
por el cliente.
Hace más de dos décadas, ya Boris Beizer había anotado un fenómeno interesante en
su libro 'Software System Testing and Quality Assurance': “El costo de corregir un defecto es
directamente relacionado a su grado de exposición pública”. Cada defecto tiene un costo
asociado a su corrección. Este costo es menor mientras más temprano se detecte en el
proceso de desarrollo del proyecto. Este costo incluye factores de arquitectura, equipo
técnico, equipo de desarrollo y calendarización y rastreo. Pero el costo más grande de un
defecto se refleja en la pérdida de credibilidad con el cliente. El defecto más costoso de todos

será aquel encontrado por el cliente. Es decir, que el factor de éxito de las metodologías ágiles
no solamente ha sido la capacidad de manejar requerimientos cambiantes, sino también el
dramático incremento de calidad del producto entregado mediante una retroalimentación
mejorada.
Cada ciclo de retroalimentación es lo que denominamos una iteración, es decir, la

repetición de un proceso o conjunto de herramientas con objeto de alcanzar una meta, para su
posterior revisión y reinserción en el modelo nuevamente. El objeto es pulir y pulir una y otra
vez, priorizando las funcionalidades a desarrollar en el proyecto, sumándolas según se vaya
avanzando en el proyecto.
Conclusión: En vez de definir un modelo lineal de gestión en proyecto (modelo

cascada) que nos lleve del punto A (situación inicial / requerimientos) al punto B (producto
entregado), la planificación mediante iteraciones se fundamenta en la identificación de puntos
intermedios (A’, A’’, A’’’) en los que definamos productos intermedios. Éstos nos permitirán
validar los requerimientos y tomar nuevos, adaptándonos constantemente con el objetivo de
alcanzar la máxima satisfacción del cliente, fundamentada en la capacidad de encontrar
errores atrapados (el cliente puede comprobar si el producto creado incrementalmente
realmente se va ajustando a su visión de producto).
Del pensamiento analítico a la actitud reflexiva
La gestión de proyectos tradicional se construye alrededor del pensamiento analítico,

es decir, la capacidad de entender una situación y resolver un problema a partir de desagregar
sistemáticamente sus partes. Incluye la identificación de las implicaciones paso a paso, la
posibilidad de organizar las variables, realizar comparaciones y establecer prioridades de
manera racional.

Dicho modelo de pensamiento fundamenta la planificación lineal anteriormente

comentada:
 Corrige problemas basándose en el análisis de información que le proveen.

 Desglosa un problema en varias partes relacionándolas lógicamente.
 Es capaz de reconocer vínculos causales complejos.
 Anticipa los obstáculos y planifica los siguientes pasos. A partir de las prioridades
identificadas, realiza una distribución temporal de as actividades.
Sin embargo, aun siendo importante el pensamiento analítico, el pensamiento ágil se

fundamenta en la Actitud Reflexiva: sentido crítico, análisis de fuentes, detección y selección
de los problemas, comprobación de las hipótesis, proyección, capacitación de realizar
aportaciones personales y proponer enfoques.
Las metodologías ágiles se tratan de un enfoque empírico y muy práctico, sujeto a la

mejora continua: en lugar de largos periodos de análisis y discusión inicial, favorece la puesta
en marcha de soluciones en pequeños pasos, análisis del resultado, y reorientación inmediata
del proyecto en caso de no conseguir los resultados esperados. Bajo esta naturaleza, aun
primando en la fase de planificación cierto pensamiento analítico, es fundamental abrazar la
actitud reflexiva, ya que las fases de retroalimentación se fundamentan en la revisión de lo
realizado y la satisfacción alcanzada.
Del cliente/usuario pasivo al cliente/usuario activo
Retomando el modelo de cascada, podemos apreciar que actualmente, incluso sin

darnos cuenta, realizamos un proceso en el que hay momentos que el usuario está excluido de
nuestro proceso de desarrollo, más allá de la situación inicial y la meta final. A su vez, esto
mismo ocurre cuando pensamos en nuestro modelo de relación contractual con nuestro
cliente. En ambos casos los dos agentes causales del éxito de nuestro proyecto (necesidades
del cliente y aceptación del usuario final) quedan relegados a situaciones específicas donde
contamos con ellos.

Sin embargo, un valor intrínseco del agilismo es la apertura del proceso y la repartición
de responsabilidades más allá del equipo, involucrando en el proceso de desarrollo del
proyecto al usuario/cliente de manera activa y efectiva. Debemos ser conscientes de la
importancia de su rol en nuestro éxito y hacerlos participes del mismo, ya que nuestra
interactuación activa con estos agentes es fundamental más allá de fases concretas, sino a lo a
largo de la línea de tiempo.
De ahí, deriva la actitud de toma de requisitos de manera constante retroalimentando

el proceso en todo momento, y no entendiéndolas como una tarea inicial estática del mismo,
sino como una obligación dinámica.
De la documentación escrita y laboriosa al Visual Thinking
Personalmente, hace tiempo que tengo la reflexión de que la palabra es el peor

invento del hombre, ya que ella nos ha derivado en un modelo de comunicación escrita
laborioso y de baja utilidad. La necesidad de documentar y transmitir la información
concienzudamente ha desembocado en una idiosincrasia tal que la generación de
documentación y su archivo ha primado por encima de la necesidad de comunicación y
transmisión de la información.
Sin embargo, las personas no pensamos o asimilamos por palabras, sino que
traducimos todo en imágenes de manera natural. Así cuando me cuentan una historia yo la
recreo en mi mente con objeto de entender su complejidad y asimilarla.
En los últimos años, este hecho ha desembocado en una involución hacia el uso de
imágenes, esquemas, artefactos… es decir, herramientas que nos permitan recrear y
comprender la realidad que nos rodea. Herramientas de síntesis de la información, utilizadas
para converger el pensamiento y construir un marco en el que poder realizar una comprensión
y asimilación efectiva, permitiendo generar conversaciones.

Ello da como resultado una nueva disciplina denominada Visual Thinking (Wikipedia:
visual thinking is the common phenomenon of thinking through visual processing using the
part of the brain that is emotional and creative to organize information in an intuitive and
simultaneous way).
El Pensamiento Visual (Visual Thinking) es, en resumen, un proceso de soporte al

pensamiento, altamente efectivo que provee una manera simple, rápida y fácil de expandir
ampliamente nuestro pensamiento potencial sobre una base continua. Su aparición en el
agilismo se presenta fundamentalmente en 2 puntos clave:
 La organización del trabajo, realizada mediante paneles de tareas, haciéndola 1.0 y

permitiendo una revisión constante de un vistazo, en detrimento de grandes
documentos con diagramas de Gant y elaborados mapas de tareas, TaskBoard.
 La creación y definición de artefactos para la retroalimentación con el cliente, es

decir, la generación constante de prototipos en detrimento de documentación,
posibilitando una comunicación directa entre las personas.

1.4.5. RESUMIENDO
Sintetizando todo lo visto en el Manifiesto Ágil y sus implicaciones podemos definir la

esencia de la agilidad como una serie de atributos concretos a aplicar en la gestión de
proyectos:
 Capacidad de adaptación al cambio y flexibilidad: necesidad de abrazar la cultura

del fallo y saber afrontarla con garantías.
 Aprendizaje constante y continuado: reflexionar sobre lo ocurrido en todo
momento y continuar hacia adelante.
 Colaboración: todos en un mismo barco, cliente y usuarios incluidos.
 Redarquía como modelo organizativo: pequeños equipos auto-dirigidos.
 Principios Lean: incorporados del Lean manufacturing, sobre todo la sobra de
excedentes (Just Enough) y la entrega a tiempo (Just in time).
 Planificación iterativa: definición de espacios temporales de trabajo con incomes y
outcomes esperados de manera regular.
 El cliente como pilar fundamental: él es el foco de nuestro proyecto, y debe
participar activamente.
 Entrega incremental: realización de funcionalidades básicas de manera
incremental con la consecuente prueba de aceptación del cliente.
 Retroalimentación activa de los requerimientos: los detalles implícitos en el
proyecto se elaboran conforme se van necesitando, en detrimento de un punto de
partida estático en el tiempo.
La suma de los mismos ocasiona la redefinición del modelo de gestión poniendo en

relieve el verdadero Valor de la Agilidad, cuyos beneficios tanto a corto plazo como a medio
plazo son evidentes:
 Limpieza temprana de fallos y errores del proyecto, ya que se basa en gestión de

mini-proyectos (iteraciones) en vez de un proyecto mayor, manifestando de
manera temprana los problemas. Garantiza un alto grado de calidad en los
proyectos, debido a su enfoque y su constante realización de pruebas en busca de
fallos y retroalimentación de información.
 Garantiza la realización del producto correcto y acorde a necesidades del cliente,
basado en su alto grado de involucración y la necesidad de validación de cada
incremento de producto.
 Responde a la realidad actual del mercado basada en un entorno cambia e
impredecible en la mayoría de ocasiones, siendo suficientemente flexible para
adaptarse.

1.4.6. IMPLICACIONES EN LA EMPRESA
Acostumbrados a gestionar nuestras empresas como auténticas fortalezas, protegidas

por elevados muros de todo aquello que nos rodea, con una organización interna estructurada
y estable de respuesta ante situaciones de peligro, la asimilación de los conceptos y su puesta
en marcha requieren de una revisión y modificación de los modelos de actuación y su relación
con el entorno.
Cada día se demuestra con nuevos casos como una empresa pequeña y ágil es capaz
de reformular un sector, poniendo en jaque todo un mercado y las empresas largamente
establecidas en él. Empresas líquidas, con capacidad de adaptación a los cambios basadas en
organigramas flexibles, capacitadas para generar la mejor organización con las mejores
personas en cada momento. Cada situación requiere de una jerarquía distinta con personas
que lideren estructuras diferentes según las necesidades de la misma.
Respecto a una empresa tradicional, opaca en ocasiones para su público objetivo, una
empresa ágil sirve a las necesidades de sus clientes de la mejor forma posible, integrándolos
en profundidad, abriéndoles sus puertas y estableciendo valores de transparencia. De la misma
manera, su relación con colaboradores traspasa la propia de definición de proveedor (relación
de subordinación), integrándolos como compañeros de viaje (relación de riesgo compartido).
En última instancia, es capaz de entender nuevos conceptos como la coopetición, siendo capaz
de colaborar e interactuar con su propia competencia de manera efectiva y provechosa.
El objetivo de todo ello es ser capaces de adaptarse a las nuevas situaciones de un

mercado en constante cambio con éxito, la clave en la supervivencia en estos tiempos de
incertidumbre. Un nuevo status quo difícil de asimilar y poner en marcha, pero necesario de
asimilar gradualmente y con sentido común, no queriendo correr demasiado pues puede
generar conflictos, pero siendo constantes.
En definitiva, hablamos de empresas basadas en la Innovación abierta (Open

Innovation), término acuñado por el Profesor Henry Chesbrough, una nueva estrategia de
innovación bajo la cual las empresas van más allá de los límites internos de su organización y
donde la cooperación con profesionales externos pasa a tener un papel fundamental:
combinación del conocimiento interno con el conocimiento externo en favor de una mayor
flexibilidad y capacidad de respuesta.
1.4.7. CONEXIONES CON OTRAS DISCIPLINAS
Establecido el agilismo y sus principios en el mundo de la industria del software, la

idiosincrasia del entorno, que lo ha ocasionado y ha permitido su desarrollo actual, va más allá
del propio sector. El contexto en el que vivimos actualmente ha ocasionado, a su vez, una

profunda reflexión en la manera en que creamos y desarrollamos las empresas, así como la
resolución de problemas desde un prisma más amplio.
De esta manera, están comenzando a emerger nuevas y diversas corrientes y

metodologías que intentan responder a los problemas actuales. No estando acogidas en un
principio bajo los principios del Manifiesto Ágil, en cuanto profundizamos en ellas podemos
apreciar que perfectamente responden a sus pilares fundamentales. Entre ellas podemos
destacar las siguientes:
 Design Thinking
 Business Design
 Lean Startup
 Customer Development
Design Thinking
El Design Thinking (DT) o Pensamiento de Diseño es una disciplina que pretende aplicar el
proceso de diseño como enfoque holístico para la resolución de problemas. En un gran auge
en las escuelas de negocio de todo el mundo en los últimos años, su vínculo con ciertas áreas
concretas ha desarrollado disciplinas con entidad propia como el Service Design o el Business
Design.
Para su correcta comprensión podemos tomar a modo de ejemplo el proceso de la d.school de

Stanford, basada en 6 pasos iterativos:

Business Design
Como hemos visto, es la aplicación directa de los principios de diseño al mundo de los
negocios. Se basa en la generación de hipótesis, la definición de modelos de negocio, su
prototipado e iteración en detrimento de la planificación y el Plan de Empresa.
Está orientado a la búsqueda de una modelización válida para la construcción de una

empresa, muy ligado al lanzamiento de nuevos productos y servicios. El mayor referente es
Alex Osterwalder, con su libro Business Model Canvas, una herramienta para dibujar y generar
modelos de negocio, permitiendo su rápida visualización y revisión.
Lean startup
Se trata de la maximización de los conceptos del Lean Manufacturing en el mundo de

las startups y su lanzamiento a mercado. Su pilar fundamental es la definición del MPV,
Mínimo Producto Viable, es decir, el entregable mínimo al cliente final para que experimente
el producto o servicio que se le quiere vender, con el objetivo de disponer de betatesters que
nos ayuden a mejorarlo y cerrarlo.
Customer Development
Se trata de una modelización de proceso de puesta en marcha de una idea de empresa

y su construcción basada en la búsqueda e identificación de clientes. Sobre todo orientado
hacia ideas emprendedoras nuevas en el mercado, sin antecedentes, y con la necesidad de
identificar su nicho concreto u océano azul.
Predomina el uso del modelo de Steve Blank, profesor Stanford:

Realizado un primer acercamiento a las mismas, no es hora de profundizar en ellas en

detalle, ya que todas serán abordadas a lo largo del curso. Simplemente matizarlas y explicar
que, aunque quizás los puristas del agilismo pudieran verlas como externas y desvinculadas,
los principios que las rigen y su funcionamiento es semejante y/o cercano a cualquier
metodología pura como Scrum o Kanban. Por ello, se considera fundamental su incorporación
y comprensión para una mayor capacitación en la gestión y dirección de proyectos.

1.5. Ideación ágil. Creatividad e innovación aplicada al

agilismo
1.5.1. CONTEXTO
En una sociedad sumida en el mundo de las redes sociales y la comunicación por

Internet, donde toda la información está al alcance de un click, la persona es plenamente
consciente de lo que consume y la calidad de sus productos. Nos hemos convertido en
“consumidores expertos”, estamos evolucionando hacia un nuevo paradigma, el
protoconsumidor, paso inevitable debido a la complejidad de la sociedad actual. Los
problemas ya nos son puntuales, sino holísticos.
Esto, unido al desarrollo de las vías de comunicación y distribución, hace que hablemos
de un mercado global y que el pensamiento de las empresas comience a ser GLOCAL (acción
local, alcance mundial).
Las consecuencias son evidentes en la evolución de la percepción del mercado y el

producto, siendo las más destacables:
 Saturación de información: como contrapartida negativa a la capacidad de

constituirnos como expertos, a veces estamos sobrexpuestos a demasiados inputs,
lo que ocasiona el efecto contrario, confusión.
 Falta de diferenciación: el mundo glocal ha desarrollado mercados homogéneos en
zonas geográficas dispersas entre sí.
 Desarrollo de un entendimiento distinto de la propiedad privada: consecuencia de
nuevos hábitos, decrecimiento de status de ciertos productos...
 Colapso de la oferta en relación a la demanda: no todo lo fabricado/desarrollado
se vende.
Por norma general, se considera que una idea fallida es consecuencia de un mal
desarrollo o finalización. Sin embargo, en un alto porcentaje, las causas se deben, en su etapa
inicial, a un incorrecto planteamiento del problema o a caminos iniciales mal seleccionados. La
causa principal se debe a una baja exploración inicial del contexto y un trabajo más enfocado
en la ejecución final y puesta en funcionamiento que en la construcción y maduración de la
idea.
“La innovación es 1% inspiración y 99% perspiración”. Thomas Alba Edison
Por otro lado encontramos que la mayoría de las empresas o emprendedores fallan
por falta de clientes más que por un fallo en el desarrollo de producto / servicio

En la mayoría de ocasiones es consecuencia de que olvidamos quién es el centro de

nuestra idea, la PERSONA, aquella más cercana a nosotros. Nos movemos en un mundo que
creemos conocer basándonos en estadísticas y datos (estudios cuantitativos), sin embargo, el
conocimiento personal, único, será aquello que nos dote de diferenciación y guíe nuestro
trabajo hacia un correcto final (estudios cualitativos).
Como resultado, se empieza a establecer la necesidad de nuevos modelos de captación

de la voz del cliente, es decir, de conocer a las personas para innovar y crear nuevo valor ya
que, en la coyuntura descrita, los modelos y herramientas tradicionales se presentan bajo las
siguientes características:
 La investigación cuantitativa describe hechos ya cotejados.

 Es un proceso lento y plausible.
 De mercados controlados hemos pasado a mercados de riesgo.
 La velocidad de la sociedad de la información no es medible.
Por contrapartida, hoy en día debemos explorar nuevas posibilidades orientadas hacia
una investigación más cercana al usuario que nos permita conocerlo en profundidad e
identificar sus necesidades, como punto de partida necesario. El objeto es ponernos en la piel
de la persona que usará el producto o servicio y plantearlo como si fuera aquella persona
quien lo estuviera desarrollando. Se trata de desarrollar la capacidad de tener empatía con la
persona objetiva y, a ser posible, integrarla en el propio proceso de desarrollo.
Hablamos en términos generales de cocreación, trabajada principalmente por la

disciplina del Design Thinking, integrada en la actualidad en las Escuelas de Negocios más
prestigiosas tanto internacionales (Standford, Harvard o Rotman School) como nacionales (IE,
ESADE, EOI). Es una filosofía de trabajo válida que está teniendo un rápido despliegue y
expasión internacional en los últimos años. Es tal su madurez de implementación en ciertos
lugares como USA que ya se empieza a hablar de su posible muerte y evolución hacia un paso
posterior, si bien en países como España apenas ha tenido calado alguno por el momento (solo
grandes compañías multinacionales).
Visto en profundidad a posterior, en resumen se trata de aplicar la filosofía de diseño

basada en la experimentación y exploración de escenarios para capacitar la búsqueda de
nuevas oportunidades de negocio o definir planteamientos de proyectos (conceptos iniciales).
Sin embargo, los nuevos escenarios no existen, hay que crearlos. De nada sirve la posición del
follower, debemos construir nuestro propio futuro, no esperarlo. Una de las premisas que
debemos plantearnos es: "¿qué es lo que hay y hacia donde lo dirigimos?".
Una meta gigante, inalcanzable quizás, nos da posibilidades mayores de crear nuevas
formas de actuar antes las incipientes necesidades aun no descubiertas. Y es ahí donde
debemos actuar.

El problema es ¿cómo capto estas ideas? ¿Es realmente una buena idea lo que creo
que lo es? Todas estas cuestiones paralizan a muchos, porque muchas veces nuestras idea se
desinflan rápidamente, no son solidas. Por ello debemos asumir dos capacidades, el
pensamiento disruptivo y la capacidad de hibridación. Ambas nos ayudaran a modelar y
entender la idea. También debemos abrazar la cultura del prototipado rápido, que nos
conferirá la idoneidad o no del producto. El mejor consejo: just do it (solo hazlo).
Vivimos una época de incertidumbre en la que debemos abrazar nuevas opciones y

posibilidades, ya que lo anterior, los modelos pasados, se están quedando impotentes para dar
respuesta a proyectos y empresas. Por ello, además de nuevas formas de hacer las tareas y
procesos en la gestión y desarrollo de proyectos, necesitamos nuevas capacidades en el
comienzo de los mismos, en la etapa embrionaria del proyecto, aquella donde se gestan las
ideas.
1.5.2. INTRODUCCIÓN A LA CREATIVIDAD E INNOVACIÓN
Por norma general, entendemos la innovación como algo novedoso, que desafía al
status quo y lo no visto hasta el momento. Sin lugar a dudas, en muchas ocasiones suele ser un
valor implícito como tal dentro del concepto, aunque bien mirado bajo ese prisma se trate de
una delimitación escasa y banal.
Innovar es la capacidad de crear valor para la persona, conseguir entregar esa nueva
propuesta de manera clara, directa y sencilla, y que alguien esté dispuesto a pagar por ello
(monetizar). La innovación debe partir de la persona y, para cerrar el círculo, esta debe ser su
fin último. Todo ha de girar en torno a ella. Para lograr este objetivo, la única manera es
entender su mundo, su contexto y sus realidades, disponer de habilidad para contar su historia
actual y alcanzar un conocimiento tácito tal que nos permita hacer intervenciones en ella,
desarrollando nuevas historias que solucionen un problema identificado o que realicen un
incremento de aportación de valor.
Ahí es donde entra en marcha la creatividad como capacidad innata de la persona, que
a la vez que está más o menos predispuesta en unos individuos más dotados, se puede
entrenar (semejanza de la memoria o nuestra capacidad física por ejemplo). Banalizada por
norma general como la capacidad de pensar diferente, de generar ideas o de ser imaginativos,
no debemos quedarnos solo en esas posibles características inherentes o definiciones parciales
sino entender realmente su naturaleza: capacidad de generar nuevas asociaciones entre ideas
y conceptos conocidos, que habitualmente producen soluciones originales (entendido original
como inédito).

Esta es la base de su importancia en el mundo empresarial actual, el por qué se prima

hoy en día, porque diferenciarse es complicado y es más necesario que nunca encontrar
nuevas relaciones, nuevas posibilidades, sutiles e inexploradas, cuando quizás en una época
pasada eran relaciones superficiales y evidentes. Debemos aprender a ir más allá de los
problemas, de los contextos y realizar conexiones y asociaciones que nos doten de un nuevo
imaginario que en su puesta en marcha se convierta en nuevas soluciones / productos /
proyectos...
Sin las premisas anteriores, hablando del mundo de la empresa, nos quedamos en los
primeros pasos del camino y hablamos de I+D. Sin embargo, recordemos que innovación es la
segunda vocal de la secuencia I+D+i+d. Alcanzar esa "i" minúscula es complejo, y va más allá de
la investigación básica, algo que los americanos entienden a la perfección pues es su foco
principal. Al otro lado del Atlántico piensan desde el inicio en monetizar, mientras que a veces
en España cometemos el pecado de anclarnos en el primer paso del camino, creyendo que por
investigar y desarrollar todo vendrá de seguido. Esto provoca que en ocasiones los astros no se
alineen, lo que sumado al cortoplacismo imperante hace necesario que revisemos nuestra
mentalidad empresarial.
Debemos trabajar por y para el usuario, desarrollando desde la necesidad, no desde la

posibilidad. Tenemos que crear historias en la base de la pirámide, usando la creatividad,
impulsando el desarrollo de la innovación.
Sin embargo, ya en el año 2006, en una de las charlas TEDx de mayor referencia, Sir
Ken Robinson evidenciaba y ponía en el estrado un tema candente: las escuelas matan la
creatividad. Nacidas como consecuencia de la Revolución Industrial y en pos del desarrollo de
un pensamiento maquinista acorde con la industria, desde pequeños, las escuelas nos forman
en un pensamiento deductivo maduro, actuando en base a unas respuestas plausibles ya
predispuestas. El objeto, fomentar la mejora continua y evitar provocar fallos imprevistos y no
controlados.
Ciertamente pocas cosas han cambiado desde entonces. Sir Robinson lanzo un
mensaje al cielo que quedó en nada en nuestras escuelas, solamente en pequeños esfuerzos
aislados que no han tenido un golpe de efecto evidente.
Su consecuencia evidente es que cuando preguntas a un adulto pocos se sienten

creativos. Por contrapartida, es posible alterar la inercia, entrenar y capacitarse. Para ello se
necesitan comprender y practicar una serie de premisas, metodologías y procedimientos:
 Pensamiento disruptivo: romper con las reglas establecidas y ser capaces de

explorar caminos nuevos, en cercanía a las antítesis de lo establecido.
 Hibridación: Capacidad de disociar conceptos para asociarlos de manera distinta
sumando un orden mayor al anterior. El producto como resultante mayor que la
mera suma de las partes.
 Design Thinking: capacidad de mezclar el pensamiento convergente y divergente
en ciclos de desarrollo de las ideas, ampliando o cerrando el flujo de información

en relación a la necesidad del momento.

 Learning by doing: necesidad de prototipar las ideas, hacerlas realidad para poder
generar espacios de conversación.
1.5.3. PENSAMIENTO DISRUPTIVO. LA ROTURA DE LAS BARRERAS

ESTABLECIDAS
“Si juegas con sus reglas, siempre irás detrás”
disruptivo, va.
1. adj. Fís. Que produce ruptura brusca.
Inmersos ya en plena maduración de la era de la información, donde todo el

conocimiento está disponible, la pregunta es ¿cómo generar ideas que realmente sean
novedosas con lo todo lo que existe ya? Ante esta situación nos encontramos con 2 posibles
soluciones:
 Bien intentas generar cosas aportando cierto valor, es decir, innovación evolutiva.
 O por el contrario rompes con el camino establecido y generas nuevos senderos,
innovación disruptiva.
La innovación evolutiva consiste en incorporar cambios incrementales, introduciendo

mejoras y aumentando la calidad. No es un pensamiento diferenciador, ya que el usuario poco
a poco no siente estas mejoras como algo novedoso, sino más bien como un añadido.
Entramos de lleno en un “Océano Rojo”, es decir, en un mercado saturado de ofertas. Ejemplo:
Evolución de los móviles.
Sin embargo, si optamos por la línea disruptiva, rompemos con lo establecido e

inventamos un mercado nuevo, nosotros ponemos nuestras normas y nosotros decidimos.
Generando algo totalmente diferenciador, las personas detectan rápidamente algo novedoso,
algo que nunca habían visto antes. Sorprender a la gente es lo más difícil en este mundo y para
llegar a esto tienes que hacerles descubrir que puede haber otra manera de hacer las cosas. Ej:
Los smartphones, que generaron un nuevo ecosistema, una nueva forma de relacionarse y
como consecuencia generaron el mercado de APP, creando así un Océano Azul, es decir, todo
un mercado por explorar.

La ideas disruptivas no son fáciles de generar y menos de implementar. Una idea

disruptiva suele crear ideas peligrosas, y no nos referimos a ideas que hagan daño a la
humanidad, sino a pensamientos que se enfrentan a los paradigmas existentes, ideas que
pueden hacer tambalear un Status Quo. Romper lo que lleva definido y establecido durante
años cuesta, estas ideas provocan miedo o rechazo porque son totalmente nuevas y como
buenos animales que somos eso nos asusta, pero debemos confiar en el pequeño simio
curioso que llevamos dentro. Si no provocamos esta reacción, nuestra idea no es totalmente
disruptiva.
¿Cómo desarrollamos el pensamiento disruptivo y la generación de ideas?
"En la mente del principiante hay muchas posibilidades, en la del experto, pocas" S.
Suzuki
¿Qué fue antes, el huevo o gallina? Para llegar a esa idea realmente radical debemos
formular la pregunta, aquella hipótesis que realmente nos hará generar un idea totalmente
disruptiva, porque sin la pregunta anterior es difícil generar realmente innovación disruptiva
(propuestas que generen valor) que no es lo mismo que generar ideas disruptivas. De este tipo
de ideas hay muchas, pero pocas llegan a la realidad.
La hipótesis disruptiva sirve para estar totalmente equivocados al principio y para

forzar la razón al final. Planteadas ciertas preguntas, al responderlas debemos adoptar valores
y actitudes en pos de identificar conexiones que nadie había visto antes, ideas totalmente
estúpidas hasta que alguien las observa desde otro punto de vista, la complejidad resuelta en
una astuta idea sencilla. Debemos tener mente abierta y ser capaces de:
 Ejercitar la capacidad de análisis. Para generar cosas nuevas (y útiles) debes

observar y reflexionar. ¿Qué es realmente lo que le está pasando a tu usuario?,
¿qué pasa en su entorno?
 Comprender la sencillez. Convertir lo inmensamente complejo en algo sencillo y
útil. Estamos rodeados de estímulos, necesitamos cosas que nos solucionen la
vida e incluso necesitamos aparatos involucionados. A lo mejor solo necesito dos
botones y no treinta. Ordenar el caos en una premisa sencilla es uno de los
principios básicos para esta era de infotoxicación.
 Abrazar el absurdo. Convertir lo aparentemente estúpido en algo genial es
posible, si bien tienes que sentirte cómodo con el pensamiento, no tacharlo de
inútil. Por ejemplo, un Chupa Chups, un caramelo con un palo, algo simple, pero
inmensamente inteligente.
 Ejercita la generación de conexiones aleatorias. Unir lo improbable, ser capaces
de meter todo en un vaso a ver qué sale... Así surgió el gintonic. En ocasiones, lo
más inverosímil es el mejor camino a tomar.

¿Cómo podemos implantar estas ideas?
A la hora de poner estas ideas en el mercado, existen 2 posibilidades:
 Encontrar early adopters del mercado o sector en el que trabajo, es decir, aquellos
que buscan la novedad como estilo de vida o hobby, porque de ellos nos
serviremos para mejorar la idea (suelen ser usuarios avanzados).
 Encontrar un nuevo nicho no solo en la idea sino en los clientes (de nuevo filosofía
Océano Azul).
¿Existe algún procedimiento?
No existe un proceso claro y estructurado universal que determine el modo de realizar

una generación de ideación disruptiva, sino que a veces puede ser un proceso concienzudo,
reflexivo y largo o bien una serendipia o vacilación fortuita fugaz. Intentado estructurar un
modelo válido para su aplicación como herramienta de resolución o identificación de
oportunidades podríamos aplicar los siguientes pasos:
 Definir la situación en la industria, mercado o categoría en que queramos realizar

una disrupción. Por ejemplo, una situación que no ha cambiado durante mucho
tiempo, la de los calcetines. Debemos evitar buscar problemas, no se trata de eso,
sino de que las mejores hipótesis e ideas surgen de espacios donde parece que no
hay nada mal.
 Identificar los clichés. Supuestos y prejuicios asociados. Podemos identificarlos a
través de la comparación de dos productos, competidores, etc., o bien preguntando
a la gente. Recordad que los supuestos naturales son los mas fáciles de ignorar.
Ejemplo: siempre se venden de 2 en 2 // son iguales.
 Generación de diversas hipótesis “What if..?”. En los clichés identifica cosas que se
puedan quitar, invertir o exagerar en escala. Con esa premisa genera diversas
preguntas. Ejemplo: ¿qué pasaría si no fueran 2? ¿Qué pasaría si no fueran iguales?
¿Qué pasaría si fueran más de 2? Etc. Selecciona 2 o 3 de ellas para continuar.
 Descubriendo una oportunidad de disrupción. Pon las hipótesis en acción, realiza
una serie de cuestiones asociadas a tus hipótesis y realiza un proceso de
investigación cualitativa básico. Pregunta a consumidores, actuales potenciales y no
consumidores. Ejemplo: ¿cómo usas los calcetines? ¿Los mezclas alguna vez?
¿Cómo los compras? Filtra la información recogida e identifica oportunidades
donde poder actuar. Intenta describir la oportunidad en una frase de 3 partes (Para
quién es + la ventaja que entregas + el hueco que revela). Recuerda que una
oportunidad no es una solución. Define un área de creación de soluciones. Ejemplo:
proveer a las niñas una oportunidad de reafirmación de personalidad.
 Generación de una idea disruptiva, transformar la oportunidad en 2 ideas de gran
impacto. Piensa de manera creativa y genera todas aquellas que den respuesta a la
hipótesis y a tu planteamiento de oportunidad. Ejemplo: calcetines impares de
colores.
 Dale forma a tu solución disruptiva. Para facilitar el feedback del usuario final

genera prototipos para testar y redefinir la idea hasta una sola solución. Sal a
buscar a ese cliente y mejora la solución hasta el punto de ver su posibilidad de
implantación.
1.5.4. HIBRIDACIÓN - 2 + 2 = 5
“Puede que esté todo inventado, pero aun faltan muchas cosas por conectar”
¿Cuántas veces te han arremetido con esta frase, la de que todo esta inventado”?
Muchísimas, seguro. Pero el problema de raíz no es ese. Para crear se necesita ver lo que
existe (las famosas cosas ya inventadas), entenderlo y asimilarlo. No se puede crear de la nada,
necesitas llenar la cocina para cocinar, ya que si no tienes ingredientes, por muchas recetas
que conozcas no harás nada.
La hibridación consiste en combinar piezas dispares de tal forma que, según su

naturaleza, cuanto menos tengan que ver mayor será el nivel de hibridación conseguido.
Podemos mezclar lo que queramos, pero si queremos resultados más disruptivos

debemos juntar lo impensable y generar conexiones improbables llegando a enlaces poco
predecibles. Sin embargo, no se trata de hacerlo de manera desorganizada (entonces no sería
un método sino una casualidad) sino que la hibridación, a la hora de generar conceptos, parte
de lo conocido, entendiendo sus variables e idiosincrasia de manera concienzuda para buscar
la intersección de 2 o más ideas para generar terceras. De nada sirve mezclar por mezclar, no
es coger un poquito de aquí y un poquito de allá, a ver qué pasa, sino que es necesario conocer

primero los ingredientes a mezclar, conocer su esencia, siendo estas más fáciles de unir que
partir de entes más abstractos. Es decir, si cojo una Coca-Cola y una Fanta de naranja y las
mezclo, el resultado será algo que no tiene mucho sentido. En cambio, si conozco los
ingredientes a mezclar (hibridar), cojo un poco de E-25 y pongo cítrico más un poco del azúcar
de la Coca-Cola y puede que salga algo con más sentido y que sea novedoso.
¿Cómo conecto estos elementos dispares para generar algo nuevo?
Existen diferentes tipos de hibridaciones según su modelización:
 Por agregación. Se trata de juntar piezas que conserven su disciplina, como por
ejemplo un sonajero pesa o papel higiénico con Sudokus impresos. Aun uniendo
estos dos elementos, ambos no han perdido su funcionalidad.
 Por Síntesis. Se trata de mezclar conceptos buscando atributos en conflicto, como
por ejemplo buscar una sopa fría o una bebida solida. Esta técnica era muy
utilizada en el Restaurante El Bulli.
 Por traslación. Inspirarnos en soluciones de un campo para llevarlas a otras, como
por ejemplo, en vez de máquina expendedora de bebidas frías, máquina
expendedora de pan caliente. La idea aquí es la de tratar de cambiar el registro del
problema, descontextualizar la solución e integrarla en un nuevo contexto.
La barrera asociativa
Siendo la hibridación una herramienta muy poderosa tenemos que tener en cuenta a
su archienemigo, la barrera asociativa. Como comentábamos antes, la hibridación debería
hacerse entre elementos muy dispares, así llegaríamos a verdaderos elementos novedosos,
pero algo frena esto y es la barrera asociativa.
Desde pequeños nos vemos inmersos en una educación que nos genera, a medida que
nos vamos haciendo mayor, un control más preciso sobre el lenguaje. El lenguaje consiste en
una asociación de conceptos preexistentes, de tal forma que cuanto mayor control tenemos
del mismo, mayor es nuestra relación con elementos de nuestra cultura, pero ¿qué conlleva
esto? A la hora de generar conexiones entre diferentes términos, estas suelen ser predecibles
y acordes con nuestra cultura, es decir, estamos muy contaminados por un solo tipo de
ingrediente.
Por ejemplo, si a un adulto de Occidente le preguntamos qué asocia con la palabra

“escoba”, su respuesta seguramente sería, “limpieza”, ”polvo”, ”suciedad”, etc. En cambio, si
se le pregunta a un niño (de occidente también), sus asociaciones serán mas ilógicas. Por
ejemplo, diría “caballo”, “juguete”, “mando a distancia”, etc. ¿Por qué pasa esto? Porque aun
no tiene muy definida esta asociación de ideas que conlleva vivir inmerso en una cultura “x”.
Por tanto, no posee aun esta barrera y es libre de generar cualquier conexión, simplemente
está jugando.

A la hora de crear cosas/ideas nuevas, es necesario romper esta barrera, disponiendo

del “azar” y las relaciones forzosas como una manera de posibilitarnos a mezclar ingredientes
diferentes. Tratando el azar, hablamos de la serendipia o hallazgo afortunado e inesperado
que se produce cuando se está buscando otra cosa distinta, es decir, hay que estar atentos y
racionalizar los descubrimientos bajo las 3 posibles asociaciones de hibridación descritas para
maximizar y modelar la idea. Las relaciones forzosas consisten en confrontar realidades
distantes, intentando entender su esencia y cómo conjugarla (ejemplo: artesanía+nuevas
tecnologías).
Como conclusión, antes de comenzar la senda de la hibridación debemos:
 Superar nuestra capacidad de asociación limitada por el uso del lenguaje.

 No cerrarnos en lo conocido, sino todo lo contrario, abrirnos para poder
conectarnos con otros elementos, los campos que no comiencen a introducir poco a
poco esta cultura de la conexión están condenados a desaparecer.
 Entender también que la hibridación es complejidad y diversidad. Por tanto, va a
haber más creatividad pero también menos eficiencia (al menos a corto), ya que
estamos experimentando y explorando nuevas vías hasta que demos con la que nos
funciona mejor.
“Dos y dos son cuatro, he aquí una idea bella, pero dos y dos hacen cinco es una idea
encantadora” Dostoievski
1.5.5. DESIGN THINKING O PENSAMIENTO DE DISEÑO
El Design Thinking (DT) o pensamiento de diseño es una disciplina que pretende aplicar
el proceso de diseño como enfoque holístico para la resolución de problemas.
En líneas generales, se trata de un enfoque práctico basado en enfrentar los desafíos

de gestión, de desarrollo de negocio, de desarrollo de servicios, etc., desde la misma
perspectiva y sistemática con la que un diseñador enfrenta y resuelve proyectos. Por ello, es
importante entender el diseño como el proceso de proyectar y no meramente como la
definición de la belleza y la funcionalidad. Steve Jobs lo definió en su frase “Design is not just
what it looks like and feels like. Design is how it works“ (diseño no es solo cómo parecen y se
sienten las cosas. Diseño es cómo funcionan).

Pudiendo parecer algo llamativamente nuevo, no deja de ser anecdótico que ya a

mediados del siglo XX, Charles Eames, uno de los mayores iconos del diseño de mobiliario de la
historia, definiera los límites del diseño como los limites de los problemas (“the boundaries of
design are the limits of the problems”).
En un contexto complejo como el actual, con demasiada información que tratar y

digerir, unido a una situación de incertidumbre, su principal arma es que se presenta como una
herramienta válida (que no exclusiva ni excluyente) para desarrollar soluciones alcanzando
puntos óptimos para la toma de decisiones. Uniendo el pensamiento racional y lógico con la
intuición, aparece un marco de trabajo que va más allá del pensamiento deductivo tradicional
(soluciones válidas a escoger) y explora el pensamiento abductivo (soluciones a explorar, no
descubiertas o planteadas previamente).
Su definición, crecimiento y evolución en los últimos años ha consolidado una serie de

bases que lo sustentan y construyen su identidad:
 Colaboración: trabajo colectivo (más de 3 personas), entendiendo el grupo por

encima del individuo. Actitud de apertura, cualquiera tiene algo interesante que
aportar.
 Integración: necesidad de observar desde una perspectiva global teniendo en
cuenta todas las posibles implicaciones, no solo de nuestro punto de vista sino de
todos los “stakeholders” implicados (grupos de interés).

 Interpretación: se trabaja sobre la construcción de suposiciones para identificar

los problemas y ver las posibles soluciones. La verdad absoluta no es
contemplada, no se plantea ni se admite. Se definen ideas válidas y posibles, no la
única.
 Exploración: fomentar la visualización de ideas espontáneas para descubrir
caminos no planteados ni validados con anterioridad.
 Experimentación: hacer prototipos para testear todo aquello que queramos llevar
a la práctica. Testar e iterar en estadios tempranos de la idea para saber qué es lo
que funciona y qué es lo que no (learning by doing).
 Iteraciones: no es un proceso lineal sino un proceso iterativo que reformula y
replantea una y otra vez en relación a esos experimentos, construyendo la
solución final.
 Cocreación: focalización en la comprensión de las personas y en la definición de
necesidades que surjan de las propias personas. Validación y construcción de las
ideas en colaboración con el usuario final.
Cabe resaltar la importancia de este último epígrafe, ya que define el Design Thinking
como un Human Centered Innovation Approach (enfoque de innovación centrado en la
persona) y constituye una de sus mayores señas identificativas. Se trata de trabajar siempre
desde la perspectiva de las personas como individuos, dejando en un segundo plano la
tecnología y el mercado. El objetivo es encontrar y resaltar necesidades no cubiertas o
incipientes puntos de conflicto, es decir, la base subyacente detrás del desafío de partida
inicial se entiende en relación a los propios sujetos implicados y debemos comprender su
contexto y realidad. Comprendida esta realidad, estaremos en disposición de desarrollar ideas
y soluciones coherentes y con fuerza.
Para qué y para quién sirve
Por norma general se considera que una idea fallida es consecuencia de un mal
desarrollo o finalización. Sin embargo, en un alto porcentaje las causas se originan en su etapa
inicial y se deben a un incorrecto planteamiento del problema o a caminos iniciales mal
seleccionados. La mayoría de las empresas, emprendedores o instituciones fallan por falta de
clientes, usuarios o adecuación más que por un fallo en el desarrollo del producto o servicio.

En la mayoría de ocasiones es consecuencia de que se olvida quién es el centro de

nuestra idea, la persona, aquella más cercana a nosotros. Debemos ponernos en la piel de la
persona que usará el producto o servicio y plantearlo como si fuera aquella persona quien lo
estuviera desarrollando. Se trata de desarrollar la capacidad de tener empatía con la persona
objetiva.
Como hemos visto, Design Thinking es un Creative Problem Solving englobado dentro
del denominado campo Human Focus Centered, colocando a la persona como eje principal
básico del proceso de innovación. Realizado en equipos multidisciplinares, es una verdadera
herramienta de cocreación, donde la voz de nuestro “stakeholder” es esencial, primando la
investigación cualitativa sobre los datos. Es un cambio radical de la perspectiva de diseñar para
personas a diseñar con personas.
Crear valor es lo que importa, tener una idea y no saber en qué va a mejorar la vida de
las personas no es una idea buena, pero si entra en la narración de una historia y conseguimos
lograr poner al usuario en ese escenario, estaremos en el camino correcto. ¿Por qué? Porque
la innovación ya no se centra solo en la tecnología más optima, ni el producto más barato, ni
en el modelo de negocio más disruptivo. Todo empieza en una historia y la parte que nos toca
es conocer a nuestro cliente. ¿Conoces a esa persona? ¿Podrías contarme como es su historia
diaria? ¿En esa historia ves algún punto en donde podríamos ayudarle o mejorar su historia?
Lo único que importa es saber empatizar con nuestro cliente o usuario. Debemos
conocer su historia y lo que es muy importante, los detalles. Si conoces esos detalles, por qué
hace esas cosas y qué siente al hacerlas, ahí es donde podemos ayudarle, desarrollando la
solución adecuada.
Con dicho objetivo, el Design Thinking puede utilizarse para resolver un amplio abanico
de problemas y ámbitos, tan distantes entre sí como son el desarrollo de productos o servicios,
el diseño de modelos de negocio o la definición de programas de ayuda social.
Como hemos visto, lo fundamental es que, más allá de herramientas concretas o

procesos, se trata de una forma de trabajo, una actitud y una mentalidad que se aplica cuando
la gestión y modelos tradicionales no dan más de sí y buscamos planteamientos que se salgan
de los límites establecidos. Su vinculación con diferentes ámbitos está desarrollando una
integración espontanea y natural que esta desembocando en disciplinas con entidad propia

tales como Business Design o Service Design, diseño de negocios o diseño de servicios
respectivamente.
Por ejemplo, la aplicación del Design Thinking al diseño de modelos de negocio o

estrategias empresariales se trata básicamente de adaptar el negocio o la estrategia de la
empresa a las necesidades de sus usuarios o clientes.
Cómo se lleva a la práctica
Quizás el punto más crítico en cuestión del Design Thinking es su puesta en práctica. Si
realizamos una búsqueda en Google podemos encontrar diversas modelizaciones y procesos,
desde el principal y más extendido desarrollado por Standford a los definidos por empresas
privadas. El problema es que básicamente definen unos marcos de trabajo unidos a unas
herramientas ampliamente extendidas, pero generalmente se entienden como la panacea
universal, dogmatizando sobre su utilización y puesta en marcha.
Sinceramente, definido en el primer apartado el Design Thinking como un proceso

válido que desarrolla soluciones óptimas con la humildad de no disponer de la capacidad de la
definición de una solución única y legítima, sino una aparentemente aplicable, no podemos
pretender disponer de un modelo único e irrefutable.
De hecho, se comienza a hablar de la muerte de la disciplina por no haber respondido

a las expectativas creadas. Su integración en las empresas ha ido unida a una industrialización
del proceso, lo que a último término, como consecuencia, haya provocado que de constituir
una apertura de mente y búsqueda de soluciones nuevas se haya convertido en un proceso

más de mejora continua, encasillado dentro de un paradigma de pensamiento lineal en vez de

entenderlo como iterativo y flexible.
Entendida la idiosincrasia de su aplicación, más allá de la búsqueda de un proceso de

trabajo legitimo y su definición o aplicación exhaustiva, sí podemos decir que existe un
“proceso de diseño” básico común y subyacente a las diversas modelizaciones actuales del
Design Thinking. En el año 2005, el British Design Council, máxima entidad de difusión del
diseño en Reino Unido, a partir de un estudio de investigación realizado en empresas de
primer nivel definió un simple gráfico: los dos diamantes.
Dividido en cuatro fases distintas, "descubrir", "definir", "desarrollar" y "ejecutar",

asigna las diversas etapas divergentes y convergentes del proceso de diseño, mostrando los
diferentes modos de pensar que los diseñadores utilizan en un proceso estándar.
Descubrir
La primera etapa del modelo de doble diamante marca el inicio del proyecto.
Comienza con una idea burda inicial, algún descubrimiento espontáneo o un desafío/problema
definido a resolver. En esta fase se centra la investigación pura y dura centrada con
herramientas de investigación cualitativa y se comienzan a identificar las necesidades del
usuario.

Definir
En un segundo paso encontramos la etapa de definición, en la que la interpretación y

la alineación de estas necesidades con los objetivos empresariales se focalizan conjuntamente
generando un punto anclaje, el brief (en diseño de producto – especificaciones de desarrollo
de producto)
Desarrollar
El tercer cuartil marca un período de desarrollo del proyecto en el que se generan

ideas, diversas soluciones al problema enmarcado en los pasos anteriores. Se exploran
posibilidades y se comienza la visualización de conceptos maduros y la creación de los
primeros prototipos.
Ejecutar
La última fase representa la fase de entrega, donde el producto o servicio está

finalizado y se procede a su puesta en marcha y a su definición final hasta llegar al punto de
entrega al cliente.
Como podemos ver en la imagen, se hace evidente la necesidad de complementar el

pensamiento convergente con el divergente, realizando ciclos de apertura en búsqueda de
información y cierre de foco. A su vez, entendido como una modelización sistémica, su
aterrizaje a tierra, generando un proceso que guíe el desarrollo de la actividad, desemboca en
diversos dibujos y esquemas como los siguientes:

Fuente: D-School Stanford
Fuente: fjordnet
Por ello es necesario que cada persona, empresa o entidad interiorice el DT y proceda
a definir una adecuación del mismo para su contexto, a la par que dejar espacios abiertos para
su adecuación a la necesidad de cada proyecto en concreto.
Case Studies Design Thinking
 ‘Design Thinking’ Initiative: The Innovation Lessons

 Discoverables
 Matter
 Patient information mat.

1.5.6. LEARNING BY DOING. NECESIDAD DE PROTOTIPAR LAS IDEAS
“Las cosas no se dicen, se hacen, porque al hacerlas se dicen solas”. Woody Allen
Actualmente vivimos en una sociedad en la que el riesgo está sobrevalorado,

preservando decisiones y procesos a una elevada madurez de desarrollo de las ideas y los
proyectos que permitan una clara evaluación de las consecuencias. El miedo al fracaso es una
constante, si bien el mismo no existe si de la caída o el error aprendemos una lección.
En la mayoría de ocasiones se cree que una idea fallida es consecuencia de que fue mal
desarrollada o finalizada, sin embargo, en un alto porcentaje, las causas se generan en su
etapa inicial, ya que la mayoría de las empresas fallan por falta de clientes más que por un fallo
en el desarrollo de producto / servicio
Nos movemos en un mundo de metainformación que creemos controlar, pero lo único

que dominamos es la capacidad de asumir el error y aprender del mismo, proyectando
nuevamente hacia adelante en el camino correcto.
Por ello debemos comenzar a entender que una idea sin ejecución no vale nada, es un
mero pensamiento que puede ser perfecto en nuestra cabeza, pero en el momento en que
comenzamos a materializarlo es cuando comienzan a aflorar los errores. Además, y como se ha
visto en las diversas prácticas e generación de ideas, es necesario comunicarnos cuanto antes
con las personas, con nuestros futuros clientes. Cuando “decimos” o “contamos” las ideas es
cuando podemos valorar si la gente también las ve bien o no, si las compraría o no, porque
muchas veces asumimos suposiciones basadas en el mercado y, por tanto, en las personas,
que en muchas ocasiones están equivocadas.
Utilizada una u otra herramienta de manera indistinta para generar una idea o
concepto, debemos convertirla en un prototipo, es decir, en una herramienta de
comunicación. Esa es su función y su mera naturaleza, comunicar y conversar entre individuos,
valorando pros y contras e identificando la verdadera oportunidad (o la ausencia de ella).
En esa línea, se hace fundamental el prototipado rápido de ideas, denominado Rude

Prototipe, es decir, elementos rápidos de visualización. Debemos perder el miedo a dibujar y
esquematizar y recuperar la esencia de niños, cuando transmitíamos todo con imágenes
(Visual Thinking). El pensamiento visual no es solo para artistas. Es para gente de negocios,
empresarios y organizaciones no gubernamentales, líderes gubernamentales, maestros,
niños... No es solo un fenómeno occidental, el pensamiento visual se está globalizando, desde
Asia a África y a América del Sur. Donde quiera que encuentre buenas ideas e historias que
contar, encontrarás el pensamiento visual, porque las imágenes son la mejor y única manera
de contarlas.

Storyboard
Realización de una historia en 6-8 viñetas, explicando el funcionamiento básico. A

modo de guion tiene una entrada, un durante y una salida, generalmente plasmando:
 Cuál es el problema y/o como llegas a la idea(en este caso producto/servicio).

 Qué pasa dentro.
 Cuál es el resultado.
Esta herramienta está generada desde la perspectiva del usuario para mostrar cómo
sería su experiencia y para reflexionar sobre ella.
¿Te imaginas lavarte sin agua? Baño por nanobacterios

¿Descubrir tu ciudad perdiéndote sin perderte? Bikini es la solucion.
Esquemas
En un segundo plano encontramos el funcionamiento interno del sistema, más allá de

la historia personal. Para su definición o comunicación visual, disponemos del uso de
esquemas, que ayudan a proporcionar una mirada más holística y completa de la complejidad
del sistema, disponiendo algunos de idiosincrasias especiales.

¿Te imaginas un sistema a lo Groupon de compra ecológica compartida de pequeños

productores locales?
¿Te gustaría diseñar y crear tu propio jarrón?

Shit prototype
En el argot, se trata de una primera visualización basta del objeto o producto en sí, con
objeto de entender sus premisas funcionales o formales básicas, pero a muy grandes rasgos.
En el mundo del software vendría a ser el wireframe en papel.

En pocas palabras, prototipar las ideas es tratar de hacerlas tangibles con objeto de
comunicar y poder generar una conversación. En caso de errores (problemas de copias y
confidencialidad), en la mayoría de casos nuestro usuario construirá con nosotros o nos dirá si
nuestra idea tiene sentido. La manera que presentemos la idea no es fundamental, sino
realmente lo que queremos contarle y conversar con él. El prototipado no se trata de que sea
bonito, sino de que sirva para algo.
“Fail early, fail often; succeed sooner“. Bill Moggridge – Cofounfer IDEO

2. Gestión de Proyectos Ágiles con Scrum

2.1. Introducción a la gestión de proyectos Scrum
2.1.1. INTRODUCCIÓN A LAS METODOLOGÍAS ÁGILES
Antes de entrar de lleno en explicar la metodología Scrum es fundamental que

tengamos unas nociones básicas de en qué principios está basado y por qué esos principios
van a ser los que terminen definiendo la metodología. En otras palabras, es importante saber
por qué las cosas funcionan para que no las saboteemos (por accidente).
Scrum es una metodología ágil, pero, ¿qué son las metodologías ágiles? Eso es lo que
aprenderemos en esta breve introducción.

 Manifiesto ágil
Las metodologías ágiles surgieron inicialmente orientadas al mundo del desarrollo de

Software.
En una reunión que tuvo lugar en Snowbird, Utah, en Febrero del año 2001, diecisiete
críticos expertos en metodologías de desarrollo de software acuñaron el término
“Metodología Ágil” para definir aquellas metodologías que surgían como alternativa a las
metodologías tradicionales.
Para especificar las características que debía reunir una metodología para poder
pertenecer a la categoría de “Ágil” se definieron una serie de postulados que conformaron un
manifiesto, el manifiesto Ágil:
 Los individuos y su interacción deben estar por encima de los procesos y las
herramientas.
 El software que funciona debe estar por encima de la documentación exhaustiva.
 La colaboración con el cliente debe estar por encima de la negociación contractual.
 La respuesta al cambio debe estar por encima del seguimiento estricto de un plan
establecido.
Dentro de cada postulado se distinguen dos “partes”. Mientras que las de la izquierda
son los “nuevos” valores a destacar en las metodologías ágiles, las de la derecha son valores
tradicionales de suma importancia en metodologías tradicionales y, de hecho, al firmar el
manifiesto se dejó constancia que era por el valor que se daba a la parte derecha de cada
postulado por lo que se valoraba aún más la parte de la izquierda.
 Principios básicos y objetivos de una metodología ágil
Los cuatro postulados del manifiesto ágil son un resumen de los objetivos que se
deben buscar a la hora de utilizar una metodología ágil. Llevados a la práctica se podría decir
que los principios (y objetivos relacionados a ellos) de una metodología ágil son:
 Nuestra máxima prioridad es satisfacer al cliente a través de entregas continuas y

tempranas de un producto de calidad.
 La gente dedicada a la gestión y la dedicada a la producción deben trabajar
conjuntamente de manera continua, de manera que el objetivo sea común y
homogéneo para todos.
 Los cambios serán bienvenidos desde el principio e incluso en etapas avanzadas del
proyecto, ofreciendo al cliente tener siempre la posibilidad de situarse en una
posición de ventaja competitiva.
 Los proyectos deben ser construidos basándose en trabajadores motivados para

únicamente tener que facilitarles el apoyo y entorno adecuado de trabajo y confiar

en que ellos harán su trabajo satisfactoriamente.
 El método más eficiente y efectivo de comunicación entre miembros del equipo es
la conversación cara a cara.
 La medida principal de progreso deberá estar basada en el producto funcional.
 Todos los miembros del proceso deben ser capaces de mantener un ritmo de
trabajo constante de manera indefinida.
 Las mejores arquitecturas, requisitos y diseños emergen de equipos auto
organizados.
 Conclusiones
Todos los conceptos vistos hasta el momento (priorizar al cliente, comunicación con el
mismo, trabajo en equipo, ritmo de trabajo constante, trabajo terminado como unidad de
medida, etc) no dejan de ser, por un lado, parecidos a los aplicados en casi cualquier
metodología de trabajo tradicional y, por otro lado, lógicos si pensamos en cómo llevar un
proyecto a buen puerto.
Por tanto, no se debe pensar en las metodologías ágiles como un invento de la época
actual, transgresor y atrevido, sino en un modo de trabajo lógico que busca la satisfacción del
cliente a través de equipos de gente motivada con su trabajo.
2.1.2. INTRODUCCIÓN A SCRUM
 ¿Qué es Scrum?
Aunque inicialmente Scrum fue creado únicamente como un marco de trabajo para
gestión de proyectos, actualmente es considerada una metodología en sí misma, ya que
cumple los principios de las metodologías ágiles y facilita los mecanismos de control mínimos
necesarios para la gestión de un proyecto.
Tal y como se comentó en el apartado anterior, las metodologías ágiles no fueron un

“invento novedoso” en el momento de ser acuñado el término, y prueba importante de ello es
que Scrum, posiblemente la metodología más representativa dentro de las denominadas
ágiles, fue descrita por Hirotaka Takeuchi e Ikujiro Nonaka en 1986 (15 años antes de la
aparición del manifiesto ágil) y formalizada en 1995.

Scrum nace de un estudio realizado sobre nuevos procesos de desarrollo utilizados en

Japón y Estados Unidos en empresas importantes como Canon, Honda y HP. Dichas empresas
realizaban proyectos que necesitaban ser actuales y novedosos, no pudiendo extender su
tiempo de desarrollo excesivamente. Para ello se requería de una descripción de requisitos
abierta a cambios y se utilizaron equipos multidisciplinares que trabajaban de manera
conjunta muy estrechamente.
El estudio comparaba dichos grupos de trabajo con las melés de los jugadores de rugby
(en inglés el termino utilizado en este deporte es Scrum) y de ahí el nombre de la metodología.
Como se comentaba anteriormente Scrum no es más que una serie de mecanismos

mínimos que facilitan la gestión de un proyecto. Estos mecanismos se dividen en una serie de
principios y normas que deben ser tenidos en cuenta en la toma de decisiones de la gestión de
un proyecto, una serie de roles necesarios dentro de un proyecto y las responsabilidades que
deben tener cada uno de ellos, una serie de artefactos que facilitarán la gestión y seguimiento
del trabajo y un ciclo de vida que el proyecto debe seguir.
 Principios básicos de Scrum
Como se ha comentado anteriormente, Scrum se basa en una serie de principios

básicos y normas a tener en cuenta a lo largo del proyecto.
Los principios fundamentales que describen Scrum y lo diferencian de otras

metodologías de trabajo son:
 Desarrollarse a partir de Sprints (o ciclos)

 Dichos ciclos deben ser de una duración determinada a lo largo del proyecto.
 Constar de grupos de trabajo auto-organizativos.
 Realizar reuniones diarias con los miembros en pie.
 Realizar una demo del trabajo realizado al final de cada iteración.
 Aprendizaje continuo.
Podemos observar cómo la mayoría de estos principios hacen relación al ciclo de vida
del proyecto, una de las características fundamentales de Scrum que veremos en detalle en
una de las asignaturas de este post-grado.
Sin embargo, aplicar una metodología sería complicado disponiendo únicamente de

estas claves o principios tan abstractos, por lo cual a continuación se detallan una serie de
normas o prácticas que deben seguirse a la hora de aplicar Scrum y que definen el carácter ágil
de esta metodología así como sus particularidades frente a otras metodologías:

1. El ciclo de vida debe estar compuesto por iteraciones: como ya hemos comentado
anteriormente, una de los rasgos más característicos de cualquier metodología ágil es estar
abierta a los cambios. En el caso de Scrum se considera que dividir el ciclo de vida del producto
en iteraciones brinda la posibilidad de utilizar el cambio de iteración como el momento
apropiado para introducir posibles cambios. Para poner un ejemplo práctico de los beneficios
que puede aportar este principio, imaginemos a un golfista a punto de empezar un hoyo de un
circuito de golf donde dispone de 4 golpes.
La previsión inicial podría ser perfectamente dar un golpe recto que deje la bola en la
calle, luego otro recto que lo meta en el Green (región donde se encuentra el hoyo), un tercero
para dejarlo cerca del agujero y por último un golpe que lo meta directo al hoyo. La
planificación es perfecta!!!!
Pero, ¿qué pasa si en el primer golpe la bola cae en uno de los bunker de arena
laterales? Solo para sacar la bola de ahí y dejarla en la calle central como debía haber estado
ya necesitaremos mínimo un golpe, con lo cual ya llevaremos un golpe de “retraso”.
Sin embargo si entre golpe y golpe (iteraciones) somos capaces de “re-planificar”

nuestra estrategia, quizás seamos capaces de intentar un golpe desde la arena hasta el Green
(aunque conlleve cierto riesgo que no estaba planificado) para continuar “entregando” la bola
al hoyo “en tiempo”.

Además de desde el punto de vista del producto, también debe verse desde el punto
de vista del equipo de trabajo.
Las iteraciones brindan la oportunidad de ver el estado del producto y pensar en

posibles cambios, pero también brinda la oportunidad de valorar la metodología de trabajo del
equipo y analizar sus pros y sus contras con el fin de mejorarla.
Eso nos permitiría tener un equipo mejor en cada iteración, y detener malas prácticas
al poco tiempo de empezar a producirse no permitiendo que se conviertan en costumbres.
2. Hay que intentar reducir riesgos lo antes posible: De cara a planificar un proyecto,
lo más difícil de estimar son aquellas acciones que conllevan un riesgo y todas las que derivan
de ellas.
Se ha comentado antes que un proyecto “ágil” debe estar abierto a los cambios, pero
eso no implica que no se puedan prever en la medida de lo posible y afrontarlos en el
momento adecuado.

Aquellas tareas que no sabemos si pueden hacerse o que su realización (el proceso
mediante el cual se hacen) puedan derivar en tomas de decisiones o incluso cambios en el
proyecto deben hacerse tan pronto sea posible.
De esta manera en caso de tener que rehacer trabajo o incluso desecharlo, el impacto
será el mínimo, ya que la cantidad de trabajo realizado y relacionado con él será el justo y
necesario para detectar esa necesidad de cambiar.
El siguiente gráfico muestra cómo priorizar tareas en base al riesgo y al valor de

negocio para el cliente (siguiente punto):
Si volvemos al ejemplo anterior, en el caso ideal teníamos 4 golpes de los cuales los
dos primeros los íbamos a utilizar para conseguir llegar al Green. Esos dos golpes no cubren la
misma distancia, ya que en el primero generalmente se intentará cubrir el máximo número de
metros posibles y el segundo para afinar el primero y meter la bola en el Green.
Es decir, en el primer golpe hacemos lo que más riesgo conlleva (al dar un golpe con
más fuerza, es más posible que la bola se desvíe hacia los laterales saliéndose de la calle e
incluso cayendo a un bunker) y a continuación las que menos riesgo entrañan. De esta manera,
detecto las desviaciones a mi plan nada más comenzar y tengo tiempo suficiente para corregir
posibles errores antes de terminar el hoyo.

3. Priorizar aquellas tareas o funcionalidades que impliquen valor de negocio: algo

muy típico en el desarrollo de proyectos es centrarse en los detalles de todo aquello que se va
a entregar. Por supuesto, es necesario entregar productos terminados y de calidad, pero a la
hora de planificar un proyecto ágil, puesto que uno de los postulados es “La colaboración con
el cliente debe estar por encima de la negociación contractual.”, es preferible priorizar
aquellas tareas que sean más importantes para el cliente a nivel de negocio, realizar tareas
completas en cuanto a funcionalidad se refiere, mostrárselas al cliente y, una vez obtenido un
feedback por su parte, mejorarlas todo lo que sea necesario.
De esta manera el cliente tendrá un producto funcional lo antes posible y podrá

obtener provecho de él, mientras que todos los flecos o posibles mejoras que desee podrán
ser llevadas a cabo posteriormente (¡ojo! Hay que tener en cuenta aquellas que conlleven
riesgo por lo comentado en el punto anterior).
4. Nunca extender una iteración para alcanzar el objetivo de la misma: no se debe

confundir “ágil” y flexibilidad con un “todo vale”, error muy común en empresas nuevas en el
uso de metodologías ágiles.
Si los objetivos marcados para una iteración no pueden ser alcanzados, no debe
ampliarse la duración de la iteración para “maquillar” el resultado.
En su lugar, deberá asumirse que el objetivo no era realista y analizar el por qué
(problemas en el entorno de trabajo, falta de formación del equipo, problemas técnicos,
simplemente una mala planificación) para lograr resolverlo.
Este ejercicio de autocrítica por parte del equipo de trabajo, lejos de desmotivarlos,
debe enriquecerlos. En el fondo se trata de uno de lo principios fundamentales de Scrum:
Aprendizaje continuo.

Una vez localizado el problema y puesto el remedio, el equipo será más sólido y
experimentado, lo cual favorecerá al proyecto en adelante.
5. La duración de las iteraciones debe tratar de mantenerse a lo largo del proyecto:

dos posibles motivos de que los objetivos no se cumplan en una iteración puede ser debido a
que la duración de la misma no es suficiente para terminar una tarea o, por lo contrario, que la
iteración es tan larga que es complicado ajustar el número de tareas a incluir en ella.
En ambos casos una posible solución sería cambiar la duración de las iteraciones para
ajustarlas a lo que el proyecto requiere (pero siempre al término de una iteración y antes de
comenzar la siguiente, nunca durante ninguna de ellas, eso atentaría contra el punto anterior).
Sin embargo, lo ideal es mantener la duración de las iteraciones a lo largo de todo el

proyecto, ya que genera, por un lado, una “costumbre” que facilita la planificación de las
mismas por parte del equipo y, por otro lado, también facilita la obtención de medidas de
velocidad del trabajo realizado y estimaciones del trabajo pendiente a los gerentes del
proyecto.
6. Durante una iteración el tiempo, el coste y la calidad son fijos: son las
funcionalidades o hitos a llevar a cabo los que deben variar.
Si para una iteración se estima que solo se pueden realizar un número determinado de
hitos, nunca este número debe aumentar a costa, por ejemplo, de reducir la calidad de lo
realizado, ni de aumentar la presión de trabajo sobre el equipo para que produzca más rápido.
Estas falsas soluciones lo único que conseguirían es reducir la calidad no solo de esos
hitos, sino del proyecto completo (así como rebajar las expectativas de calidad dentro del
propio equipo) y crear un ambiente y ritmo de trabajo no sostenible en el equipo que
únicamente falsearía la estadística de velocidad de trabajo del equipo, que a su vez podría
conllevar estimaciones no realistas en iteraciones futuras (es como una fila de fichas de
dominó: una vez cae una pieza, el resto se ven empujadas por la anterior).
Hay que recordar uno de los principios ágiles que se han comentado: “Todos los
miembros del proceso deben ser capaces de mantener un ritmo de trabajo constante de
manera indefinida.”

7. Mantener siempre las entregas o demos parciales al cliente: de nuevo entra en

juego el postulado “La colaboración con el cliente debe estar por encima de la negociación
contractual.”.
Presentar a nuestro cliente el trabajo realizado regularmente facilita que él mismo

pueda darte un feedback y replantearse la priorización de todos aquellos hitos que queden
pendientes (hay que estar abierto al cambio).
Además del valor que supone tener la opinión del cliente, también es un incentivo para
el equipo de trabajo. Muchas veces los trabajadores no se sienten parte de una empresa o un
proyecto porque no tienen ningún tipo de visibilidad del resultado de su trabajo.
Sin embargo, en Scrum, gracias a las demos, van a poder comprobar de primera mano
la reacción del cliente a su trabajo y lo normal es que tras una demo negativa no se quiera
volver a defraudar en la siguiente y tras una positiva se quiera continuar recibiendo un
reconocimiento al trabajo iteración a iteración.
8. Reforzar la importancia de la gente implicada en el proyecto y especialmente los

equipos de trabajo: como se ha comentado anteriormente, Scrum se basa en equipos auto-
organizados, a los que se expone el trabajo a realizar y se confía en su capacidad para llevar a
cabo dicho trabajo.
La figura del manager o directivo vigilante no tiene cabida en Scrum y, por tanto, es
importante que la gente implicada en el proyecto sea consciente de la confianza depositada en
ellos y les sirva como motivación para realizar bien su trabajo.
Para ello es conveniente hacerles ver que si ellos no funcionan, el proyecto podría
derrumbarse, y de la misma manera, si el proyecto se derrumba, serán los primero
responsables de ellos.
En Scrum las decisiones se toman en su mayoría en el lugar donde se realizan los hitos
que las requieren. Es por ese motivo que los equipos suelen ser multidisciplinares para tener
siempre, en la medida de lo posible, una persona más experimentada en cada una de las áreas
implicadas en el proyecto que tome la decisión en cada problemática que pueda surgir.
9. Facilitar un entorno de comunicación apropiado: Uno de los principios de las

metodologías ágiles era “El método más eficiente y efectivo de comunicación entre miembros
del equipo es la conversación cara a cara.”.

El motivo del mismo es tratar de evitar situaciones de “teléfono estropeado” que tan
bien se expresa en la siguiente caricatura que hace referencia a los distintos pasos de un
mensaje a lo largo de la estructura jerárquica de una metodología tradicional.
Es razonable que en un proyecto el cliente tenga un interfaz único de comunicación,

para que sepa a quién puede acudir en todo momento para tratar cualquier tema relacionado
con el proyecto. Sin embargo, es muy típico también que dentro del propio proveedor se
establezcan largas cadenas de mando que separan a dicho interfaz del equipo final del trabajo.
De esta manera, cuando surge una duda en el equipo de trabajo, debe comunicárselo a
un tercero, que seguramente también tendrá gente entre medias de él y el interlocutor con el
cliente, de modo que cuando la pregunta llega a este último puede hacerlo de manera
deformada. Eso no queda ahí, ya que la respuesta suele seguir el mismo canal de
comunicación solo que en sentido contrario, desvirtuando también la respuesta.
No hay que decir que a este problema se suma que durante todo el proceso se ha
perdido un tiempo precioso solo en pasar la información de un eslabón a otro de la cadena de
mando.
Ya veremos más adelante que, para reducir este efecto tan nocivo para cualquier
proyecto, Scrum delimita qué roles deben existir en el proyecto y establece una comunicación
directa entre ellos, de modo que el equipo siempre debe poder comunicarse rápida y
directamente con el responsable de tratar con el cliente para tratar cualquier tema que
requiera de su intervención.

Por otro lado, la comunicación no solo se limita a las conversaciones entre miembros
del equipo, sino también al estado del proyecto, las iteraciones, los hitos en los que se está
trabajando e incluso el entorno de trabajo y el feedback del cliente.
Toda esta información debe ser lo más accesible posible para todo el mundo y la
comunicación para tratar cualquier tema fluida y frecuente.
Para ello, Scrum propone una serie de artefactos y reuniones cíclicas donde todos
estos aspectos se muestran y pueden ser discutidos. Los estudiaremos a fondo más adelante
en el curso.
10. Los equipos deben estar conformados en base a las necesidades del cliente: como
ya se ha comentado varias veces, el equipo debe ser multidisciplinar, pero no todos los
proyectos requieren de las mismas disciplinas y, por tanto, no necesariamente un equipo debe
ser el mismo independientemente de la naturaleza del proyecto en que trabaje.
Adaptar la formación de un equipo a un proyecto determinado conlleva dos beneficios

muy importantes: reducir los recursos externos de los que se pueda tener necesidad y, sobre
todo, incrementar la calidad del producto final entregado.
2.1.3. DESVENTAJAS DE SCRUM
Hasta hora todo lo hablado de Scrum es positivo y eso podría hacer pensar que se trata
de una metodología perfecta sin ningún tipo de inconveniente o dificultad.
Sin embargo, no es así y, como cualquier otra metodología, tiene sus inconvenientes y
riesgos, de los cuales los más importantes son:
1. Tendencia a no trabajar con fecha de fin: en muchos casos se piensa que por ser
una metodología ágil, todo vale, y uno de los mayores errores que se puede cometer es
comenzar un proyecto con un presupuesto fijo pero sin una fecha de fin.
La agilidad sí que pasa por poder variar los requisitos a desarrollar en función de los
progresos logrados y demostrados o de los riesgos surgidos. Sin embargo, hay veces que los
clientes utilizan ese concepto de ágil para pedir más y más funcionalidades que se les van
ocurriendo para el proyecto.

Esto no es negativo, pero puede serlo si no se les hace ver que el introducir nuevas
funcionalidades casi siempre supone descartar alguna de las ya propuestas.
Si tienes fijada una fecha de fin, esto puede parecer más evidente al cliente, ya que a
medida que se acerca dicha fecha él va viendo que está realizado y qué puede quedarse sin
realizar.
Sin embargo, si no tienes un fecha, el cliente tenderá a pedirte que continúes

desarrollando todo lo que se le ha ocurrido en el producto convirtiéndolo en infinito.
2. La dependencia en el compromiso del equipo: en Scrum la parte más importante de

la metodología es el equipo. Sin duda, el ceder el control al propio equipo puede incrementar
la productividad y satisfacción del equipo enormemente.
Sin embargo, es importante detectar si algún miembro no está comprometido con la

metodología, porque, si es así, es probable que las ventajas que ofrece Scrum (al respecto del
equipo) desaparezcan, como la motivación, el afán de superación y el incremento de velocidad
y conocimientos a lo largo de los sprints.
Y lo peor es que existiendo una sola persona en el equipo que presente este problema,
podría darse el caso de “la manzana podrida”, que dice que si tienes un miembro no
comprometido con la metodología, lo más normal es que su negatividad contagie al resto de
miembros del equipo y al final este se desmorone.
3. Solo se recomienda aplicar en equipos pequeños y ágiles: Scrum es una

metodología pensada para equipos de tamaño no superior a 8 personas.
Los motivos para esto pasan por la capacidad de coordinación de grupos, que cuanto
más grandes son más se complican, y por la metodología en sí, que define una serie de
reuniones y mecanismos que veremos en próximas asignaturas y que se alargan en función del
número de componentes del equipo (uno de los objetivos de Scrum era reducir las reuniones
lo máximo posible).
4. Se requieren miembros del equipo experimentados: este inconveniente va ligado al

anterior.
Los equipos de Scrum deben ser multifuncionales y de tamaño limitado, lo cual deriva
en que los miembros que lo formen deben tener ya una experiencia.

Aunque quizás no sea necesario en todos los miembros del equipo, sí que se requiere que al
menos la mitad de ellos tengan la experiencia suficiente para ser capaces de estimar el trabajo
de manera correcta y aportar soluciones a las tareas a las que se tengan que ir enfrentando.
5. Scrum solo funciona si el Scrum Master confía en el equipo: el Scrum Master, como
veremos más adelante será el encargado de asegurarse que la metodología se cumple y que el
equipo es capaz de auto gestionarse.
Si el Scrum Master no confía en el equipo y en su capacidad de auto organización, al final se

dedicará a “vigilar” al equipo y a decirles qué tienen que hacer en todo momento.
Con esto se pierde una de las grandes virtudes de Scrum y se tiende a una organización más
jerárquica, propia de las metodologías tradicionales.
6. La rotación en el equipo: en Scrum es muy importante que el equipo trabaje como tal. Con
el paso de los Sprints, cada miembro va adoptando un rol dentro del equipo y se adquieren
mecanismos en la organización del trabajo que beneficia mucho la velocidad de desarrollo del
producto.
El cambio de un miembro del equipo distorsiona esa dinámica más que en otras metodologías
más tradicionales, ya que en ellas la persona que entra lo hace con un rol asignado, mientras
que en Scrum, tendrá que adaptarse al resto del equipo y encontrar su rol dentro de él.
Por tanto, la curva de aprendizaje es más elevada y la productividad podría verse mermada en
los primeros Sprints de un nuevo miembro.

4.- Diferencias entre Scrum y una metodología tradicional
Durante la exposición de los principios de Scrum se ha recurrido en varias ocasiones a

la comparación de esta metodología con las llamadas “tradicionales”.
En dichas comparaciones se proponían soluciones a problemas de las que no son

ágiles, sin embargo eso no significa que Scrum sea la metodología definitiva para cualquier
proyecto ni que las metodologías tradicionales estuviesen equivocadas y se deba evitar su uso.
La inclusión de “ágil” en el mundo de las metodologías lo que hace es ofrecer una

alternativa válida para la gestión de cierto tipo de proyectos a los que las metodologías
tradicionales no se ajustaban o cuyo rendimiento podía mejorarse.
En concreto, el cambio más significativo podría ser la forma de plantear los proyectos.
En una metodología tradicional, lo primero de lo que se dispone es de que los

requisitos que están completamente fijados. A partir de ellos, las empresas que van a
desarrollar el producto realizan una estimación de los recursos necesarios para entregar en
una fecha concreta o de la fecha de entrega en función de los recursos.
En las metodologías ágiles eso cambia sustancialmente. En este caso, lo que

tendremos fijo será el equipo de trabajo que va a realizar el proyecto, la fecha en la que se
quiere fijar un límite para tener el producto y lo que puede variar a lo largo del proyecto son
las funcionalidades o el nivel de detalle del producto, es decir, sus requisitos.

A continuación se muestra una tabla que ofrece de un simple vistazo las diferencias
más significativas entre una metodología tradicional y una ágil (en concreto Scrum) teniendo
en cuenta los proyectos a los que pueden ser aplicados:
Tal y como se puede intuir del gráfico anterior, cada columna muestra un tipo de
proyecto muy específico (el primero, por ejemplo, podría corresponderse con un producto
bien definido, de presupuesto muy acotado, y el segundo con un proyecto de investigación con
presupuesto variable) que se ajusta a una metodología tradicional en el caso de la primera y
ágil en el caso de la segunda y donde no tendría sentido utilizar la otra.
Otro de los cambios significativos entre las metodologías tradicionales y las ágiles (en
concreto Scrum) es el lugar que ocupa cada persona involucrada en un proyecto dentro del
mismo, o lo que es igual, los roles.

Cada empresa y proyecto puede presentar unas características que le impidan realizar
una u otra metodología. Como hemos visto a lo largo de la asignatura, una empresa muy
grande con mucha rotación y gente poco experimentada, quizás no esté preparada para hacer
Scrum, mientras que una muy pequeña con gente especializada, quizás no tiene suficiente
gente para todos los roles de una tradicional y, por el contrario, su estructura se acerca a lo
deseado para Scrum.
Por tanto, antes de utilizar Scrum u otra metodología ágil en un proyecto habrá que
estudiar si sus características se ajustan al mismo o es más conveniente recurrir a una
metodología tradicional.
Hasta aquí llega la introducción a Scrum. La semana que viene veremos con más
detalle los roles vistos en la imagen anterior.

2.2. Roles y artefactos en Scrum
Scrum es una metodología ágil que principalmente ha sido utilizada en el ámbito del
desarrollo de software, aunque no deja de consistir en una serie de herramientas (principios,
roles y artefactos) que facilita una metodología de trabajo flexible y dinámica.
A lo largo de esta asignatura haremos un repaso a los roles y artefactos que son
utilizados en Scrum para más adelante ver como interactúan todos ellos a lo largo del ciclo de
vida de un proyecto Scrum.
2.2.2. ROLES EN SCRUM
Uno de los principios más importantes todas las metodologías ágiles, tal y como dice
su postulado es “Los individuos y su interacción deben estar por encima de los procesos y las
herramientas” y en concreto en la clase anterior vimos que uno de los fundamentos de Scrum
es “Facilitar un entorno de comunicación apropiado”.
Entonces ya se dijo que uno de los mecanismos para asegurar dicha comunicación, a
parte del propio ciclo de vida de Scrum es restringir la cadena de mando del proyecto a una
serie de roles con responsabilidades bien definidas para evitar que los procesos burocráticos

habituales en las metodologías tradicionales dificulten que el equipo de trabajo tenga claro el
objetivo final del proyecto así como los pasos que deben darse para alcanzar dicho objetivo.
No hay que olvidar que mientras en el caso de las metodologías tradicionales, la

especificación de requisitos del producto final suele ser detallada y cerrada por motivos
contractuales, en un proyecto “ágil”, la flexibilidad y el cambio son habituales e incluso
predominantes.
Para que tanto los cambios solicitados por el cliente sean reflejados en el proyecto lo
antes posible, como que las dudas que surjan en el equipo reciban una respuesta lo antes
posible, las líneas de comunicación entre ambos, cliente y equipo, deben ser lo más directas
posibles.
Sin embargo, en casi ningún proyecto es habitual que el equipo de trabajo pueda tener
línea directa con el cliente, ni tampoco sería recomendable, ya que es lógico que el cliente
tenga un interfaz único de comunicación con la empresa para que la información no se
disgregue y sea persistente en el proyecto.
Este rol Scrum lo denomina Product Owner, ya que más allá de su comunicación con el
cliente, su responsabilidad final dentro del proyecto será el producto entregado.
Ya se ha nombrado en varias ocasiones el concepto de equipo de trabajo, que si bien

en otras metodologías se podría dividir a su vez en una serie de roles (probablemente con un
sentido jerárquico) en Scrum serán considerados como una sola entidad.
Por otro lado, ya comentamos que las metodologías ágiles, lejos de ser sencillas o
indisciplinadas, están regidas por una serie de principios que deben seguirse para que un
proyecto no se convierta en caótico. Dichos principios podrían interpretarse de manera que
beneficiase a algunas de las partes implicadas en el proceso, en este caso al Product Owner o
al equipo en caso de que surgiesen complicaciones.
Para mediar en cualquier conflicto y asegurarse que la metodología se sigue

convenientemente, existe un tercer rol muy importante en Scrum, el Scrum Master.
Pese a que se ha utilizado la palabra “mediar” para definir una de las responsabilidades
del Scrum Master, no se debe pensar en él como un intermediario de la comunicación entre el
Product Owner y el equipo, sino como un facilitador de la comunicación entre ambos:

De esta manera la comunicación es siempre directa entre todos los roles de la

metodología, lo cual se ciñe a uno de los principios vistos de las metodologías ágiles: “El
método más eficiente y efectivo de comunicación entre miembros del equipo es la
conversación cara a cara.”
Como curiosidad (aunque bastante instructiva), incluyo la “fábula” de los cerdos y las
gallinas siempre vinculada a Scrum:
Lo que esta fábula quiere hacer ver es que, mientras que el cerdo se juega su propia
carne en el negocio, la gallina solo implica aquello que es suyo, los huevos que pone, sin llegar
a estar realmente comprometida.

En el caso de Scrum, se denominan cerdos a aquellos que ponen el 100% en el

proyecto, los que realmente están comprometidos, que serían aquellos que pertenecen a los
roles anteriormente expuestos.
Alrededor de ellos, también “pendientes” del proyecto, aunque no tengan una

dedicación completa, se encontrarían las “gallinas”: recursos externos que puedan necesitarse,
los directivos de la empresa proveedora, quizás un comité de negocio implicado, los posibles
usuarios finales del producto e incluso el cliente para el cual se trabaja.
Todos ellos forman parte del “negocio”, pero no están igualmente comprometidos con
el desarrollo del producto, sino con el fin.
Una vez introducidos los distintos roles, así como la comunicación existente entre
ellos, es conveniente ver cada uno de los roles en más profundidad para entender cuáles son
sus responsabilidades y cuáles serán las interacciones más habituales entre ellos.
 El equipo
Si se busca “Equipo” en Wikipedia se encontrará: “Un equipo comprende a cualquier

grupo de 3 o más personas unidas con un objetivo común (una investigación o un servicio
determinado). Un grupo en sí mismo no necesariamente constituye un equipo”. Es una buena
definición donde la clave de la misma es “unidas con un objetivo común”. Sin ese matiz, tal y
como indica, no son más que un grupo de personas.
Los equipos deben estar constituidos por miembros con habilidades o conocimientos
complementarios (imagina un equipo de fútbol formado únicamente por delanteros, aunque
todos fuesen Messi difícilmente serían un equipo competitivo) que generen juntos una sinergia
mediante la cual cada miembro potencia lo mejor de sí mismo y minimiza sus debilidades.
Si cumplen estas condiciones, los equipos son especialmente apropiados para la

realización de tareas de alta complejidad y compuestas de muchas tareas independientes.
En Scrum esto es precisamente lo que busca. Un equipo tendrá que realizar tareas de
alta complejidad (requisitos del producto) dividiéndolas en tareas independientes y trabajando
en ellas de forma que la resolución de todas dé lugar, finalmente, a un “todo” complejo de
nuevo.
Ya habíamos hablado que en Scrum se recomendaban equipos de trabajo

multidisciplinares, que permitirán en la medida de lo posible disponer siempre de un “experto”
para cada posible tarea compleja que aparezca.

Por otro lado, también se ha comentado que los equipos de Scrum deben ser auto-
organizativos (es uno de los principios básicos de Scrum) o, lo que es lo mismo, deben
gestionarse ellos mismos.
El motivo no es otro que generar un ambiente óptimo de trabajo, beneficioso no solo

para los miembros del equipo, sino para la propia marcha del trabajo, teniendo en cuenta los
siguientes puntos:
 La gente es más productiva cuando se organiza a sí misma, siempre que el enfoque

del trabajo sea el adecuado.
 La gente se toma los compromisos adquiridos por ellos mismos más en serio que
los adquiridos por otro en su nombre.
 Escondidos entre los ratos ociosos del día pueden aparecer los momentos más
creativos.
 Bajo presión para “trabajar más duro”, la gente suele sacrificar calidad a cambio de
velocidad.
Lo que viene a decir esto es que la gente se ve mucho más motivada cuando es ella
misma la que asume los retos que aparecen a lo largo de un proyecto, en lugar de que les sea
impuesta por un mando superior.
Probablemente no deje de ser una cuestión psicológica o de orgullo, pero se ha

comprobado que un equipo que asume retos por sí mismo es más exigente consigo mismo y
ambicioso con los retos asumidos que aquellos a los que se les impone unos objetivos.
En cierta ocasión se realizó el siguiente experimento: Se crearon 3 grupos de trabajo

independientes con el mismo número de componentes para mover cajas de un lado a otro.
 Al primer grupo se le pagó una cantidad de dinero X por 5 minutos moviendo cajas.
Movieron 159 cajas.
 Al segundo grupo se le pagó una décima parte de lo que al primero. Movieron 101.
 Al tercer grupo no se le pagó. Únicamente se les planteó (no se les exigió) como un
reto entre los 3 grupos. Movieron 168 cajas.
Tener un objetivo común (mover más cajas que los otros dos) autoimpuesto les motivó
más que ningún tipo de recompensa económica.
Lo que sí se le impone al equipo es una serie de responsabilidades, como a todos los

roles de Scrum. En este caso las suyas serán:
 Estimar esfuerzo necesario y dependencias de los distintos hitos del proyecto: al ser
el equipo el que está compuesto por expertos y los que tienen que realizar el
grueso del trabajo, habrán de ser capaces de analizar cada uno de los hitos para
saber si pueden hacerse y cuánto esfuerzo costará.
 Crear en cada una de las iteraciones un plan de ejecución: como equipo

autogestionado, una de las responsabilidades del mismo es trazar un plan de ruta

de los hitos asignados a cada iteración (cuando se estudie el ciclo de vida en Scrum,
se verá que incluso la cantidad de trabajo de cada iteración viene determinada por
el propio equipo).
 Trabajar de cara a producir entregables periódicos de valor funcional o estratégico
completo: ya se comentó que uno de los principios de Scrum es trabajar en
funcionalidades completas y de utilidad para el cliente, de manera que a medida
que avanza el proyecto, y no únicamente a su finalización, pueda disponer de un
producto del que obtener rentabilidad.
 El Product Owner
Como su propio nombre indica, el Product Owner es el “dueño” (manera drástica de

decir “responsable”) del producto.
Su objetivo es que el producto sea el esperado por el cliente y que, dentro de la

flexibilidad que ofrece Scrum a los cambios, los entregables que se van ofreciendo al cliente
contengan siempre los hitos o funcionalidades que más valor le ofrezcan al cliente.
Sus responsabilidades son:
 Crear una visión del producto: el Product Owner va a ser el interfaz único con el
cliente (al menos en lo que a requisitos del producto se refiere) y, por tanto, es su
responsabilidad no solo extraer del cliente toda la información necesaria del
producto, así como el feedback de lo ya realizado, sino también saber transmitir al
equipo esa visión. Es el responsable de crear el objetivo por el que todos trabajan
y que este sea claro y homogéneo para todos.
 Crear un plan de entregas: es una de las responsabilidades que más dificultad

entraña. En un proyecto ágil es difícil determinar qué se va a entregar en un
periodo de tiempo, ya que el proyecto está muy abierto a cambios. Sin embargo,
para evitar que este se eternice o que nunca se pase de una primera fase al
introducir cambios constantemente y no llegar nunca a nada tangible, el Product
Owner deberá marcar al cliente fechas de entrega parciales del producto, para que
este sea consciente de que los cambios introducidos no son una suma gratuita al
producto, sino que nuevas funcionalidades reemplazan a otras ya existentes en los
plazos estimados.
 Determinar valor de negocio en las funcionalidades: teniendo en cuenta el punto

anterior, una de las responsabilidades del Product Owner es guiar al cliente a la
hora de introducir cambios o mejoras, ayudándole a priorizar aquellas
funcionalidades que más valor aportan al producto final, de manera que sean las
primeras integradas o implementadas en el mismo.

De esta manera, el producto que el cliente tiene en cada momento le aportará el

máximo rendimiento y rentabilidad posibles, pudiendo incluso considerarse un producto
acabado aún en el caso de que el proyecto se tuviese que finalizar quedando funcionalidades o
mejoras pendientes (por cuestiones económicas o de tiempo).
 Definir los criterios de aceptación de cada hito: de cara a asegurar una calidad
mínima de cada uno de los hitos del producto y de dotar al equipo de una base
sobre la que trabajar, el Product Owner deberá marcar una serie de criterios
mínimos para cada hito, que se deben cumplir para considerar dicho hito como
terminado.
 Obtener feedback del producto por parte del cliente y/o el usuario final: aunque
ya se ha comentado anteriormente como parte del primer punto, el feedback del
trabajo ya realizado tiene la importancia suficiente como para considerarlo una
responsabilidad en sí misma.
En metodologías ágiles, el cambio es bienvenido, pero cuanto antes se detecte esa

necesidad de cambiar, mejor. Por tanto obtener un feedback lo antes posible aumentará
considerablemente la productividad del proyecto.
 El Scrum Master
Como hemos visto hasta ahora, metodología ágil y más en concreto Scrum, no es
sinónimo de metodología fácil. Aun siendo una metodología flexible, no deja de tener una
serie de normas o principios que aseguran que la metodología sea eficiente y no caótica. Y no
son pocas.
Para asegurarse que todas esas normas se cumplen, que cada rol asume sus
responsabilidades, que la metodología se aplica correctamente y que es adecuada para el
proyecto, existe el rol del Scrum Master.
Habitualmente se suele decir que el Scrum Master es un facilitador. Paradójicamente,

siendo mayormente un observador y el encargado de hacer cumplir las responsabilidades al
equipo y al Product Owner, el Scrum Master es el único que en el fondo trabaja para todos.
Sus responsabilidades son:
 Naturalizar la auto-organización del equipo: que el equipo sea auto-organizado es

fundamental en Scrum y, por tanto, es responsabilidad del Scrum Master lograr que
el equipo logre ese objetivo. Para ello, debe apoyarles siempre que lo necesiten,
proveyendo de mecánicas o rutinas que ayuden al equipo a organizarse,
asegurándose de que realmente este tiene el control sobre el trabajo que realizan

(se ayudará de los artefactos, como veremos a continuación) y protegiéndolos de

las posibles presiones externas que pudiesen hacer que la organización no fuese del
propio equipo, sino que estuviese guiada desde el exterior (Producto Owner o
incluso gente más allá de los roles de Scrum).
 Ayudar al equipo a ser productivo: si el equipo no es productivo, el proyecto no

avanzará debidamente. Puede haber muchos motivos que reduzcan la
productividad, tanto técnicos (falta de conocimientos o formación, material de
trabajo inadecuado, etc.) como humanos (falta de entendimiento en el equipo,
entorno hostil de trabajo, falta de motivación, etc.).
 Es responsabilidad del Scrum Master mantener una comunicación constante con el

equipo para ser consciente de esas limitaciones y proponer alternativas tanto a
ellos como a los responsables de la empresa para solventarlas.
 En el caso de limitaciones técnicas, podrá buscar la formación adecuada para el

equipo y lograr introducirla como parte del proyecto tanto en tiempo como
económicamente. También deberá proveerlos de las herramientas necesarias para
que la calidad del producto sea la máxima posible.
 En el caso de limitaciones humanas, deberá dotar al equipo de un entorno

adecuado de trabajo y ayudarles a encontrar una motivación (la motivación es un
sentimiento personal de cada uno, no se puede dar, pero se puede ayudar a
encontrarla).
 Orientar al cliente sobre los beneficios que puede obtener de Scrum: nadie conoce
la metodología más a fondo que el Scrum Master. En caso de que sea necesario,
será su responsabilidad trasladar su conocimiento al cliente para que este sepa los
beneficios y dificultades derivados de utilizar esta metodología y colabore en su
correcta utilización.
 Eliminar impedimentos: la imagen de facilitador ofrecida por el Scrum Master viene

determinada por esta responsabilidad. Más adelante se verá que el ciclo de vida de
Scrum ofrece al equipo la posibilidad de reportar diariamente impedimentos que les
hayan surgido durante la implementación de un hito y que les impide seguir
trabajando en él.
 El Scrum Master será responsable de hacer desaparecer dicho impedimento, bien

sea buscando un recurso que lo solucione o dotando al equipo de las herramientas
para hacerlo por sí mismos.

 Facilitar las comunicaciones: la comunicación directa entre los distintos

componentes del proyecto es otro de los pilares fundamentales de Scrum. El Scrum
Master deberá asegurarse que se disponen de los medios para que esa
comunicación se produzca y que los términos de comunicación entre las distintas
partes, con distintos intereses, son los adecuados.
 Manejar el entorno de proyecto: parte de la comunicación entre miembros del

proyecto se realiza a través de sus artefactos. El Scrum Master deberá asegurarse
que estos artefactos son utilizados e incluso responsabilizarse de su uso y
actualización en el caso de alguno de ellos.
 segurarse que todas las personas implicadas están comprometidas con la

metodología: como en cualquier entorno de trabajo o metodología utilizada, para
lograr el éxito, las personas implicadas en proyecto deben creer en él.
Especialmente si la metodología utilizada se sale de lo habitual (de las llamadas
metodologías tradicionales). Es responsabilidad del Scrum Master lograr que todo el
mundo crea en la metodología y neutralizar cualquier conato de “manzana podrida”
(se denomina así a una persona que no cree en la metodología y arroja negatividad
sobre el resto de personas, logrando que finalmente tampoco crean en ella).
2.2.3. ARTEFACTOS DE SCRUM
Scrum es una metodología sencilla en conceptos y fácil de aplicar siempre que se

mantenga un nivel aceptable de disciplina.
Para garantizar que esa disciplina existe, aparte de la propia motivación y

convencimiento de los integrantes del proyecto, hemos visto que existe una figura o rol que es
el Scrum Master. El Scrum Master hace uso a su vez de una serie de artefactos o ayudas, que
deben ser puestos a disposición y utilizados por los distintos miembros del proyecto para
gestionar el trabajo de manera correcta.
A continuación se describen los principales artefactos utilizados en Scrum, explicando

el porqué de su importancia en el proceso.

 Product Backlog
En cualquier proyecto, al inicio del mismo, el responsable o responsables del proyecto

realizan una toma de requisitos del producto requerido por el cliente.
En las metodologías tradicionales, estos requisitos son la meta a alcanzar y se reflejan

normalmente de manera contractual, de manera que permanecen inmóviles desde el inicio
hasta el final del proyecto.
En el caso de Scrum, como metodología ágil que es, esa toma de requisitos inicial es
más un punto de partida, susceptible a ser modificado a lo largo del proyecto tanto en
volumen como en prioridad. Por tanto, tenerlo reflejado en un papel, sería engorroso, ya que
este tendría que ser reescrito en cada cambio solicitado.
En lugar de eso, se propone al Product Owner (responsable del producto e interfaz con
el cliente) mantener una pila de producto (Product Backlog), que no es más que un soporte, en
principio físico, aunque podría ser virtual, donde poder ordenar fichas que reflejen los distintos
hitos que componen o podrían componer potencialmente el producto.
Dichos hitos se denominan en Scrum historias de usuario y suelen ser reflejadas en

tarjetas de la siguiente manera:

Y en el revés de la tarjeta se escribirán los requisitos mínimos de calidad requeridos

por el Product Owner, llamados “criterios de aceptación”.
Una vez todas las historias de usuario han sido trasladadas a tarjetas, se colocan sobre
el product backlog en orden de prioridad, de modo que la más prioritarias estén situadas lo
más arriba posible.
Este tipo de organización permite que en caso de que el Product Owner, ya sea por
decisión propia o por conversaciones mantenidas con el cliente, pueda reordenar los
elementos de este Backlog en caso de que las prioridades cambien e introducir nuevas
historias de usuario en el punto que les corresponde por su prioridad según vayan surgiendo.
Aparte de con todas las historias de usuario, la pila de producto en ocasiones se

completa con otra información de vital interés para tener un objetivo claro del producto. Por
ejemplo, en el caso de la construcción de un coche se puede tener como prioridad principal del
producto su aerodinámica y su fiabilidad a la hora de conducir. En ese caso, se añadirá una
columna a la derecha de la pila de historias de usuario, donde se añadirá una tarjeta por cada
una de esas constantes que se quieren mantener a lo largo de todo el proyecto.
En el caso de que el producto responda a una imagen, también es muy útil tener un
boceto de cómo se quiere que sea el resultado final o de las normas de estilo que deben
cumplir cada uno de sus componentes.
Igualmente, en muchas pilas de producto, se añade también una columna que

enumera los distintos actores y entidades relacionados con el proyecto y la interacción que
existe entre ellos. Se llama área del modelo.

Para entender esto último lo mejor es poner un ejemplo: imaginemos que nuestro
proyecto consiste en diseñar una máquina expendedora de refrescos.Si analizamos el
funcionamiento de principio a fin de lo que queremos que haga nuestro producto, podremos
detectar distintos actores. Veámoslo:
“El usuario se acerca a la máquina expendedora, introduce una moneda por la ranura
destinada a tal efecto y pulsa el botón correspondiente al refresco deseado. La máquina
calcula la diferencia entre el precio del producto y la cantidad de dinero introducida. En caso
de que la cantidad sea insuficiente, se muestra en un display, mientras que si es suficiente,
calculará el cambio a devolver, lo devolverá y sacará por el conducto de entrega el refresco
solicitado”.
A primera vista se ven dos actores claros: el usuario y la máquina expendedora.
Pero si profundizamos un poco más en esta segunda, veremos que solo por el
enunciado descrito anteriormente podemos encontrar más actores, como serían las monedas
o las latas de refresco y descomponer la máquina en distintas entidades: ranura de inserción
de monedas, botones, display, “calculadora”, conducto de entrega.
Un ejemplo de Product Backlog bastante completo sería:
 Sprint Backlog
El Product Backlog se ha explicado como un artefacto de ayuda al Product Owner, pero la

organización derivada de él resulta también de utilidad para el equipo, ya que al final también
tiene que trabajar sobre historias de usuario.

Sin embargo, la visión del equipo, aun debiendo tener siempre una visión global del
producto final, debe estar centrada en la iteración en curso para no tener distracciones del
objetivo parcial que se ha marcado a sí mismo.
Por tanto, para reflejar las historias pertenecientes a cada iteración (en Scrum
llamadas Sprints), el equipo debe disponer de un Sprint Backlog, que será un artefacto análogo
al Product Backlog donde el Product Owner trasladará únicamente aquellas historias de
usuario que el equipo se haya comprometido a finalizar a lo largo del Sprint.
Este Sprint Backlog suele estar integrado en el siguiente artefacto que vamos a
estudiar, la Scrum Board, siendo uno de los apartados de la misma.
 Scrum Board
Si existe un artefacto importante en Scrum ese es la Scrum Board. A grandes rasgos,

una Scrum Board es una pizarra que refleja el estado concreto de un Sprint en cada momento.
Por tanto debe contener:
 El trabajo pendiente de realizar.

 El trabajo que se está realizando en cada momento.
 El trabajo ya realizado.
 Opcionalmente se suelen reflejar también los impedimentos actuales que pueda
tener cualquier miembro del equipo y tanto los puntos positivos como negativos
que el equipo va observando a lo largo del sprint.
Pero para analizar cómo se refleja toda esta información, veamos primero un ejemplo
de Scrum Board sencillo:

En ella podemos distinguir 5 columnas:
 Sprint Backlog: en ella se ponen una debajo de otra y en orden de menor a mayor
las distintas historias de usuario a realizar en el sprint.
 Tareas pendientes: el equipo tiene que determinar en qué tareas se puede
descomponer cada historia y situarlas a la derecha de cada una de ellas.
 Tareas en progreso: cada vez que alguien del equipo comienza una nueva tarea,
debe moverla de la columna anterior a esta para que todo el mundo sepa que está
trabajando en ella.
 Historias por verificar: una vez todas las tareas de una historia han sido realizadas,
se supone que la historia debe estar terminada. Antes de decir que esto es así, se
mueven a esta columna para que el Product Owner compruebe que ciertamente la
historia cumple con todos los criterios de aceptación por él definidos.
 Trabajo terminado: cada tarea que se finaliza se mueve a esta columna y, una vez
el Product Owner ha verificado que la historia está completa, las quita y sitúa en
esta columna la historia del Product Backlog.
Para que la Scrum Board sea realmente útil, debe ser visible y accesible al equipo en
todo momento, por tanto deberá tener un tamaño considerable y estar situada dentro del
entorno de trabajo del equipo en un lugar visible para todos. Esto permite que el equipo
siempre tenga una constancia del estado del sprint y les sirva no solo de guía, sino también de
motivación.
Como hemos dicho anteriormente, pueden existir Scrum Boards mucho más
complejas, ya que es habitual integrar otros artefactos dentro de ella, como veremos más
adelante, lo que permitirá que todos los factores que influyen dentro de un sprint estén
siempre a la vista de todo el mundo.

Algunos ejemplos de Scrum boards más complejas serían:
En la asignatura que explica el ciclo de vida de Scrum se volverá a incidir en cómo las
historias se mueven de unos artefactos a otros y dentro de ellos y, por tanto, veremos de
nuevo el uso de la Scrum Board.
 Lista de bloqueos
Otro de los artefactos utilizados a lo largo de un sprint es la lista de bloqueos. El

cometido de esta lista es mostrar los bloqueos que el equipo tiene en cada momento, así como
los solucionados.
Un bloqueo es cualquier circunstancia que impide al equipo continuar progresando en

el desarrollo de una historia de usuario o que lo ralentiza considerablemente.
Hay que tener cuidado con el uso de la palabra bloqueo y tener muy claro que es un
concepto aplicable a una historia de usuario, no a un miembro del equipo. Es decir, que el
hecho de que una historia de usuario presente un bloqueo no significa que un miembro o más
del equipo no puedan continuar trabajando (a no ser que no queden historias pendientes sin
bloquear), sino que esa historia está bloqueada, luego no se puede continuar trabajando en
ella.

Es, por tanto, responsabilidad de los miembros del equipo notificar la existencia de
esos bloqueos y reflejarlos en la lista de bloqueos y, sin embargo, será responsabilidad del
Scrum Master ir dándole solución a todos esos bloqueos para que el equipo continúe
trabajando (es su labor de facilitador del equipo).
Esta lista en ocasiones se añade como un apartado de la Scrum Board, ya que forma
parte del estado del Sprint y permite a equipo y Scrum Master ver de un vistazo los bloqueos
aparecidos y resueltos.
 Burn-down Chart
Hasta ahora se han visto artefactos que ayudan al equipo, al Scrum Master y al Product
Owner a organizar el trabajo y tener una representación gráfica del sprint en cada momento,
pero queda aún un concepto por cubrir: una visión global de la marcha de cada sprint.
En Scrum, a la hora de trabajar con historias existe una regla de oro: se debe trabajar
funcionalidad a funcionalidad en la medida de lo posible. Ya lo veremos más a fondo cuando se
hable del ciclo de vida de Scrum, pero lo ideal es que todo el equipo trabaje en paralelo en una
misma historia de usuario hasta haberla terminado y, entonces, pasen a la siguiente (por ello
se subdividen en tareas paralelizables).
Al crear las distintas historias, ya habíamos visto que uno de los apartados de las
tarjetas que las contienen es la estimación. Dicha estimación se puede medir en puntos de
complejidad/duración o simplemente en horas y dicha medida será utilizada para medir la
velocidad de trabajo que un equipo tiene en cada sprint.
La Burndown Chart no es más que una gráfica que contiene en su eje X los días que
dura el Sprint y en el eje Y los puntos que el equipo se ha comprometido a realizar a lo largo
del Sprint.
Cada día, se pondrá un punto en la unión de los ejes correspondiéndose en X al día

actual, y en Y a los puntos que quedan pendientes. Al unir los puntos se obtiene una gráfica del
avance a lo largo del Sprint.

La información que este gráfico desprende no es solo una cuestión de velocidad. La

forma de la curva de bajada nos puede dar muchas pistas sobre los problemas que haya
podido tener el equipo o malas prácticas con respecto a la metodología.
Por ejemplo, una línea recta en el gráfico podría indicar que el equipo ha estado
bloqueado durante algún tiempo o que han estado trabajando con una historia muy grande
(algo poco recomendable en Scrum, como veremos más adelante).
Una línea que presenta un escalón o bajada muy pronunciada en un momento dado
podría significar que el equipo no ha estado trabajando en paralelo en una misma historia, sino
que se han realizado varias de golpe y terminado a la vez.
Del mismo modo se puede realizar un gráfico similar con el progreso del proyecto a lo
largo de los sprints:

Gracias a este gráfico se puede medir la velocidad del equipo, ya que refleja el número
de puntos entregados por Sprint.
Al contrario que en el Burndown chart, aquí será positivo que la tendencia de la gráfica
sea ascendente, aunque en proyectos muy largos lo normal es que con el paso de los sprints
tienda a estabilizarse.

2.3. Aplicación práctica de un ciclo de scrum
2.3.1. VISIÓN GENERAL
Hemos podido observar que muchos de los principios de scrum, así como la mayoría
de sus artefactos, están íntimamente relacionados con el ciclo de vida de la propia
metodología.
En esta asignatura por fin estudiaremos dicho ciclo y analizaremos de qué partes se
compone cada una de las iteraciones de un proyecto scrum, adentrándonos en el día a día de
un grupo de trabajo.
Como siempre hemos visto, scrum es una metodología iterativa, con ciclos o sprints de
un tiempo determinado. Sin embargo, siempre debe existir un punto de partida y en scrum ese
punto es disponer de un product backlog inicial que contenga todos los requisitos con los que
comienza el cliente sobre el producto, dividido en hitos o funcionalidades, aquí llamadas
historias de usuario.
Es responsabilidad del product owner obtener del cliente toda esta información y
establecer una priorización de qué historias de usuario deben ser entregadas primero, a ser
posible por peso estratégico en el proyecto.
Igualmente, y como se comentó en temas anteriores, el product owner procurará que

las primeras en realizarse sean aquellas que mayor riesgo conllevan, para mitigar dicho riesgo
lo antes posible o buscar alternativas y cambios en un estado poco avanzado del proyecto.

Una vez ha realizado este trabajo, el product owner dispondrá de su product backlog:
Y una vez obtenido el product backlog, ya se dispone de suficientes historias de usuario

como para dotar al equipo de trabajo necesario para un sprint concreto. De esta forma, ya
podemos empezar la fase de iteraciones o sprints:

2.3.2. EL SPRINT
Se denomina sprint a cada una de las iteraciones realizadas en scrum. La duración de

este debe ser lo suficientemente larga como para que se puedan realizar historias de usuario
completas y lo suficientemente corta como para que los cambios solicitados sobre el trabajo
hecho sean lo menos traumáticos posible.
La duración normal de un sprint suele ser entre 2 y 4 semanas dependiendo del

proyecto.
Cada sprint se divide en una serie de fases que podríamos denominar:
 Planificación: se asume la cantidad de trabajo a realizar durante el sprint y se

organiza.
 Periodo de trabajo: el equipo trabaja en las historias de usuario comprometidas con
el apoyo del product owner.
 Entrega de trabajo: se analiza el trabajo terminado y se muestra al cliente para
obtener feedback.
 Análisis del sprint: el equipo analiza la marcha del sprint que termina para detectar
posibles puntos de mejora en futuras iteraciones.
Uno de los objetivos de scrum es eliminar, en la medida de lo posible, documentación

y reuniones constantes y no productivas.
Para ello, introduce a lo largo del sprint una serie de reuniones que claramente
representan las distintas fases de las que consta. Existen otro tipo de reuniones más
específicas que se podrían introducir dependiendo de la envergadura y el modo de trabajo en
el proyecto, pero las más representativas y obligatorias en cualquier proyecto scrum son las
detalladas a continuación.

2.3.3. SPRINT PLANNING
Nada más comenzar cada sprint, lo primero que se hace es la planificación. Para ello el
product owner selecciona de su sprint backlog cuáles son las historias de usuario que
considera que el producto debería contener de cara al próximo entregable, basándose para
eso en las prioridades establecidas junto al cliente.
A parte de la funcionalidad en sí, el product owner tiene que tener en cuenta dos
cosas:
 Para que el equipo comience a trabajar, él tiene que ser capaz de transmitirles la
visión de lo que se espera de dichas historias de usuario.
 Como ya se ha comentado, a lo largo de un sprint solo se debe trabajar en historias
de usuario que puedan finalizarse.
Por tanto, el product owner nunca deberá incluir aquellas historias que no estén lo
suficientemente detalladas y granuladas como para que el equipo pueda trabajar en ellas y
finalizarlas en un sprint. No debe caer en la tentación de desgranar las historias lo justo para
que encajen en un sprint, ya que eso llevaría a que el equipo solo se comprometiese a una
historia por cada uno de ellos y cualquier imprevisto implicase un sprint sin nada finalizado.
Lo ideal es que el product owner, una vez escrita una historia, analice y detecte si esa
única historia podría dividirse en dos o más historias que contengan una funcionalidad
concreta. Por ejemplo: un product owner está escribiendo historias de un proyecto que
consiste en una máquina de hacer zumos. La historia más obvia sería:

“Como usuario quiero que, una vez apriete la naranja contra la máquina, se obtenga un zumo”
Sin embargo, dicha historia prácticamente resume el proyecto completo y ni especifica

al equipo el funcionamiento de la máquina en detalle, ni es probable que logren hacerlo en un
solo sprint.
En una primera fase de concreción, el product owner podría dividir dicha historia en
varias historias más pequeñas:
“Como usuario quiero que, una vez apriete la naranja contra la máquina, la pieza rotatoria
empiece a girar”
“Como usuario quiero que, una vez el jugo cae por la pieza rotatoria, caiga en un filtro”
“Como usuario quiero que, una vez el jugo pase por el filtro, sea conducido hacia el vaso”
Y así sucesivamente. Una vez terminado este paso, deberá repetirlo con cada una de
las historias resultantes. De esta manera, intentará crear historias lo más pequeñas y
detalladas posibles.
No importa el número, lo importante es que, cuantas más pequeñas sean, más

funcionalidades independientes tendrán el equipo para trabajar y menor posibilidad de dejar
una historia sin terminar al final de un sprint.
Una vez están seleccionadas y preparadas las historias que el product owner podrá
mostrar al equipo, se reúne con ellos en una sala y comienza el sprint planning propiamente
dicho.
Por orden de prioridad, el product owner selecciona la primera historia de su product

backlog y realiza el siguiente proceso:
 Se expone la historia al equipo: una vez finalizada su exposición el equipo podrá

realizar una breve ronda de dudas que les haya surgido sobre la historia.
 El equipo vota la estimación del peso de la historia: ya habíamos visto que dicha
estimación se realiza en base a la complejidad y duración de la misma y se utiliza

para medir la velocidad de trabajo del equipo.
Sin embargo, ¿cómo medimos la complejidad en una historia de usuario? Para hacerlo
tendremos que tener en cuenta dos factores: la concreción de los requisitos definidos y el
dominio del equipo en la tecnología que debe utilizarse para implementar una solución.
Cuanto menos concretos son los requisitos o menor el dominio del equipo, más difícil
es encontrar una solución a la historia y por tanto más compleja y arriesgada resultará.
El siguiente gráfico define muy bien lo que esto significa:
Una historia con unos requisitos pobres y que requiere del uso de una tecnología
desconocida por el equipo puede sumirse en el caos, es decir, realizarse a base de prueba y
error hasta dar con un resultado aceptable.
Lógicamente, planificar un trabajo de ese tipo es complicado, ya que el

desconocimiento y la falta de experiencia en tareas similares nos impiden basarnos en algo
para realizar la estimación.
Para realizar las estimaciones, una de las técnicas más sencillas es el planning poker.
Consiste en que, una vez descrita una historia por parte del product owner, cada miembro del
equipo alce la mano al mismo tiempo con su estimación de la historia, utilizando para ello unos
baremos (suelen utilizarse los números de la sucesión de Fibonacci) donde se habrá fijado de
antemano qué valor indica que la historia es demasiado grande para ser abordada en un solo
sprint.

Existen cartas que se pueden comprar y que contienen juegos de valores para puntuar
y cartas especiales para indicar que no es posible valorar la historia o que es demasiado larga
para un sprint (La necesidad del uso de estas cartas es tal para estos casos que existen diversas
aplicaciones móviles, tanto para Android como para iPhone).
En caso de que no exista unanimidad en el voto, cada miembro del equipo que haya
votado el valor mínimo o máximo de la votación podrá exponer el por qué de su puntuación.
Una vez expuesto, se repetirá la votación. En cuanto exista unanimidad, se tendrá el peso de la
historia.
Si tras 3 votaciones sigue sin haber unanimidad, pero los valores son muy cercanos, se
podrá elegir el más votado o un valor medio.
Si los valores son muy dispares o si por unanimidad se decide que esa historia no es
comprensible (y por tanto valorable) o es demasiado grande para el sprint, el product owner
tendrá que devolverla a su product backlog y detallarla o desgranarla en distintas historias
para futuros sprints.
 Una vez estimado el peso de la historia, este se apunta en la tarjeta y se traslada la

historia al sprint backlog: en este momento el product owner debe preguntar al
equipo si ya tienen trabajo suficiente para el sprint o si se comprometen a afrontar
una nueva historia.
Mientras el equipo se vea con posibilidades de comprometerse a realizar más historias,

el product owner seguirá cogiendo historias de su product backlog por orden de prioridad y
repitiendo los pasos del 1 al 3.
Una vez el equipo ya estima tener suficiente trabajo para un sprint, se dejan de
mostrar historias y el equipo tiene su sprint backlog, con el que trabajarán durante la siguiente
iteración, y su objetivo será realizar todo el trabajo al que se han comprometido.
Como vemos, aunque es el product owner quien guía qué se debe hacer, es el propio
equipo el que se gestiona, estimando cuánto cuesta hacer cada cosa y comprometiéndose a
tener el máximo trabajo posible en el sprint.
Esto sirve como motivación al equipo, que si bien tiene un objetivo claro y una
cantidad de trabajo para el sprint, este no viene marcado por una tercera persona, sino que
viene determinada por ellos mismos y su afán de trabajo y superación (los burndown charts de
sprints anteriores pueden servir como baremo de los puntos que ya han logrado hacer y lograr
que “batir ese récord” sea un objetivo y motivación para el equipo es tarea del scrum master.

Antes de concluir la reunión del sprint planning, el equipo ya con las historias en la
mano deberá dividirlas en tareas independientes en las que los miembros del equipo puedan
trabajar de manera autónoma, teniendo siempre en mente que la idea es que todos o el
máximo número de miembros del equipo trabajen paralelamente en tareas de la misma
historia hasta finalizarla y que la duración máxima de cada tarea no debe excederse en la
medida de lo posible de un día natural.
Con el sprint backlog y las historias divididas en tareas, el scrum master ya puede
trasladar los artefactos a la scrum board y crear la burndown chart del sprint para comenzar a
trabajar.
2.3.4. DAILY SPRINT
Ya tenemos el trabajo a realizar y ahora nos enfrentamos al día a día. Aunque en

iteraciones relativamente cortas como las que se realizan en scrum y por los fundamentos de
la metodología vistos hasta ahora podría darse por hecho que la organización recae
totalmente en el equipo y no hay ningún tipo de control, esto no es exactamente así.
Existe un mecanismo de control para el trabajo del equipo, solo que no implica control
por parte de terceros, sino por el propio equipo (el equipo se autogestiona). Dicho mecanismo
de control consiste en una reunión diaria donde se comparte el progreso de las actividades del
sprint.
Pero habíamos dicho que en scrum y en general en las metodologías ágiles se

intentaban evitar las reuniones innecesarias y largas que únicamente quitan tiempo de trabajo
al equipo… y así es. Sin embargo, esta reunión se sustenta sobre una serie de normas que
hacen que su duración sea lo más reducida posible y que sea útil para el equipo y su ritmo de
trabajo.
El daily sprint es una reunión que debe realizarse cada día a la misma hora, lo más
pronto posible dentro de la jornada de trabajo del equipo. Los asistentes a dicha reunión serán
todos los miembros del equipo y el scrum master. Se puede invitar a más asistentes si el
equipo está conforme con ello, pero como simples oyentes.
Es importante que la reunión tenga lugar cada día a la misma hora sin posibilidad de
retraso. Si algún participante se retrasa no se le esperará (y en la mayoría de los casos se les
suele imponer un castigo menor previamente pactado, como pagar una multa a un bote que a
la larga se utilizará para pagar el desayuno al equipo un día).
La duración de la reunión nunca debe exceder los 15 minutos y debe realizarse con
todos los asistentes (participantes e invitados) en pie. De esta manera, todo el mundo

procurará ir al grano y no se convertirá en una reunión que sistemáticamente quita tiempo de

trabajo a todo el mundo.
Durante la reunión, todos los asistentes deben responder a tres simples preguntas:
 ¿Has terminado las tareas que te comprometiste ayer a terminar? En caso

negativo habrá que explicar brevemente por qué no.
 ¿Qué tareas te comprometes a terminar hoy? Cada miembro del equipo debe
exponer qué tarea o tareas de las existentes en la scrum board se compromete a
tener terminadas (si va a realizar una tarea parcialmente, debe especificar hasta
qué punto la tendrá realizada, de manera que al día siguiente pueda decir si
cumplió o no su propósito). Deben evitarse frases abstractas del tipo “me
comprometo a empezar una tarea y avanzar lo máximo posible”.
 ¿Existe algún elemento bloqueante en tu camino? En caso de que exista algún
impedimento para que un miembro del equipo haya realizado sus compromisos
del día anterior o que le impidan realizar los de ese mismo día, deberá exponerlos
para que el scrum master tome nota y les ponga solución.
3 ejemplos de lo que un miembro del equipo podría exponer en un daily serían:
 “Buenos días, ayer me comprometí a localizar 3 posibles proveedores del

componente necesario para la historia 5 y los localicé. Hoy me comprometo a
terminar la siguiente tarea, que es negociar y realizar el pedido al más ventajoso de
ellos. No tengo elementos bloqueantes”.
componente necesario para la historia 5 y únicamente logré localizar 2. Hoy me
comprometo a localizar el tercero y a terminar la siguiente tarea que es negociar y
realizar el pedido al más ventajoso de ellos. No tengo elementos bloqueantes”.
componente necesario para la historia 5 y no pude hacerlo. Hoy me comprometo a
terminar esta misma tarea. Tengo un elemento bloqueante que es que la línea
telefónica de la oficina no funciona y no dispongo de móvil”.
En el primero de los 3 casos, claramente todo va según lo provisto, ya que el

componente del equipo es capaz de ir cumpliendo sus compromisos.
En el segundo caso, pese a no existir un elemento bloqueante, el miembro del equipo

no es capaz de cumplir su compromiso. Esta es una situación que puede darse ocasionalmente,
pero si se repitiese habría que localizar el foco del problema (quizás ese miembro del equipo

requiere de más formación o recursos o simplemente midió mal el tiempo necesario para la
tarea).
En el tercer caso, el miembro del equipo está bloqueado y será responsabilidad del
scrum master ayudarle a dar una solución (en este caso, comunicarse con los responsables de
la oficina para ver qué pasa con la línea o conseguirle temporalmente un teléfono móvil).
Como se puede observar, cualquiera de los 3 casos describen una exposición que no
requiere más de un minuto. Por tanto, sumando la exposición de todos los miembros del
equipo (a no ser que esté sobredimensionado) no se deberían exceder los 15 minutos máximos
de duración de la reunión.
Los beneficios de esta reunión diaria se pueden intuir fácilmente:
 El equipo debe trabajar y reportar como un equipo y la expresión “me

comprometo” o “me comprometí” es clave es este tema (recordad la fábula del
cerdo y la gallina). Es el propio trabajador quien adquiere un compromiso consigo
mismo y con el equipo, ya que la unión del trabajo de todos determina el
resultado final.
 El hecho de que las historias hayan sido divididas en tareas que puedan medirse
por días de trabajo facilita que los compromisos de los miembros del equipo
tengan más sentido. Si me comprometo a realizar una tarea, ya sé de antemano
cuánto debería tardar en realizarla.
 Teniendo en cuenta el punto anterior, el scrum master es capaz de detectar qué
miembros del equipo podrían no estar cumpliendo con las expectativas de
velocidad del resto de sus compañeros y ponerle solución quizás con formación
específica o proponiendo que en un futuro sprint dicho miembro trabaje codo con
codo con otro más experimentado para que intente adoptar su rutina de trabajo.
 El equipo tiene una oportunidad al inicio de cada día de reportarle al scrum
master los problemas que le impiden hacer su trabajo con normalidad y este
buscará una solución lo antes posible.
 Por último, y quizás lo más importante, esta reunión sirve para que cada miembro
del equipo encuentre en el trabajo de los demás una motivación extra para
superarse. El hecho de tener que decir en público delante de tus compañeros cuál
ha sido tu progreso y cuáles tus expectativas para ese día, sumado al hecho de
que a su vez estás escuchando cuál es el ritmo de trabajo de los demás, es un
revulsivo para que el nivel de trabajo nunca decaiga.
Tras la reunión y con la información del trabajo recién actualizada por cada uno de los
miembros del equipo, el scrum master tiene una oportunidad inmejorable de acercarse a la
scrum board y comprobar que realmente esta refleja el estado descrito en la reunión.

2.3.5. MECÁNICA DE TRABAJO
Tras el daily sprint, el equipo comenzará su jornada de trabajo con normalidad. Lo

único a reseñar en cuanto al uso de scrum sería que cada miembro del equipo debería estar
trabajando en una tarea perteneciente a una historia (idealmente, todos los miembros
trabajarán en paralelo en tareas de la misma historia).
Para reflejar en qué se está trabajando y qué está pendiente de realizarse, se hace uso
de la scrum board.
Al inicio del sprint, tanto las historias como sus tareas estarán en la columna de
“pendientes de realizar”.
Una vez se inicia el sprint, cada miembro del equipo coge la tarea en la que va a
trabajar, la mueve a la columna “en progreso” y marca que está trabajando en ella (por
ejemplo, con un post-it de un color asignado a él o con una chincheta).

Una vez un miembro termina la tarea en la que está trabajando, la moverá a la

columna de “terminado” y, en caso de que fuese la última de las tareas de una historia,
moverá la historia a la columna de “verificación” para que el product owner pueda comprobar
si efectivamente cumple con todos los requisitos de calidad mínimos especificados para la
historia.

Tras mover la tarea (e historia si corresponde), tendrá que coger una nueva. Para ello
volverá a la columna de “pendientes de realizar”, seleccionará una por orden de prioridad y la
moverá a “en progreso” marcando que él la realiza.
Mediante esta sencilla rutina de trabajo, la scrum board se convierte en uno de los
artefactos más útiles para todos los miembros implicados en el proyecto, ya que de un solo
vistazo permite ver el estado del sprint en tiempo real, saber en qué está trabajando cada
compañero y detectar posibles desviaciones de tiempo lo antes posible.
La scrum board además realiza una segunda labor para el scrum master, la de chivato.
En ocasiones sólo con ver cómo están los Post-it situados en la scrum board, el scrum
master puede detectar que la metodología no se está siguiendo correctamente.
Un ejemplo sería si el scrum master viese que las primeras historias situadas en la
scrum board no están en progreso y, sin embargo, alguna que está por detrás sí (eso significa
que el equipo no está trabajando en base a las prioridades marcadas por el product owner) o si
hay muchas historias en progreso pero ninguna terminada (eso significa que no se está
trabajando en equipo sino individualmente).

A continuación se muestra un ejemplo de scrum board que denota estos problemas:
2.3.6. SPRINT-REVIEW
Una vez finaliza el tiempo estipulado de cada sprint, se realiza una demostración de las
funcionalidades del producto terminadas.
Para ello se convoca una reunión a la que asistirán el equipo, el scrum master, el
product owner y, en la medida de lo posible, el cliente o una representación del mismo.
También se puede invitar a toda aquella persona que se considere oportuna (por ejemplo, a un
usuario final para obtener su feedback o a algún alto mando de la empresa para que sea
partícipe del progreso del proyecto).
El objetivo de esta reunión es doble:
 Por un lado, los distintos miembros del proyecto ven el progreso que se ha realizado
del mismo y obtienen una visión global del estado actual del producto a entregar.
 Por otro lado, el cliente tiene la oportunidad de ver cómo va evolucionando su
producto y detectar posibles cambios, mejoras o diferencias de interpretación de
los requisitos iniciales.

El sprint review es una de las reuniones más importantes en scrum por este segundo
punto, ya que es el que marca la diferencia entre encontrar los fallos o cambios solicitados por
el cliente durante el proceso de producción del producto, donde las modificaciones no son tan
traumáticas y el proyecto está a tiempo de ser replanteado, o encontrarlos al finalizar el
proyecto, cuando ya nada se puede hacer o hacerlo implica la pérdida de mucho tiempo (y
dinero) invertido.
Es decir, marca en gran medida que scrum sea una metodología ágil.
En cuanto a las reglas a seguir en esta reunión, se recomienda que su duración no sea
demasiado extensa (máximo 2 horas) y que lo que se muestre en ella sea únicamente
funcionalidades completas (jamás trabajo que ha quedado a medias) y visualmente sencillas de
mostrar.
Deben evitarse demostraciones teóricas o explicaciones extensas de lo que se muestra,

ya que podría confundir al cliente y lograr el efecto contrario al pretendido con esta reunión.
Si no hubiese nada visual que enseñar (por ejemplo, si todo el sprint se hubiese
dedicado a tareas de investigación), es preferible no realizarla o hacerlo de manera interna sin
cliente.
2.3.7. SPRINT-RETROSPECTIVE
Antes de dar por finalizado el sprint, se realiza una última reunión. Quizás es la que
más valor aporte al equipo, pero también la que más madurez exige por parte del mismo.
Se trata del sprint retrospective y consiste en un análisis por parte del equipo y el
scrum master de los puntos fuertes y débiles del equipo y la metodología de trabajo a lo largo
del sprint.
Normalmente no se invita a más asistentes para evitar que el equipo se sienta

incómodo o expuesto a la hora de hacer un trabajo de autocrítica. Así mismo, las exposiciones
tanto positivas como negativas deben ser tratadas a nivel equipo en la medida de lo posible,
tratando de evitar personalizaciones que podrían derivar en conflictos entre miembros del
equipo.

Se suelen tratar 4 puntos en este orden:
 Cosas que han ido bien: se da la oportunidad a cada miembro del equipo de
exponer aquellas rutinas, actitudes o herramientas que se considera que han sido
positivas a lo largo del sprint.
 Cosas que han ido mal: se exponen aquellas cosas que se piensan han perjudicado
al equipo o su rendimiento.
 Cosas que se deben empezar a hacer: basándose en los dos puntos anteriores, se
deben trazar objetivos de mejora para el siguiente sprint. Será responsabilidad del
scrum master facilitar que esto se lleve a cabo.
 Cosas que se deben dejar de hacer: igualmente que en el caso anterior, se deben
marcar objetivos concretos de cosas que no deben hacerse desde el siguiente
sprint.
Un ejemplo de una pizarra con el contenido de una sprint retrospective sería:
Como base para comenzar el análisis y la discusión, es conveniente hacer uso de uno
de los artefactos que muestran un “histórico” del progreso del sprint, el burndown chart, que
dará una idea general del avance del trabajo a lo largo del sprint y podría mostrar al equipo
fallos a la hora de emplear la metodología.

Por ejemplo, un burndown chart como el siguiente:
Se percibe claramente un escalón grande más o menos en la mitad del sprint. Esto
podría denotar que durante un tiempo se ha trabajado en varias historias en paralelo o que
hubo un bloqueo que se alargó demasiado en el tiempo.
O un burndown chart como este:

En el cual se observa que el equipo no ha conseguido acabar los puntos antes de

finalizar el sprint, y por tanto podría estar estimando mal las historias, comprometiéndose a
más trabajo del que es capaz de realizar o reduciendo su velocidad habitual.
Un ejemplo de una retrospectiva podría ser:
 Cosas que han ido bien: “la comunicación entre equipo y product owner ha sido
fluida”, “la estimación de pesos de las historias estaba afinada”.
 Cosas que han ido mal: “varias personas han requerido de una misma utilidad para
realizar sus tareas y, por falta de comunicación, la han buscado cada una por su
lado”, “la división en tareas de las historias se hizo únicamente por tiempos y hacía
que no se pudiese trabajar en paralelo en ellas”, “el uso de email para
comunicarse entre miembros del equipo creaba altos tiempos de espera.”.
 Cosas que se deben empezar a hacer: “crear una wiki donde documentar las
utilidades encontradas durante las tareas”, “buscar una nueva forma de dividir las
historias en tareas”.
 Cosas a dejar de hacer: “utilizar el email en lugar de la conversación directa para
plantear dudas a los compañeros del equipo”.
Como se puede observar, los dos últimos apartados no dejan de ser un reflejo de las
soluciones que se proponen a los problemas encontrados por el propio equipo.
Algunas de ellas dependen de la disciplina de trabajo de los propios miembros del

equipo (como dejar de mandar mails), aunque la mayoría implican que el scrum master
presente soluciones o alternativas para su ejecución (crear una wiki que puedan utilizar,
enseñar técnicas de división en tareas al equipo).
Una vez finalizada esta reunión (que no debe exceder la hora, para evitar que la
exposición de puntos de vista se convierta en debates interminables), se puede dar el ciclo del
sprint por finalizado y se comenzaría uno nuevo con un nuevo sprint planning.
Esta reunión tiene que tratarse con especial delicadeza, ya que puede ser un foco de
conflictos dentro del equipo debido a la naturaleza crítica de la misma.
En muchos casos se aconseja que el scrum master dote a esta reunión de un punto de
originalidad en función del estado anímico del equipo. Por ejemplo, en un sprint muy duro y en
el que se han detectado tensiones entre los miembros del equipo, cambiar la ubicación de la
reunión y trasladarla a un lugar más amigable que una sala de reuniones, por ejemplo un
parque, podría relajar el ánimo de los asistentes y hacerla más productiva.

También es importante que la reunión no se convierta en un mero debate sin fin, sino
que de ella se obtengan conclusiones.
Para ello es recomendable que el scrum master y el equipo elaboren conjuntamente

un resumen de lo que ha ido bien, lo que ha ido mal y una serie de acciones que deben
comprometerse a realizar a lo largo del siguiente sprint para mejorar el proceso.
Aquellas relacionadas con el trabajo del equipo deberán ser realizadas por ellos y el
resto será responsabilidad del scrum master que la persona implicada la realice (puede ser, por
ejemplo, solicitar mayor claridad al product owner durante los planning o solicitar a la empresa
algún tipo de recurso o formación).

2.3.8. CUADRO RESUMEN
El gráfico que se puede ver a continuación resume bastante bien los distintos
componentes del ciclo de vida de Scrum:

2.4. Buenas prácticas de la gestión con Scrum
Hasta ahora hemos visto la base teórica de la metodología scrum, pero en esta
asignatura quiero daros algunos consejos a seguir para implantarla en una empresa que,
históricamente, funciona bajo el paraguas de las metodologías tradicionales. Analizaremos
juntos algunos casos de empresas que ya la han utilizado, veremos por qué era conveniente o
no utilizarlo y profundizaremos en algunos aspectos que podréis encontraros a la hora de
tener que trasladar la teoría del uso de Scrum a un caso real.
2.4.2. ¿CÓMO INTRODUZCO SCRUM EN UNA EMPRESA?
Lo primero que hay que tener en cuenta a la hora de introducir una metodología ágil
en el proceso de trabajo de una empresa y especialmente tratándose de scrum es que NO es
fácil, y mucho menos si dicha empresa tiene años de experiencia en el uso de otro tipo de
metodologías de trabajo.
A continuación describo una serie de pasos a seguir para conseguir implantar scrum
con éxito en una empresa.
Identificar quién está a favor y en contra del cambio (los llamados early-adopters)
La decisión de cambiar de metodología de trabajo no suele tomarse a la ligera debido

al tiempo y los recursos necesarios para la transición. Por tanto, siempre suele haber un
detonante que lleva a plantearse dicho cambio.
Principalmente el origen de la petición de cambio puede surgir de tres fuentes

distintas: los trabajadores, la directiva o una consultora externa.
El primer caso suele derivar en problemas burocráticos, si es necesario convencer a la

directiva del sentido de ese cambio, pero sin embargo hace mucho más sencilla la transición
una vez se aprueba, ya que el equipo estará obteniendo lo que quiere, lo cual les motiva y les
abre totalmente a las novedades que irán encontrando a lo largo del proceso.
Aun así, es conveniente saber el porqué de esa petición de cambio. Al fin y al cabo, si
los trabajadores piden algo es porque tienen unas expectativas. Idealmente estas estarán
basadas en el ánimo de mejorar su metodología de trabajo, ya sea porque la que utilizan no

funciona o porque piensan que su productividad puede ser mayor con una metodología ágil, lo
cual les beneficiará laboralmente.
Sin embargo, es posible que simplemente les atraigan algunas partes de la

metodología (autogestión, es decir, no tener a un jefe encima, reducir documentación, etc.). Es
importante que comprendan todos los cambios que va a suponer el uso de scrum, para que no
se sientan defraudados al ver que al principio es duro y tienen un enfoque a medio plazo, lo
que hace que, en ocasiones, la transición no llegue a completarse.
En caso de que la petición provenga de la dirección de la empresa, los trámites

burocráticos se verán reducidos, pero el trabajo de concienciar a los trabajadores y conseguir
que se comprometan con la metodología puede resultar más arduo, puesto que nunca se
recibe igual de positivamente aquello que viene impuesto.
Al igual que pasaba en el caso anterior con los trabajadores, es importante concienciar
a la directiva de la empresa de los riesgos que conlleva un cambio de metodología y hacerles
ver que los resultados del cambio serán progresivos y no inmediatos, como podrían
plantearse.
También es importante saber qué les motivó a solicitar ese cambio. En ocasiones se
confunden los principios ágiles y se interpretan de manera incorrecta buscando el propio
beneficio.
En el caso de que sea una consultora externa quien propone el cambio, se duplicaría la
tarea de concienciación, ya que por un lado se tendrá que motivar a los trabajadores para que
se adapten a la nueva metodología y, por otro, se tendrá que convencer a los directivos para
que aprueben el cambio.
Sin embargo, si una consultora ha recomendado el cambio, lo habrá hecho basándose

en algún tipo de estudio de la empresa. Por tanto ya habrán realizado una parte importante
del camino: proporcionar la justificación para el cambio.

Habitualmente estas recomendaciones están basadas en problemas de productividad,

en el análisis del tipo de producto que ofrece la empresa o en los recursos humanos de la
misma y la manera de optimizar su trabajo para obtener un futuro crecimiento.
Apoyarse en profesionales
El proceso de transición desde una metodología tradicional a una ágil es complicado y

trae consigo la aparición de dudas en todos los ámbitos. Muchas de ellas surgirán de la propia
directiva de la empresa, que querrá tener un plan de acción lo más detallado posible y tenderá
a intentar convertir la metodología en lo que ellos quieren y no en lo que realmente es.
Es por eso que se recomienda contratar a una persona externa, al menos durante la
planificación del cambio y en los primeros meses de transición, ya que al ser ajeno a la
empresa no tendrá problemas con expresar las cosas tal y como son, sin miedo a futuras
represalias.
Por otro lado estará el equipo, que tendrá que abordar los primeros meses con
bastantes dudas surgidas entre sus miembros, debates sobre cómo deben hacerse las cosas e
incluso los Sprint Retrospective más duros.
Es por esto que es importante que la persona que actúe como Scrum Master esté
realmente formada para desempeñar esa función. De otra manera, surgirán las dudas no
resueltas, la falta de confianza en el líder del cambio y los debates y discusiones provocados
por mensajes contradictorios lanzados por un Scrum Master improvisado.

Trazar un plan de acción realista
Como se ha comentado anteriormente, el factor psicológico juega un papel muy

importante en el cambio hacia Scrum. Al iniciar el proceso, todo el mundo estará deseando ver
los resultados del cambio lo antes posible. Sin embargo, el proceso requiere su tiempo y su
esfuerzo.
Hay que dejar bien claro al exponer una planificación en qué momento podrían
empezar a notarse los beneficios, ya que, de lo contrario, o el equipo puede desanimarse y por
tanto llevar el proyecto hacia el fracaso o los directivos podrían perder la paciencia y dar
marcha atrás.
Comienza el cambio con un proyecto piloto
Este punto cobra mayor importancia cuanto mayor es el número de personas

afectadas por el cambio. La mejor manera de introducir un scrum en la empresa es aplicando
el scrum al propio proceso de cambio, ya que un scrum aboga por el avance iterativo e
incremental, necesarios aplicarlos desde un principio al cambio:
 Tras el periodo de análisis de la gente implicada y sus motivaciones, selecciona un

pequeño equipo con la gente más próxima a la metodología y la más abierta al
cambio.
 Procura que esa gente trabaje en un proyecto de duración no muy extensa y, una
vez instaurada la metodología, si realmente ha supuesto un avance con respecto a
la metodología anteriormente utilizada, realiza una presentación a la directiva y al
resto de trabajadores implicados en el cambio, exponiendo las mejoras logradas
con el cambio de metodología (sería análogo a una Sprint Demo).
 Si es posible, una vez terminada la demo, reúne al equipo piloto para realizar una
sesión de debate en la que puedan exponer qué les ha parecido el cambio, qué ha
sido lo mejor y lo más duro y qué cambiarían en el proceso de transición si
pudiesen (sería análogo a un Sprint Retrospective).
 Invita a los trabajadores que vayan a verse implicados en el futuro. De esta
manera escucharán de sus propios compañeros los cambios y ventajas de utilizar
un Scrum.
Continúa el cambio progresivamente
En la mayoría de las ocasiones, el triunfo de un proyecto piloto hace que el Scrum

Master o incluso la directiva consideren que la idoneidad del cambio está más que probada y
decidan emprender el periodo de transición con toda la plantilla y proyectos restantes.

Aunque existirán casos donde esto sea posible, es importante realizar un nuevo
trabajo de análisis previo (una nueva iteración) en el que se incluirá dentro del estudio el
aprendizaje obtenido por la experiencia con el proyecto piloto.
Hay que tener en cuenta el esfuerzo invertido en formar, motivar, guiar y resolver
dudas a un pequeño equipo y dimensionarlo en su justa medida al trabajo que queda por
delante. Que se haya podido formar un equipo en un tiempo concreto no significa que en ese
mismo tiempo se pueda formar un equipo de dimensión mucho mayor.
Tampoco significa que si se han empleado X meses con el equipo piloto, se necesiten x
* 4 para formar 4 equipos. La experiencia ha de ser tenida en cuenta y una práctica muy útil es
introducir al menos un miembro del equipo piloto en cada nuevo equipo a formar.
De esta manera, ya existirá otra persona con conocimiento que puede guiar a sus
compañeros de equipo (al fin y al cabo el equipo se auto gestiona y cada miembro acaba
encontrando su rol).
2.4.3. EXPERIENCIA POSITIVA (COMENZANDO POR EL EQUIPO)
 Antecedentes
Este caso trata de la experiencia vivida por una empresa de desarrollo de software a la
hora de implantar scrum.
La empresa buscaba una nueva forma de trabajar, ya que se habían dado cuenta de
que cada vez más contaban con perfiles muy especializados en determinadas áreas y
productos de los cuales una sola persona era experta.
Esto llevaba a que la ausencia de un miembro del equipo de desarrollo penalizaba

enormemente el desarrollo de nuevos proyectos y ni que decir cabe del mantenimiento de
proyectos en producción.
Así mismo, la propia metodología de trabajo había derivado en un ciclo vicioso en que
lo único que se hacía era resolver crisis inmediatas, ya que todos los clientes con los que
trabajaban solicitaban nuevos desarrollos y cambios en los productos ya entregados, sin
ningún tipo de control y siempre con prioridad alta.
Esto derivaba en que, por un lado, el equipo de desarrollo se antojase

infradimensionado, asignando finalmente una sola persona a varios proyectos sin ningún tipo
de comunicación o intercambio de información con sus compañeros, y, por otro, a que los
miembros del mismo no tuviesen manera de planificar y dimensionar su trabajo de manera
coherente. La paralelización del desarrollo de funcionalidades e incluso entre proyectos hacía
que las peticiones de los clientes se comenzasen nada más ser solicitadas, dejando paradas

tareas que estaban aún en progreso, acumulando así trabajo pendiente y entregando
finalmente la mayoría del trabajo mal y tarde.
Trasladado fuera de los límites del equipo de desarrollo, los Project Managers tenían
que lidiar a diario con clientes descontentos por falta de compromiso en las entregas o incluso
que estas se produjesen fuera de plazo.
Este caso, aunque pudiera parecer exagerado, se ajusta perfectamente al vivido por
muchas pequeñas empresas de desarrollo (o pequeños departamentos en una empresa de
gran magnitud) cuya producción crece rápidamente.
Normalmente el crecimiento de la plantilla suele llevar cierto desfase y la acumulación

de trabajo hace que se opte por crecer con la misma metodología con que se trabajaba siendo
pequeño, en lugar de parar y adaptar la metodología de la empresa o departamento a las
nuevas circunstancias.
 Adaptándose a scrum
Para solucionar el problema que tenían y tras barajar distintas posibilidades que
pudiesen solucionar su situación, la empresa optó por adoptar Scrum como metodología. Sin
embargo, el cambio fue gradual para minimizar el impacto tanto en el equipo como en la
percepción de los clientes.
Se creó un equipo de trabajo de 3 personas y se montó la infraestructura necesaria

para permitir el trabajo en equipo. Al tratarse de una empresa de desarrollo, esto implicaba
dotar al departamento de un repositorio de código que controlase el acceso simultáneo de
varios miembros del equipo a un mismo recurso.
Se realizó un trabajo inicial que consistía en analizar los proyectos en los que estaban
implicadas estas tres personas para crear un artefacto parecido a un Product Backlog con
todas las tareas pendientes. Ya con una visión general del trabajo que tenían que realizar, se
sentaron a priorizar las distintas tareas, dividirlas en distintas subtareas y asignarles una
estimación de tiempo.
En cuanto a las reuniones de scrum, aparte de este Sprint Planning a gran escala, se
comprometieron a realizar el Daily Scrum. Este simple hecho ya supuso un avance
considerable en su metodología de trabajo, ya que pasaron del desconocimiento absoluto del
trabajo de otros compañeros y el trabajo individual y sin ayuda a conocer diariamente el
trabajo de los demás y a interactuar con otros miembros, sobre todo en el caso de aparición de
problemas. A pesar de que suena sencillo, en ocasiones lo más difícil es disponer del momento
para exponer tus problemas y dar la oportunidad a otros compañeros a tomar el relevo.

Una vez consideraron que el equipo inicial era lo suficientemente estable con un grupo
reducido de personas, empezaron a ampliarlo para comprobar que la metodología no se
resentía con un equipo de trabajo de tamaño considerable.
Para realizar esta ampliación, lo primero que tuvieron que hacer es convencer a los
nuevos miembros de la utilidad de la metodología. Esto se convertía en un ensayo de cómo
vender scrum a un cliente, solo que hablando con perfiles técnicos como los suyos.
Hicieron una presentación mostrando los actuales planes de gestión que se llevaban a
cabo en su departamento y pidieron que, por favor, expusiesen los puntos positivos y
negativos que ellos veían. Lógicamente, al estar trabajando en la misma empresa, los negativos
coincidían con aquellos que les había llevado a ellos a probar con una metodología ágil.
Expusieron entonces cómo scrum había dado solución a esos problemas que ellos
también encontraron en su momento e hicieron una presentación de cómo creían que el
departamento podía reorganizarse utilizando una metodología ágil (aparte del uso de
herramientas de control de código y de trabajo en equipo).
El departamento al completo estaba ilusionado con la posibilidad de una nueva

manera de trabajar más eficiente, de modo que poco a poco todos se implicaron en el uso de
scrum como metodología de trabajo.
Al principio y puesto que la persona más reticente al cambio era precisamente el jefe
de departamento, se centraron en la división del trabajo en historias, tareas, etc., en las
reuniones diarias y en la retrospectiva.
Cuando su jefe notó que el trabajo avanzaba de manera más organizada e incluso que
el ambiente en el equipo mejoraba, decidió implicarse más y tomar un papel importante en la
definición de los artefactos y en las planificaciones de los sprint.
 Conclusión
De esta manera se consigue que todo el departamento esté trabajando con scrum. Su
productividad se ha visto incrementada notablemente, si bien siguen lidiando con algunos
problemas, como trasladar a sus clientes el nuevo modelo de trabajo o incluso a sus miembros
directivos.

2.4.4. EXPERIENCIA POSITIVA (COMENZANDO POR LA DIRECCIÓN)
 Introducción
Considero muy positivo plantear un caso desde la otra perspectiva mencionada en el

tema de cómo implantar scrum: convencer primero a la directiva y luego trasladar la
propuesta al equipo.
En este caso, el primer paso adoptado por el responsable del cambio fue certificarse
como Scrum Master para tener todo el conocimiento necesario para informar a sus superiores
e instruir al equipo en el cambio (recordad el tema de pasos a seguir para instaurar scrum en
una empresa, donde se indicó que uno de los pasos más importantes es formarse
adecuadamente).
Nota: se podrá observar además cómo muchos de los problemas que se encuentran en
este ejemplo y en el anterior son comunes y las soluciones, sin embargo, distintas.
 Antecedentes
En el caso de esta empresa, el problema se basaba en un tema de productividad. El

equipo estaba contento con la metodología de trabajo, sobre todo porque se sentía cómodo
con ella debido a los años de experiencia utilizando metodologías tradicionales.
Sin embargo, según ibas escalando en la jerarquía de la empresa, te ibas dando cuenta
de que la mentalidad cambiaba, puesto que la productividad no se ajustaba a lo deseado.
Fue entonces cuando uno de los jefes de proyecto se planteó el uso de las
metodologías ágiles.
 La implementación
Ya hemos comentado que ningún cambio es sencillo y mucho menos cuando implica
modificar metodologías de trabajo, que pese a que puedan estar obsoletas o no se ajusten a
las necesidades de la empresa en un momento dado, han sido utilizadas durante mucho
tiempo produciendo resultados positivos durante un intervalo considerable de tiempo.
En ese caso y sobre todo si el equipo no es consciente de los detalles económicos de

los proyectos (con lo cual piensan que como el trabajo acaba saliendo todo está bien), lo mejor
es buscar como primer aliado para el cambio a la gente de arriba, a la que mira los resultados
en términos de productividad.

Aunque a priori se pueda pensar que lo complicado es convencer a aquel que tiene
que cambiar su rutina del día a día al introducir una nueva metodología, en muchas ocasiones
es mucho más difícil convencer a aquellos a los que el cambio no afecta (al menos a nivel
operativo). Más aún si no se tiene una prueba que ofrezca cierta garantía de que el cambio va
a funcionar, como pasaba en el ejemplo anteriormente visto.
El primer paso, por tanto, fue formarse para tener los conocimientos que se
traducirían en argumentos necesarios para convencer a la directiva de la empresa de que el
riesgo de la transición merecía la pena y que, si bien al principio los resultados podrían no ser
del todo visibles, a la larga lo que ofrecía Scrum era productividad en el trabajo del equipo. Esa
formación consistió en obtener la certificación de Scrum Master.
Tras una serie de exposiciones con los pros, los contras, los riesgos y un primer boceto
de road map para el cambio, el siguiente objetivo era encontrar gente dentro de los equipos
que compartiese el optimismo por el cambio.
De nuevo se optó por un cambio top-down, es decir, empezar por los responsables
para terminar por los que ocuparían el rol de miembros del equipo.
Se convocó a todos los jefes de equipo del departamento, se les planteó la cuestión y
se les ofreció una formación para ejercer el rol de Scrum Master en los distintos equipos que
se conformarían. Por fortuna, la exposición de la metodología y la oportunidad de ser formado
en algo novedoso fue suficiente para que todos lo aceptasen con entusiasmo.
Sin embargo, tras finalizar la formación, ellos mismos fueron conscientes de que el
cambio no iba a ser sencillo. Harían falta nuevas rutinas, nuevos mecanismos, nuevas
herramientas… incluso nueva documentación que no tenía nada que ver con lo que se venía
usando hasta el momento. Era casi como empezar de cero.
El siguiente paso era quizás el más temido. Era el momento de convencer al equipo. Y
en este caso no hablaban de un grupo reducido de gente, sino de una plantilla que ya de por sí
se dividía en diferentes equipos de trabajo de tamaño considerable.
Se les expuso en una sesión las nociones básicas de la metodología, sus ventajas
(haciendo especial hincapié en aquellas relacionadas con la gestión del equipo), un road map
de los pasos a seguir para implantar la metodología. También se les hizo ver la confianza que la
directiva había depositado en el cambio, los motivos que les había movido a ellos y la
responsabilidad que recaía en el equipo de que todo funcionase.
Era importante que supiesen que la migración sin su colaboración era imposible y que,
a pesar de los inconvenientes que cualquier cambio supone, los primeros beneficiados serían
ellos, tanto por la calidad de su trabajo como por la nueva manera de gestionarse.

Además de la presentación, se preparó documentación que se puso a su disposición y

aquellos que habían recibido formación se ofrecieron a responderles cualquier duda o
inquietud que les pudiese surgir.
Por otro lado, se les pidió que también devolviesen un feedback de las sensaciones que
el cambio producía en ellos y expusiesen todas aquellas ideas y mejoras que creían serían
positivas para el periodo de transición.
 Puesta en marcha
Sin embargo, el mayor cambio que tenía que llevar a cabo el equipo no era el más
evidente cuando se empieza a trabajar con scrum, que suele ser el hecho de que el equipo se
autoorganice, era algo todavía más básico: trabajar en equipo.
Hasta ese momento, la estructura de la empresa, como la de tantas otras dedicadas al

desarrollo de oftware y sobre todo en aquellas con cierta envergadura organizativa, consistía
en una división por departamentos que diferenciaban claramente cada fase del desarrollo de
un proyecto: por un lado estaban los diseñadores, por otro los programadores, los
responsables de calidad, de pruebas, de experiencia de usuario, resolución de incidencias y
mantenimiento, etc.
El trabajo del día a día era más parecido a una cadena de montaje en una fábrica: el
proyecto pasa por un departamento, una vez han terminado pasa al siguiente, una vez han
terminado al siguiente y así sucesivamente hasta que se termina y se pone en producción.
Sin embargo, existe una diferencia fundamental con una cadena de montaje: en este
caso no se ensamblan copias de un mismo diseño o producto, sino que cada unidad que pasa
por la cadena es única e irrepetible… por tanto, tiene que ser probada en su totalidad para
darla por buena.
Ese era el punto que más invitaba a cambiar de metodología. El trabajo del primer
grupo podía necesitar ser cambiado mucho tiempo después de haber “terminado” el trabajo.
Lógicamente, ese grupo de gente no podía estar meses, ni semanas, ni días de brazos cruzados
esperando a que el resto terminasen su labor para saber si había terminado realmente el
producto, sino que cuando le volvía cualquier modificación, ya estaban inmersos en nuevos
proyectos, con sus planificaciones, sus tiempos, etc.
Encontrar un fallo en un proyecto implicaba retrasos no solo en ese mismo proyecto

(más retraso cuanto más cerca estaba el grupo que encontraba el error, del final de la cadena
de montaje, ya que implicaba volver a tener que pasar todos los pasos intermedios), sino
también en el proyecto en que se encontrasen inmersos en ese momento.

Muchas veces el intento de no asumir ese retraso hacía que se instalasen productos
con deficiencias detectadas en producción y se tratasen como bugs de mantenimiento. Esto no
beneficiaba en absoluto a la empresa, ya que dejaba en entredicho uno de los valores de
nuestra empresa más importantes en el mercado: la calidad.
Por tanto, lo que se hizo fue fundir todos esos distintos departamentos en uno solo y
dividir a la gente en equipos multidisciplinares. No era una idea descabellada. Scrum abogaba
por equipos heterogéneos con expertos en todas las áreas necesarias y eso precisamente es lo
que teníamos.
Así, nuestros equipos estarían formados mínimo por un miembro de cada

departamento (siempre había más desarrolladores que otros perfiles). Lo mejor de todo es que
los productos empezarían a trabajarse de manera que todos sus diferentes aspectos (diseño,
implementación, pruebas, etc.) se paralelizarían.
La definición de “hecho” implicaba que todos los miembros hubiesen realizado su

trabajo en el producto y, por tanto, este se ajustase a lo esperado en diseño, implementación,
experiencia de usuario y calidad entre otros requisitos. Las entregas a cliente serían desde
entonces de un producto realmente acabado.
Lo que resultó más difícil de llevar todo esto a cabo fue sacar a los miembros del
equipo con más antigüedad de la comodidad que suponía para ellos hacer “el trabajo de
siempre” y comenzar a realizar labores que hasta entonces realizaba gente de otro
departamento ajeno, ya que, lógicamente, ni el tester podía estar de brazos cruzados hasta
que el resto del equipo desarrollase algo que poder probar, ni el desarrollador podía quedarse
parado mientras el tester probaba su trabajo.
Poco a poco, aunque con más resistencia al principio, todos los miembros del equipo
sabían hacer de todo, aunque por supuesto cada uno tenía su especialidad y la explotaba
siempre que le era posible, en beneficio no solo propio, sino del equipo entero.
Al existir varios equipos, se vio necesaria también la figura de múltiples Scrum Master,
que, como antes se comentó, ya se tenía pensado que fuesen los distintos jefes de proyecto.
De esta manera, ningún equipo se sentiría desatendido, ya que al hacer un cambio tan
grande y no progresivo (recordad que al principio de la clase hemos visto que lo recomendable
es empezar por un pequeño proyecto piloto y después escalarlo al resto de proyectos) un solo
Scrum Master tenía altas probabilidades de sentirse desbordado.
Para el rol de Product Owner se barajó la posibilidad de contratar a una nueva persona
con experiencia de Business Analyst, pero como una de las grandes preocupaciones iniciales
era los posibles problemas de comunicación entre equipo y Product Owner, la decisión final
fue que el jefe de proyecto precursor del cambio ocuparía ese rol de inicio y más adelante se
irían incluyendo nuevos Product Owners.

En relación a la confianza, también resultó complicado al principio una de las

reuniones más críticas para el buen funcionamiento de Scrum y del equipo en particular: el
Sprint Retrospective.
Al principio los desajustes eran considerables y el hecho de que los miembros de los
equipos trabajasen en todo y no solo en su especialidad llevaba a que, en la retrospectiva, se
señalase esa falta de experiencia como motivo de retrasos o errores.
Sin embargo, esta crítica sirvió para que el equipo poco a poco aprendiese a organizar
las historias de manera que se minimizaba en la medida de lo posible el tiempo que una
persona trabajaba en algo en lo que no estuviese especializado.
Es difícil y largo de contar, pero trabajando en dos historias al mismo tiempo (pese a
que el objetivo debe ser que todo el equipo trabaje en paralelo en una sola) conseguían que
mientras los diseñadores trabajaban en una historia, los desarrolladores desarrollaban otra
que no requería diseño, los testers iban preparando las pruebas de esa historia, etc.
 El resultado
Tras dos años de uso de la metodología, los avances fueron notables. La directiva se
mostraba satisfecha, ya que los tiempos de entrega no solo se ajustaban más a lo estimado al
principio de los proyectos, sino que se habían reducido notablemente.
Se dieron cuenta de que, sobre todo en las finalizaciones de los proyectos, había
espacios de inactividad de varios de los antiguos departamentos en espera de resultados, y
que por tanto la productividad se veía afectada más de lo que se pensaba en ese momento.
Los equipos en general también estaban contentos. Su ritmo de trabajo se había

intensificado, ya que Scrum es una metodología muy dinámica y continúa, no da mucho
margen a relajarse, pero sin embargo la satisfacción por el trabajo realizado era compensación
más que suficiente.
Ahora no veían el producto como un objeto que pasa por sus manos durante un
tiempo para pasárselo a otro grupo que continuase con él. Ahora el producto era “su”
producto, de principio a fin. Veían su evolución desde que se iniciaba hasta que se entregaba al
cliente, y gracias a la Demos de fin de Sprint, podía ver incluso la satisfacción del cliente una
vez entregado.
Pero no todo fue tan fácil y tan ideal como puede parecer. También a lo largo de los
dos años surgieron problemas y se tuvo que dar marcha atrás en algunos de los pasos dados.

El departamento de arquitectura de software nunca llegó a conseguir integrarse

dentro de los equipos. En realidad, ellos veían que su labor terminaba en el momento en que
el equipo cogía la historia, ya que las tecnologías y el grueso del diseño de arquitectura debían
estar hechos antes de que se abordase la misma, y por tanto debían trabajar con un Sprint de
antelación.
Finalmente ese departamento se restableció como independiente, aunque siguieron

vinculados a la metodología, solo que en lugar de trabajar con el equipo, trabajan con el
Product Owner a la hora de confeccionar las historias y dotan al equipo de un diseño a alto
nivel con el que empezar a trabajar.
El otro punto pendiente fueron los clientes. No todos estaban dispuestos a modificar
su metodología de trabajo, si bien el hecho de tener el Product Owner una ventanilla única con
la empresa sí les parecía un buen cambio.
En esos casos, el Product Owner ocupa también el rol de cliente, lo cual hace perder el
beneficio de que al realizar la entrega, puedan surgir pegas que se traducen en cambios y estos
en consecuentes desviaciones en la planificación inicial.
Pero la semilla estaba ya puesta y, pese a que los problemas seguían existiendo, como
en cualquier empresa y trabajo, la mejora conseguida avalaba el cambio de metodología.
2.4.5. SCRUM MULTI-SITE
En muchos casos, sobre todo en empresas de gran envergadura, el trabajo no es

realizado por un solo departamento, sino que sacar adelante el proyecto conlleva la
coordinación de gente de distintos ámbitos, departamentos y, en no pocas ocasiones, incluso
de diferentes localizaciones.
Imaginemos, por ejemplo, una empresa de zapatillas de deporte desarrollando un

nuevo modelo (producto). Quiere que ese modelo sea diseñado en base a las líneas de la
marca, que sea cómoda y que ofrezca propiedades aerodinámicas para su uso en deportes de
élite.
Al fin y al cabo, lo que vamos a necesitar es un equipo de trabajo con especialistas en

diseño, con especialistas en calzado y con especialistas en aerodinámica o física, es decir, un
equipo multifuncional.
Hasta aquí no habría gran problema, ya que en eso consiste un equipo de scrum, ¿no?
Sin embargo, como se ha comentado antes, esta empresa es muy grande y su departamento
de marketing y diseño se ubica en Barcelona, el de calzado en Madrid y para el de
aerodinámica ni siquiera disponen de un departamento, sino que han subcontratado a dos
especialistas freelance que trabajan en EEUU.

El traslado a un punto común no es viable, de manera que se plantean dos opciones:
 Trabajar de manera independiente e iterativa: trazar un plan mediante el cual uno

de los equipos realiza su trabajo, se lo pasa a otro equipo que lo adapta a su
ámbito, este al tercer equipo y de este al primero para comprobar que nada ha
cambiado (o al menos no de manera equivocada).
 Trabajar con Scrum Multi-site: crear solo grupo de personas con todos esos
miembros y dotarles de las herramientas que les permita trabajar como un
auténtico equipo.
Los inconvenientes que se pueden encontrar en el Scrum multi-site se reducen al final

a un factor común: la comunicación. El hecho de estar separados físicamente dificulta
notablemente la aplicación de la metodología.
Los principales problemas que podemos encontrar son:
Scrum Master como facilitador
El hecho de que existan dos localizaciones o más diferentes puede dificultar la tarea
del Scrum Master en aquella en la que no esté ubicado físicamente.
Muchos de los problemas que pueden surgir a lo largo de un sprint son de carácter
meramente técnico o burocrático (no tengo acceso a un servidor que necesito, no me funciona
el ordenador, no tengo permisos para acceder a una información clasificada, etc.) y requieren
de una intervención personal por parte del Scrum Master que puede verse ralentizada o
impedida si no se encuentra en la localización donde surge el problema. Esto se puede arreglar
mediante un sencillo desplazamiento, pero, dependiendo de las distancias entre localizaciones,
podría suponer una gran pérdida de tiempo (bloqueos excesivamente largos).
La solución que se le suele dar a este problema es la existencia de más de un Scrum

Master, idealmente uno por localización. Sin embargo, para que el trabajo en equipo entre los
miembros de todas las localizaciones no se vea resentida, es muy importante asegurar una
gran coordinación entre Scrum Masters. Para ello se introduce una nueva reunión en el ciclo
de vida de Scrum: el Scrum de Scrums.
Esta reunión tendrá lugar mínimo dos veces a lo largo del sprint, una al comienzo y
otra a mitad del mismo, si bien lo ideal es que se celebre a diario tras el daily sprint de manera
que todos los Scrum Masters puedan compartir los distintos bloqueos surgidos en las
diferentes localizaciones.

A esta reunión únicamente asistirán los diferentes Scrum Masters y aquellas personas
que ellos consideren necesarias en cada reunión para dar solución a los distintos bloqueos
surgidos.
Scrum Board
Cuando se ha hablado de la Scrum board con anterioridad, se ha hecho mención a la

misma como un artefacto físico a la vista de todo el equipo con tarjetas pegadas que reflejen el
estado del sprint en cada momento.
Sin embargo, en equipos con miembros en distintas localizaciones es evidente que no

se puede disponer de una pizarra física a la que todo el mundo tenga acceso permanente, ni a
la vista de todos.
Para este problema la solución pasa por saltarse una de las características
fundamentales de la Scrum Board: que sea una pizarra física.
En muchas empresas a cambio se utiliza un fichero Excel donde se colocan todas las
historias y tareas a modo de pizarra. Esto es poco recomendable ya que este tipo de ficheros
suelen tener un modo de escritura no simultáneo.
La mejor alternativa es utilizar una Scrum Board virtual. Esto son pizarras de scrum
creadas en aplicaciones o portales web que permiten el acceso simultáneo a varias personas y
cuyo aspecto se ajusta exactamente al de una Scrum Board física (siendo muchas de ellas
configurables). Una alternativa gratuita sería por ejemplo SeeNowDo:

Comunicación en el día a día
Uno de los principios básicos de scrum dice que la comunicación entre los miembros
del proyecto (especialmente los miembros del equipo entre sí y con el Product Owner) debe
ser directa y constante.
Cuando se trabaja con equipos en distintas localizaciones, esta comunicación puede

verse resentida, ya que tratar un tema con otra persona no se reduce a levantarse y preguntar.
En muchas empresas con esta situación se tiende a utilizar el correo electrónico como
alternativa de comunicación. Sin embargo, no es un medio recomendable, ya que, si bien deja
una constancia de las conversaciones mantenidas, produce grandes retrasos al dejar a una
persona en espera de una respuesta. Esto se acusa especialmente cuando la comunicación se
quiere establecer con el Product Owner, que, además de resolver dudas a los miembros del
equipo, tiene otras tareas que podría considerar prioritarias dejando para el final el contestar a
los correos.
Como alternativa os propongo el uso de herramientas de comunicación instantánea

como puede ser Skype, que además te ofrece la posibilidad de realizar llamadas,
videollamadas y chats, lo cual agiliza la comunicación y proporciona un contacto más personal
entre los miembros del proyecto.

Reuniones
Muy relacionadas con el punto anterior se encuentran las reuniones propias de la

metodología.
En el caso del Daily Scrum, el hecho de que la hora sea fija e inamovible toma especial
importancia. Al igual que se ha dicho antes, se recomienda una herramienta de
videoconferencia para mantener dicha reunión, ya que cualquier otro método podría alargar la
reunión a más de los 15 minutos recomendados.
En caso de que no se puedan cuadrar los horarios (imaginemos un equipo con dos
localizaciones, una en Europa y otra en Sudamérica, la diferencia horaria es muy grande),
tendríamos que volver al concepto de un Scrum Master por localización y una reunión entre
ellos para poner en común lo hablado en cada sitio.
En cuanto al resto de reuniones, la demo es la que menos problemas debería

ocasionar, ya que una de las alternativas más utilizadas para no ocasionar problemas a los
clientes es la de realizarla por videoconferencia, luego teniendo un sistema que permita más
de dos conferenciantes, la diferencia con un equipo multi-site es mínima.
Una opción, aunque no es gratuita, es GoToMeeting, que ofrece la posibilidad de

conectar a varios conferenciantes al mismo tiempo, pudiendo dar el mando a uno de ellos para
que comparta su escritorio y gestione los turnos de intervención (ambas cosas muy útiles para
las presentaciones, demos y turnos de preguntas de los clientes):

La Scrum Retrospective sí es recomendable realizarla conjuntamente mediante

videoconferencia, ya que puede resultar muy enriquecedor para los equipos conocer los
problemas y mejoras que el resto de localizaciones ha sufrido a lo largo del Sprint. Sin
embargo, esto solo se podrá hacer cuando los miembros de las distintas localizaciones tengan
una relación de confianza entre ellos.
Si hubiese poca confianza, podría coartar a la gente y eso restaría sentido a la reunión.
Ni que decir tiene que sería aún peor si surgiese una alta competitividad entre las distintas
localizaciones, ya que nadie expondría sus problemas ni puntos de mejora para no
“debilitarse” ante los demás.
Para fortalecer los vínculos entre distintas localizaciones, una recomendación (siempre
que el presupuesto lo permita) es realizar las tres reuniones de fin/comienzo de Sprint
conjuntamente en una misma localización, de modo que todos los miembros del equipo
presenten su trabajo y expongan sus problemas como uno solo.

En el caso del Sprint Planning, depende un poco de la organización del equipo si debe
realizarse de manera conjunta o separada:
 Sí, pese a la separación, las historias se desarrollan implicando a gente de varias

localizaciones, el compromiso del trabajo a realizar debe ser conjunto.
 Si, por lo contrario, la tendencia es a que cada localización se “especializa” en un

área determinada y su interacción es casual, quizás es conveniente realizarlo
separadamente para no alargar la reunión más de lo recomendable.
 Si observamos los distintos problemas, todos se reducen a un denominador común:

la comunicación. No hay que olvidar tampoco otros posibles factores como las
diferencias horarias que ya hemos comentado, ya que trabajar en las mismas
historias con diferentes horarios de trabajo dificulta la paralelización y dificulta
apoyarse en el equipo para resolver dudas o desenquistar tareas que se complican.

3. Gestión de Proyectos Ágiles con Kanban y XP
3.1. Kanban I. WIP, processos pull y flujo
3.1.1. ¿QUÉ ES KANBAN?
Kanban es una palabra de origen japonés que incluye los conceptos de tarjeta o
identificador visual y de tablero, que son los dos elementos (o artefactos) básicos que dan
soporte a la forma de trabajo de Kanban.
A modo introductorio, veréis que en cualquier cadena de producción que utiliza

kanban, cada contenedor (ya sea de materia prima, subproductos intermedios o producto
final) lleva asociada una tarjeta. Cuando un contenedor es consumido, su tarjeta se lleva al
tablero y se convierte en el indicador visual de la necesidad de un nuevo contenedor de este
tipo. Este proceso genera una demanda desde el final de la cadena hacia el principio que
caracteriza esta forma de trabajo. Kanban es un sistema pull, esto es, es el final de la cadena
(el cliente) el que inicia todo el proceso de producción y reabastecimiento. Veamos esto con
más detenimiento.
 Pull vs push
Tradicionalmente, una empresa de producción intentaba determinar la demanda de su

producto y, en base a eso, planificaba la producción. De esta forma, por ejemplo, si una
empresa preveía la venta de 100 unidades de su producto, en los próximos 3 meses ponía en
producción esas 100 unidades y por tanto la producción estaba dirigida desde arriba, desde los
órganos decisores de la empresa.
El mayor problema de este esquema, aunque no el único, es que se adapta mal a los
cambios en la demanda. Siguiendo el ejemplo anterior, si la demanda baja un 50%, tendremos
50 unidades almacenadas con los costes que esto pueda conllevar.

Toyota, en la búsqueda de una optimización de stocks y el almacenamiento así como

de la reducción del gasto en materiales y mano de obra, se inspiró en cómo los supermercados
realizan sus procesos de estocaje.
En un supermercado, cada producto tiene asignado en el lineal un sitio y un espacio,

pongamos 5 unidades de un producto concreto. Cuando uno o varios clientes retiran producto
del lineal dejan huecos, estos huecos han de ser rellenados y por tanto los reponedores irán al
almacén en busca de producto. A su vez, estos productos retirados del almacén dejan sus
huecos, que han de ser rellenados (simplificando mucho) por producto procedente de un
almacén central y así sucesivamente. Como vemos en este sistema, es el final de la cadena el
que tira (pull) cuando un cliente retira un producto del lineal. La propia limitación de espacio
del lineal hace de cuello de botella, nunca habrá más producto del que cabe y por tanto un
modelo push no tendría sentido.
Ahora visualicemos este proceso de otra manera. Imaginemos que cada paquete de
cereales tiene adherida una tarjeta y de igual manera el ketchup y la carne picada. Cuando
llegamos a la caja el cajero recoge estas tarjetas y las coloca en un tablero de tal manera que el
reponedor solo tiene que acercarse al tablero, recoger las tarjetas e ir al almacén para reponer
tantas unidades de cada tipo de producto como tarjetas tenga en su poder. Ya tenemos un
sistema de reabastecimiento pull basado en un tablero Kanban.
En la figura que encontraremos unos párrafos más adelante, podemos ver este
proceso de manera esquemática en una imagen de Toyota. También en este vídeo podéis ver
estos conceptos de una manera muy ilustrativa (aunque le falte un poco de ritmo al vídeo).
Adelantémonos un poco al temario para sacarle el mayor partido al ejemplo:

supongamos que el reponedor puede llegar a cargar un número indeterminado de productos
en un viaje al almacén pero que a partir de diez productos sabemos que la “calidad” del viaje
empeora:

Tarda mucho
Se le caen productos
Se deterioran los productos por exceso de peso
Si establecemos una política de número máximo de productos que transportar a la vez

a ocho, con total seguridad los lineales serán rellenados con mayor frecuencia y de una
manera más satisfactoria para el cliente final. Habríamos limitado el “Work in Progress”.
 Limitando el Work In Progress
Limitar el trabajo en curso (work in progress) es uno los principios básicos de Kanban y
es el punto de partida de cualquier implementación de esta metodología en un proyecto, ya
que el propio hecho de limitar el WIP estructura el flujo y hace que la metodología pull tenga
sentido. Limitando el número de elementos en los que se trabaja de manera simultánea
aparecen las colas de elementos pendientes, cuando un elemento es finalizado se tira de un
elemento que se encuentre en la cola y de esta manera se va creando una cadena o flujo de
elementos de producción a través del sistema.
Limitando el número máximo de elementos simultáneos en los que estamos

trabajando también estamos creando el concepto de hueco o slot de producción. Si definimos
que en una fase concreta del proceso productivo no puede haber más de tres elementos a la
vez, y en un momento dado tenemos dos, existe un hueco o slot libre. Si no existiera este
concepto no tendríamos ningún indicador de cuándo estamos en disposición de aceptar una
nueva orden de producción de las que tenemos en cola o podríamos pasar todas a la vez

perdiendo todo el valor de Kanban. Son los huecos los que provocan el avance de las tareas
por el sistema.
Por tanto, cuando hablamos de limitar el WIP o trabajo en curso estamos hablando de
establecer un límite numérico de elementos máximos en los que podemos trabajar en un
momento dado.
Son muchos los beneficios que se derivan del simple hecho de limitar el número de
elementos en los que estamos trabajando en un momento determinado:
 Mantenemos el foco: en nuestro día a día en la oficina o en la fábrica tendemos a

estar “a mil cosas”. Esto es tan cierto para un administrativo como para un
desarrollador de software o para alguien de comunicación. Preparar los contenidos
para la nueva web, seleccionar material fotográfico para una nota de prensa,
prestar atención a las redes sociales, acabar ese post del blog, finalizar el montaje
de ciertos elementos... Son tantas las tareas con las que queremos avanzar que
vamos saltando de una a otra sin avanzar realmente con ninguna de ellas. Son esos
días en los que te quedas con la sensación de haber trabajado mucho pero no
haber avanzado nada.
 Evitamos desperdicios de tiempo: más allá del hecho de que tener muchas cosas
abiertas nos impide focalizar bien, está el hecho de que cambiando de tarea se
pierde tiempo. Necesitamos colocar el espacio de trabajo (ya sea abrir un Word o
buscar unas tijeras), recuperar la información necesaria para llevar a cabo la tarea,
recordar por dónde íbamos, etc. Si tenemos mucho trabajo abierto a la vez iremos
cambiando mucho de tarea y perderemos mucho tiempo en estos saltos. Los
informáticos estudian esto mucho en la carrera y es tan válido para un ordenador
como para los seres humanos. Los ordenadores son multitarea pero no es tanto
que hagan muchas cosas a la vez como que cambian de tarea rápidamente. Puede
llegar a pasar que si le pedimos a un ordenador que cambie mucho de tareas (y
más si son pesadas) se pase tanto tiempo preparando el cambio de una a otra que
para cuando se va poner con ello ya tiene que cambiar a lo siguiente y no avanza. A
esto se le llama, hiperpaginación.
 Evitamos perder información importante: la cantidad de información que podemos
mantener en la cabeza en periodos cortos de tiempo es limitada. Por muy buenos
que seamos documentando nuestro trabajo, la mayor parte de la información
necesaria para llevar a cabo una tarea está en nuestra cabeza. Como queremos
abordar cierto presupuesto, los comentarios del cliente sobre una muestra que le
hemos entregado, ese párrafo de un documento que queríamos corregir, etc., cada
vez que saltamos de una cosa a otra almacenamos en nuestra cabeza un pequeño
montón de datos, con cada salto posterior guardamos un poco más, pero no nos
damos cuenta de que vamos perdiendo información. Cuando volvemos sobre la
tarea inicial nos encontramos una nota que dice: “corregir párrafo” o “comentar
con producción feedback del cliente” pero ya no recordamos cuál era el párrafo y
probablemente recordemos solo 3 de las 5 cosas que queríamos comentar con
producción. Lo que nos lleva directamente a la siguiente ventaja.
 Mejoramos la calidad de nuestro trabajo: si mantenemos el foco y estamos
centrados en un conjunto de tareas limitado, con la información de las mismas en
la cabeza, con total probabilidad el resultado de nuestro trabajo sea mejor, más

cercano a las especificaciones del mismo y con un menor número de defectos.

 Reaccionamos antes a problemas y bloqueos: estando a muchas cosas a la vez, si
en un momento determinado no podemos avanzar con una tarea pasamos a la
siguiente, y así sucesivamente. Si en todo lo que estamos haciendo encontramos
dificultades empezamos con algo nuevo. El número de tareas que pueden llegar a
estar bloqueadas porque requieren hablar con alguien, pedir cierta información,
etc., puede llegar a ser muy alto hasta el punto de bloquearnos. Muchas tareas se
retrasan indefinidamente olvidadas al final de una lista de tareas. El límite del WIP
nos empuja a resolver los bloqueos. Si en la fase de presupuestación tenemos un
límite de 2 y se nos bloquea un presupuesto, a falta del precio de una subcontrata
pasaremos al siguiente, si se nos bloquea también tendremos necesariamente que
solucionar uno de los bloqueos para no quedarnos parados. Si tenemos un
elemento bloqueado mucho tiempo en la columna nos va a consumir un hueco de
manera constante reduciendo nuestro WIP real a 1 y esto nos va a forzar a querer
liberar el bloqueo para recuperar un flujo normal.
 Conseguimos una cadencia de entrega predecible: este punto es clave y
volveremos mucho sobre él. Como hemos visto, limitando el WIP evitamos que se
nos queden tareas aparcadas. La tareas van saliendo adelante de una manera
ordenada siguiendo nuestras políticas a la hora de seleccionar las nuevas tareas a
realizar. Si esto es así veremos cómo la desviación típica sobre el tiempo medio
que una tarea está dentro de nuestro tablero es cada vez menor. Dicho así puede
sonar complejo, lo que queremos decir es que cada vez nos será más fácil predecir
cuánto tiempo tarda un elemento en discurrir por toda nuestra cadena de valor (su
tiempo de entrega o lead time) y cuánto tiempo pasa desde que empezamos
verdaderamente a trabajar en él hasta que lo acabamos (cycle time). Conocer estos
tiempos nos va a permitir hacer el ajuste fino de nuestra implementación de
Kanban. Llegaremos a eso.
 Ponemos de manifiesto los cuellos de botella: de manera natural, en las fases de
trabajo inmediatamente anteriores a un proceso que se ha convertido en un cuello
de botella, tendremos siempre la mayor parte del tiempo en espera o haciendo
cola. No habrá pull desde esa fase y, por tanto, no se liberarán huecos que nos
permitan meter más trabajo.

3.1.2. LEAN MANUFACTURING: KANBAN, JIT, KAIZEN Y OTRAS HIERBAS
El vocabulario, la terminología y los conceptos concernientes a esta nueva forma de

trabajo en la fábricas es muy rico y extenso y llevaría un libro entero explicar cada uno de ellos
en profundidad: JIT, Jidoka, Heijunka, Kaizen, las 5 s’s, SMED... Nuestro objetivo en este punto
no es entender cada uno de ellos por separado sino extraer de ellos la motivación subyacente,
que no es más que aumentar el VALOR de proceso de producción para todos los stakeholders
involucrados, o lo que es lo mismo:
 Para los clientes: se busca entregar la máxima calidad en el menor tiempo posible
con la mayor capacidad de reacción y con el coste más ajustado.
 Para la empresa: reducir costes, reducir despilfarros, mejorar el espacio de trabajo,
mejorar la capacidad de respuesta...
Para ello, lean manufacturing se centra en un serie de principios que a su vez tendrán
su traducción a conceptos más definidos en cada una de las áreas de aplicación dentro del
flujo de producción:
 Perseguir la perfección: se traduce en la búsqueda de la entrega al cliente de

productos con cero defectos y la filosofía Kaizen de mejora continua que es base de
todo el lean manufacturing de manera generalizada.
 Eliminar el despilfarro: son muchos los tipos de despilfarro que se busca reducir.
Sobreproducción, tiempo de espera, transporte, exceso de procesado, inventario,
movimientos, defectos, potencial humano subutilizado.
 Procesos pull: es el cliente el que guía la producción desde el final de la cadena de
valor tirando de la producción. Esto permite reducir muchos costes innecesarios
pero no solo eso. Como veremos más adelante, esta forma de enfocar la
producción (tanto en la fábrica como la gestión de proyectos) genera la necesidad
de un ecosistema adaptable, flexible, ágil y bien engrasado. Esta forma de producir
nos ayudará a identificar aquellos aspectos de nuestro proceso que necesitamos
mejorar para ofrecer la entrega de valor que demandan nuestros clientes o de
manera generalizada aquellos que están al final de nuestra cadena de valor
(downstream).

Para ello, lean manufacturing se apoya en dos grandes pilares que veremos muy
brevemente, por ser referencias obligadas:
 JIT (just in time o “justo a tiempo): debemos entender JIT como el resultado de un
proceso (largo) de búsqueda de la mejora constante dentro de la fábricas de
Toyota. Se trata de un conjunto de principios que rigen la producción, la relación
con los proveedores, la forma de distribuir la plantas, la adaptación de las
máquinas, etc. Taiichi Ohno (creador de JIT) dice: “Al intentar aplicarlo, se
pusieron de manifiesto una serie de problemas. A medida que estos se aclaraban,
me indicaban la dirección del siguiente movimiento. Creo que solo mirando hacia
atrás somos capaces de entender cómo finalmente las piezas terminaron
encajando”.
 Jidoka: este concepto nos habla de automatización pero con un toque humano. La
revolución de este concepto no está en el qué sino en el cómo. Jidoka nos habla
de evitar la propagación de errores a lo largo de la cadena de producción de tal
forma que, si se detecta un error, se para de producir (cualquier persona en
cualquier parte del proceso), se subsana, se estudia, se busca su origen y se vuelve
a empezar. El objetivo es que el propio proceso de mejora en la automatización,
nos lleve a contar con máquinas Poka-Yoke (máquinas que detectan o ayudan
evitar los errores en la producción).
A su vez, estos dos pilares se asientan sobre otra serie de pilares más pequeños (unos
procedimentales, otros conceptuales) que hacen de cimientos la estructura de lean
manufacturing.

Hay muchísima información disponible, tanto a nivel editorial como en la red, sobre
estos conceptos, así que os dejo dos títulos de referencia: The Toyota Way y Toyota Production
System: Beyond Large-Scale Production de Taiichi Ohno.
Os recomiendo cotillear un poco cada uno de ellos prestando especial atención a

Kaizen por su interés y porque de alguna manera el concepto de mejora continua es que el que
ha llevado a todas las metodologías ágiles a convertirse en las herramientas que son hoy en
día. Esta pulsión de la mejora continua mantiene en permanente revisión cada uno de los
procesos de las metodologías ágiles que usamos muchísimas empresas y profesionales
alrededor del mundo y seguirá aportando nuevas y mejores herramientas.
Seguiremos ahora con Kanban, pero saliendo ya de las plantas de producción. A partir
de ahora subiremos a las oficinas de Microsoft, Yahoo, Google o la mía misma, para ver cómo
todos estos conceptos nos pueden ayudar en nuestras startups, en nuestros proyectos, en
nuestros grupos de trabajo o incluso en nuestro día a día más personal para conseguir lo
mismo que busca lean manufacturing, mayor calidad con un mejor aprovechamiento de los
recursos.
3.1.3. OTRA VEZ KANBAN
Desde que las metodologías ágiles hicieron su aparición son muchas las
aproximaciones que han ido tomando cuerpo: FDD, XP, Scrum, Kanban, etc., aunque todas
ellas comparten un espíritu común divergen en su enfoque, sus artefactos y sus prácticas.
Algunas son más complejas, más regladas, más estructuradas y otras son más adaptables, pero
nunca debemos olvidar que está en nuestra mano adaptar cualquiera de estas metodologías a
nuestras necesidades específicas. Dado que no hay dos empresas iguales, no hay dos maneras
iguales de implementar Scrum, XP y mucho menos Kanban.
A partir de ahora vamos a empezar a analizar Kanban desde el punto de la gestión de

equipos de producción y proyectos en entornos de oficina. Este flavour de Kanban nació en el
ámbito del desarrollo de software y gestión de equipos de IT, y sigue siendo en este campo
donde tiene una mayor acogida aunque, como ocurre con casi todas las metodologías ágiles,
su uso se está generalizando rápidamente y todo lo que contaremos aquí es igualmente
aplicable a equipos de ventas, marketing, recursos humanos, diseño y un etcétera cada vez
más amplio de equipos que aplican estas técnicas en la realización de sus tareas diarias.
Después de haber hablado de lean manufacturing creo que es importante aclarar que,
a pesar de sus similitudes procedimentales y conceptuales, Kanban no es una evolución del
anterior sino una metodología en sí misma. David J. Anderson fue el primero en llamar Kanban
(inspirados para las similitudes que encontró en los procesos pull) a la metodología con la que
estaba trabajando en sus equipos y proyectos. El origen de su trabajo estaba inspirado tanto
por el manifiesto por el desarrollo ágil de software como en la teoría de colas.

La teoría de colas es un área del conocimiento específica de las ciencias de la

computación con un gran impacto en informática, ya que se utiliza para optimizar infinidad de
procesos en los que una serie de actores o sistemas compiten por el uso de recursos (desde la
impresora hasta el propio procesador del ordenador). Es fácil hacer el símil entre el procesador
de nuestro ordenador y un trabajador de un equipo, ya que ambos pueden tener muchas
tareas pendientes que sacar adelante y una correcta gestión puede marcar una diferencia
radical en el aprovechamiento de los recursos.
Para mí es fundamental que conozcas en detalle el concepto de flujo en Kanban para

entender qué es lo que estamos buscando con esta metodología. Por eso, pararé brevemente
en él antes de empezar a estructurar los conceptos que dan cuerpo al proceso de Kanban.
 Entendiendo el concepto de flujo
De manera continuada abordamos más trabajo del que podemos afrontar a la vez. Esto
provoca colapsos que nos impiden sacar trabajo a la velocidad que somos capaces por las
dificultades de cambiar de tarea, recuperar la información que necesitamos para cada una de
ellas, colocar el espacio de trabajo, etc. Esto es aplicable de manera individual o a nivel de
equipo u organización. Kanban se basa en la idea de que centrándose en un número de tareas
determinado (limitando el WIP) podremos ser más efectivos en la finalización de las mismas y
mejoraremos el flujo. Si además optimizamos y equilibramos el cómo una tarea va pasando de
una unidad de producción a la siguiente poco a poco iremos localizando y aliviando los cuellos
de botella. Paso a paso iremos consiguiendo esa velocidad de crucero a la que (como en el
vídeo) las tareas van fluyendo sin entorpecerse unas a otras.
Cuando hablamos de flujo en este campo estamos hablando de ese “discurrir de

elementos” (partes de proyectos, historias de usuario, oportunidades de ventas o la redacción
de este mismo documento) desde que aparecen en el horizonte de cosas que tenemos que
hacer, hasta que las damos por cerradas. Por ejemplo, una oportunidad de ventas se puede
generar en una visita comercial de la fuerza de ventas de vuestra empresa, ser posteriormente
cualificada por el mismo u otro equipo, en un tercer paso analizada por un equipo técnico para
estudiar su viabilidad y finalmente firmada por el gerente de la empresa. Imaginemos esto
como una tarjeta que ha ido pasando por distintos equipos o personas dentro de la empresa.
Una de las analogías más claras que podemos usar cuando hablamos de flujos es el de
coches avanzando por carreteras. Un coche es una tarjeta que viaja por nuestra organización a
través de carreteras que son las distintas personas o equipos que la conforman. Si nuestro
equipo de analistas de software son una autopista de 5 carriles, muchas especificaciones
pasarán rápidamente por sus manos y fluirán a la siguiente carretera. Si nuestro equipo de
desarrollo es más bien una carretera regional, tendremos un atasco en el paso de una a la otra,
un cuello de botella. Por el contrario, si fuera al revés, nuestro equipo de desarrollo se pasaría
gran parte de su tiempo simplemente esperando trabajo. Cuando el tráfico se colapsa, la

velocidad de avance de los coches pasa a ser mucho menor que la velocidad marcada para esa
carretera por la dificultad de gestionar coches colapsados, acelerones y frenazos que impiden
que la circulación fluya.
Cuando introducimos Kanban, lo que estamos buscando es ajustar el flujo y encontrar

esa velocidad de crucero que hará que todos los coches avancen sin pararse por cada una de
nuestras carreteras hasta su destino. Os dejo este vídeo que ilustra mis palabras punto por
punto.
 Lead time y cycle time
Estas dos métricas describen nuestro flujo. Hemos de diferenciar el lead time (o
tiempo transcurrido desde que una tarea llega a nosotros hasta es entregada al cliente) del
cycle time (o tiempo que transcurre desde que empezamos a trabajar en ella, hasta que es
finalizada).
Por ejemplo, imaginad que somos una carpintería y un cliente hoy nos encarga un
aparador. Apuntamos la orden de trabajo y 4 días después empezamos a trabajar en el
aparador. 6 días después le llamamos para que venga a por él. Nuestro Lead Time ha sido de
10 días y nuestro Cycle Time ha sido de 6.
En Kanban, nuestro objetivo va a ser siempre conseguir reducir la variabilidad de

nuestro lead time al mínimo. Por ello, buscaremos equilibrar todos nuestros proceso, nuestros
límites de WIP, nuestras políticas, la forma de dividir el trabajo en tareas, optimizar nuestros
cuellos de botella, etc., para conseguir que nuestro lead time sea lo más constante posible.
Conociendo y confiando en nuestro lead time podremos planificar tanto nosotros como
nuestros clientes o upstream y generamos confianza nuestros stakeholders. Más adelante, en
el apartado de métricas, ahondaremos con detalle en el LT (lead time).

 El equipo en kanban
Decíamos al principio que Kanban impone muy pocos elementos y eso se traduce
también en los roles. Así como en Scrum teníamos al PO, el Scrum Master, etc., en Kanban no
tenemos ningún rol preestablecido. Por supuesto, esto no significa que pueda o deba haberlos,
pero no serán roles específicos de Kanban (por ejemplo, si antes de introducir Kanban en un
equipo de programadores existía un Jefe de equipo lo seguirá habiendo después de introducir
Kanban).
En cualquier caso, no olvidemos Kaizen y la mejora continua. En muchas ocasiones,

roles artificiales provocan gastos innecesarios. A modo de reflexion y cuando queráis aplicar
esta metodología en vuestros equipos, preguntaos si la existencia de este rol aporta algún
valor y recordad siempre que el lead time en una de nuestras grandes referencias a todos los
niveles en Kanban.
Otra gran diferencia entre Kanban y Scrum es la propia concepción del equipo:
 En Scrum buscamos equipos multifuncionales. Dentro de un sprint, la melé (scrum)

trabaja de manera conjunta de tal manera que (por lo menos en teoría) cada
miembro del equipo es capaz hacerse cargo de cualquiera de las tarjetas, por ello
el tablero no se subdivide por áreas de conocimiento.
 En Kanban los equipos se plantean de manera multidisciplinar. De esta manera,
distintos miembros del equipo aportan distintos conocimientos y por ello trabajan
en una misma tarea en momentos distintos. Esto hace que los tableros Kanban con
frecuencia suelen reflejar un mayor número de fases dentro del flujo de una tarea.
De esta manera podemos mezclar gente de experiencia de usuario o diseño gráfico
y programación dentro de un mismo equipo aunque su interacción sea en
momento diferentes del proceso. Por ejemplo, cuando una funcionalidad del
software que estamos desarrollando pase a producción es probable que primero
pase por una fase de análisis funcional, después de diseño UX, luego de diseño
gráfico y después de desarrollo y validación. Cada uno de estos pasos será
reflejado por una columna (o conjunto de ellas) dentro de nuestro tablero, como
veremos a continuación.
 Artefactos
Hasta ahora hemos hablado de Kanban aproximándonos desde conceptos teóricos o

casi filosóficos. A partir de ahora nos metemos en harina y empezaremos a ver qué significa
Kanban en el día a día y con qué elementos articularemos su implantación.
Las tarjetas
Veíamos en lean manufacturing que las tarjetas de producción eran indicadores de demanda
que iban en proceso ascendente desde el cliente o downstream hacia arriba en la producción.
Aquí las tarjetas toman otro enfoque, siguen siendo indicadores visuales de trabajo pero hacen

referencia a una tarea concreta que ha de ser producida y viajan de izquierda a derecha por el
tablero. Las tarjetas no viajan de un proceso al anterior, sino al revés.
No por ello el sistema deja de ser pull ni mucho menos. En nuestro tablero, lo que tira
de las tareas son los huecos en el WIP. Por ejemplo, si en la fase de desarrollo de un equipo de
producción de software hemos decidido limitar a 3 el número de funcionalidades que estamos
programando y finalizamos una, nos quedará un hueco que habremos de rellenar. Para ello,
iremos a la fase anterior (por ejemplo a análisis de funcionalidades) y buscaremos una tarjeta
que esté finalizada y lista para desarrollar. De esta manera no se empuja de una fase a otra, se
tira de ella cuando estamos listos para abordarla.
Una tarjeta Kanban incluye, al menos, un título o descripción corta de la tarea

(“Propuesta para Repsol”, “Formulario de búsqueda de vuelos”, “Reparación armario
almacén”, “Integración con Google Maps”, etc.). Esta descripción nos permite identificarla de
manera clara y unívoca en su contexto, lo que no implica que debamos redactar la tarea con
toda la información necesaria para realizarla, sino que debemos poder identificarla
claramente. Desde aquí recomendamos poner el título de proyecto en la primera línea y en la
segunda la tarea en si misma, esto nos viene muy bien ya que podemos trabajar hasta con seis
proyectos dentro de nuestro tablero de producción.
Además podemos encontrar otros elementos como:
 Fecha de entrada. El día que añadimos la tarea al tablero. Útil de cara a seleccionar
la próxima tarjeta que llenará un hueco de producción y nos ayudará también a
medir el lead time.
 Fecha límite o “Deadline”. Es importante entender que no todas las tarjetas deben
llevar este dato, solo aquellas que por su naturaleza verdaderamente han de llegar
al final del tablero antes de una fecha determinada (nos detendremos en esto
cuando hablemos de las clases de servicio), normalmente por motivos estratégicos,
legales o por el elevado coste de entregar dicha tarea después del plazo marcado.
Encima de la tarjeta podremos encontrar otros indicadores visuales como:
 Un post it rojo, naranja o similar indicando que la tarea está bloqueada y que no
puede avanzar: por ejemplo, en la preparación de una oferta comercial podríamos
bloquearnos a la espera del precio de un proveedor o en el desarrollo de una
funcionalidad de un software porque no disponemos de la descripción de la
interfaz que necesitamos.
 Un indicador visual de la persona (o equipo) que está sacando adelante un
elemento: a veces se usan imanes de colores, personajes de series de televisión
(por ejemplo, de Los Simpsons o South Park) o fotos/avatares de los miembros del
equipo.

 Indicador de retraso: si un elemento ha sobrepasado el lead time o se acerca su

fecha límite es útil indicarlo de manera visual para prestarle una especial
consideración a la hora de hacer pull. Por ejemplo, usar banderitas que venden en
cualquier tienda de material de oficina, tanto para esto como para los bloqueos.
 Algunos de los datos habituales: podemos (y deberíamos) introducir cualquier

información que pueda ser fácilmente incluida en la tarjeta y aportarnos un valor
tangible a la hora de visualizar el tablero. En la siguiente imagen podemos observar
una tarjeta propia de un proceso de producción en lean manufacturing.
El tablero
Haciendo una búsqueda rápida en Google Images con el término Kanban vemos
claramente dos tipos de resultados predominantes, los flujos de Kanban en lean
manufacturing y el tablero Kanban o tableros característicos de esta metodología.

Dos versiones diametralmente opuestas. La primera imagen es la implementación más

sencilla que podemos hacer de Kanban. Como vemos, cada tarjeta (o post it) refleja una tarea
o elemento que debemos realizar y dividimos el tablero en lo que tenemos que hacer, lo que
estamos haciendo y lo que está hecho. Sin embargo, el tablero de la segunda imagen refleja un
flujo más real en un entorno empresarial. Aunque la imagen sea pequeña, nos debería llamar
la atención varias cosas en contraposición al anterior:
 La gran cantidad de columnas: son las fases por las que va pasando un elemento de
trabajo dentro del sistema. También hay colas y buffers. El número de columnas de
nuestro tablero dependerá de la complejidad de nuestra organización y de los
procesos seguidos para completar una tarea. Dividiremos nuestro tablero en tantas
columnas como necesitemos siempre que esta división nos ayude en la visualización
y control del flujo. Iremos viendo cómo construir nuestro tablero a medida que
avancemos.
 Las tarjetas: podemos observar una mayor cantidad de información (fechas de
entrada al sistema, fecha máxima de entrega...).
 Los colores de las tarjetas: nos servirán para identificar clases de servicio (unidades
de trabajo con políticas distintas que nos permiten adaptarnos a los distintos tipos
de trabajo que realizamos, se verá en profundidad en la siguiente clase). Además, el
uso de indicadores visuales encima de las tarjetas (de color naranja en este caso)
nos servirá para identificar situaciones concretas como los bloqueos.
 Si nos acercáramos veríamos unos números al lado de las columnas, se tratan de los
límites del WIP.
Si a estos elementos que vemos en la fotografía le sumamos una serie de políticas y

métricas tendremos una implementación completa y real de Kanban.

Cada implementación Kanban es diferente y por ello cada tablero Kanban es único.
Como siempre, debemos entender claramente el objetivo del tablero para poder configurar el
nuestro de la manera más útil posible para nuestra organización.
El tablero nos va a servir en todo momento para visualizar el flujo; continuando con
nuestro símil lo podemos ver como una fotografía aérea del estado de las carreteras. Con un
simple vistazo debemos ser capaces de ver atascos (cuellos de botella), accidentes que están
parando la circulación (bloqueos), etc. El tablero nos permite visualizar pero también trabajar
sobre él y tomar decisiones.
Cuando un elemento en el que se está trabajando se finaliza, se mueve a la columna de

la derecha. Esto deja un hueco en la columna que ha de ser rellenado con un elemento de la
fila de la izquierda, tiramos de una tarea (hacemos pull). El tablero nos indicará cuáles son los
candidatos a rellenar este hueco y la información de las tarjetas, sumada a las políticas
establecidas nos indicará el mejor de los candidatos.
Como hemos podido ir viendo, un tablero Kanban se divide en columnas. Cada

columna identifica un estado del elemento o tarea. La división más sencilla que podemos hacer
es la que indica los elementos pendientes, elementos en proceso y elementos terminados.
Este esquema puede ser válido para administrar nuestras tareas personales pero
probablemente necesitaremos añadir cierto grado de sofisticación para gestionar nuestro
equipo, nuestro departamento o nuestra empresa.
En este ejemplo del mundo del desarrollo de software vemos nuevas divisiones.
Hemos dividido el pendiente/haciendo/hecho en tres subprocesos, identificando que una
nueva funcionalidad que queremos introducir en nuestra aplicación deberá ser analizada,
desarrollada y posteriormente probada antes de pasar a producción. Estos pasos son
consecutivos, y por ello el “hecho” de uno de ellos se convierte en el “pendiente” del
siguiente.

3.1.4. KANBAN EN FUNCIONAMIENTO
 La búsqueda del equilibrio
Vemos la aparición del concepto de cola, etiquetado en este caso como next o
siguiente. Ya no tenemos una pila (backlog) enorme del que vamos tirando. Esta columna está
estrechamente ligada a la planificación. Profundizaremos en esto cuando veamos el apartado
de la planificación pero por el momento pongamos un ejemplo: supongamos que cada tres
lunes se reúnen los directores de los departamentos de marketing, atención al cliente e IT para
decidir qué funcionalidades nuevas entrarán en producción. Esta columna servirá para
identificar estos elementos y por tanto se deberán arrastrar del backlog tantos elementos
como huecos disponibles tengamos en la columna.
Aunque en un primer momento esta columna puede recordarnos al Sprint Backlog de

Scrum, son muchas las diferencias. Debemos recordar que en Scrum el tiempo está acotado en
sprints, por lo que cada 2-4 semanas tendremos una meta y empezará una carrera. Suena el
disparo de salida, corremos, llegamos a la meta y vuelta a empezar. Sin embargo, en Kanban el
proceso es una carrera de larga distancia, buscamos ese trote que nos permita no detenernos
en ningún momento. Buscamos velocidad media.
Por ejemplo, si tenemos un punto de avituallamiento cada 15 km y corremos de media

a 7 km/h, guardaremos agua para dos horas más o menos en cada punto. Esa es la cola de
next. Si los jefes de departamento se juntan cada tres semanas para planificar y sabemos que
de media sacamos adelante 2-3 funcionalidades por semana, querremos tener alrededor de
ocho tarjetas en la cola al finalizar su reunión para garantizar que no nos falte trabajo hasta
que se vuelvan a reunir. Veremos que en algunos casos, puede ser perfectamente válido
reducir esta cola a un solo elemento si no es costoso planificar un nuevo elemento y puede
hacerse un tiempo inferior al de finalizar una tarea. Por tanto, no se trata de cumplir un plazo,
se trata de mantener el flujo.
Siguiendo con el tablero, vemos los números que identifican los límites del WIP en
cada una de las fases. El concepto se entiende a simple vista. No puede (o no debe) haber más
de N tarjetas en esta columna, pero si nos paramos un momento nos empiezan a surgir
algunas preguntas en las que iremos profundizando:
 ¿Qué hacemos si hay tres tarjetas en desarrollo y ya están todas en “done”?

¿Seguimos tirando?
 Si una fase es siempre más lenta que la anterior, ¿cómo podemos aliviar los cuellos
de botella para no tener parado al equipo?
 ¿Cuál es el tamaño apropiado para el WIP en cada fase?

Nuestro objetivo va a ser siempre mantener el tablero equilibrado e iremos viendo

cómo. El gran valor de Kanban es que el simple hecho de empezar a trabajar con el tablero
pondrá de manifiesto dónde se encuentran nuestros cuellos de botella, qué nos para y dónde
nos bloqueamos.
Voy a aprovechar el tablero para apuntar algunas diferencias clave entre Kanban y
Scrum. ¿Te sientes tentado a comparar un tablero Scrum con uno Kanban? Te propongo la
siguiente aclaración visual:
Scrum funciona en sprints en los que tratamos de llevar desde el sprint backlog hasta
el "hecho" todos las historias propuestas, por lo que al principio de un sprint solo tenemos
elementos en el sprint backlog, mientras que al final del sprint solo tenemos tareas en el
"Hecho". En Kanban, por el contrario, no existe un marco temporal. El tablero se rellena con
una cadencia constante, y el flujo avanza de manera constante, continua y equilibrada por el
tablero.
 No mires atrás
Llega el momento de dejar muy clara una política fundamental a la hora de trabajar
con Kanban y el tablero: una tarjeta solo puede avanzar por nuestro tablero, nunca retroceder.
Os pido que reflexionéis sobre esta pregunta: ¿de qué sirve limitar el WIP si podemos liberar
un slot solo con devolver una tarjeta a la columna anterior?
Os aseguro que cuando empecéis a trabajar con Kanban os vais a sentir tentados de
manera constante de devolver tareas a "pendiente", pero al hacerlo estamos pervirtiendo
nuestro tablero ya que perdemos la visibilidad de los bloqueos, estamos “haciendo trampas”
con los límites del WIP, etc., y esto va a eliminar todo lo bueno que nos aporta Kanban.

Existen motivos más justificados para mover hacia atrás una tarea. Imaginad una
columna "revisión". Cuando hemos acabado de las creatividades de la siguiente campaña de
Coca-Cola, el equipo de cuentas revisa nuestro trabajo para juzgar si está aliado con el briefing
del cliente. ¿Qué pasa si no lo está? La tarea tiene que volver al equipo de diseño. ¿La
volvemos a llevar a "diseño"? Solo hay una mala respuesta a esta pregunta, no establecer una
política clara. La tarjeta podría efectivamente volver hacia atrás a "pendiente" de volver a
entrar en el WIP de "diseño". Podría quedarse bloqueada en "revisión" y generar una nueva
tarjeta, esta solución me gusta especialmente.
Dos ventajas en esta solución:
 La tarea sigue consumiendo WIP en "revisión" además del de "diseño", lo que

producirá cierta tensión positiva destinada a acelerar la resolución del problema
(nos ayudará a mantener el tiempo de entrega).
 Nos puede ayudar a identificar un problema si vemos que surgen cuellos de botella
derivados de estas tarjetas de revisión. No se están transmitiendo correctamente
las especificaciones del cliente al equipo de diseño.
Aprovecho para hacer hincapié en la idea de que no hay dos Kanban ni dos tableros
iguales busca siempre que el tablero que te aporte el mayor valor posible a ti.
 Buscando el límite
Elegir el tamaño apropiado de WIP para cada una de las columnas del tablero es una
tarea importante de cara a buscar la mayor eficiencia. Puede resultar complejo elegir el límite
ideal pero recordad que el proceso de implantación de Kanban es siempre evolutivo y está en
constante revisión. Seleccionemos unos límites que nos parezcan razonables y empecemos a
trabajar con ellos. En poco tiempo veremos son apropiados o deben ser ajustados. No hay una
norma general para establecer un límite inicial. Pongamos algunos ejemplos que nos puedan
ayudar.

Por ejemplo, un programador buscará bajar su WIP al máximo para prestar la mayor
atención posible a la funcionalidad que está desarrollando. El que pueda o no bajar su WIP a 1
dependerá en mayor medida de su entorno y de la forma de relacionarse con otros miembros
o equipos con los que trabaje. Si se está desarrollando una funcionalidad para una aplicación
web y se le presentan dudas sobre la interfaz de usuario es probable que esta tarea pueda
quedar bloqueada. Si es sencillo hacer una consulta al equipo de UX podrá proseguir sin
bloquearse. Si por el contrario el equipo de UX no está en la misma oficina o no está disponible
para una consulta rápida por Skype, en grandes empresa una consulta puede llegar suponer
rellenar un formulario y esperar lo que probablemente nos deje bloqueados. Un WIP de 1,
aunque pueda resultar ideal, puede llevar a dejarnos parados con mucha facilidad. En
empresas de desarrollo tamaño PYME es muy normal que exista un único pool de
programadores que atiendan tanto los nuevos desarrollos como la corrección de defectos de
software en producción y es necesario avanzar en paralelo, un WIP de 2 elementos nos puede
ayudar a compaginar mejor.
Para atender la labor comercial de una empresa, un WIP tan ajustado puede no ser
operativo en absoluto. En mi empresa, por ejemplo, es normal que haya entre 3 y 5 procesos
comerciales en un momento determinado en marcha, una persona canaliza y gestiona todas
las ofertas. En el proceso de realizar las ofertas depende del cliente, de proveedores, de un
técnico que analice la viabilidad, los plazos y los costes y en última estancia del visto bueno de
una entre dos personas (que solemos estar de un lado para otro). Esto hace que sus elementos
se bloqueen constantemente. Un límite de 2 mantendría el flujo de ofertas totalmente parado
la mayor parte del tiempo. En este caso 4 es un límite razonable.
No dilatemos esta decisión más de lo necesario y si dudas elige el número menor de

los que estés planteando.
 Los cuello de botella
Un cuello de botella es ese punto del tablero que estrangula el flujo. Si una carretera
de 4 carriles llega a un estrechamiento de 2 y luego vuelve a 4, los dos carriles extra después
del cuello de botella no serán necesarios.
Los cuellos de botella son naturales, en algunos casos podemos mejorar para
minimizarlos o incluso hacerlos desaparecer y en otros casos no podremos hacer nada para
evitarlos. Por ejemplo, pongamos una empresa de construcción que cuenta con 3 arquitectos y
20 peones de obra, quizá los tres arquitectos puedan diseñar 1 edificio al mes de 5 plantas
pero 20 peones nunca podrán construir uno al mes. Es de suponer que si una empresa de
construcción tiene ese volumen de pedidos ampliará el equipo de peones para adaptarlos a la
demanda de los clientes pero no es siempre tan sencillo. En una oficina puede llegar el caso de
que no sea rentable, estratégico o simplemente no haya espacio para introducir más gente en
el equipo. Por descontado, existen procesos que no podemos acelerar por más recursos que

añadamos, son los problemas tipo “embarazo”. Una chica tendrá 1 niño en 9 meses, jamás
conseguiremos que 9 chicas tengan 1 niño en un mes.
Limitar el WIP, como hemos visto, pone de manifiesto los cuellos de botella. Cuando
estos aparecen debemos intentar eliminarlos si esto es posible. Llegado el caso en el que no
podemos mejorar más un proceso y sigue limitando el flujo solo podemos hacer una cosa,
garantizar que el cuello de botella nunca se pare.
 Los buffers
Los buffers son columnas que, colocadas y limitadas estratégicamente, nos van a servir
para optimizar el flujo cuando aparecen cuellos de botella que no podemos eliminar.
Lo primero que nos podemos plantear es que un cuello de botella nunca se va a

quedar parado ya que limita el flujo, pero en la práctica esto no es 100% cierto. En el mundo
real no hay dos tarjetas iguales, unas nos llevarán más y otras menos. Esto nos puede llevar al
siguiente caso: el cuello de botella está forzando a que el "listo" de la fase anterior esté lleno y
por tanto no se está trabajando. Hay 3 items a la espera y en un momento concreto el cuello
de botella libera 3 slots prácticamente a la vez y, por tanto, entran 3 items nuevos en la fase
anterior. Imaginemos ahora que uno de estos item de los que ha tirado el cuello de botella lo
resuelven antes de que llegue ningún item a "listo". Tenemos un slot libre en el cuello de
botella y es una pena porque es probable que en breve esté frenando el flujo de nuevo pero
ahora lo está infrautilizado.
¿Ampliamos el WIP del proceso anterior para que nos quepan más elementos en el
"listo"? No es la solución, ya que perderíamos todas las ventajas de limitar el WIP. La solución
es sencilla, introducimos lo que en informática llamamos un buffer, una nueva columna con su
propio límite entre las dos columnas que nos amortigüe este tipo de situaciones:

De esta manera no tocamos el WIP de "análisis" pero sí conseguimos disminuir las

probabilidades de que "desarrollo" se quede sin tarjetas para hacer pull. Por lo demás, el
buffer se comporta como una columna más.
Pautas para manejar el buffer:
 Establecer el límite de tarjetas de un buffer es similar a cualquier otro límite del

WIP. Se trata de un proceso de refinamiento en que empezaremos con un buffer
pequeño, de 1 o 2. Si no llega a cumplir su función y el equipo de desarrollo se
queda sin tarjetas para hacer pull a menudo, aumentamos de unidad en unidad
hasta encontrar el punto óptimo. Esto no significa que este número sea inamovible
ya que si en el futuro el cuello de botella mejora deberemos ir reduciendo el buffer
buscando siempre el límite inferior que garantice que el cuello de botella disponga
siempre de trabajo de que tirar.
 Sobredimensionar los buffers nos va a llevar a aumentar el lead time más de lo
necesario y por eso es recomendable que los buffers sean del tamaño adecuado.
 Las reuniones
Kanban, al contrario de lo que ocurre con Scrum, no prescribe reuniones específicas

pero, una vez más, esto no significa que no las haya. La naturaleza de cada equipo y
organización es diferente y no hay recetas estrictas, pero sí algunas recomendaciones que
pueden ayudar a gestionar más eficazmente la autogestión de los equipos:
 Reunión diaria: pero no en el sentido de Scrum. En Kanban todo esto lo vemos en el

tablero, no nos detengamos en ello. El objetivo de las reuniones diarias de Kanban
será revisar el flujo y ver qué nos está frenando. Si podemos resolver algún bloqueo
como equipo lo resolvemos. Es típico (y productivo) que después una reunión diaria
aparezcan de manera espontánea pequeñas reuniones de carácter más técnico,
normalmente para analizar el enfoque de algunas tareas. De esta manera
aprovechamos la interrupción de la reunión y así no tendremos que detenernos ni
interrumpir a otros compañeros después.
 Replenishment (o rellenado): cada cierto tiempo necesitamos alimentar el tablero y
rellenar la cola de “seleccionado”, “to do” o “next”. Como ya comentábamos con
anterioridad, en algunos casos el proceso de rellenado es trivial y se puede hacer
sobre la marcha, en cuyo caso esta reunión es innecesaria. Normalmente, un
equipo u organización puede recibir trabajo de diversos clientes (ya sea otras
empresas o particulares u otras entidades dentro de la misma empresa) y a veces
seleccionar qué nuevas tarjetas rellenarán los huecos disponibles no es sencillo.
Cuando sean necesarias, estas reuniones nos ayudarán a seleccionar estas tarjetas.
Más adelante hablaremos detenidamente sobre esto.
 Retrospectivas: en un mundo ideal y volviendo al concepto de Jidoka del que
hablamos en lean manufacturing, si algo no va bien se paran máquinas, se estudia,
se arregla y volvemos a empezar. Por desgracia, el día a día es complicado de
gestionar y normalmente no es posible. Además, muchas veces no somos

conscientes de que algo no va bien hasta que nos paramos y observamos. El

objetivo de estas reuniones es parar máquinas de manera forzada y revisar. La
cadencia de estas reuniones las decidirá el equipo, podemos empezar con una al
mes e ir adaptándonos. Hay mil maneras de hacer estas reuniones, hay hasta libros
al respecto, pero lo más sencillo para empezar es preguntarse: ¿Qué estamos
haciendo bien? ¿Qué estamos haciendo mal? ¿Cómo podemos mejorar?
Respondiendo a estas tres preguntas surgen muchas ideas y reflexiones dentro del
equipo. Lo ideal en este punto es ser un poco estricto y convertir las respuestas en
planes de acción, incluso dentro del tablero. Sin planes de acción convertiremos
cada reunión en debates sobre los mismos temas sin llegar a poner las mejoras en
práctica.

3.1.5. ¿QUÉ HEMOS APRENDIDO EN ESTA UNIDAD?
En esta primera clase hemos aprendido:
 Kanban (tanto en lean manufacturing, como en la gestión de equipos y proyectos)

es un método de planificación y gestión de la producción basado en vOKisualizar el
proceso de producción, limitar el WIP, tirar de la producción desde abajo (pull) y
buscar siempre la máxima calidad y la mejora continua reduciendo el despilfarro.
 Para visualizar el flujo utilizamos un tablero (similar al de Scrum pero con profundas
diferencias) y unas tarjetas de trabajo con la información necesaria para la toma de
decisiones con respecto a su planificación.
 Kanban es más un conjunto de herramientas de visualización y una serie de
principios que una metodología estricta. Teniendo un tablero y limitando el WIP
tendremos una implementación básica de Kanban. El cómo y cuánto la
personalicemos y la adaptemos a la realidad de nuestras organizaciones será clave
para sacarle el mayor partido. No hay dos empresas iguales, no hay dos tableros
iguales.
 Limitar el WIP es la práctica fundamental de Kanban. A medida que aprendemos y
trabajamos con Kanban vamos encontrando los límites necesarios para las distintas
fases de nuestra cadena de valor, encontramos nuestros cuellos de botella y
trabajamos en ellos y optimizamos su rendimiento introduciendo buffers.
 Kanban no impone reuniones ni roles dentro de nuestra organización. Esto no
implica que estos no tengan valor o que haya que eliminarlos. Implica que debemos
plantearnos cuáles y con qué objetivo, buscando siempre el valor que aporta a
nuestro flujo de producción.

3.2. Kanban II. Equipos y proyectos. Gestión evolutiva

del cambio
En la primera parte de este módulo de Kanban vimos los principios fundamentales de

la metodología, las herramientas/artefactos que utilizamos y otros conceptos básicos
relacionados con cómo gestionar correctamente el flujo de un proceso con Kanban. Con todo
ello seremos capaces de implementar Kanban y empezar poco a poco a dar un mayor valor a
nuestra forma de trabajo.
En esta segunda parte vamos a profundizar en algunos conceptos que nos ayudarán a
sacar un mayor partido a nuestros tableros. Veremos nuevas herramientas y métricas que nos
permitirán adaptarnos de una manera más precisa a la realidad de nuestras organizaciones.
Veremos también cómo planificar nuestros inputs y dividir el trabajo para maximizar la
predictibilidad de nuestra producción.
Tenemos las herramientas y sabemos utilizarlas pero no siempre es fácil realizar

cambios. A veces los cambios, aunque sean para bien, no llegan a buen puerto (o a ninguno)
por no elegir la forma correcta de implementarlo y gestionarlo en el día a día. Por ello, en esta
unidad, veremos cómo podemos realizar un cambio de manera evolutiva y natural, sin
movimientos drásticos, de tal forma que vayamos aportando cada vez un poco más de valor al
proceso y que todos los involucrados vean el valor y quieran participar en él.
3.2.2. CLASES DE SERVICIO
Durante la primera parte hice mucho hincapié en la necesidad de adaptar Kanban a la

realidad de nuestra empresa, equipos, etc. porque no hay dos empresas iguales. Además de
que no hay dos empresas iguales, dentro de una empresa no se trabaja siempre igual y las
clases de servicio nos ayudan a adaptarnos a las diferentes formas de trabajo de manera
natural.
Pongamos un ejemplo concreto con una empresa que desarrolla software para dos
mundos completamente distintos: la publicidad y proyectos de emprendimiento. Estos últimos
suelen ser proyectos de un mínimo de 2 meses de trabajo y un máximo indeterminado. Los
primeros en cambio son proyectos (normalmente) de menos de un mes, a veces incluso de
pocos días. Por otra parte los proyectos de emprendedores tienen un grado bastante más alto
de indeterminación, pueden cambiar de objetivos, de funcionalidades o incluso (por desgracia)

pueden detenerse en cualquier momento por falta de financiación, por cambios en el

mercado, etc.
Por otra parte el coste (no necesariamente económico) asociado al retraso es muy
diferente en ambos casos. En un proyecto de emprendimiento con un horizonte temporal de 4
meses sufrir un retraso en una funcionalidad concreta no es grave, hay tiempo para ponerse al
día antes del lanzamiento y además las fechas de lanzamiento suelen ser medianamente
flexibles. Probablemente el coste de un retraso será más intangible que económico. En cambio
en el mundo publicitario no hay retraso que valga, se trabaja con unos márgenes de maniobra
muy escasos y las fechas de lanzamiento son inamovibles (puede ser un evento, puede ser una
campaña que está firmada ya para emitirse en televisión). De ocurrir, un retraso en este tipo
de proyectos puede significar no cobrar el trabajo y perder el cliente.
Finalmente todo estos trabajos acaban siendo tarjetas dentro de nuestro tablero pero,
¿Cómo diferenciamos una tarjeta que “tiene que estar para el lunes” de otra que “TIENE que
estar para el lunes”? Es aquí donde entran en juego las clases de servicio.
Las clases de servicio son un mecanismo que nos permite diferenciar tipos de tareas y
asignarles políticas distintas dentro del tablero permitiéndonos adaptar nuestra
implementación de Kanban a nuestra forma de trabajo. Una clase de servicio se diferenciará
de otra por:
 Su representación visual. Es típico usar post-its de diferente color para representar

elementos de distintas clases de servicio.
 El impacto sobre los límites del WIP. Puede existir una clase de servicio que
represente elementos de extrema urgencia que permita no tener en cuenta los
límites del WIP a la hora de tirar de ella.
 La forma de priorizar esta clase de servicio. Podemos tener una clase de servicio de
tarea de muy poca relevancia que puedan ser siempre pospuestas en favor de
cualquier otra clase de servicio.
3.2.3. POLÍTICAS Y CLASES DE SERVICIOS
Hemos ido hablando de las políticas en Kanban a lo largo del texto. Ahora que
conocemos las clases de servicio es muy buen momento para profundizar un poco en este
concepto.
La primera clave de las políticas es que sean explícitas y conocidas por todos. Además
intentaremos en la medida de lo posible que nuestro tablero refleje visualmente estas políticas
haciendo más sencillo su manejo.

En Kanban trabajamos con políticas a varios niveles, unas más cercanas al trabajo de
valor que realizamos y otras al método. Aquellas que tienen que ver con el trabajo, con los
elementos que producimos, son propias de cada sector empresarial y de los procesos propios
de cada empresa. Con las divisiones del tablero, las tarjetas y otros elementos de visualización
trataremos de reflejar estas políticas en nuestros tableros y ayudar a su cumplimiento.
Nosotros por ejemplo no enviamos nada a cliente que no haya revisado el gestor de esa
cuenta. Por tanto tenemos una columna de revisión anterior al “entregado a cliente” que es
nuestro “hecho”. Además nuestras tarjetas podrían indicar siempre quien es el gestor de la
cuenta de cada elemento en el tablero (no lo hacemos porque por nuestra forma de trabajo es
una información de sobra conocida por todos y no nos aporta valor en la visualización).
Por otro lado tenemos las políticas que son propias del método de trabajo, de la
gestión de flujo. Hemos ido viendo los límites de WIP, las políticas de visualización (tarjetas,
indicadores visuales, colores, etc) y de la priorización en los procesos Pull. Vamos a ver estas
políticas con más detalle en el contexto de las clases de servicio.
Políticas y clases de servicio
Cada clase de servicio que establezcamos vendrá definida por una serie de políticas. El
objetivo de estas políticas es garantizar que se cumplen las necesidades concretas de cada
clase de servicio en cuanto a Lead Time, uno de los criterios con mayor impacto a la hora de
definir clases de servicio, u otros criterios diferenciales.
Cada clase de servicio tiene sus propias políticas independientes del resto de clases de
servicio pero a la hora de definirlas no podemos olvidar que todas ellas conviven dentro de un
mismo ecosistema y por tanto, deben ser coherentes entre sí.
Para cada clase de servicio definiremos los siguientes tipos de políticas:
 Políticas de visualización.
 Límites.
 Políticas de priorización.
 Políticas de visualización
La primera política que establecemos sobre una clase de servicio es la visual, la forma
en que la identificamos dentro del tablero. Las tarjetas de colores es la forma más común de
diferenciar clases de servicio. En muchos casos se incluye una leyenda en el propio tablero:

Además del color, podemos establecer otro tipo de decisiones visuales, como por
ejemplo establecer una fila diferenciada para una clase de servicio en concreto o incluir en la
tarjeta información específica para esa clase de servicio (por ejemplo: la fecha límite de
entrega).
En el caso de la empresa de ejemplo, podríamos separar en 2 clases de servicio e

indicar con post-its de color amarillo los elementos de proyectos publicitarios y en verde los de
emprendimiento. Añadimos uno más. A veces, sucede algo inesperado que pone la empresa
patas arriba, que detiene toda la producción, que focaliza el trabajo durante un corto espacio
de tiempo y hace que nos dediquemos todos sin excepción a sacar adelante una tarjeta... estas
tarjetas son de color morado y suelen significarse en una línea aparte del tablero para no
confundirlas, ya que salen del flujo habitual.
NOTA: Como veis en la imagen del tablero, he separado el carril exclusivo para
visualizar mejor el flujo de la clase de servicio, significando lo “urgente” en color morado. Esta
política puede ayudar a visualizar el hecho de que “urgente” no compite con el resto de tareas
del tablero en los procesos pull ya que tiene la máxima prioridad.

 Límites
Las políticas asociadas a los límites nos van a dar una nueva dimensión de
customización en nuestro tablero.
Hasta ahora hemos limitado el WIP de manera vertical, esto es, por columna, pero no
es la única manera de hacerlo. Veíamos en la imagen anterior como habíamos dividido una
columna independiente para tareas muy urgentes. Es muy normal no admitir en el tablero más
de un elemento de este tipo a la vez.
En la empresa del ejemplo, podemos utilizar esta clase de servicio para proyectos muy
cortos de gran valor económico. Estos proyectos se identifican con una sola tarjeta dado su
naturaleza reducida y no permitimos por política más de una tarjeta morada a la vez en el
tablero. La motivación de este límite es mantener a raya el impacto de este tipo de proyectos
sobre el flujo normal del tablero, evitando que se detenga por completo el avance de otras
tareas.
De esta manera hemos establecido un límite horizontal, pero podremos además

establecer límites verticales por clases de servicio para garantizar el avance de elementos de
distintas clases:
Hemos limitado las tareas en producción a seis pero además hemos independizado los
límites por clase de servicio de tal forma que siempre tendremos, por ejemplo, una tarea de
mejora en producción o, por lo menos, siempre tendremos hueco para una lo que nos va a
estimular a trabajar este área dentro de la organización.

NOTA: Este tipo de divisiones no son en absoluto necesarias y no debemos realizarlas

sin una motivación real dentro de la organización ya que si no se adaptan correctamente van a
entorpecer el flujo de elementos de manera considerable.
 Políticas de priorización
Las políticas de priorización funcionan a dos niveles:
 Priorización dentro de elementos de la misma clase de servicio.

 Priorización entre clases de servicios diferentes.
Además, existe un nivel de priorización por encima que tiene que ver con los input o
upstream de nuestra cadena de valor que veremos en la siguiente sección.
Dentro de la misma clase:
 Se suele priorizar usando una política FIFO (first in - first out). Consisten en que se
selecciona para rellenar un hueco la tarea que lleve más tiempo en el tablero.
 Podemos utilizar también una planificación Round Robin, en la cual seleccionamos
una tarjeta de un cliente o proyecto distinto cada vez.
 En organizaciones pequeñas con un alto conocimiento por parte del equipo de
producción de los proyectos e intereses de la empresa, se prioriza de manera
intuitiva teniendo en cuenta tanto el tiempo que lleva una tarjeta en el tablero
como la importancia del proyecto o sus plazos.
Las políticas de priorización entre clases de servicio pueden ser más complejas y tener
un mayor impacto sobre el flujo, de esta forma, podemos establecer que de existir una tarjeta
morada (urgente) se seleccionará siempre esta tarjeta antes que cualquier otra del tablero a la
hora de hacer pull o, por el contrario, podemos establecer una clase de servicio “tareas para
cuando sea posible” que irán siempre las últimas a la hora de seleccionar.
La complejidad de estas políticas de selección dependerá de cada organización y su

forma de trabajo. A continuación encontrarás ejemplos de clases de servicio estándar con sus
políticas que te pueden inspirar y servir de punto de partida.

 Ejemplos de clases de servicio
A la hora de ejemplificar las clases de servicio se suelen utilizar las cuatro que os
presento a continuación. No son más que ejemplos que pueden nos sernos útiles y servirnos
como punto de partida y después adaptarlas a nuestras peculiaridades.
Expedite
Se trata los elementos de máxima urgencia de los que hemos venido hablando, en el
mundo Kanban se suele utilizar el término expedite o silver bullet para esta clase de servicio.
Identifican elementos excepcionales que por motivos de negocio (grandes presupuestos,
motivos estratégicos de peso, etc.) o por su gran impacto (por ejemplo un bug importante
encontrado en un software que permite a atacantes introducir virus en el sistema) se les da
una prioridad excepcional.
Cuando una tarjeta de este tipo entra en el tablero altera significativamente el flujo ya
que se convierte en máxima prioridad por encima incluso de tareas con fecha de entrega
cerrada.
Veamos una posible definición de sus políticas:
 Visualización: Tarjetas moradas, con una fila propia.

 Límites: Un único elemento de esta clase en el tablero. Además elimina otros límites
de WIP que puedan existir temporalmente. Si la tarjeta ha finalizado una fase
alguien de la fase siguiente comenzará con ella aunque tenga que sobrepasar el
límite de WIP temporalmente.
 Priorización: Prioriza la primera siempre y se saltan los buffers que podamos tener
definidos.
Estándar
Es la clase de los elementos típicos o más frecuentes dentro de nuestra cadena de

valor. Tienen un nivel de prioridad normal y no alteran en el avance normal del flujo.
 Visualización: Tarjetas amarillas.

 Límites: Utilizan los límites verticales establecidos.
 Priorización: Utilizamos una planificación FIFO.

Fecha cerrada
Indican elementos que deben estar finalizados antes de una fecha concreta. Esto no
necesariamente indica urgencia. Por ejemplo podemos encontrar tarea de adaptación a
normativas que entran en vigor en una fecha concreta. El grado de urgencia de esta clase de
servicio depende de lo cerca que nos encontremos de la fecha de finalización límite.
Normalmente se tratan de manera similar a la estándar con algunas salvedades.
 Visualización: Tarjetas naranjas, fecha de entrega límite explícita sobre la tarjeta.

 Límites: Utilizan los límites verticales establecidos, no se permite que sobrepasen
los límites del tablero.
 Priorización: Priorizan por encima de las estándar si su plazo de entrega es cercano
o menor al Lead Time medio de nuestro tablero.
 Otras: Si su fecha de entrega se encuentra a menos de 5 días laborables se convierte
en un Expedite. Cambiaremos la tarjeta por una morada con la misma información y
entrarán en juego las políticas de esta clase de servicio.
Intangibles
Como hemos ido comentando se trata de tareas que “habría que hacer”. No tienen un
fecha de entrega ni un coste derivado de su retraso y por tanto van las últimas en cualquier
priorización.
 Visualización: Tarjetas azules.

 Límites: Utilizan los límites verticales establecidos.
 Priorización: Priorizan las últimas en caso de no existir ninguna tarea de prioridad
superior de la que tirar.
3.2.4. INPUTS Y SU PLANIFICACIÓN
 Pizza a domicilio
Nuestros “inputs” son aquellas personas, departamentos, clientes, etc. que van
cargando de tareas nuestro pendiente, son los clientes de nuestro negocio de pizza a domicilio.
Cuando llega un encargo se pone a la cola.
Nuestro departamento de producción trabaja ya con Kanban y es tan predecible como

un horno de pizza: tiene una entrada por un lado y una salida por el otro y las pizzas avanzan a
un ritmo constante deslizándose por su interior hasta que están listas (la variabilidad de lead
time es muy baja). Por tanto, una vez que entra una pizza en el horno nuestros inputs confían
en que el tiempo de entrega será de diez minutos.

Por otra parte nuestro horno tiene un ancho determinado (WIP limitado) y por tanto
no podemos tener en el horno más de 6 pizzas. La única manera de alterar la planificación es
decidiendo en qué orden entran las pizzas en el horno.
Para ello definiremos también políticas que pueden ir desde una cola de pedidos
similar al de nuestra pizzería (donde los pedidos se atienden por estricto orden) hasta
esquemas de mayor complejidad siempre y cuando ésta sea justificada.
Siempre puede ser que además de pizzas empecemos a producir también lasaña (otra
clase de servicio) que es más pequeña. Cuando manejemos distintas clases de servicio,
tendremos que establecer políticas que garanticen que ambas clases de servicio son atendidas
de manera adecuada a las necesidades de nuestros inputs.
 Priorizando nuestros inputs
Aquellos que alimentan nuestra cadena de valor son nuestros input o upstream, pero
no todos los inputs de nuestros Kanbans son iguales. En algunos casos nuestro equipo forma
parte de una cadena de valor más grande y nuestros inputs son procesos anteriores dentro de
la misma u otra compañía. En algunos casos podemos gestionar una empresa entera con un
solo tablero y nuestros input son los clientes finales del servicio o producto. La forma de
interactuar con nuestros inputs y de decidir las tarjetas que entran en producción es muy
distinta en cada caso.
De igual manera que priorizamos tarjetas una vez que están en nuestro tablero
también se priorizan las tarjetas de nuestros inputs que van a entrar en nuestro cola de
tarjetas o columna de "siguiente". En algunos casos podremos formar parte de la decisión y en
otros no. En algunos casos esta priorización puede depender de un solo input y en otros puede
suponer armonizar varias fuentes de trabajo. Veamos algunos ejemplos clarificadores.
Si somos el departamento de maquetación de una editorial podemos tener como

inputs a los diferentes departamentos encargados de las diferentes publicaciones: infantil,
divulgativo y novela de nuestra editorial. En este caso es probable que nuestro departamento
no tenga ningún peso en la decisión de qué elementos entran en nuestro backlog.
Probablemente en este caso el departamento de marketing tenga la última palabra en la
decisión de cuáles de los libros que ya han sido corregidos interesa enviar a imprenta antes.
Para ello de manera periódica informaremos al departamento de marketing del número de
slots que tenemos libres y recibiremos las órdenes de trabajo.
Si por ejemplo somos el servicio de mantenimiento de un gran edificio de oficinas y

damos servicio a todas las empresas que alquilan espacio tendremos que dividir nuestro
tiempo entre todas ellas. Por tanto en este caso tendremos tantos inputs como empresas
alquilen oficina. En este caso la priorización está en nuestra mano. Para este caso podríamos
optar por un esquema Round Robin como el comentado en el apartado de políticas y de esta

forma ir atendiendo una vez a cada empresa (cada hueco en siguiente es rellenado por la
siguiente empresa de la lista) y volviendo a empezar cuando lleguemos a la última empresa.
Podríamos pensar incluso en una manera más justa de hacerlo usando un esquema
Round Robin ponderado por número de metros cuadrados alquilados. De esta manera
otorgaremos un mayor número de slots (reparaciones) al mes a las empresas con mayor
número de metros arrendados.
En muchos casos se busca el consenso entre todos los inputs o se realiza de manera
democrática. Cada input argumenta por qué deberían entrar en siguiente sus tarjetas y luego
se vota.
En la empresa de nuestro ejemplo esto se podría realizar por consenso entre las
personas que tratan directamente con los clientes y que se responsabilizan directamente de
los proyectos de los clientes que gestionan. Utilizando terminología Scrum cada uno es product
owner de los proyectos de sus clientes. A pesar de ello todos estamos al día del estado de cada
proyecto y nos es sencillo decidir cómo priorizar la cola.
A veces nuestros inputs conocen Kanban, entienden su forma de trabajo y por tanto
saben qué esperar de la producción en base al lead time e independientemente del método
usando para priorizar las tarjetas entienden el flujo de producción. En otros casos nuestra
forma de trabajo es opaca y, como en nuestra oficina, con muchos clientes se trabaja con
contratos tradicionales en los que se especifica plazos y precios fijos en base a una
especificación o briefing. En estos casos como os he comentado trabajamos con POs internos
que hacen las veces de input y trasladan los intereses del cliente y los contratos a tarjetas, de
alguna manera “agilizan” formas de trabajo más tradicionales y son ellos los que deciden qué
tarjetas llevan o no una fecha de finalización determinada o due date (en general aquellas que
deban estar acabadas dentro de un plazo inferior al lead time medio) y los que discuten la
priorización de las mismas en función de los plazos de los proyectos.
3.2.5. DIMENSIONAR TARJETAS: EL PODER DE LA NO ESTIMACIÓN
 Tamaños
Como hemos visto, estamos buscando un lead time medio estable que nos permitan
confiar en el sistema y tener una visibilidad razonable de cuándo llegarán al final del tablero las
tareas que estamos introduciendo en la columna de "siguiente" ahora.

El lector intrépido (ya conocedor de Scrum) se habrá dado cuenta de que todavía no
hemos hablado de nada parecido a épicas, historias de usuario, etc. y que no hemos
mencionado todavía nada de técnicas de estimación de tareas como planning poker u otras. El
motivo de todo ello es que en Kanban encaramos de otra manera la planificación. En Scrum,
basándonos en el conocimiento aprendido del equipo sabemos aproximadamente cuántas
unidades de trabajo podemos sacar adelante en las próximas dos semanas (sprint medio) y
nuestro objetivo a va a ser seleccionar un conjunto de historias de usuario que nos permitan
ajustar al máximo el sprint backlog; sin embargo, en Kanban no funcionamos con divisiones
temporales, no hay sprints y por lo tanto no nos vamos a centrar en intentar ajustar el
volumen de trabajo a un marco temporal. Todo lo contrario, lo que estamos buscando en
Kanban es ese “horno de Telepizza”, estamos buscando reducir la variabilidad y confiar en que
nuestras tareas saldrán por el final del horno pasados diez minutos aproximadamente.
Por tanto no queremos estimar tarjetas, queremos que las tarjetas tengan un tamaño
similar que podamos acomodar en una clase de servicio. El enfoque como veis es diferente.
Además no nos vamos a preocupar en exceso, nos bastará la experiencia y el sentido común
para saber si una tarea es adecuada o no. Os propongo las siguientes claves para dimensionar
una tarjeta para hacer que sea pequeña.
 Los límites del WIP no se llevan bien con tareas grandes (de semanas o meses). Si
tengo un límite de 2 y estoy trabajando en 2 tareas de un mes de duración me he
convertido en un cuello de botella automáticamente.
 Evitemos las tareas con sub-tareas. Nos quitan visibilidad y crean bloqueos
parciales difíciles de gestionar ya que nos permiten avanzar a medias con una
tarea.
 Es más fácil ajustar la variabilidad de las tarjetas si procuramos que sean siempre
pequeñas.
Para aprender a dimensionar, hay que entender qué significa pequeña en nuestro
contexto, que no es un concepto genérico.
Queremos que las tareas fluyan por un tablero con pulso, que las veamos avanzar y
entregar valor de manera constante. Esto nos permite ser ágiles, tomar decisiones y detectar
problemas de manera rápida. Os recomiendo que intentéis en la medida de lo posible que las
tarjetas sean de un tamaño tal que vuestro equipo pueda sacarlas adelante en pocos días o
una semana como máximo. Si una tarea veis que va a ser más larga preguntaros siempre si es
divisible en unidades menores de valor. Esto es clave, no sirve de nada dividir en unidades que
no generen un valor para nuestros stakeholders ya que esta es la clave del sistema, entregar
valor de manera constante. Si una tarea no se puede dividir porque no generaríamos valor con
las divisiones de manera independiente, entonces no es divisible.

Existen multitud de escenarios en los que las tareas necesariamente son más largas,
estos tiempos son una recomendación para tener un punto de partida. Como siempre, cada
caso es diferente.
Tampoco nos debemos pasar de pequeñas, si sacamos adelante una tarjeta cada dos
horas estamos creando un sobre esfuerzo de priorización muy grande.
Por tanto no estimamos de manera tradicional: “Tardaré unos tres días en hacer esto”
sino más bien clasificamos e intentaremos dividir el trabajo en unidades similares que nos
permitan reducir la variabilidad de nuestro Lead Time. Es este Lead Time medio el que nos
ayudará a planificar la entrega de valor.
No intentemos partir lo indivisible, si una tarea en concreto no tiene sentido en

unidades más pequeñas no significa que no podamos introducirla en el tablero, las
excepciones si son controladas no deberían afectar en exceso al flujo ni al Lead Time medio.
 Dividiendo el trabajo
En Scrum o XP se suele trabajar con una serie de niveles o de jerarquías que nos
pueden ser igualmente válidas si se adaptan a nuestra forma de trabajo, si no podemos buscar
otras divisiones si es que nos hacen falta. En el mundo del software y en concreto en las
metodologías ágiles, se trabaja mucho pensando en unidades de valor para el cliente, en la
entrega de valor constante. Por ello, a menos que no haya alternativa, intentamos no trabajar
largas temporadas en “tripas” que no podemos enseñar al cliente sino en unidades de trabajo
enseñables, lo que hace que la división en historias de usuario es muy natural.
Lógicamente para un departamento comercial estas divisiones carecen de sentido ya

que dividir jerárquicamente el trabajo no es necesario... una propuesta comercial puede ser
una tarjeta si es abordable en nuestro concepto de “pequeño”. Si por el contrario somos una
ingeniería presupuestando una nueva presa, es probable que necesitemos varios meses para
preparar el presupuesto. En este caso “presupuesto” podría ser nuestro primer nivel de
jerarquía y podríamos subdividir en varios niveles más, hasta llegar al tamaño adecuado de
tarjeta de producción.
Algunos equipos utilizan nuevas divisiones en el tablero para trabajar a la vez con dos
tamaños distintos de tarjeta o dos niveles jerárquicos simultáneamente. Os presento dos
alternativas.

Tablero a:
En el primero de los ejemplos trabajamos con un nivel superior de tarjetas a nivel de

cola, por ejemplo con historias de usuario. Una vez que las historias entran en producción
ocupan una fila exclusiva (swim lane) y se fraccionan en tareas de tamaño apropiado.
Tablero b:
En este segundo ejemplo, vemos como hay una zona superior en las que introducimos
las historias de usuario y en la zona inferior trabajamos como habíamos visto hasta ahora. En
ambos casos se limita el WIP en ambos niveles.
Esta alternativa puede ser interesante en algunos equipos y en otros no, como criterio
a usar antes de la implantación: no debemos complicar nuestro tablero con elementos
superfluos que no nos ayudan a visualizar el flujo.

 Divisiones de valor
En el mundo del desarrollo de software en el que Kanban se forjó, existen unos hitos
fundamentales que marcan el timing de los desarrollos: las releases (personalmente, me gusta
más usar el término en inglés pero se suele traducir como liberación o publicación). Es el
momento en el que se pone a disposición del usuario una nueva versión del programa con
nuevas funcionalidades.
Aunque de un tiempo a esta parte la aparición del software como servicio (SaaS o
Software as a Service) ha minimizado en muchos casos estos costes, sobretodo en el mundo de
las aplicaciones disponibles a través de nuestro navegador web (Gmail, Google Drive, Dropbox,
Salesforce, SurgarCRM y un larguísimo etc.). Los lanzamientos de nuevas funcionalidades
dentro de este mundo tienen un coste menor ya que no requieren de paquetización,
distribución... pero no por ello dejan de conllevar costes aunque sean menores. Por ello, es
importante entender que el propio hecho de lanzar una nueva release lleva asociados unos
costes como son:
 Marketing y comunicación para la nueva versión (no hay más que ver los
lanzamientos de las últimas versiones de Windows...).
 Si es software tradicional vendido en tiendas, conlleva gastos de producción,
embalaje, distribución, etc.
 Gastos por parte de los clientes, no sólo por la compra de nuevas licencias sino por
los gastos de adaptación a los nuevos programas: actualización de equipos,
formación, etc.
 Costes internos (tiempos, reuniones, desplazamientos, etc.).
Entender el concepto de release es importante en el mundo Kanban ya que se utilizan

a menudo jerarquías que dividen los proyectos en base a las releases.
Minimum Marketable Feature (MMF)
Definimos un MMF como un conjunto mínimo de funcionalidades a las que se

encontrará valor de manera independiente una vez liberadas.
Es una forma muy diferente de conceptualizar conjuntos de requisitos o

funcionalidades a como se hace, por ejemplo, en una historia de usuario. La inclusión de
Marketable en el concepto es la clave de la diferenciación. Dividimos en función de elementos
que aportan valor al usuario final. Este valor puede ser de muy diversa índole:
 Generación de retorno.
 Ahorro de costes.
 Ventajas competitivas.
 Imagen de marca.

Además se incluye Minimum. Hablamos de mínima en el sentido de que si fuera más

pequeña no proporcionaría el valor de mercado que buscamos.
En comparación con las historias de usuario estamos hablando de unas divisiones de

mayor tamaño. Desde este punto de vista entendemos que las historias de usuario de manera
aislada muchas veces no generan valor para el usuario y lo que hacemos es identificar el valor
que estamos buscando para que sea el valor el que guíe el desarrollo.
Una release estará definida por un conjunto de MMF realizados en un espacio de

tiempo.
Minimum Marketable Release (MMR)
Podemos definir un MMR como la un conjunto de funcionalidades que aportan

suficiente valor añadido al usuario como para justificar los costes de su salida al mercado.
A pesar de que el término MMF es ampliamente usado en el mundo de Kanban,

algunos (incluido David Anderson, creador de Kanban para la ingeniería de software) prefieren
utilizar este otro término ya que divide el desarrollo en subconjuntos de funcionalidades que
pueden ser lanzados al mercado de manera independiente.
De esta manera cada release puede estar potencialmente definida por un sólo MMR.
 Conclusión
Las divisiones anteriores son muy utilizadas en el mundo Kanban pero no siempre se
adaptan a todas las empresas y contextos. Por ello, está en nuestra mano utilizar las divisiones
que mejor se adapten a nuestro trabajo. Pueden ser divisiones basadas en historias de usuario,
en divisiones centradas en el valor de mercado como las que hemos visto, o en divisiones
totalmente ad hoc para nuestra empresa.
Como siempre (una vez más), aprendamos a coger de las metodologías ágiles aquello
que nos es válido a nosotros y sintámonos libres para adaptar o mejorar lo que necesitemos.

3.2.6. DE NUEVO MÉTRICAS: TOUCH TIME
Hablábamos antes del horno de pizza. Cuando llamamos a Telepizza y nos dicen un
plazo aproximado de entrega no le prestamos demasiada atención, sabemos que si están
tranquilos será media hora, si no una hora. Tenemos confianza y nos planificamos, sabemos
que tenemos tiempo para bajar a por unos refrescos o tender la ropa ;)... en definitiva,
conocer estas métricas nos ayuda a planificarnos.
Hasta ahora hemos visto dos métricas dentro del mundo Kanban: Cycle Time y Lead
Time. Son dos métricas sencillas pero con un enorme valor: con ellas podemos aprender sobre
el equipo, valorar el impacto de cambios y mejoras y sobretodo, nos sirven como referencia
tanto hacia el equipo como hacia los stakeholders de nuestra cadena de valor. En este
apartado, conoceremos una nueva métrica y hablaremos de la importancia del control y la
gestión del cambio.
 Touch Time
Vamos a ver una última métrica de interés, el Touch Time.
Hasta ahora medimos cuando tardamos en servir una pizza desde que nos la piden por
teléfono, cuánto tardamos en preparar una pizza desde que empezamos con ello hasta que la
damos por finalizada, cabe preguntarse: ¿Cuánto tiempo estamos verdaderamente trabajando
en la pizza? El Touch Time mide el tiempo total que hemos estado trabajando de manera
efectiva en una tarea.
Volvamos con la pizza. Tenemos un cocinero que hace la masa, otro pone las salsa e
ingredientes, otro controla la fase de horneado y el último mete la pizza en la caja y adjunta
servilletas y demás. Cuando cualquiera de los cocineros acaba con la pizza que está se la pasa
al siguiente, pero probablemente entrará en cola (buffer) a la espera de que el siguiente
cocinero haya acabado las pizzas que tuviera antes de ésta. Así sucesivamente. Si hemos
tardado 1 hora en servir el pedido y hemos tardado 35 minutos en cocinar la pizza es probable
que sólo 7 minutos hayamos estado “trabajando” en la pizza. El resto del tiempo la pizza ha
estado esperando a que se la atienda. Fijaros que siempre se cumple:
Touch Time < Cycle Time < Lead Time
Medir el Touch Time no es tan sencillo como nuestras dos métricas anteriores que sólo
requerían apuntar una fecha cada una en la tarjeta. Si utilizamos un tablero digital (se verán en
la próxima unidad) nos puede ser más sencillo pero si no, os recomiendo una aproximación
sencilla para vuestros tableros analógicos, como por ejemplo la que os enseño a continuación.

Hemos añadido una zona de puntitos con la idea de añadir un puntito en la reunión de
las mañanas si el día anterior nadie trabajó sobre esa tarea. Con esta técnica, no controlamos
exactamente las horas pero si que tenemos información de valor.
Otra opción es controlar nuestras métricas con una hoja de cálculo sencilla y muy fácil
de llevar sin necesidad de estar utilizando ningún tablero digital. Nos servirá para ir
acumulando datos por fecha y de aquí podemos sacar muchísima información. Os dejo un
ejemplo:
 Reflexiones e interpretaciones de nuestros datos
Una vez que vemos hecha la labor de “guardado y registro de datos”, nos será más
fácil analizar y sacar conclusiones sobre el funcionamiento de nuestro proyecto. Un momento
apropiado para hacer esta reflexión pueden ser en la retrospectivas, en ellas, analizaremos los
datos del último periodo en comparación con los anteriores y comparamos. El siguiente mapa
mental os puede ayudar como guía para interpretar los datos:

NOTA: Debemos conocernos y saber considerar qué afirmaciones pueden ser ciertas y
qué factores no reflejados en las métricas pueden haber forzado los datos (empezando por
unas simples vacaciones) para obtener información lo más fidedigna posible.
3.2.7. LA GESTIÓN EVOLUTIVA DEL CAMBIO
A lo largo de la primera unidad y durante gran parte de la segunda, hemos ido

conociendo Kanban: sus principios, sus herramientas, su forma trabajo... También, hemos
podido ver su valor y entender cuáles son sus beneficios. A modo de resumen, hemos visto
como Kanban usa una metodología liviana, sencilla y muy fácil de entender (de verdad os digo
que se puede explicar a un nuevo miembro de un equipo la reglas básicas de nuestro tablero
en cuestión de minutos).
Ahora bien, no es lo mismo entender que interiorizar. Más allá de las bondades de
Kanban o cualquier otro método tanto Lean como tradicional, su implementación en el equipo
y en la organización puede convertirse en una odisea si no gestionamos el cambio de una
manera apropiada.
La gestión del cambio es, desde mi punto de vista, una de las áreas del agile
management más complicadas porque en ella, entran en juego variables que no podemos
reflejar en las celdas de una hoja de cálculo: formas de ser, sentimientos, inseguridades,

enfoques personales encontrados... por ello, son cada día más las consultoras, coaches y
expertos que asesoran a empresas de todo tamaño en estos procesos.
Uno de los grandes valores de Kanban radica para mi precisamente en este punto.
Kanban es en sí misma un herramienta de gestión del cambio y un catalizador de la mejora
progresiva y continua. Vamos a ver en lo que queda de unidad, cómo partiendo desde el punto
actual de nuestra organización, sin ningún gran-cambio organizativo, podemos empezar a
aplicar Kanban de manera muy sencilla y dejar que nos guíe en todo este proceso.
 Objetivos
Lo primero que tenemos que tener claro cuando introducimos Kanban son nuestros
objetivos, ya que son ellos los que han de guiarnos en el proceso:
 Optimizar nuestros procesos: Kanban nos ayuda a mejorar la manera en que

hacemos lo que hacemos. No nos dice cómo hacerlo.
 Mejorar la calidad de nuestra cadena de valor: Limitar el WIP nos permite
mantener el foco, queremos mejorar la calidad de nuestro trabajo.
 Hacer más predecible el desempeño del equipo: Queremos reducir las fuentes de
variabilidad mejorando la confianza de nuestros stakeholders y mejorando la
sensación de control.
3.2.8. IMPLANTACIÓN DE KANBAN
Cuando empiezas a usar una nueva metodología y estás contento y convencido, lo

normal es estar un poco confuso también. Ayer trabajabas en un equipo anárquico de 6
programadores, gente muy buena que sacaba trabajo adelante, que ha decidido que quiere
evolucionar y mejorar, ser más eficiente y, por decirlo de alguna manera, reducir la entropía
(una forma bonita de llamar al caos).
Ayer erais 6 programando por las mañanas, discutiendo en las comidas y programando
por las tardes. Hoy estáis hablando de cerdos y gallinas, del PO, de tableros, preguntando si
hay que meter las reuniones en el backlog... es un cambio profundo que requiere de una gran
implicación y motivación por parte de los integrantes para llegar a buen puerto. Estamos
pidiendo al equipo que interiorice roles, prácticas, artefactos, reuniones, metodologías de
planificación, etc.
El punto de partida de Kanban va a ser muy diferente. Como hemos visto no se

imponen roles, reuniones ni una forma concreta de hacer las cosas y vamos a empezar

exactamente donde estamos. El no realizar cambios estructurales a nivel de roles y procesos

nos ayudará a evitar, una gran parte de la resistencia al cambio por parte de la organización.
 Primeros pasos
La clave con Kanban una vez que estamos decididos a dar el paso es empezar de una
manera progresiva y aprovechar el empuje de estas prácticas, para introducir la mejora
continua dentro de nuestra organización.
Visualiza el flujo de trabajo (workflow)
Cuando pensamos en Kanban pensamos en el tablero. El tablero es un reflejo visual de

nuestra cadena de producción (da igual que produzcamos software o visitas turísticas) y las
tarjetas son el reflejo visual del valor que estamos produciendo. Por eso, lo primero que
debemos hacer cuando queremos empezar a utilizar Kanban es dar forma visual a esta cadena
de valor.
Para ello intentaremos descomponer en fases claras los pasos por los que pasa una
unidad de producción desde que entra en nuestra cadena de valor hasta que la abandona.
En el primer tema habéis podido ver varios modelos de tableros y diferentes

soluciones para casos concretos. No pretendáis hacer el mejor tablero posible para vuestra
organización el día uno, porque rara vez lo vamos a conseguir. Mi recomendación es empezar
con un tablero sencillo que identifique fases claras y evidentes del proceso. No creemos
divisiones complejas al comienzo, dividamos en pasos naturales.
Una forma de detectar de manera sencilla las fases de nuestra cadena es ver en qué
momentos cambian de mano las tareas o qué momentos empezamos a utilizar habilidades
diferentes para continuar con la producción.

Un tablero básico To-Do/Doing/Done puede ser perfectamente válido para arrancar el

proceso si no existen o no vemos de manera clara las divisiones en nuestro proceso. Buffers,
divisiones en filas y otras prácticas que hemos visto, os recomiendo que no las introduzcáis en
el primer momento a menos que lo tengáis muy claro. En general, vamos a dejar que sean las
necesidades y la práctica la que nos pida mejoras y evoluciones. Os dejo un ejemplo que puede
servir como punto de partida a un equipo de ventas:
De igual manera haremos con las tarjetas. Os recomiendo empezar con un nombre
para las tareas y la fecha de entrada ya que nos va a ayudar a calcular el Lead Time además de
ayudarnos en la priorización a la hora de hacer pull.
En esta fase más es menos, no buscamos el Kanban perfecto, buscamos un punto de

partida con foco en la simplicidad para que nos ayude a evitar la resistencia al cambio, luego, a
partir de este tablero inicial iremos evolucionando. Las evoluciones surgirán de manera natural
si estamos atentos a las necesidades que se van planteando y sobre todo a los momentos de
duda, por ejemplo, si en un momento determinado no sabemos dónde posicionar una tarjeta
o vemos que algún miembro del equipo deja una tarea entre dos columnas será el momento
de plantearnos cambios sobre el tablero.
No dudéis en introducir cambios en el tablero si creemos que nos pueden beneficiar,

seamos ágiles, probemos. Si un cambio no demuestra su utilidad en un plazo de tiempo
razonable, simplemente volvemos hacia atrás o probamos una solución alternativa.

Por ejemplo, que haríais en el tablero anterior si, como pasa en mi empresa, aparecen
elementos urgentes con el briefing cerrado en cualquier momento. ¿Se quedan en Leads hasta
que se libere espacio en contacto inicial? ¿Los metemos directamente en oferta aunque no
queden slots libres?... Lo importante en estos casos es establecer una política clara para estas
situaciones en caso de que sean recurrentes. Otro truco para hacer las cosas incluso más
progresivas es pedirles que escriban una tarjeta la próxima vez que se pongan con una tarea
concreta. De esta manera no les estaremos pidiendo que analicen todo el trabajo que tienen
abierto de una vez si no a medida que empiecen a trabajar en tareas nuevas o que ya tengan
abiertas. La ventaja de esto es que nos vamos adaptando al tablero paso a paso. Nos
acostumbramos a escribir y a mover tarjetas y no hemos realizado ningún proceso tedioso.
NOTA: Tampoco nos hemos de preocupar por casos muy puntuales ya que no alterarán el flujo
en exceso.
En resumen: diseñamos nuestro tablero, las fases y pedimos al equipo que vayan
rellenando tarjetas y colocándolas en su fase actual y las vayan moviendo a medida que
avancen. Dos semanas después de esto, tendremos un tablero lleno de tarjetas. Habremos
visualizado el flujo y lo bueno de este enfoque es que, probablemente, estaremos empezando
a ver nuestros cuellos de botella sin haber limitado todavía la cantidad de WIP.
Limita el WIP
Podemos introducir límites desde el día uno y luego ir adaptándolos o, si hemos

dilatado esta fase intermedia que comentábamos, podemos empezar a trabajar los límites
desde algo así:

Este sería probablemente el caso de mi oficina si no tuviéramos el WIP limitado porque

tenemos un cuello de botella en las ofertas. En nuestro caso se debe a que las ofertas
requieren no sólo del encargado de la cuenta sino de algún técnico que se tiene que separar
de su producción para incluir la parte técnica de la oferta.
Os propongo un momento de reflexión que os invito a compartir en el foro, antes de

seguir leyendo... en el caso anterior, ¿Qué límites pondrías?
Si recuerdas cuando hablamos de los límites, dijimos que tirásemos hacia abajo.
Vemos que tenemos en este momento un total de doce elementos en nuestro WIP (dos
haciendo cola en el backlog y uno cerrado). Vemos también claramente que oferta está
haciendo de cuello de botella sobrecargando hacia atrás y dejando pocos elementos en las
siguientes fases. Nos interesa sobre todo limitar “Oferta” para observar si forzando el foco en
menos ofertas conseguimos una entrega más continuada para equilibrar nuestro flujo.
Tenemos que tener muy en cuenta las probabilidades de que una tarea se bloquee en Oferta
por mucho que limitemos el WIP ya que en muchos casos la dependencia de un técnico puede
dejar a los gestores de cuentas bloqueados. En este caso yo empezaría con algo así:
Hemos empezado con un límite de dos elementos por columna dando un poco más de
margen a oferta y a negociación. A este último le hemos dado tres porque, aunque está vacío,
la intuición nos dice que es por el atasco de ofertas. La negociación puede ser lenta y puede
haber puntos de bloqueo por parte del cliente por lo que tres nos ha parecido un punto de
valor para empezar.
A partir de aquí empezamos a trabajar con los límites. Lógicamente empezaremos

siempre con los límites de varias columnas por encima de su capacidad. Nuestro objetivo
inicial será hacer pull desde las columnas que estén por debajo de su límite para que el tablero
se vaya equilibrando. Para ello, pediremos al equipo que se focalice en cerrar ofertas y no
tiraremos de briefing hasta que tengamos huecos.

Estamos empezando por lo que no nos pongamos muy estrictos. Busquemos una
adaptación progresiva a los límites. Van pasando los días y nos vemos aquí:
Como vemos, hemos mejorado pero seguimos con problemas en oferta. Ya lo hemos
comentado, el equipo técnico (que también ha empezado con su Kanban) tiene problemas
para dedicarnos tiempo. Esto tiene sentido, ellos tienen su WIP limitado en su tablero y algo
no encaja ¿Cómo gestionamos el WIP si tenemos personas en dos tableros a la vez? Limitar el
WIP por persona y por columna.
La solución es muy sencilla, cada persona de la oficina tiene un número de imanes

asignados por colores y cada tarjeta en la que está trabajando tiene un imán de su color. Una
persona no puede hacer pull de ninguna tarjeta sin ponerle un imán encima. La gente de
producción técnica tiene dos imanes cada uno, gestión tres y comercial cinco.
En nuestro caso esto tiene un doble valor, nuestro equipo de desarrollo se ocupa de
las 3 fases que tenemos definidas (análisis, desarrollo y pruebas) por lo que la gente va
saltando de columnas según necesita. Por tanto nuestro tablero tiene esta pinta hoy en día:

Como podéis ver sólo limitamos el siguiente. El resto de límites dependen de los
imanes. Hemos eliminado fases de presupuestación ya que no nos aportaban valor (debido a
que los procesos de presupuestación no son nada lineales), además de colocar los dos tableros
juntos para mejorar la visualización. (Nota: Quizá os llame la atención el Backlog abajo, esto es
por un tema de espacio, nuestra pizarra es vertical).
Hagamos las políticas explícitas
Hemos llegado al punto anterior y aún así seguimos con un gran cuello de botella en
presupuestación (al haber eliminado columnas el cuello de botella afecta a toda la fase de
presupuestación) y seguimos sin conseguir que los técnicos dediquen tiempo a propuestas.
La parte de arriba del tablero está avanzando con fluidez por lo que llegado el
momento, siempre hay alguna tarea de la que tirar y por tanto nuestros técnicos no “bajan” a
presupuestación. Necesitamos regular esto, necesitamos algunas políticas y las debemos dejar
claras.
 Políticas visuales: Necesitamos visualizar las tareas bloqueadas. Nuestros

programadores no es que sean unos egoístas, es que no son conscientes de los
bloqueos que sufre la presupuestación. Introducimos las banderitas rojas que
vimos más arriba para indicar los bloqueos. Esto mejora, cuando vemos 3 o 4
tareas bloqueadas en presupuestación proactivamente ayudamos a desbloquear
tareas.
 Políticas de priorización: A pesar de que hemos mejorado seguimos
descompensados así que decidimos aplicar una política de priorización: cada dos
tareas de desarrollo finalizadas saltaremos a presupuestación si hay algún
presupuesto pendiente de la valoración técnica.
Estas políticas las escribimos debajo de la pizarra además de comunicarlas a todo el

equipo. Dependiendo de los roles establecidos esto puede ser responsabilidad del líder del
equipo o en equipos más auto-gestionados y maduros, discutido y decidido entre todos. Como
hemos dicho en varias ocasiones, las políticas han de ser explícitas y conocidas por todos.
Además, estas políticas nacen de la necesidad y del uso, no se impusieron el primer día, se
decidieron para mejorar un cuello de botella. Nuestro Kanban será más productivo cuanto más
adaptemos tanto el tablero como las políticas a nuestra organización. No se trata de dividir por
dividir ni introducir políticas al azar. No me cabe duda de que existen organizaciones que
trabajan muy bien con un tablero muy estándar y con muy pocas políticas.

Controlemos el flujo y midamos
Tenemos ya nuestro tablero inicial y nuestros límites, estamos funcionando y vemos el

valor que nos está aportando la visualización y el control del WIP. Queremos seguir mejorando
y empezaremos a buscar la mejora continua desde aquí. A partir de ahora queremos reducir la
variabilidad de nuestra cadena de valor, queremos empezar a funcionar como el horno de
telepizza.
Vamos a empezar a medir el Lead Time de las tareas que pasan por nuestro tablero y
nos fijaremos especialmente en aquellas tarjetas que sobrepasen la media de manera
significativa (si estamos tardando 6 días en finalizar una tarjeta, nos fijaremos en las de 10 o
más). Para poder evaluar este tipo de cuestiones necesitamos introducir las reuniones de
retrospectiva, busquemos un momento tranquilo (primera hora del lunes, última del viernes, o
la que sea buena para nosotros) y revisemos.
Os recomendaría que seáis pacientes si estáis haciendo una implementación muy

progresiva y no empecéis con las retrospectivas hasta que el equipo se empiece a encontrar
cómodo con el tablero y hayan llegado ya a cierto nivel de interiorización incluso hasta que se
hayan hecho las primeras mejoras y adaptaciones.
El objetivo de revisar estas tarjetas que exceden por mucho el Lead Time es iniciar una
conversación de mejora progresiva. Cuando estudiemos estas tareas es normal la conversación
fluya en las siguientes direcciones:
 Hemos tardado más porque era una tarea más larga. ¿Se podría partir? ¿Son
normales estas tareas de mayor tamaño? ¿Debemos empezar a trabajar con clases
de servicio diferentes para estas tareas?
 Ha habido problemas en la ejecución. ¿Se pueden evitar? ¿tenemos que mejorar
algún proceso? ¿podemos aprender de ello? ¿podemos establecer mecanismos de
control para que no vuelva a pasar (os acordáis del poka yoke)?
 La tarea se ha pasado mucho tiempo en cola. ¿Necesitamos revisar el tablero?
¿necesitamos revisar las políticas?
Que empiece la ciencia
En muchos textos sobre Kanban se habla de aplicar el método científico. A lo que nos
referimos con ello es a la mejora basada en la experimentación:
 Probar: juguemos con nuestro tablero, busquemos nuevas y mejores formas de

estructurarlo, nuevas políticas, buffers... todo es susceptible de cambiar y
evolucionar. No hay nada estático en una implementación Kanban.
 Observar y medir: una vez introducido un posible cambio o mejora observemos los

resultados, controlemos la métricas y analicemos las dinámicas.

 Validar: recogidos los datos validamos nuestra hipótesis: ¿he aportado valor?
¿hemos mejorado nuestros tiempos? ¿hemos mejorado la calidad?. Si no es así,
no pasa nada, volvemos al punto anterior y seguimos probando.
 Conclusión
 Las clases de servicio son una herramienta muy útil a la hora de adaptarnos de una
manera más concisa a los diferentes tipos de trabajo que realizamos en nuestra
organización.
 Las políticas explícitas nos ayudan a trabajar de una manera fluida, reducen el
tiempo dedicado a la toma de decisiones y nos ayudan estructurar el flujo así como
a buscar mejoras de calidad en la producción.
 Nuestra cadena de valor no es un elemento aislado, trabajamos en coordinación
con nuestros inputs de trabajo y con los receptores del mismo. Debemos acomodar
nuestro flujo y la forma en que priorizamos las diferentes entradas de trabajo para
buscar el mayor grado de satisfacción en todos nuestros stakeholders.
 Dividir el trabajo buscando unidades de producción de tamaño similar nos ayuda a
reducir la variabilidad produciendo una entrega continua de valor. Hemos visto
también el valor de estructurar estas divisiones centrándonos en su valor añadido
de cara al mercado.
La gestión de cambio es una labor compleja. Kanban permite una integración evolutiva
sin realizar cambios bruscos de roles o procesos que nos ayuda a reducir la resistencia al
cambio. Aprender de los resultados y experimentar con nuestra implementación creará una
mejora continua en nuestra forma de trabajar así como en la calidad de lo que producimos.

3.3. Kanban III. Mastering Kanban
En la primera unidad de Kanban vimos los conceptos más generales, las herramientas
básicas y la forma de trabajar con esta metodología.
En la segunda vimos cómo adaptar de una manera más precisa Kanban a nuestros
equipos de trabajo. También estudiamos cómo abordar la implantación de Kanban en un
equipo pequeño y cómo gestionar el cambio.
En esta tercera unidad profundizaremos en:
 Cómo conseguir mejorar de forma continua nuestros procesos.

 Scrumban, tomando lo mejor de Scrum y de Kanban.
 El despliegue de Kanban en una organización de mediano o gran tamaño[1], que
puede o no estar acostumbrada a metodologías ágiles y en el tratamiento de
proyectos de cierta entidad.
 Finalmente entraremos en una problemática específica, las herramientas a utilizar,
especialmente en los tableros virtuales.
[1] Muchos de los aspectos comentados aquí han sido observados en el despliegue de
Kanban en el área de desarrollo de Destinia.com, con 40 ingenieros de desarrollo y
programadores divididos en seis equipos de trabajo.Con una tradición de desarrollo por ciclos
cortos y necesidades de negocio cambiantes, Kanban fue introducido hace cuatro años y desde
hace dos años se ha introducido Scrum para proyectos cruzados. Actualmente (2015) se
comienza a implantar Scrum de forma general para proyectos y Kanban para mantenimientos
y bugs. Algunas de las mejores prácticas observadas se comentan en los siguientes apartados.
3.3.2. PROCESOS DE MEJORA SISTEMÁTICA EN KANBAN
En las unidades anteriores hemos vuelto una y otra vez sobre el concepto de mejora
continua ya que si recordáis, consideramos Kanban como un catalizador del proceso de
mejora.
De hecho, la propia implantación progresiva de Kanban en nuestra empresa como un

proceso de mejora continua en sí misma pero a partir de cierto punto de madurez, una vez que
nos hacemos con las riendas del tablero, nos surge la siguiente pregunta:

¿Cómo podemos seguir mejorando?
En este apartado nos vamos a centrar en los cuellos de botella, la reducción del gasto y
la reducción de la variabilidad a través de modelos que nos ayudarán a identificar estas
oportunidades de mejora y nos aportarán maneras sistemáticas de abordarlas.
 Cuellos de botella
Cuando hablamos de cuellos de botella no necesitamos una definición estricta, todos

tenemos una idea intuitiva de qué es un cuello de botella (si las botellas no tuvieran un cuello
que limitara la salida del líquido del interior cuando las inclinamos verterían todo su contenido
sin control). En Kanban, se entiende por cuello de botella, aquello que limita el flujo de
contenido que pasa a través suyo.
Un cuello de botella en el flujo de nuestro tablero es un punto (proceso, columna, fase,

recurso,…) que está limitando la cantidad de tarjetas que pasan a través de él. Esto sucede
cuando los procesos anteriores al cuello de botella despachan tarjetas a una velocidad media
mayor. Los cuellos de botella surgen por dos causas fundamentales:
 Capacidad insuficiente. Este tipo de cuellos de botella surgen cuando el equipo que
trabaja en una columna no es capaz de producir todo el trabajo necesario para
mantener el ritmo de producción de los procesos anteriores. Esto no quiere decir a
priori que el equipo esté mal dimensionado o no sea eficiente, sólo indica que el
cuello de botella se produce por una descompensación entre la velocidad de
producción las fases anteriores y la del cuello de botella.
 Recursos de acceso limitado. Estos cuellos de botella surgen cuando dependemos
de recursos (ya sean personas, otros departamentos, elementos ajenos a nuestra
organización...) de los que no disponemos de manera instantánea y nos bloquean.
Para ilustrar la diferencia, os pondré un ejemplo: Supongamos que para hacer mi

trabajo requiero del servicio de reprografía de la empresa pero siempre están hasta arriba y no
dan abasto...claramente, son un cuello de botella por falta de capacidad. Supongamos ahora
que el servicio de reprografía no es muy utilizado y que, para reducir costes la empresa, se ha
reducido su horario de 10 a 12 de la mañana. Yo dependo de ellos para presentar mis informes
y me bloquea que estén cerrados el resto del día. Son un cuello de botella ya que son un
recurso de acceso limitado.

Qué hacer cuando la capacidad no es suficiente
La solución más inmediata que viene a nuestras cabezas cuando detectamos un cuello
de botella por falta de capacidad, es aumentar en número de recursos. Es decir, si el equipo de
consultores del proyecto no es capaz de cumplir plazos contratamos un consultor más.
Probablemente esta sea la única opción en algunos casos, pero en la mayor parte de
ellos será una opción equivocada ya que introducir un nuevo miembro en el equipo nos va
conllevar un aumento de costes que tendremos que estudiar y analizar para valorar su
rentabilidad (inversión vs beneficio), un proceso de selección que probablemente quite tiempo
a los consultores (queremos que revisen los perfiles para buscar al mejor candidato para el
proyecto) y un proceso de formación que una vez más va a quitar tiempo al equipo de
consultores que está trabajando. Durante un periodo de tiempo no despreciable (en mi
empresa históricamente 2 meses) el nuevo recurso quitará más tiempo del que aportará. En
muchos contextos (no todos) añadir un nuevo recurso a un proyecto en marcha sólo servirá
para retrasarlo todavía más.
Por otro lado, somos Lean y queremos reducir el gasto y maximizar la eficiencia.
Contratar nuevos recursos será nuestra última opción pero, ¿podemos mejorar el rendimiento
del cuello de botella? Os propongo una serie de enfoques sistematizables que nos pueden
ayudar a buscar soluciones:
 Centrar el trabajo del equipo en tareas de valor añadido. En el día a día todos
tenemos 3 tipos de tarea:
◦ de valor añadido (realizar la consultoría)
◦ sin valor añadido pero necesarias (maquetar los documentos)
◦ sin valor añadido e innecesarias (rellenar un parte de horas que nadie está
revisando).
 Para eliminar el cuello de botella, debemos favorecer que nuestro equipo se centre
en las tareas de valor añadido y para ello vamos intentar eliminar las tareas
innecesarias y vamos intentar apoyar al equipo en las tareas necesarias que no son
de valor añadido. Por ejemplo, en la oficina de consultoría del ejemplo anterior
haremos que todos puedan maquetar correctamente un documento y llevarlo a
impresión y por tanto, podamos descargar de este tipo de tareas (sin valor añadido)
con otros recursos más libres.
◦ Para averiguar qué tareas son de uno u otro tipo, hay 2 preguntas que debemos
responder:
▪ ¿Qué tarea o responsabilidades podemos eliminar?
▪ ¿Qué tareas o responsabilidades del cuello de botella son delegables?
 Automatizar tareas. Incluso dentro del proceso de generación de valor añadido
realizamos muchas tareas sistemáticas que, en algunos casos, pueden ser
automatizables. Analicemos con el equipo del cuello de botella su trabajo por un
momento, en busca de tareas repetitivas o automatizables: Nuestros consultores
realizan una serie de cálculos financieros complejos en busca de ciertos
indicadores, invirtamos un poco de tiempo en automatizar las hojas de Excel. Si

además de ello el Excel a través de las fórmulas pre-genera parte del informe en
formato Word estaremos quitando/reduciendo el tiempo de redacción.
 Demos prioridad a los bloqueos del cuello de botella. Los bloqueos interfieren en el
correcto desempeño de todo el equipo de trabajo. A pesar de ello en muchos casos
puede ser sensato dar mayor prioridad a la resolución de los bloqueos del cuello de
botella. Es el cuello de botella el que está limitando el flujo y por tanto sus bloqueos
afectan con mayor impacto en el desempeño global del tablero. Si este es el caso
de nuestros consultores estableceremos una política para dar mayor prioridad a sus
bloqueos. Podemos acompañar esta política con un indicador visual propio (un
indicador de otro color) que nos ayude a visualizar estos bloqueos “más urgentes”
en nuestro tablero.
 Evitemos que el cuello de botella se quede sin trabajo. Vimos esto cuando
hablamos de los buffers en la primera unidad.
 Miremos fuera del cuello de botella. En muchos casos los cuellos de botella se
producen fuera del mismo pero no nos damos cuenta. Por ejemplo, puede ser que
el trabajo previo entregado al cuello de botella tenga defectos que ralentizan el
trabajo dentro del mismo. El cuello de botella se produce en un punto pero
tenemos que buscar la causa en fases anteriores.
Cómo identificar tareas que no aportan valor añadido para maximizar producción
Como acabamos de ver en el punto 1 del apartado anterior, reducir las tareas que no
aportan valor es importante para aliviar un cuello de botella. Dar nombre a este tipo de tareas
nos ayudará a identificarlas y buscar soluciones.
En el mundo Lean, se habla muy frecuentemente de los Mudas (gastos o mal gastos)
que se suelen clasificar como gastos derivados de: sobreproducción, espera, transporte,
inventario, movimiento y exceso de procesamiento. En el mundo de la gestión de proyectos
simplificamos a 3 tipos de gastos o costes (dado su carácter necesario a veces el término coste
nos ayuda a pensar de una manera menos negativa):
 Gastos de transacción: Son todos aquellos gastos derivados del proceso de

preparar, gestionar y finalizar el trabajo. Por ejemplo, para realizar una auditoría
necesitamos un cuaderno para tomar notas y, por tanto, la tarea de comprar un
cuaderno es necesaria (no se puede eliminar), luego es un gasto de transacción,
hay que hacerlo pero no aporta valor. Dado que son necesarios (no perdamos esto
de vista, ya hemos eliminado los no necesario) podemos minimizarlos,
automatizarlos o re-asignarlos. No vayamos a la pizzería llamemos a Telepizza o
compremos el cuaderno en Kalamazoo.
 Gastos de coordinación: Consideramos gastos de coordinación a todas las tareas
enfocadas a organizar a los miembros del equipo. Que pueden ir desde emails
hasta reuniones o incluso la propia gestión del tablero. Por ejemplo, cuando estoy
hablando contigo por teléfono para preguntarte cuando crees que me vas a poder
enviar los resultados de tu informe o esa pieza que necesito para acabar el trabajo,
estoy gastando tiempo y no estoy, necesariamente, generando valor ( en términos
sencillo a nuestro cliente no le aporta ningún valor).
 Gastos derivados de defectos previos: En muchos campos (en el mundo del

software de manera muy importante) nos pasamos parte de nuestro tiempo

corrigiendo errores. Solucionar un problema de diseño en un producto es
necesario, hay que hacerlo, pero es un gasto que podríamos haber evitado de
haber entregado el diseño con una mayor calidad en origen. Analicemos si nuestro
cuello de botella pierde mucho tiempo derivado de errores (tanto suyos en forma
de tareas de corrección) como de otras fases o columnas del tablero; si es así,
deberemos valorar soluciones que pueden pasar por mejorar el control de calidad
o automatizarlo, buscar mecanismos o prácticas que eviten los errores, formación...
son muchas las soluciones en función de la causa del problema. (NOTA: ¿Os
acordáis de Jidoka y Poka-yoke? Si no, revisa la introducción de la primera unidad
de Kanban).
Si dudamos sobre si una tarea es o no de valor añadido preguntémonos: ¿Quiero tener

más tiempo para este tipo de tareas? Si la respuesta es negativa probablemente no. No quiero
más tiempo para comprar cuadernos, ordenar material, preparar el trabajo, llevar o traer
cosas, encender o apagar sistemas, instalar software, … Por el contrario si quiero más tiempo
para pulir, armar, estructurar, diseñar, presupuestar, analizar...
Cómo mejorar la eficiencia de los recursos de acceso limitado
Por desgracia por su propia naturaleza es bastante más complicado optimizar este tipo
de cuellos de botella. En muchos casos una vez que tenemos accesible el recurso el flujo se
libera rápidamente, lo que nos suele bloquear es la imposibilidad de avanzar en el flujo sin su
intervención.
Utilizaremos un buffer para evitar que el flujo se detenga en las fases anteriores al
cuello de botella estudiando el límite con cuidado. Imaginemos que para poder dar una pieza
por acabada y pasarla a la siguiente fase en una cadena de montaje necesitamos que alguien
del equipo de calidad la revise. Un miembro del equipo de calidad (que tiene otras tantas
tareas que controlar) dedica una hora al día a esta labor. Supongamos en una hora puede
revisar 4 piezas. El límite lo estableceremos en 4, si lo ponemos más alto se irán acumulando
revisiones de un día al siguiente y no servirá de nada, si por el contrario lo hacemos inferior es
probable que infra utilicemos este recurso cuando esté disponible.
Fijémonos en un detalle. Dado que el proceso de revisión es rápido y suponiendo que

normalmente no se producen más de 4 piezas al día el problema no es de sobrecarga, el
sistema está bien dimensionado. Podemos pensar en soluciones creativas. Si en vez de dedicar
a revisión una hora (pongamos por las mañanas), se dedican dos medias horas (mañana y
tarde), se habrá dedicado el mismo tiempo pero se habrá aliviado mucho el cuello de botella
permitiendo a los procesos posteriores al cuello de botella trabajar de una manera mucho más
fluida. Además podremos reducir el límite del buffer a la mitad y reduciremos nuestro Lead
Time.

Con este tipo de cuellos de botella tendremos que pensar de manera creativa, los
motivos que reducen la disponibilidad de recursos son muy dependientes de la cadena de
valor y la mayor parte de las veces no está en nuestra mano ampliar la disponibilidad del
mismo. De igual manera que con los problemas de capacidad, como última instancia y, si es
factible, podemos ampliar la disponibilidad del recurso o incluso convertir a nuestro recurso de
disponibilidad limitada en un recurso de disponibilidad inmediata. Tendremos que analizar los
costes y alternativas de cara a minimizar el gasto.
 Fuentes de variabilidad
Hemos venido hablando a lo largo de los capítulos de lo importante que es reducir la

variabilidad dentro de nuestro tablero con el objetivo claro de reducir el Lead Time.
Reducir la variabilidad nos ayuda a aumentar la predictibilidad, mejora el feedback y

hace al equipo más flexible y adaptable.
Igual que hemos hecho con los cuellos de botella, ahora vamos a fijarnos con
detenimiento en las fuentes variabilidad, identificándolas y buscando mejoras y soluciones.
Existe una primera gran división en las fuentes de variabilidad:
 Fuentes internas: Dependen de nosotros, de nuestras políticas, nuestros procesos,

la forma de trabajo, la coordinación del equipo, etc. Son fuentes de variabilidad
sobre las que podemos trabajar dentro del equipo.
 Fuentes externas: Las fuentes externas son de naturaleza muy variada, las
identificamos porque escapan a nuestro control directo. Una fuente de
variabilidad externa puede ser desde nuestros clientes que distribuyen sus pedidos
de una manera poco predecible creando picos y valles de trabajo dentro de
nuestro equipo hasta la lluvia que puede dificultar nuestro trabajo si somos, por
ejemplo, una empresa de mantenimiento del alumbrado público.
Sobre las primeras podremos influir desde nuestro tablero y sus políticas así como con
la mejora técnica de procesos dentro de nuestro sector. Sobre las segundas no podemos influir
pero identificarlas nos va a ayudar a mitigar sus efectos sobre el flujo y establecer mecanismos
para reducir su impacto. No podemos impedir que llueva pero podemos hacer que la lluvia no
sea un problema.

 Fuentes internas de variabilidad
Recordad siempre que estamos buscando un flujo estable con una cadencia
predecible, no necesariamente intentar ir muy rápido si eso nos genera variabilidad en la
entrega de valor. Por ejemplo, prefiero una ducha con un chorro constante aunque no sea muy
fuerte, que una con un chorro de agua cambiante; la segunda no genera confianza.
Fuentes internas de variabilidad
1) Tamaño de nuestras tarjetas: Tarjetas de muy diferentes tamaños en nuestro flujo generan
una alta variabilidad en el Lead Time medio de nuestro tablero. Hablamos en la unidad
anterior de buscar tarjetas de tamaño similar (de pocos días preferentemente).
La experiencia, tanto en el desempeño técnico como en el trabajo con nuestro equipo,

no ayuda a dividir el trabajo en tareas similares de una manera natural pero nos podemos
ayudar también de otras herramientas para ello.
Y el uso de plantillas a la hora de definir y redactar nuestras tarjetas nos ayuda a

homogeneizar las tareas y su tamaño.
Es típico en equipos que utilizan XP o scrum, verles trabajar con plantillas para definir
las historias de usuarios del tipo: “Como usuario quiero esto para aquello”. Esta plantilla da pie
a historias del tipo: “Como administrador quiero un resumen diario de actividades para
mejorar la visibilidad sobre el sistema”.
En el caso de kanban, no es necesario que usemos historias de usuario para definir

nuestras tareas, ya que podemos utilizar plantillas sea cual sea nuestra forma de dividir el
trabajo. Por ejemplo: “En dónde debemos reparar qué” puede ser un plantilla válida que evite
tareas poco específicas como “reparaciones menores en planta 7” que generan variabilidad en
un equipo de mantenimiento.
2) Distintos tipos de tareas y clases de servicio: Una de las mayores causas de variabilidad en
las primeras fases de Kanban es tratar los distintos tipos de tarea de igual manera. Por
ejemplo, podemos resolver incidencias a una velocidad de 2 al día y realizar avancen en el
proyecto a razón de 1 tarjeta a la semana. Si no separamos estas tareas en clases de servicio
distintas llegaremos a la conclusión de que nuestro Lead Time medio es de 3 días pero
tenemos una variabilidad enorme, por el contrario identificando las tareas correctamente

sabremos que cada clase de servicio tiene su Lead Time medio con una variabilidad mucho
más baja.
De esta manera, también podremos ajustar los límites del WIP por clase de servicio lo
que nos ayudará a establecer políticas que nos ayuden a resolver la interacción entre las
distintas clases de servicio. El Touch Time es un dato importante en este proceso ya que, por
ejemplo, podemos tener un Lead Time de 10 días en el tablero para una clase de servicio
concreta con un Touch Time de 1 día. Esto no es bueno o malo pero se, es un indicador que
nos ayuda a entender más profundamente el flujo y tomar decisiones en las políticas del
tablero.
3) Volver sobre lo ya trabajado: Este en un problema recurrente que abordamos en el proceso

de mejora desde todos los ángulos. Tenemos que volver a trabajar sobre una tarea que ya salió
del tablero por causa de errores o una baja calidad en el desempeño de la tarea. La gestión de
estas tareas es compleja y divide al equipo de producción entre la generación de valor y la
corrección de errores, aumentando la multitarea, el WIP, el esfuerzo de gestión... . Podemos
generar valor nuevo cada 3 días de touch time, pero si las tareas de corrección de errores nos
entorpecen el avance nuestro Lead Time se verá muy perjudicado.
Como hemos dicho antes, estas fuentes de variabilidad están centradas en el flujo y
son las que podemos trabajar desde Kanban de una manera independiente.
Además de las anteriores, existen otras fuentes internas que tienen que ver con el área
de trabajo específica y que deberemos trabajar, por tanto, con las herramientas técnicas
específicas. Si bien Kanban nos ayudará a identificar estas fuentes de variabilidad porque:
 Nos pondrá de manifiesto bloqueos por columnas.

 Nos ayudará a controlar la variabilidad por clases de servicio.
Está en nuestra mano seguir profundizando en las métricas para que, de igual manera
que medimos el Lead Time, Cycle Time y Touch Time podamos medir el tiempo que pasa una
tarea en cada una de las columnas o procesos para así identificar los puntos de mayor
variabilidad dentro del tablero...

Fuentes externas de variabilidad
En muchos casos por muy maduro que sea nuestro proceso, nuestra gestión del flujo,
nuestra capacidad técnica... seguimos teniendo un alto grado de variabilidad por elementos
que escapan a nuestro control. Por eso, de la misma manera que identificamos las fuentes de
variabilidad interna con el objetivo de reducirlas, debemos identificar las fuentes de
variabilidad externas para adaptarnos a ellas, mitigar su impacto y volvernos flexibles antes
elementos que no podemos controlar.
Las principales fuentes de variabilidad externa son:
1) Ambigüedad en los requisitos: En muchos casos el cliente de nuestra cadena de valor no es

capaz de transmitir correctamente sus necesidades. Los informáticos nos pasamos la vida
echando la culpa de los retrasos al cliente: no sabe lo que quiere, me cambia los requisitos a
mitad del proyecto... Esta fuente de variabilidad es constante tanto en la informática como en
otros campos y en gran medida, es inherente al mundo cambiante en el que vivimos y al lógico
desconocimiento de nuestro campo por parte del cliente.
Pero recordad: nosotros somos Lean, flexibles y ágiles sabemos que los proyectos
mutan y pivotan y eso nos gusta, porque eso los hace mejores. No veamos el cambio como un
riesgo, asimilamos formas de trabajo que nos anticipan a los cambios y que trabajan con cierto
grado de ambigüedad de manera natural.
Como recomendación: cuando nos bloqueemos en tarjetas debido a ambigüedades o

falta de definición en las tareas, debemos disponer de mecanismos establecidos para la
resolución de estas ambigüedades. Por ejemplo: es necesario que estas “incidencias” escalen
rápidamente hasta el nivel adecuado para su resolución, puede ser un Product Owner dentro
de nuestra organización o un cliente de nuestra empresa. No disponer de una política clara en
estos casos nos llevará a bloqueos constantes y dilatados que generarán un alto grado de
variabilidad (NOTA: recordad cuando hablábamos en el capitulo anterior de las políticas del
proyecto/organización).
2) Expedites: Vimos esta clase de servicio en la unidad 2. Son tareas que por su naturaleza
alteran el flujo, alteran los límites y dejan al resto de elementos en segundo plano pero ¿cómo
afrontar este tipo de tarjetas para evitar que afecten negativamente a la variabilidad?
dependerá de la frecuencia de éstas de tal forma que si es baja, su impacto será bajo también
pero si es alta, podremos:

 Reservar espacio de producción. Si son frecuentes reservemos hueco en el tablero,

reduzcamos los límites de nuestro WIP y creemos una fila para estas tareas.
 Intentemos reducir nuestro Lead Time y maximizar la entrega de valor. Para un
equipo ágil los expedites no lo son tanto. Además la entrega constante de valor y la
confianza generada en nuestros clientes hace que aparezcan menos expedites
quedando absorbidos por el flujo normal de trabajo.
 Limitar el número de expedites. Si nos conseguimos reducir su impacto en el
tablero deberemos plantearnos decir no y limitar el número de expedites hasta un
nivel asimilable por el equipo. Esto puede significar decir que no a pedidos, hablar
con nuestros inputs o con la dirección de la empresa. Este proceso puede no ser
fácil ya que entramos en decisiones a nivel de negocio que pueden estar por
encima de nuestro equipo o que pueden ser vistas como un riesgo y deberán ser
consensuadas a todos los niveles.
3) Variabilidad del mercado: El mercado es cambiante....a veces de manera predecible, otras

de manera estacional y en muchos casos, de manera impredecible, pero nuestro equipo se ha
de adaptar a la demanda de manera flexible con lo que se requiere conocer perfectamente el
mercado para adaptarnos a la variabilidad conocida o predecible, y gestionar los riesgos de
posible cambios no predecibles (como la cancelación de un proyecto en curso).
Si disponemos de un equipo pequeño que se adapta a un mercado en temporada baja

tendrá problemas para gestionar las temporadas altas y si lo hacemos al revés, probablemente
tendremos un equipo sobredimensionado para el resto del año. Por ello, en algunos caso
contar con recursos temporales externos (outsourcing, freelances, becarios) de apoyo puede
ser un buena solución para momentos de mucho movimiento (las pastelerías en navidad, por
ejemplo) pero esto no siempre es fácil en campos de mucha especialización. De hecho, la re-
asignación temporal de recursos dentro de una misma empresa entre equipos es una
estrategia normal. Hay empresas de desarrollo que cuentan con un equipo para cada producto
del portfolio, además de con un pool de desarrolladores de apoyo que dan soporte a los
equipos que más necesitan de ellos, además esta reasignación puede ser parcial (la mitad del
día por ejemplo).
Estos tres tipos de variabilidad externas son tres tipos muy comunes, pero existe una
lista interminable de elementos que escapan al control de nuestra cadena de valor y que, sin
embargo, debemos tener en cuenta porque pueden afectar a nuestro Lead Time. Tratemos de
identificar y mitigar su efecto con las estrategias adecuadas en cada caso y sobre todo !seamos
ágiles!
Tiempos reducidos de entrega de valor y una alta calidad en la producción nos ayudan
a responder de manera ágil a los cambios, pero la agilidad, sobre todo, es una actitud del
equipo que debemos fomentar. El propio proceso de mejora asociado a la naturaleza de
Kanban y la introducción continua de mejoras en los procesos crea en la organización un clima
propicio para la adaptación rápida y orgánica de cambios.

Otras técnicas
Existen multitud de técnicas para abordar la resolución de problemas de manera

sistemática, durante los anteriores epígrafes hemos visto reflexiones sistemáticas muy
enfocadas hacia Kanban.
Podemos utilizar muchas otras técnicas para abordar y plantear mejoras en nuestro
equipo. El valor de estas técnicas es darnos un marco y un enfoque concreto a la hora de
buscar y resolver problemas. Os dejo un enlace para que tiréis del hilo y sigáis investigando
sobre el tema: 5Ms
3.3.3. SCRUMBAN
Llevamos muchas páginas hablando sobre las bondades de Kanban y aunque son
muchas, la gran mayoría las comparte con otras metodologías ágiles también (os digo esto
porque lo último que podemos ser, si nos queremos considerar agile, es dogmáticos ya que,
como ya sabéis, cada metodología se adapta mejor a unas circunstancia u otras). Además, no
debemos olvidar que cualquier metodología es una herramienta que podemos retocar y
adaptar a nuestras necesidades (en Kanban no hay otra manera).
En este apartado, nos vamos a centrar en jugar con dos metodologías que, por su
naturaleza, son muy mezclables. Como expone en el libro: “Saquemos lo mejor de los dos”.
 Dos metodologías para dos escenarios: Scrum-Kanban
Desde un punto de vista Lean de entrega constante de valor, Kanban y el concepto de

flujo continuo, busca entregas de valor ininterrumpidas. Mientras que en Scrum, estas
entregas de valor están encapsuladas temporalmente en sprints que nos limitan la capacidad
de decisión. Ambos enfoques tienen sus ventajas: La entrega de valor constante genera una
gran confianza por los clientes de nuestra cadena de valor pero es más complicada de
planificar, por lo menos, hasta alcanzar cierto nivel de experiencia con el método. Por el
contrario Scrum focaliza muy bien el trabajo, genera un pulso muy fuerte y es más fácil de
planificar pero se adapta peor a cambios de planificación necesarios.
Pongamos por ejemplo que establecemos un sprint para las próximas tres semanas
con el objetivo de restaurar 10 motocicletas custom a nuestros clientes. Damos inicio al sprint
y nos encerramos en nuestro taller. A mitad de sprint aparece un cliente importante como dos
motos que quiere reparar de manera urgente ya que quiere participar en un concurso la
semana próxima. ¿Cómo gestionamos esto en Scrum? Estamos en un aprieto, nos hemos

comprometido a cumplir el sprint y tenemos al equipo 100% dedicado a ello pero no podemos
decir que no a nuestro cliente y su concurso.
En general en Scrum vamos a tener problemas con replanificaciones necesarias a

mitad de sprint, mientras que en Kanban estaríamos trabajando con un tablero y unas clases
de servicio que se adaptarían a esta situación sin excesivo problema, ya que nada nos impide
poner las reparaciones en marcha en cuanto tengamos capacidad en el sistema eso si, a costa
de replanificar las tareas que estuvieran en nuestro “pendiente”.
Por otro lado, cuando podemos cerrar el foco y trabajar sin interrupción en un
proyecto (o varios) sin tener que dar soporte urgente ni atender a “expedites”, la limitación
temporal de Scrum crea un pulso muy fuerte que insta al equipo a trabajar de manera ágil y
muy alineada lo que hace que la planificación de un proyecto en base a Sprints sea más
sencilla, y, llegado el caso, más sencilla de negociar con un cliente, desde un punto de vista
contractual.
En mi empresa, empezamos trabajando con Scrum hace cosa de un año pero dada la
naturaleza cambiante y poco predecible del trabajo en el mundo publicitario éramos incapaces
de trabajar con sprints de manera correcta. Las replanificaciones son constantes, los proyectos
muchas veces llegaban y se entregaban en mitad de una Sprint impidiendo además la
finalización del Sprint Backlog. Llegamos a trabajar con distintos tableros de Scrum, con
distintos plazos de sprints y con el mismo equipo... un lío. Por el contrario en el tiempo que
llevamos trabajando con Kanban, tenemos una sensación mucho mayor de control y orden.
No hay verdades absolutas, no es mejor Kanban o Scrum o Scrumban, es mejor uno

concreto para un equipo y contexto específico. Conozcamos las herramientas y usemos la más
adecuada.
 Lo mejor de cada casa
Vamos a ver cómo podemos utilizar Scrumban para intentar obtener los beneficios de
ambas metodologías aplicando un método que ya conocemos. Scrumban es una mezcla de
ambas metodologías pero esta mezcla no es exacta, Scrumban requiere de una adaptación
aplicada a nuestro contexto y a nuestro equipo. Para realizar esta adaptación nos podemos
valer de un método que ya conocemos: La gestión evolutiva del cambio con Kanban.
Para mí es más sencillo ver Scrumban como un scrum potenciado con los conceptos de flujo y
límites del WIP: apliquemos Kanban a nuestro Scrum.

Limitando el WIP de nuestro Kanban
 Partimos desde donde estamos, Scrum: roles y procesos que ya conocéis.

 Visualizamos la cadena de valor. Es muy normal que los equipos de trabajo en
Scrum utilicen tableros similares a los de Kanban pero, es menos normal que se
refleje el trabajo en producción como un flujo de procesos independientes
conectados por su upstream y su downstream a la cadena. Aprovechemos el gran
poder de visualización de Kanban para adaptar el tablero de Scrum a nuestro flujo
de trabajo.
 Limitemos el WIP. Como primera aproximación podemos ver Scrumban como
Scrum con dos límites de WIP distintos:
◦ Límite de de historias de usuario por Sprint
◦ Límite de tareas simultáneas o límite por columnas.
 Establezcamos políticas: Si empezamos por establecer las políticas más básicas de
Kanban habremos evolucionado rápidamente hacia un modelo Pull dentro de
Scrum.
Este primer acercamiento a Scrumban (perfectamente válido en sí mismo) se centra en

re-convertir en Sprint en un flujo continuado y así, empezar a trabajar con una metodología
Pull, de tal forma que estaríamos reduciendo el WIP simultáneo y ya, sólo con eso, habremos
introducido en Scrum la eliminación del gasto que conlleva el exceso de multitarea, habremos
mejorado la visualización y , sin darnos cuenta, habremos abierto el camino a nuevas mejoras
derivadas del control del flujo (empezaremos a identificar cuellos de botella de manera
natural).

En el siguiente ejemplo hemos introducido límites de WIP en las columnas To Do e In

Process:
Al limitar el WIP de estas columnas hemos llevado el concepto de flujo a Scrum,

limitando la cantidad de trabajo simultáneo que está llevando a cabo cada miembro del equipo
e introduciendo la forma de trabajo Pull. Con este pequeño cambio hemos introducido el flujo
a nivel de Sprint, seguimos trabajando con Scrum a todos los niveles. Este cambio es aplicable,
en principio, a cualquier equipo de Scrum que quiera aprovechar las ventajas de evitar el
exceso de multitarea.
Una fila para tarjetas fuera de Sprint
En Scrum la capacidad de replanificación está limitada al comienzo de cada nuevo

Sprint. Esto permite focalizar mucho el trabajo, pero en muchos escenarios no es factible al
100%. Muchos equipos de producción tienen que atender también tareas de corrección de
errores de manera urgente, no pudiendo esperar al siguiente Sprint para ello. En muchos casos
surgen pequeños proyectos / tarjetas de gran valor que debemos poner en producción de
manera inmediata (expedites). Si este es nuestro caso podemos seguir añadiendo elementos
de Kanban a nuestro tablero.

Nos gusta planificar en Sprints pero queremos ser capaces de aceptar tarjetas
importantes de manera natural sin que esto suponga una interrupción importante para el
avance de los sprints ni terminarlos en plazo. Para lograr esto, vamos a dividir el trabajo y, por
tanto, el tablero en dos zonas:
 Tarjetas Scrum: Son las historias o sub-historias de usuario con las que veníamos
trabajando hasta ahora. Tareas que por su naturaleza se adaptan correctamente al
concepto de Sprint: Nuevos desarrollos, corrección de errores no críticos, etc.
 Tarjetas Kanban o fuera de Sprint: En esta clase de servicio (o conjunto de clases)
acomodaremos todas esas tarjetas que surgen en cualquier momento del trabajo y
por motivos de negocio, estrategia, etc. no pueden esperar al próximo Sprint.
También podemos usar esta división a la hora de planificar un nuevo Sprint para
tareas de mucho valor que queremos poder entregar antes del final del Sprint que
estamos planificando. La Zona Kanban no entiende de Sprints, las tarjetas entran
cuando lo determinamos y salen cuando se finalicen. Se guían por su propio flujo.
Como veis hemos introducido una nueva fila dentro del tablero y hemos seleccionado
un color propio para la tarjetas fuera de Sprint. Es hora de definir las políticas de este nuevo
tablero:
 La zona superior o zona de Sprint funcionará siguiendo la forma de trabajo de

Scrum que viniéramos utilizando hasta ahora. No sufre ninguna modificación.
 La zona inferior o fuera de Sprint funcionará como un tablero Kanban. Esto
significa que deberemos ir trabajando en su estructura, límites, etc. para
adaptarlo a este tipo de tareas y su naturaleza concreta (errores, expedites, ...).
Dada la complejidad añadida es normal que el nivel de adaptación de este tablero
inferior sea menor que en una implementación Kanban pura.

Como veis, hemos hecho poco más que juntar dos tableros en uno. La clave es la
convivencia. Partimos lógicamente de que un mismo equipo va a atender las dos partes del
tablero y para ello tenemos que crear hueco. Nuestra capacidad de producción bruta no ha
aumentado en principio luego, en principio, el límite de WIP total tampoco debe aumentar.
Tenemos que fijar límites para todo el tablero razonables y probablemente deberemos reducir
un poco la cantidad de trabajo planificada para un Sprint con el objetivo de reservar espacio de
producción para la zona inferior.
La labor de equilibrar adecuadamente los límites de WIP entre los dos tableros será
progresiva además de flexible. Por ejemplo, si vamos a poner a disposición del público un
nuevo producto en el que hemos estado trabajando es probable que en los primeros sprints
después de este lanzamiento aumentemos los límites de la zona inferior y reduzcamos los
superiores para poder atender las incidencias propias del lanzamiento. Consecuentemente
adaptaremos la carga de los Sprints para que nos dé tiempo a cumplir los plazos del mismo.
Breve nota sobre métricas
Estamos mezclando dos metodologías y también sus métricas. Las métricas en cada
una de las metodologías son importantes para el correcto desempeño y la mejora.. por tanto,
parece sensato intentar mantener las métricas de cada parte del tablero. Si esta sobrecarga es
excesiva, en lo que a la zona Kanban se refiere, podemos trabajar exclusivamente con el Lead
Time medio.
NOTA: esta métrica es fundamental de cara a la planificación y la visibilidad del flujo.
 Aplicando los procesos de mejora continúa
Con la segunda aproximación que hemos visto hemos generado todavía más valor, no
sólo contamos con los beneficios de limitar el WIP sino que ahora somos capaces de dar cabida
a tareas que desestabilizan cualquier Sprint.
Ni Scrum, ni Kanban son dos ciencias exactas y, por tanto, la suma de ambas tiene
unos límites menos claros aún. Estamos mezclando y en este proceso nos vamos a quedar en
el medio o más cerca de uno de los extremos. El dónde dependerá mucho de cómo trabajemos
la mejora continua y qué se adapte mejor de cada metodología a nuestro equipo.

Lo normal en Scrumban es mantener los roles y reuniones establecidos por Scrum, de

hecho es muy normal que equipos que usan Kanban en el mundo del desarrollo de software
utilicen estos mismos roles y reuniones porque resultan muy naturales y útiles. No por ello
debemos dejar de eliminar o modificar aquellos artefactos que no nos aporten valor.
A partir de aquí experimentemos, midamos, experimentemos y mejoremos. Hemos

visto un nivel de integración de tableros sencillo, sin profundizar en aspectos específicos de
sectores o equipos concretos. Tenemos mucho espacio para la mejora y la adaptación aquí.
Hemos visto también a lo largo de esta unidad y de las anteriores guías e ideas que
podemos aplicar manera sistemática para mejorar el flujo. Todos ellos nos pueden ayudar con
Scrumban, nuestro Scrum ahora tiene flow y podemos optimizarlo.
3.3.4. ESCALANDO KANBAN
Hasta ahora hemos visto la implantación de Kanban en organizaciones de reducidas

dimensiones, en un pequeño equipo de trabajo. Nos ha servido especialmente bien para
iniciarnos en Kanban y es extremadamente útil si estamos pensando en su aplicación directa
en una startup o una organización pequeña de reciente creación.
Sin embargo y con toda probabilidad, nos encontraremos también organizaciones de

un tamaño mediano o grande, que requieran de una optimización de sus procesos de trabajo,
con departamentos de 10, 30 o 100 personas, donde tendremos un problema de escalado.
Además, en relación con su tamaño, con una cultura madura y asentada y con menor o
mayor capacidad para adaptarse a un cambio. De forma usual los cambios culturales no son
nunca fáciles, aunque inicialmente pueda parecer que todo el mundo los acepta de buen
grado.
También relacionado con su tamaño suelen aparecer necesidades de mayor entidad

(proyectos) y en mayor número, donde participan un mayor número de recursos que
sobrepasan las dimensiones de un único equipo ágil y con una cada vez mayor complejidad de
las tareas y su interrelación.
No encontramos mucha literatura, especialmente dedicada a llevar Kanban a

organizaciones de tamaño más grande, así que en este apartado intentaremos profundizar en
este tema.
Si bien no hay (y no debe haber) una “fórmula estándar” para escalar Kanban, en los
siguientes apartados vamos a analizar los principales aspectos problemáticos y ofrecer una
serie de ideas, obtenidas de la experiencia, que pueden ayudar en el proceso.

Aunque verás que los ejemplos y en muchos casos los términos provienen de una
organización IT, son aplicables a cualquier organización que desee aplicar Kanban en la mejora
de sus procesos.
En los siguientes apartados veremos algunas ideas sobre cómo:
 Comenzar a introducir Kanban en este tipo de organizaciones.

 Organizar los equipos de trabajo.
 Resolver los bloqueos entre equipos.
 Trabajar con varios Products Owner simultáneamente.
 Llevar a cabo proyectos complejos donde deben participar varios equipos.
 Apoyarnos simultáneamente en Scrum y en Kanban.
 Coordinar el trabajo de varios equipos y ofrecer una visión de alto nivel para el
management.
 Introduciendo Kanban en la organización
A la hora de plantearnos la introducción de Kanban en una organización de cierto

tamaño debemos ser conscientes del contexto en el que nos vamos a encontrar, ya
comentado, de organizaciones que ya no son pequeños equipos, cuentan con una “tradición”
sobre cómo hacer las cosas y tienen necesidad de gestionar convenientemente proyectos
complejos.
La aplicación de nuevas metodologías de trabajo puede suponer un choque importante

que, cuanto menos, puede provocar un bache organizativo temporal hasta su estabilización.
Esto puede suceder incluso contando con el apoyo de la dirección (con la que por supuesto
debemos contar) y la buena predisposición de la organización para aceptarlo. Por otro lado, se
trata de un cambio cultural y como todos los cambios culturales no son concebibles de un día
para otro.
Para intentar minimizar estos efectos contamos con un background importante. Somos
ágiles y Lean[1]. Debemos aportar valor desde el comienzo, con un objetivo a largo plazo (en
los siguientes apartados entraremos más en detalle en este aspecto) y con un plan detallado a
corto, con el objeto de ser flexibles y poder variar nuestras prioridades. No debemos tratar de
abordar un cambio organizativo completo. Debemos comenzar por probar que lo que tratamos
de llevar a cabo es viable y ofrece mejoras sobre lo existente, correr un riesgo razonable y
ejecutarlo en un tiempo reducido. Esto último evitará la pérdida de impulso.

La mejor vía es comenzar por un equipo pequeño, suficientemente autónomo (con

pocas dependencias externas) y con un Product Owner único. Básicamente la formulación más
sencilla.
Conseguido nuestro objetivo podremos ir avanzando en la adopción de Kanban por

otros equipos con composiciones organizativas y funcionales más complejas, que veremos en
los siguientes apartados.
Cosas con las que deberíamos contar a priori:
 El apoyo decidido de la dirección

 Master(s) director(es) del cambio (internos o externos)
 Product Owners / Product Managers afines por el cambio
Comenzar con un equipo piloto
Decidida la estrategia, la mejor forma para comenzar la implantación es elegir un

equipo piloto. El objetivo de este “experimento” es precisamente demostrar su viabilidad de
forma rápida y con un riesgo controlado.
El equipo piloto debería estar formado por personas afines al cambio y al pensamiento
ágil, que luego se diseminarán, tras el periodo inicial, por los siguientes equipos a formar en las
siguientes etapas, en una “polinización” de la cultura ágil. Este equipo deberá pasar por
diferentes experiencias para concretar las mejores prácticas iniciales para el resto de equipos.
El resto de equipos, por supuesto, tendrán que ajustar estas prácticas iniciales a sus propios
contextos.
Como inductores del cambio debemos formar temporalmente “parte del equipo” en
las técnicas Kanban y en la resolución de problemas, ejerciendo de coach, tal y como hemos
visto en las clases anteriores, hasta su madurez.
No debemos engañarnos. Si finalmente el resultado es negativo en un plazo razonable,

debemos ser lo suficientemente objetivos para aceptarlo, reconocer los errores y revisar
nuestra forma de abordar el problema para recomenzar o abandonar. se trata de
precisamente eso, un experimento que nos ha de demostrar la capacidad real para
transformar el proceso y las ventajas objetivas que conlleva (normalmente una producción
mayor, con mejor calidad y un menor coste).

[1] Por supuesto podemos abordarlo como un proyecto de implantación con un backlog más o
menos completo. Ya conocemos Scrum y Kanban y conocemos su problemática así que ¿por
qué no?
 Organización por equipos
Superada la implantación en un equipo experimental y demostrada su valía podemos

comenzar a ser más ambiciosos. Dependiendo de la organización podremos abordar la
adopción de la metodología de forma general o continuar con una adopción paso a paso. Sí
debemos tener, en cualquier caso, un plano organizativo objetivo, que analizaremos en este
apartado.
Como hemos visto, los equipos pequeños, dada su entidad, pueden reorganizarse y modificar
sus procesos de una manera ágil, impensable para equipos de trabajo más grandes. Esta
parece una guía correcta, así que debemos abordar la división en equipos pequeños y, si estos
no existen, de equipos más grandes, hasta unas dimensiones razonables para un equipo ágil 5-
7 personas.
Un criterio óptimo para la división por equipos es lograr que en su trabajo diario sean
lo más autónomos posibles, esto es, evitando que tengan que interaccionar con otros equipos
y los consiguientes bloqueos de su actividad. Trabajar de una manera autónoma en una parte
del proceso end to end. Esto permitirá una planificación de su trabajo con el menor número
posible de dependencias externas. Esta división, dependiendo del tipo de procesos, puede
realizarse de dos formas diferentes (es probable que incluso una combinación de las dos):
Particionado de procesos complejos y particionado por producto o funcionalidad.
El particionado de procesos complejos trata de descomponer procesos con muchas

actividades en varios subprocesos y hacer que cada grupo se encargue de uno de ellos. En
Kanban podemos encadenar la actividad de los diferentes tableros, atravesando los diferentes
equipos hasta completar el proceso. Un síntoma típico de la existencia de este tipo de
procesos es que comienzan a aparecer demasiadas columnas en Kanban y los equipos son
grandes.
Por su parte, el particionado funcional o por producto, nos permite dividir equipos en
función del producto final de su actividad. El equipo realiza todas las actividades relacionadas
con el desarrollo o mantenimiento de un producto o sistema. En ocasiones apoyados por una
infraestructura de base y estructuras de apoyo eventual. Este modelo es una abstracción (y
muchas veces objetivo) de la división por unidades de negocio y se está convirtiendo en el eje
para la innovación de las grandes empresas, creando equipos de trabajo específicos, pequeños
y muy ágiles para sacar adelante proyectos de innovación. A la hora de abordar el particionado
de un equipo grande de trabajo puede ser un buen comienzo si los procesos no son
excesivamente complejos. Tenemos un ejemplo de este tipo de organización en Spotify.

Imagen 1. Varios equipos trabajando en Kanban
Lo más probable es que ya nos encontremos en la organización con alguna división de

estos tipos, aunque quizás con equipos más grandes. En cualquier caso debe prevalecer una
adaptación al modelo existente y la división debería adaptarse de forma sencilla o casi
transparente para evitar colisionar con las estructuras existentes. Este es uno de los factores
de éxito de Kanban y es donde podemos encontrar, como hemos visto, sus verdaderas
ventajas.
Varios Product Owners (o Inputs) y su priorización
Como hemos visto Kanban gestiona especialmente bien el trabajo solicitado desde
varias fuentes (inputs) y lo hace apto para situaciones donde un mismo equipo recibe
solicitudes de varias áreas o Product Owners.

Imagne 2. La contienda por el Product Backlog
Ya hablamos de las políticas de priorización y clases de servicio en Kanban II. Estas

políticas permiten que el trabajo en el equipo se priorice automáticamente. No obstante, se
trata de una manera de automatizar la priorización con unas reglas básicas de funcionamiento
que provoca contiendas entre los diferentes Product Owners para conseguir la priorización de
sus trabajos.
En estas ocasiones es frecuente recurrir a swimlanes, uno para cada canal de entrada,
estableciendo una política round robin por defecto entre todos los inputs. Quizás moderada
por un wip individual por swimlane, cuya suma debe respetar el wip de la columna y que
permite modular los recursos que se desean reservar para cada input.

Imagen 3. Product Owner (Input) por Swimlane
No es fácil, en cualquier caso, una coordinación con múltiples Product Owners. Cada
uno de ellos tiene diferentes ciclos de revisión de Kanban y muchas veces es difícil de controlar
la periodicidad de “replenishment”. Algunos autores proponen encuentros de priorización
periódicos con los Product Owners. También podemos ajustar el WIP en Backlog para admitir
más entradas si el Product Owner tiene un periodo prolongado de priorización. En estos casos
no viene mal establecer un protocolo de ordenación para las tareas en wips > 1, para poder
tirar de la tarjeta adecuada.
Una solución pragmática es asignar un role de coordinación dentro del equipo que
periódicamente realice las reuniones con los Product Owners (Véase queue replenishment
meeting) para conocer sus requerimientos y la importancia de estas y que realiza la
priorización de tareas en el día. Esta solución tiene el riesgo de “alejar” la priorización de las
necesidades reales del negocio.
Es muy interesante también que los Product Owners colaboren entre sí para
determinar la priorización de los trabajos del equipo. Se cimenta una priorización de las
necesidades de negocio en vez de una priorización por razones “departamentales”. Por esta
razón puede ser una buena idea priorizar el trabajo con todos ellos a la vez.

Colisiones en diferentes equipos
Con frecuencia nos encontraremos el caso en el que un determinado Product Owner

requiera la ejecución de actividades de las que dependen actividades propias sobre el tablero /
Swimlane de otro Product Owner. Este segundo Product Owner tiene una priorización propia
que llevar a cabo.
Aparte de algunas otras posibilidades como wip reservado, silver bullets y otras clases
de servicio que ya hemos estudiado, la colisión de prioridades es una actividad que debe
resolverse a nivel de Product Owners y lejos de ser un inconveniente, permite que diferentes
Products Owners colaboren conjuntamente en la visión del negocio y sean capaces de
determinar qué grado de prioridad posee la actividad entrante respecto a sus propias
prioridades frente al negocio.
Desde este punto de vista, se deben evitar islas dictatoriales, frente a una visión
común de las necesidades de la organización.
Resolución de bloqueos entre equipos
Tanto si los equipos están formados de manera natural como si hemos podido realizar
una división para minimizar los bloqueos, en el trabajo diario es normal que una actividad
quede bloqueada o pendiente por la ejecución de cierta parte de esa actividad u otra actividad
derivada en otro equipo.
Para evitarlo y a la hora de diseñar las tareas, aparte de un tamaño homogéneo como
ya hemos visto, es importante tener en cuenta que no deben tener dependencias de terceros.
Tenemos ya un lead time y sabemos cuánto tiempo tarda aproximadamente en servir una
tarea un equipo. Utilicémoslo.
Supongamos que tenemos un determinado conjunto de tareas en el backlog, resultado

de dividir el trabajo necesario para un determinado proyecto. Las tareas son heterogéneas,
algunas son dependientes entre ellas y además deben ser realizadas por diferentes equipos.
Conociendo el orden en el que deben ser realizadas y el lead time podemos realizar una
planificación de alto nivel para introducir las tareas en cada equipo en el momento oportuno.

Imagen 4. Relación de dependencia entre tareas de diferentes kanbans
Finalmente, en el peor de los casos, si un equipo en una de esas tareas requiere del
trabajo de otro equipo para completar su labor, deberá esperar a que el otro culmine su
trabajo en el lead time del otro equipo. Evidentemente es una situación no deseable, muchas
veces devenida por los propios principios Kanban y uno de los motivos fundamentales para no
aplicarse a la hora de desarrollar trabajo complejos y perdurables en el tiempo (proyectos).
 Proyectos versus servicios
Para entender la problemática en el uso de Kanban para proyectos debemos realizar

un análisis del propio significado de un proyecto y su diferencia con los servicios.
Podemos ver un proyecto como un conjunto grande de actividades relacionadas entre

sí y dirigidas a la producción de un elemento concreto de cierta complejidad, por el tiempo o
recursos necesarios para su desarrollo o el riesgo asumido. Aunque pueden existir proyectos
similares, la realidad es que dada su complejidad las diferencias entre ejecuciones pueden ser
notables. Este hecho se refleja en que la definición del proyecto y su planificación,
normalmente, son etapas dentro del mismo proyecto. En este modelo y dentro del mundo del
desarrollo de software, por ejemplo, entendemos el desarrollo de funcionalidades de calado,
el desarrollo de nuevos sistemas y subsistemas o la realización de modificaciones que afectan
a su funcionamiento de manera significativa

Podemos ver un servicio como una actividad concreta, repetitiva, con un alcance
definido, planificado de antemano y riesgos conocidos. Colocar una puerta en un coche,
cambiar una ventana, etc. son algunos ejemplos. En este modelo podríamos tener también:
 El Mantenimiento de software, donde se aplican mejoras correctivas (corrección

de errores) o mejoras (funcionales, rendimiento…), normalmente de poco calado,
que aunque pueden tener cierta variabilidad suele ser mucho menos significativa
que la observada en el desarrollo de nuevos desarrollos o mantenimientos
mayores.
 Las Operaciones del área de sistemas donde, aunque se da la existencia de
proyectos internos de mejora, el porcentaje de actividades repetitivas se lleva la
mayor parte del pastel (instalación de un nuevo servidor, una nueva base de datos,
un nuevo usuario…).
De ambos análisis observamos que Kanban se ajusta como un guante a la ejecución de

servicios, mientras encontramos un peor ajuste a la ejecución de proyectos.
Kanban y proyectos
Entendido que, a priori, Kanban tiene un peor ajuste (o al menos más oscuro) a
proyectos, su propio creador propone una descomposición jerárquica de requerimientos, con
un seguimiento paralelo de dos niveles de descomposición sobre el tablero.
La aproximación recomendada es similar a la utilizada en Scrum, una descomposición

de epics en historias. Sobre el tablero se suelen representar en líneas paralelas. La
descomposición de historias en tareas no aparece en el tablero. El objetivo es desacoplar la
entrega de valor de la variabilidad de las tareas de trabajo finales, representando en el tablero
Kanban solo los niveles de entrega de valor.
Algunos equipos llegan a este nivel de descomposición (tareas) en tableros separados

del kanban principal de seguimiento de tareas y de historias en tareas. Algunos tableros
virtuales admiten el tercer nivel de descomposición, tareas.
En esta concepción, los ítems de menor nivel que atraviesan en tablero son historias y,
para mantener los principios Kanban, se requiere un esfuerzo adicional en la etapa de análisis
para descomponer los epics en historias pequeñas y de tamaño similar, habilitando un flujo
suave y una predictibilidad de lead times.

Múltiples proyectos en un mismo Kanban
El tratamiento de un único Product Owner y un único proyecto (o una serie de

proyectos del mismo Product Owner) sobre un único tablero Kanban resulta casi trivial con
todo lo aprendido, desde el punto de vista de que el Product Owner puede gobernar,
mediante priorización, el avance de sus proyectos.
En el caso que nos ocupa, como escalar Kanban, nos vamos a centrar en el tratamiento
de múltiples proyectos (con múltiples Products Owners) en un único tablero Kanban y/o el
tratamiento de proyectos que requieren actividades en varios tableros Kanban.
En el primer caso, el de tratamiento de múltiples proyectos en un mismo Kanban, la

creación de swimlanes por input (Product Owner), cuya problemática vimos en el tratamiento
de varios Product Owners en un mismo tablero, da lugar a un lead time por swimlane que
puede ser utilizado para planificar adecuadamente un proyecto y obtener, por ejemplo, fechas
estimadas de entrega.
En cualquier caso esta fórmula simplifica la ejecución de un proyecto por input en un

momento dado. Varios proyectos llegando desde un mismo input deberían ser secuenciados
(no ejecutados simultáneamente) por simplicidad en su gestión. Como hemos visto durante el
curso, el Product Owner debería tener dedicación exclusiva en su actividad para un proyecto
ya que simultanear varios proyectos reduce normalmente la calidad y los tiempos de ejecución
de los proyectos.
Si a pesar de todo nos encontramos en esta situación, deberían abrirse swimlanes por
proyecto.
Múltiples proyectos con múltiples Kanban
Llegamos al colofón de la complejidad en la gestión con Kanban (y con otras

metodologías ágiles) aunque, como hemos visto, aún puede complicarse más dependiendo del
contexto (diferentes ubicaciones incluso a nivel internacional de los equipos en lo que no
entraremos).
Es estos casos se exige una capacidad de coordinación muy elevada por parte del
Product Owner, que deberá priorizar actividades entre diferentes tableros. Una vez más,
métricas como lead time en cada tablero le permitirán sincronizar tareas interdependientes.
Este lead time no es fácil de obtener en el comienzo de los proyectos y probablemente

requerirá de:

 Ajustes del lead time previsto según avanzan.

 Conocimiento profundo de la experiencia de los equipos participantes en la
tecnología y riesgos de cada proyecto.
 Ajuste dinámico de WIPs de acuerdo con la dirección.
En cualquier caso es necesario dotar al Product Owner de ciertas herramientas que

mejoren su gestión. La primera propuesta pasa por que el propio Product Owner posea una
“visión transversal” sobre todos los tableros de sus actividades, filtrando de cada tablero las
actividades sobre las que tiene responsabilidad y, si es posible, el “proyecto” asociado.
Este objetivo puede lograrse sobre un Kanban personal físico donde exista una copia
simplificada de las tarjetas que el propio Product Owner actualiza en función de los avances en
los diferentes Kanbans.
Esta implementación resulta mucho más sencilla en tableros de tipo electrónico,

donde podemos filtrar actividades más fácilmente teniendo en cuenta las dimensiones
mencionadas de Product Owner y proyecto asociado y es un punto a su favor cuando
escalamos.
Como alternativa, podemos plantear un modelo de Kanban de Kanbans, de un modo

similar a “Scrum de Scrums”, manteniendo la figura de products owners delegados que
participan a su vez en un kanban de coordinación o la figura de embajador que colabora por
parte del equipo base en el equipo de nivel de coordinación.
Del proyecto al sistema y su mantenimiento
Hacemos un inciso aquí para indicar que en muchos contextos hay una transición del
estado proyecto al estado mantenimiento del producto o sistema desarrollado en el proyecto.
Esta transición es excepcionalmente ligera en Kanban, bajando simplemente los wips y
eliminando swimlanes en los equipos que no requieran ya participar en el mantenimiento del
producto.
En esta transición y para simplificar la gestión, podemos asignar varios sistemas a un

mismo swimlane, siempre y cuando ese swimlane (y por lo tanto el mantenimiento de estos
sistemas) pertenezca al mismo Product Owner. El Product Owner conoce qué actividades y de
qué sistemas debe priorizar las actividades en Kanban.
[1] Kanban: Successful Evolutionary Change for Your Technology Business - David J. Anderson

 Combinando Kanban y Scrum
En una organización multiequipo se puede aplicar Kanban a muchos niveles y con

múltiples propósitos. Su implantación es sencilla, muy adaptable y proporciona ventajas
evidentes de forma inmediata en muchos procesos.
Sin embargo, hemos visto con anterioridad que Kanban se comporta especialmente
bien en la ejecución de servicios, actividades pequeñas de duración limitada. A la hora de
aplicar Kanban en entidades mayores (proyectos concretos), con unas fechas de entrega
requeridas y con cierta criticidad, puede provocar bloqueos por coordinación del trabajo
(bloqueos entre Products Owners, seguimiento en múltiples equipos…).
A este respecto, ya estamos familiarizados con Scrum, que está, como estamos viendo,
más especializado en la ejecución de proyectos. Es precisamente en esta problemática donde
puede complementarse a la perfección con Kanban. De hecho, Scrum puede aparecer como la
evolución lógica para el tratamiento de este tipo de trabajos, cuando madura la operación con
Kanban y puede ser más fácilmente aceptado y más adecuado a procesos de este tipo
(realización de proyectos).
No obstante, no resulta sencillo acotar una actividad en otra categoría y de hecho

conviene hacer notar que Kanban puede lograr mejores resultados en proyectos poco
definidos o en entornos muy, muy cambiantes, con ciclos muy cortos, incluso un poco caóticos,
donde una entrega grande de producto no tiene una fecha concreta de salida.
Scrum posiblemente sea más adecuado en trabajos con las siguientes características:
 Definición relativa del producto que se requiere. Requiere al menos generar un

conjunto de historias suficiente para un sprint.
 Focalizado en proyecto. Objetivo: terminar el proyecto en un plazo determinado
con la máxima calidad.
 Un solo PO - un solo producto.
Kanban por su parte operará mejor en:
 Definiciones muy borrosas del producto final o con requerimientos altamente

cambiantes.
 Procesos con operaciones pequeñas y repetitivas, es decir, donde se pueda realizar
una buena división en tarjetas del trabajo (pequeñas, homogéneas).
 Focalizado en tarjeta (menor entidad que un proyecto). Objetivo terminar cada
tarjeta en un plazo determinado con la máxima calidad.
 Mantenimientos menores y bugs.
 Operaciones con ciclos de trabajo cortos (días).

 Múltiples POs - Múltiples productos.
Una de las posibles alternativas que hemos visto ha sido Scrumban, intentando recoger
lo mejor de ambos mundos en un contexto mono equipo. Ahora veremos otra fórmula
alternativa de combinación que permite su escalado a un contexto multi equipo.
Scrum en proyectos, Kanban en servicios
Aunque posiblemente encontréis mil y una forma de adaptarlas a la organización, mi

recomendación (mi propia experiencia ha sido muy buena) siguiendo este análisis, es la de
utilizar Scrum para proyectos, actividades que van a superar las dos - cuatro semanas de
trabajo y ejecutar Kanban para actividades de mantenimiento menor y corrección de bugs.
Para ello es necesario que cada equipo se divida en dos unidades, que pueden ser
temporales, de por ejemplo 5-1, 4-2 o 3-3 miembros. Una de las unidades (normalmente la de
mayor tamaño, aunque puede modificarse el criterio en función de la carga de trabajo) se
dedica a trabajar en los proyectos y sus historias, con metodología Scrum. Quedan
“bloqueados” para Scrum. La otra unidad se dedica a mantenimiento menor y bugs, utilizando
para ello Kanban.
Ambas unidades pueden participar en las actividades de planificación, dailies, demos y

reviews previstas para Scrum. Es, por supuesto, opcional, pero en el caso de los dailies
proporciona una cohesión de trabajo sin precedentes.
Uno de los problemas a la hora de abordar Scrum es cómo conseguir gestionar las
interrupciones de trabajo. Hay varias alternativas propuestas que ya hemos visto: en Scrumban
reservando wip, liberando una persona del equipo… Con este mecanismo podemos conseguir
además liberar al equipo Scrum de estas interrupciones y conseguir una línea de trabajo suave
en Kanban, consiguiendo una efectividad mayor.
Es conveniente realizar una cierta rotación entre las dos unidades. La frecuencia de la
rotación puede afectar tanto al lead time de Kanban como a la velocidad de Scrum, por lo
tanto debemos tener cuidado a la hora de realizarla y no modificar la capacidad de trabajo
demasiado frecuentemente.
Una vez en este nivel de madurez es especialmente sencillo abordar proyectos cross
complejos y normalmente críticos para el negocio, que requieren de la participación de
miembros de diferentes equipos de una forma ordenada y eficiente. Llegamos en este punto a
una gestión de proyectos transversal que muchas organizaciones ejecutan mediante fórmulas
tradicionales y que podemos plantear de una forma ágil. También encontraremos una fórmula
ideal para propagar el conocimiento, como ya vimos, mediante “polinización”.

La disposición de recursos para la ejecución de un determinado proyecto debería

realizarse entre coordinadores de equipos y cada Product Owner. En este punto se nos abre
una problemática ligada con este nivel, la de gestión de recursos, que analizaremos en el
siguiente apartados.
 Coordinación de equipos, proyectos y la gestión de recursos
Cerrando el tema de escalado debemos entrar en la problemática de organizar

adecuadamente todo el capital humano para que funcione ordenadamente. No en vano y
como hemos visto, tenemos:
 Varios Products Owners trabajando en varios proyectos de forma simultánea

 Varios equipos a cargo de la ejecución de proyectos y mantenimiento de los
sistemas generados
 Proyectos transversales que tienen recursos de diferentes equipos bloqueados
 Proyectos internos por equipo
 Recursos dedicados a labores menores de mantenimiento
Esta maquinaria requiere de un cuadro de mando desde el que se pueda supervisar su

funcionamiento y que permita establecer con claridad:
 La priorización de los proyectos desde el punto de vista del negocio.

 La situación de los recursos en un momento dado y sus perspectivas de
reasignación.
 La gestión de capacidad a través de los diferentes tableros Kanban (establecimiento
de wips).
Esta problemática no es en absoluto nueva y recae ya dentro del área de gestión de

recursos y planificación de proyectos a alto nivel de la cual tenemos a nuestra disposición
conocimiento y herramientas.
Para comenzar debería ser suficiente una simple hoja de cálculo donde coloquemos
proyectos y recursos en filas y meses (por ejemplo) en columnas. Tantos proyectos y sus
recursos como tengamos previstos, en ejecución o finalizados en un cierto periodo de tiempo.
Cada proyecto debería tener asignado un Product Owner y sus fechas de comienzo y
duración estimadas deberían quedar registradas, así como la fecha de comienzo y duración
real a posteriori. En la casilla de cruce del equipo / proyecto con el periodo temporal deberían
aparecer los recursos asignados del equipo a ese proyecto.

La última fila puede quedar asignada a Kanban y en ella se fijan los recursos
disponibles para estas actividades, que nunca deberían llegar a ser cero.
Con toda esta información es posible realizar una planificación de recursos básica pero
muy importante. Además debería estar publicada al menos en el ámbito de Product Owners,
Coordinadores[1] de equipos, management, etc. con posible modificación por parte de los
Product Owners y coordinadores.
Es evidente que los datos de fecha y duración estimadas serán bastante erróneos pero
con el tiempo adquiriremos las métricas suficientes para realizar una estimación de proyectos
mucho más aproximada, según los Products Owner adquieran experiencia en sus solicitudes y
los equipos que las implementan.
A partir de aquí resulta trivial obtener un resumen de estimaciones y costes por

proyecto, que sin lugar a dudas será reclamada por el staff ejecutivo. Este debe asumirlo en
términos aproximativos, aunque cada vez más precisos.
Imagen 5. Ejemplo de gestión de proyectos, recursos y costes
[1] Hasta ahora no hemos mencionado el role de coordinador de equipo o Team leader por no
ser especialmente relevantes en los aspectos que nos ocupan. Ahora aparecen como gestores
de los recursos disponibles en cada equipo y de la actividad interna de los mismos. También
ejercen el papel de líderes técnicos.

3.3.5. TABLEROS DIGITALES
Como ya has visto con anterioridad existen multitud de herramientas digitales (tanto
herramientas web como de escritorio) destinadas a simplificar la gestión de proyectos y, en el
caso de kanban gracias a que poco a poco su implementación es mayor, va creciendo el
número de herramientas específicas para aplicar la metodología.
 Ventajas y desventajas de los tableros digitales
El uso de estos tableros tiene ventajas en multitud de escenarios que veremos

rápidamente pero, desde mi punto de vista, también tiene para mí dos carencias
fundamentales con respecto a los tableros analógicos que hemos estado viendo:
 Ningún tablero digital es tan versátil como aquel en el que tú puedes dibujar:
Hemos dicho siempre que una de las claves para sacarle el mayor partido posible a
Kanban pasa por customizar el tablero y la forma de trabajar con él para
adaptarlos progresivamente a nuestra forma de trabajo y sobre todo a las
peculiaridades de nuestro equipo y su contexto. Por muy configurables que
puedan llegar a ser las herramientas digitales, nunca serán tan customizables
como una pizarra y unos postits.
 La visualización no es igual por varios motivos:
◦ Las pantallas son más pequeñas que un buen tablero; vemos menos de un
vistazo.
◦ La presencia no es constante. Desde mi escritorio con levantar unos
centímetros la cabeza puede revisar el tablero ANALOGICO, No tengo que
abrir el navegador u otro programa, no tengo que tocar ni cambiar nada, está
ahí.
◦ El trabajo en equipo sobre el tablero DIGITAL se hace más distante. Por
ejemplo, en nuestra oficina trabajamos una temporada con Leankit kanban,
un tablero muy potente, y lo que ocurría es que al final las reuniones de status
de las mañanas las hacíamos hablando en alto desde nuestros asientos cada
uno en su monitor...como imaginaréis, esto no fomenta en absoluto el diálogo
y la gente perdía la atención muy rápido (la opción de sentarse todos
alrededor de una pantalla tampoco nos resultó cómoda...).
Ahora bien, son muchas las ventajas de los tableros digitales:
 Deslocalización. No hay que estar en la oficina para ver el tablero. Para muchísimas
empresas sólo esta opción, ya justifica la digitalización del tablero.
 En línea con la anterior, nos permite trabajar con equipos divididos. Cuando un
equipo está dividido ya sea por más de unos metros o por varios kilómetros, el
tablero digital es la forma más sencilla de trabajar.

 Métricas automáticas. Muchos tableros digitales nos calculan las métricas que
hemos visto en la unidad anterior (y algunas más) de manera automatizada, lo cual
nos quita trabajo y simplifica los procesos de recogida de datos y medición.
 Valor añadido sobre las tareas. Los tableros digitales nos permiten añadir sobre las
tarjetas información de todo tipo: links a documentación útil, links a otros sistemas
electrónicos (correos electrónicos, bug trackers, ...), imágenes, etc.
 Histórico. Los tableros digitales nos permiten revisar información histórica de
manera sencilla. Los post its físicos acaban en la basura.
La decisión sobre si usar tableros físicos o digitales depende de cada equipo y de cada
PM. Para mí, los tableros físicos explotan mejor la ventajas de Kanban pero hay valores de los
tableros digitales que son necesarios para equipos grandes y, fundamentalmente, para
equipos cuyos miembros no están todos en la misma oficina.
Para la primera implementación del tablero, tal y como hemos visto en unidades
anteriores, os recomiendo empezar siempre por el tablero físico ya que tendremos más claro
qué buscamos en un tablero digital si hemos trabajado sobre un tablero físico sin limitaciones
artificiales.
 ¿Cómo elegir el mejor tablero digital?
 Pruébalo: La mayor parte de los softwares de gestión de proyectos cuentan con

versiones de evaluación (modelo de uso free) que nos permiten probar el software
antes de pagarlos. Merece la pena el esfuerzo de probarlos y jugar con ellos para
ver si nos sentimos cómodos con él y si hace todo lo que necesitamos. Intenta
construir con ellos el tablero que necesitas a ver si funciona.
 Entiende la licencia: La mayor parte de estos tableros nos hacen pagar más o
menos en función de la configuración de nuestro equipo y de las funcionalidades
que queramos utilizar. Conviene revisar bien el escalado de precios para evitar
sustos con la factura a medida que nuestro equipo crece.
 Revisa las métricas que aporta el software, algunos tableros digitales aportan muy
poco valor a nivel estadístico.
 Consideraciones para el escalado
Hemos debatido ya sobre el uso de tableros físicos o virtuales. Aquí lo haremos desde
una perspectiva de escalabilidad.
Como ya sabemos, los tableros físicos potencian la interacción en el trabajo diario en el

equipo y en una gestión interna del equipo. Pero llegados al punto de escalado y la gestión de
actividades complejas, estos tableros resultan menos útiles, dada la limitada capacidad de
gestión de más alto nivel que ofrecen.

Algunas de las características que deberíamos tener en cuenta a la hora de seleccionar

una herramienta:
 Soporte a la planificación
◦ Soporte de proyectos
◦ Establecimiento de dependencias
◦ Asignación en icebox de diferentes tableros
◦ Lead times esperados por tablero / equipo incluyendo swimlane y otras
características del servicio
 Seguimiento
◦ Filtrado por proyecto
◦ Estado de tareas de un determinado Product Owner, con situación en columna
y equipo que la ejecuta
◦ Repriorización de actividad
◦ Señalización de bloqueos
◦ Presentación en Kanban de Product Owner
Imagen 6. Kanban para Product Owners
Encontraréis estas funcionalidades en las herramientas en la nube más maduras y en

plataformas con cierta tradición en desarrollo con adaptaciones ágiles como Jira / Agile.

 Recomendaciones
 Leankit Kanban. Herramienta realmente profesional, con gran catidad de las

funcionalidades deseadas y ya muy madura en la nube.
 Trello. Tablero Kanban extremadamente sencillo pero con funcionalidades
realmente prácticas. Excepcional para el uso personal o grupos de trabajo muy
dinámicos. En la nube.
 Taiga. Herramienta open source (on site) y en la nube con sello español que
permite gestión por scrum y por kanban. Aunque carece de algunas
funcionalidades “estándar” en este tipo de herramientas, es muy usable y posee
otras funcionalidades que le convierten en una herramienta verdaderamente ágil.
 Jira / Agile. Herramienta con larga experiencia en proyectos tradicionales y que
ahora incorpora módulos de “agilización” para Scrum y Kanban. On site y en la
nube.
Aquí tenemos una pequeña comparativa entre Leankit y Trello.
3.3.6. ALGUNAS REFERENCIAS
 Use of Kanban in the Operations Team at Spotify. Problemas y soluciones en la

implementación Kanban en el área de operaciones (sistemas) de Spotify, en un
equipo de 7 personas, donde se mezclan proyectos de mejora y servicios con
múltiples inputs.
 Spotify engineering culture. Una visita a la organización de desarrollo con división
funcional de Spotify. En este caso basada en Scrum pero asimilable a Kanban.
 Nexus, marco de escalado para Scrum. Artículo sobre el marco Nexus para escalado
de Scrum en el Blog de Javier Garzas, con enlaces a otros artículos sobre diferentes
técnicas de escalado que pueden servirnos de referencia para el escalado Kanban.
 Kanban: Successful Evolutionary Change for Your Technology Business.
Especialmente de interés el capítulo 13: “Scaling Kanban”, dedicado a la gestión de
proyectos con Kanban. Incluye un análisis de la problemática de trabajar en
proyectos con Kanban e Incluye algunas configuraciones del tablero de interés para
la descomposición jerárquica de requerimientos hasta tareas Kanban.
Leading the transformation, applying Agile and DevOps principles to scale - Gary
Gruber & Tommy Mouser. De reciente publicación y algo denso, es un excelente documento
que presenta la problemática del escalado de una metodología ágil. Cómo abordarlo desde la
perspectiva de negocio, recursos, ROI...

3.4. Programación externa (XP)
3.4.1. ¿DE DÓNDE VIENE XP?
Las metodologías ágiles se utilizan para llevar a cabo muchos proyectos, tanto los de
desarrollo como otro tipo de proyectos de cualquier naturaleza. Existen muchas
particularizaciones de los principios ágiles en forma de metodologías concretas y buenas
prácticas. Scrum y Kanban son las metodologías concretas más conocidas en el mundo de
desarrollo software y de gestión de proyectos tecnológicos.
Scrum se puede considerar como un conjunto de guías y buenas prácticas para

coordinar el trabajo de todos los integrantes de un equipo. El desarrollo basado en iteraciones,
la planificación para cada sprint, involucrar al cliente, reuniones cortas pero frecuentes, etc.,
son aspectos propios de la gestión y coordinación del proyecto. La experiencia ha demostrado
que aplicar esas buenas prácticas favorece que los proyectos se desarrollen de forma
satisfactoria.
Como ya te habrás planteado, en la metodología Scrum no se menciona prácticamente

el desarrollo de software. Se habla de construir un producto que tiene que cumplir un
conjunto de propiedades que el cliente solicita. No obstante, ese producto no tiene por qué
ser un producto software. Por ejemplo, las metodologías ágiles se han aplicado
satisfactoriamente en la elaboración de libros de forma colaborativa. En general, cuando el
producto que se quiera desarrollar sea eminentemente intelectual y no se pueda definir con
precisión “a priori”, se puede aplicar una metodología ágil como scrum. Esto se debe a que
scrum pone el énfasis en la coordinación, la toma de decisiones, la definición durante el
proceso de creación, etc.
Aunque se puedan aplicar en ciertos proyectos, es cierto que han tenido su máxima
expresión en el desarrollo de software. No obstante, las metodologías ágiles como Scrum o
Kanban no mencionan prácticamente nada de las cuestiones técnicas relacionadas con el
desarrollo de software. Y ese es precisamente el hueco que ocupa la programación extrema.
Para conocer la programación extrema hay que conocer la historia de cómo se

desarrolló. En los años 80, el programador Kent Beck comenzó a trabajar con SmallTalk, un
lenguaje orientado a objetos, que nació con la pretensión de acercar el proceso de
razonamiento humano al proceso de razonamiento usado en el desarrollo de software, con el
objetivo de que el software sería más sencillo de crear y de mantener. Kent Beck y su
colaborador Ward Cunningham, comenzaron a probar diversas prácticas en el desarrollo de
software con el lenguaje SmallTalk. Algunas de ellas, de las que luego hablaremos en detalle
fueron la integración continua, la refactorización del código, etc. Además, también empezó a
usar prácticas de gestión como tener al cliente cerca y desarrollar en pequeños incrementos.

En el año 1996 publicó “Smalltalk, best practices patterns”, en el que describía estas buenas
prácticas.
Kent Beck empezó a trabajar en 1996 en la empresa Chrysler como líder de un

proyecto software y fue refinando esas buenas prácticas en el desarrollo de software que le
permitían desarrollar software de forma continua y de calidad. En 1999 publicó el libro
“Extreme Programming Explained” explicando en detalle dichas prácticas. El nombre se basa
en la idea de que si una práctica en el desarrollo en últil, hay que llevarla al extremo para
poder aprovecharla en todo su potencial. Posteriormente, en 2001, Kent Beck firmó el
Manifiesto Ágil, junto con otros miembros de la recién creada comunidad agilista.
Kent Beck trabaja actualmente en Facebook y sique publicando y trabajando en el

mundo de los patrones software. En el año 2008 publicó: “Implementions Patterns” un
referente dentro del mundo del desarrollo del software.
3.4.2. EL OBJETIVO DE XP
Como ya hemos mencionado antes, la programación extrema es una metodología ágil

que tiene como objetivo que un equipo de desarrollo pueda crear software de alta calidad de
la forma más productiva posible y que cumplan con los deseos de los clientes.
Para que se puedan cumplir estos objetivos, la programación extrema propone una
serie de recomendaciones en forma de buenas prácticas técnicas para el equipo de desarrollo.
Pero esas buenas prácticas no son suficientes por sí mismas, tienen que entenderse bajo un
conjunto de valores y principios que permiten al equipo comportarse como una unidad con un
objetivo común.
3.4.3. METODOLOGÍAS ÁGILES Y XP
Las metodologías ágiles como Scrum y Kanban y la programación extrema se han

desarrollado de forma independiente. Scrum y Kanban se centran más en la gestión, mientras
que la programación extrema se centra en el equipo de desarrollo y las buenas prácticas
técnicas necesarias para crear software de calidad.
Aunque se han desarrollado de forma independiente, existen algunos puntos en los

que estas metodologías se solapan y proponen las mismas técnicas para resolver los mismos
problemas. Por ejemplo:

 Tanto scrum como en XP se recomienda el desarrollo en iteraciones cortas y

entregas frecuentes, en vez de largos procesos de desarrollo. En scrum se detalla un
poco más cómo pueden realizarse esas iteraciones desde el punto de vista de la
gestión (reuniones diarias, de planificación del sprint, de retrospectiva, etc.) y la
programación extrema propone las técnicas informáticas para conseguir que eso se
pueda llevar a cabo de forma sencilla por el equipo de desarrollo.
 En scrum se favorece que el cliente (representado por el product owner) cambie de
opinión o vaya refinando los requisitos del producto a medida que se avanza en su
desarrollo, y en la programación extrema se proponen las mejores prácticas
técnicas para que eso se pueda realizar sin comprometer la calidad del producto y
sin que se ponga en riesgo la conclusión del proyecto.
 Pero, sobre todo, hay un aspecto en el que coinciden la programación extrema y
metodologías como scrum y que está recogido en uno de los valores del manifiesto
Ágile: “Individuos e interacciones sobre procesos y herramientas”. Es una forma de
decir que la importancia radica en las personas y la forma que tienen de
relacionarse. Aunque la programación extrema es un compendio de buenas
prácticas técnicas, veremos como el equipo (las personas y sus interacciones) están
en el centro de la mayoría de esas buenas prácticas.
3.4.4. LOS VALORES DE XP
Los valores sobre los que se sustenta la Programación Extrema son:
Comunicación
El primer valor de la Programación Extrema es la comunicación.
Para que los desarrolladores puedan construir un producto que cumpla con las
necesidades o deseos de un cliente, tiene que haber una comunicación entre el cliente y los
desarrolladores. En las metodologías no ágiles, se considera que esta comunicación tiene que
realizarse a través de contratos y documentos. En la programación extrema se considera que
esa comunicación tiene que realizarse de la forma más directa posible, que permita una
conversación e incluso una negociación.
Además, muchas de las buenas prácticas técnicas permiten que haya comunicación
dentro del propio equipo de desarrollo y con los clientes. Todos los involucrados en un
proyecto tienen que conocer de forma clara los objetivos del proyecto, para que todas sus
acciones vayan encaminadas a la consecución de esos objetivos.
Por ejemplo, las entregas frecuentes de software funcionando se han demostrado

como una de las mejores formas de comunicación entre el equipo y el cliente. La estimación
del coste de forma conjunta por todos los miembros del equipo, la programación por pares y el

concepto de que todo el código es de todos fomentan la comunicación entre los miembros del
equipo.
Simplicidad
Este concepto está muy relacionado con el tipo de software que se está desarrollando.
La experiencia ha demostrado que en ciertas ocasiones los sistemas software se implementan
de tal forma que están preparados para cosas que nunca ocurren y eso tiene mucho coste y
poco valor. Es como la metodología lean startup pero aplicada al desarrollo de software.
Intenta consumir los mínimos recursos necesarios para sacar una funcionalidad, pero no
pienses en lo que vas a necesitar mañana o dentro de un mes, piensa en las necesidades
actuales y reduce el coste de llevarlas a cabo.
Por ejemplo, supongamos que queremos iniciarnos en el mundo del sky. Podemos
comprarnos un equipamiento de sky bastante básico, o incluso alquilarlo, con la idea de
probar. De forma que si finalmente nos gusta, podremos comprar otro equipamiento mejor.
En el mundo del desarrollo de software la simplicidad propone a los desarrolladores

que no piensen en diseños complejos para funcionalidades futuras que habrá que
implementar. Esto se conoce como el sobre-diseño. La programación extrema te dice que
programes justo para lo que necesitas hoy, pero no más. Esto tiene la ventaja de que las
discusiones con el cliente están mucho más focalizadas, no hay elucubraciones futuras.
También el código suele ser más fácil y rápido de implementar y de probar. Lo que implica que
el cliente puede tener esa funcionalidad mucho antes y puede aportar su realimentación.
Los anglosajones tienen muchos acrónimos relacionados con este valor. KISS es el
acrónimo de “Keep it simple, stupid” que se puede traducir por “Hazlo simple, estúpido”.
También usan el acrónimo YAGNI, el acrónimo de “You aren't gonna need it”, que se puede
traducir por “No lo vas a necesitar”. La programación extrema considera que si no sobre-
diseñas y te centras en lo importante de forma inmediata, no corres el riesgo de emplear tus
esfuerzos en hacer algo que es probable que no necesites porque aunque ahora te parece muy
evidente que será necesario, es posible que llegado el momento las necesidades del cliente
hayan cambiado. Y la última, BDUF, que quiere decir “Big design up front”, “Un gran diseño
previo” y hace referencia al caso extremo de definir completamente la arquitectura del
software antes de empezar a programar. Estas ideas se aplican en otras disciplinas de la
ingeniería (por ejemplo en construcción), pero han resultado muy poco adecuadas para el
desarrollo de software, utilizándose principalmente en el desarrollo en cascada.
Un código más sencillo es más fácil de entender (favorece la comunicación, el primer

valor de la programación extrema). Y si un código es fácil de entender, también es más fácil de
mantener y, por tanto, de adaptarse a las necesidades (cambiantes) del cliente.

Hay desarrolladores que se toman este principio al pie de la letra y sólo programan lo
estrictamente necesario para la iteración actual. Pero hay otros desarrolladores que evalúan
de forma cuidadosa cada caso y deciden emplear más recursos en la iteración actual para que
la incorporación de funcionalidades futuras sea pueda hacer de forma muy sencilla, aunque
eso implique un mayor coste de implementación incial. Como esta es una cuestión bastante
importante en el desarrollo de software, volveremos sobre ella más adelante.
Realimentación
En el contexto de la programación extrema, la realimentación se asocia con la

capacidad de medir diferentes aspectos del desarrollo software. En concreto, se suele aplicar a
los siguientes aspectos:
 Realimentación del sistema: gracias a los test automatizados, el sistema es capaz

de generar un informe automático sobre su estado interno. Por eso es tan
importante para poder desarrollar software de calidad la programación de test
automatizados.
 Realimentación del cliente: gracias a las entregas frecuentes de software

funcionando el cliente puede evaluar el software según se va desarrollando. Esta es
una importante herramienta para verificar que el proyecto avanza en la buena
dirección. Y reaccionar en caso de que no sea así. Además, se recomienda que el
cliente colabore activamente en la creación de test de aceptación, tests que validan
de forma automática que la funcionalidad deseada es la que está realmente
implementada.
 Realimentación del equipo: si el cliente quiere incorporar funcionalidades no

previstas en el producto, el equipo podrá estimar el coste de implementar dichas
características, ofreciendo información necesaria al cliente para que toma la
decisión de incluir o no esa funcionalidad.
Obviamente la realimentación está muy relacionada con la comunicación. Pero la

realimentación se focaliza no en la simple transmisión de la información, si no en la medición,
la validación de que los datos obtenidos están alineados con los objetivos del proyecto.

Coraje
Los desarrolladores deben tener valor durante el desarrollo de un proyecto en los

momentos y ante las situaciones adecuadas. Por ejemplo:
 Cuando se detectan problemas de coordinación o de incomunicación, cualquier

miembro del equipo tiene que tener el coraje suficiente para poner los problemas
encima de la mesa antes de que se agraven y sean más difíciles de solucionar.
 Los programadores deben tener el coraje de asumir los fallos que se cometan y, si
es necesario, pedir ayuda para solucionarlos.
 Los desarrolladores tienen que defender sus convicciones y negociar incluso con
los otros miembros del equipo si no están de acuerdo en algo. Hay que intentar
llegar a situaciones de compromiso siempre que sea posible por el bien del
equipo, y para eso hay que tener coraje.
 Otro ejemplo de coraje y responsabilidad consiste en saber reconocer cuando uno
se equivoca y dar su brazo a torcer. Por ejemplo, desechar una tecnología si es
aceptado por todos que ya no cumple los objetivos, por mucho trabajo que se
invirtiera en ella.
Además, también hay que tener el valor necesario para arriesgarse. El refranero
español lo tiene claro: “el que no arriesga, no gana”. Si un desarrollador cree en una idea tiene
que defenderla, convencer al equipo y arriesgarse por ella.
Respeto
El respeto es el quinto valor de XP, que se incorporó en la segunda edición del libro
“Extreme Programming Explained” (2004).
El resto de los compañeros del equipo se merecen un respeto. Un compañero nuevo

con poca experiencia se merece el mismo respeto que un programador experimentado. El
respeto se manifiesta de muchas formas durante el desarrollo de un producto software. A
continuación se muestran algunos ejemplos:
 Como todo el código es de todos, hay que hacer un esfuerzo extra por hacer el
mejor código que puedas hacer. Cuando programas para ti mismo, puedes tomarte
muchas “licencias” y hacer las cosas rápido y sin pensar en el mantenimiento
futuro. Pero cuando tu código en realidad es el código de todos, por respeto a ellos,
deberías cuidar al máximo su calidad.
 Si tu código hace que varios test dejen de funcionar, por respeto a los demás
miembros, deberías solucionar los problemas lo antes posible. Porque unos test
que no funcionan están invalidando el trabajo de todos.

 Si un miembro del equipo tiene poca experiencia, hay que respetar sus ganas de
aprender y mejorar y hay que hacer un esfuerzo por ayudarle y enseñarle todo lo
posible. Las críticas siempre deben ser constructivas y deben estar enfocadas en la
mejora, no en la crítica destructiva.
3.4.5. LOS ROLES EN XP
En la actualidad, muchos proyectos de desarrollo software se llevan a cabo aplicando a

la misma vez Scrum y programación extrema. Las cuestiones de gestión como las reuniones,
plazos, entregas, selección de tareas, etc., están definidas dentro de la metodología scrum y
las prácticas técnicas que aplica el equipo de desarrollo para que el software que se desarrolla
sea de calidad, esté preparado para las adaptaciones que pide el cliente están recogidas en la
programación extrema. De hecho, hay muchos libros que presentan ambas metodologías de
forma conjunta, siendo uno de los más famosos “Scrum and XP from the Trenches”, de Henrik
Kniberg. Se puede encontrar de forma gratuita en la red y traducido al castellano.
En el desarrollo de software hay principalmente tres actores implicados:
 Clientes/Usuarios: son los que necesitan que se cree la aplicación. Tendrán que
aprender el modo de comunicarse con el equipo, para conseguir transmitir sus
ideas. El equipo le ayudará en ese cambio de mentalidad para obtener el producto
en plazos.
 Gestores: son los que controlan los recursos del proyecto. Aprenderán a medir el
progreso del proyecto, la calidad del producto y cómo responder a las preguntas
importantes. Es muy importante que aprendan a confiar en la propia gestión que
hace de sí mismo el equipo de desarrollo.
 Programadores: son aquellos, dentro del un proyecto XP, que definen la
arquitectura, diseñan el sistema, escriben los test y el código. Aprenderán cómo
tratar con los requisitos cambiantes, con el cliente y lo más importante cómo
desarrollar lo que es necesario hoy sin pensar en las necesidades futuras.
Clientes, programadores y gestores, todos juntos trabajaran para construir lo que el

sistema necesita.

El equipo en XP
Un proceso puede mejorar la productividad de un equipo, pero tan sólo para esa
mínima parte dentro de todo el proceso; en cambio, un equipo que trabaja de un modo
eficiente “como una unidad” puede mejorar la productividad en todas y cada una de las etapas
del desarrollo del software, aunque en muchas ocasiones esto no ocurre. No existen tantos
equipos que trabajen de manera compenetrada y unida, como si fueran una sola persona. En
el mundo del desarrollo del software hay muchos egos (o “estrellas del rock”) que prefieren
trabajar en solitario y no compartir su conocimiento.
Esto es uno de los aspectos que pretende cambiar la programación extrema. Es

necesario que todos los desarrolladores colaboren juntos, como un verdadero equipo, para
crear el mejor producto que jamas hayan soñado. La motivación y el objetivo compartido es
también uno de los aspectos que se fomentan.
XP es un proceso simple que pone a personas a trabajar de manera conjunta para

lograr aplicaciones de éxito. XP se puede usar tanto en equipos distribuidos, como en equipos
que trabajan dentro de la misma empresa en una oficina en común. La principal característica
que tendrán todos es que desean crear software de calidad de un modo rápido y flexible.
El cliente/usuario
Al igual que en Scrum, en XP el cliente pasa a ser un miembro más del equipo.
La forma de trabajo habitual antes de la popularización de las metodologías ágiles era

hablar con el cliente cuando casi se estaba llegando al final del proyecto y comprobar si todo
era correcto. Entonces el cliente se podía encontrar con desagradables sorpresas. En cambio, si
el cliente trabaja de manera activa con el equipo de desarrollo, puede ir acotando los
problemas, ofreciendo soluciones e, incluso, aprendiendo cosas nuevas acerca del problema.
Siempre es un experto en el ámbito del problema el que encuentra las soluciones más
elegantes y mejores. En la metodología Scrum, el cliente está representado en el equipo como
el Product Owner.
El gestor
Dependiendo de la metodología de desarrollo que estemos empleando en el proyecto,

el gestor recibe diferentes nombres y puede asumir unos roles u otros. En la metodología
Scrum la figura con más carga de gestión en el Scrum Master. Aunque en esta metodología el
equipo de desarrollo se autogestiona y sus tareas distan mucho del tradicional gestor de
“ordeno y mando”, que planifica tareas a sus subordinados. En términos generales, el gestor
no desarrolla el producto, sino que facilita el contexto en el que el equipo de desarrollo

desarrolla el producto, por ejemplo quitándoles impedimentos. La labor más importante de un

gestor es conseguir que cada uno pueda hacer el trabajo que debe hacer.
El/La Programador/a
El programador/a analiza, diseña, testea el software y lo integra en el sistema.

También estima el coste de implementar cada historia y cuando finalmente la implementa, se
puede medir su velocidad.
Para un desarrollador/a, lo más importante es entender correctamente la

funcionalidad que está descrita en la historia de usuario. Ante cualquier duda, debería tener
accesible al cliente para entablar una conversación que le permita entender la funcionalidad,
su motivación y el mecanismo que el cliente usará para verificar que la historia se ha
implementado correctamente. De forma complementaria, el cliente debería ver cuanto antes
la funcionalidad implementada, de forma que pueda dar realimentación a los desarrolladores
si no han comprendido correctamente lo que él quería. También puede ocurrir que el cliente
quiera refinar la funcionalidad una vez que la haya empezado a usar o que incluso cambie de
opinión completamente.
Hasta ahora puede parecer que la programación extrema es un compendio de

principios que están presentes en las metodologías ágiles que ya conocemos. Pero aquí
empieza la aportación significativa de la programación extrema. XP describe y recomienda un
conjunto de buenas prácticas para que el equipo de desarrollo “programe bien” y por tanto
produzca “software de calidad”.
Hay muchas técnicas parar determinar la calidad de un producto software. Algunas son
más cuantitativas (por ejemplo, medir el porcentaje de código duplicado), y otras son más
cualitativas (p.e. revisando el código entre los miembros del equipo). Existen algunas técnicas
que para medir la calidad se centran en los aspectos más tecnológicos (arquitectura software,
patrones de diseño...). Otras técnicas miden la calidad en función de la satisfacción del cliente,
cumplimiento de plazos, etc. Entraremos en detalle en estos aspectos en la siguiente clase.
Pero en este punto, podemos considerar que un software se ha desarrollado “bien”, es decir,
es de calidad, si cumple los siguientes criterios:
 El producto está libre de defectos, es decir, no falla.

 El producto hace lo que el cliente espera de él.
 El producto se puede mantener, es decir, se le pueden añadir funcionalidades y se
puede adaptar a nuevas plataformas o entornos con unos costes aceptables.
 El producto se desarrolla en unos tiempos predecibles.
 XP es una metodología que se centra especialmente en describir las buenas
prácticas que el equipo de desarrollo debe seguir para producir software de calidad.
Aunque menciona algunos aspectos relativos a la gestión del proyecto, otras

metodologías como scrum los tienen más desarrollados. En este sentido se puede
decir que XP está enfocada principalmente en los desarrolladores software.
 Esta metodología se denomina programación extrema porque cuando se propuso,
sus buenas prácticas eran una forma de llevar al extremo tareas que los
desarrolladores ya realizaban pero de forma mucho menos frecuente.
 Si revisar el código es bueno, entonces lo llevamos al extremo y el código se revisará
por otro compañero cuando se está creando. Es decir, se programará se revisará el
código todo el tiempo y por parejas. (Programación por pares).
 Si los test son buenos porque de forma automática dicen si el software hace lo que
tiene que hacer y sin defectos, entonces todos los involucrados del proyecto
realizarán tests, incluso los clientes. (Test unitarios, de integración y de aceptación).
Además, si ejecutar los test me aporta confianza de que todo funciona, ejecutemos
los test en cada cambio del código (integración continua).
 Si un código con un buen diseño es importante, entonces diseñemos todos los días
y cambiemos nuestro código para que siempre tenga un buen diseño (Refactorizar).
 Si lo sencillo es lo mejor, siempre se intentará desarrollar de la manera más sencilla
posible para poner en marcha la funcionalidad y aportar valor al cliente, aunque eso
implique tener que rediseñar. (Hacer el trabajo actual de la manera más sencilla
posible).
 Si la iteraciones cortas son buenas, se harán iteraciones cortas de días o de
semanas. (Re-planificación y retrospectivas).
Al final de esta clase y en la siguiente, desarrollaremos mucho más las buenas prácticas
de XP, pero a continuación se presentan algunas de las más importantes de forma resumida:
Tests, tests y más tests
Los test automatizados son uno de los aspectos más importantes para que el código
desarrollado sea de calidad, es decir, esté libre de errores (calidad interna) y se comporte
como el usuario quiere (calidad externa). Además, los test son críticos a la hora de incorporar
nuevas funcionalidades a un producto, porque se reduce mucho el riesgo de que algo deje de
funcionar cuando añadimos una nueva funcionalidad. En realidad, un test no impide que se
introduzca un error al cambiar el código, pero al ejecutar el test veremos que falla cuando algo
que funcionaba deja de hacerlo. En este sentido, también existen unos test orientados al
cliente llamados test de aceptación. Estos test son el mecanismo con el que el cliente está
seguro de que el sistema se comporta como él desea, y lo sigue haciendo cuando se van
incorporando nuevas funcionalidades.
En la siguiente fotografía podemos ver cómo aplican los test automatizados otros
sectores como los fabricantes de sillas. En este caso, se prueba la resistencia al uso, en el
software, se prueba que el sistema no se rompe cuando se incorporan nuevas funcionalidades.

Código “entregable”
El código debe estar siempre listo para empaquetar un producto y entregárselo al

cliente (o al menos al final de cada iteración). Se ha demostrado empíricamente que si se
cumple con ello, se reducen mucho los riesgos del proyecto y el equipo de desarrollo y el
cliente pueden adaptarse mejor al cambio. Para conseguir que el equipo pueda entregar el
producto prácticamente en cualquier momento, se utilizan técnicas como la integración
continua y el despliegue continuo, que consisten básicamente en ejecutar de forma
automática todos los pasos que permiten tener un software entregable partiendo del código
fuente. Además, durante el proceso de “construcción” del software se ejecutan todos los test
que existan hasta el momento, de forma que se puede verificar que todo sigue funcionando
como antes. Todo esto se explicará de forma detallada en la siguiente clase.
Todo el código es de todos
Uno de los secretos para que un proyecto tenga éxito, es que el equipo esté unido en
la consecución de los objetivos del mismo. Cuando el equipo es un conjunto de desarrolladores
que tienen que realizar un producto software, esto se traduce en que todo el código es de
todos, independientemente de quién haya escrito cada línea. Es decir, no hay propiedad del
código. Para conseguir esto, habitualmente se hacen revisiones de código de unos
desarrolladores a otros, y los desarrolladores participan en varias partes del código a lo largo
del proyecto. Esto permite que todo el código sea considerado como propio por todos los
desarrolladores. Esto también fomenta la colaboración entre los miembros del equipos, lo
miembros con mejores capacidades técnicas enseñarán a los novatos cuales son las mejores
técnicas. Al fin y al cabo, todos los desarrolladores deben sentirse cómodos con todo el código,
como si hubiese estado escrito por ellos mismos.
Diseño simple y código de calidad
El código debe tener un diseño simple, que sea suficiente para la funcionalidad que se
está proporcionando hasta ese momento. Se desaconseja que el código esté
sobredimensionado y ultraflexible, porque eso puede hacer que sea más complejo de lo
necesario, lo que finalmente dificulta su creación y mantenimiento. Además, debe cumplir con
los criterios de calidad, entre otros: que no haya código repetido, que sea sencillo, que sea fácil
de entender una vez escrito, que se comporte de forma esperada, etc. Para conseguir que el
código tenga calidad se aplica de forma continuada una técnica llamada “refactorización”, que
consiste en realidad cambios en el código con el objetivo de que tenga mayor calidad, pero sin
añadir ninguna funcionalidad adicional. Además, se usan técnicas de análisis continuo que
miden la calidad del código. Una de las métricas más básicas y más usadas es la que determina
si hay código duplicado.

Programación por pares
Programar es una tarea compleja que requiere de un esfuerzo intelectual importante.

Cuando un programador empieza a desarrollar un programa tiene como objetivo que el
programa se comporte como él quiere y que lo haga aprovechando los recursos hardware
disponibles. Además, también quiere que el código sea comprensible para que él (u otro
desarrollador) pueda ampliar o mejorar ese código en el futuro. Obviamente, el programa
tiene que estar libre de defectos. Pero conseguir un código que reúna todas esas
características no es sencillo. Se ha demostrado empíricamente que si dos desarrolladores
programan en el mismo PC el mismo código se consigue un código de mucha mayor calidad,
con menos defectos y mucho más comprensible. Hay ocasiones en las que el código es
bastante sencillo, y la programación por pares no aporta mucho valor y se podría considerar
que se están desaprovechando el tiempo de un desarrollador, que podría estar haciendo otra
cosa. Pero cuando el código es complejo, bien por la propia complejidad de la funcionalidad a
desarrollar, o bien porque la tecnología es desconocida, la programación por pares es
altamente productiva. En este sentido, programar es tomar llegar a situaciones de
compromiso, porque hay fuerzas que tiran en sentidos opuestos. Tener la posibilidad de
intercambiar opiniones con otro desarrollador mejora enormemente la calidad de las
soluciones aportadas.
3.4.6. LOS PRINCIPIOS DE XP
Los valores son universales y muy genéricos. Aunque en las explicaciones hemos
introducido ejemplos específicos relacionados con la programación, en realidad podríamos
haber puesto ejemplos de cualquier otro contexto, ya que la comunicación, simplicidad,
realimentación, coraje y respeto se podrían aplicar en otros contextos.
Para cubrir el hueco entre los valores y las buenas prácticas técnicas, Kent Beck, uno
de los autores de la metodología XP decidió indicar una serie de Principios. Según él, los
principios son guías vitales específicas de un entorno concreto. Dicho de otra forma, los
valores son demasiado abstractos para guiar el comportamiento. Los principios son un
refinamiento de los valores pero concretados para un entorno específico.
En XP se definen los siguientes principios:
1. Humanidad: los desarrolladores son personas y, como tales, tienen necesidades y objetivos
personales. La programación extrema es consciente de este aspecto y no considera a las
personas como recursos intercambiables. Algunas de las prácticas de XP tienen como objetivo

satisfacer, en la medida de lo posible, las necesidades personales de cada miembro del equipo
de forma equilibrada con el equipo como conjunto. El razonamiento detrás de este enfoque es
muy sencillo, una persona estará involucrada con los objetivos del equipo si en cierta forma
esos objetivos están alineados con sus propios objetivos personales.
2. Economía: alguien paga los sueldos. Así que todo el trabajo técnico tiene que estar alineado
con los objetivos de negocio. Siempre se intentan implementar cuanto antes las historias de
usuario con mayor valor para el negocio. Hay dos cuestiones económicas que afectan al
desarrollo software. Por una lado está el valor del dinero en el tiempo, que se refiere a que
tener un euro hoy es mejor que tener es mismo euro mañana. Por eso es necesario tener
software funcionando cuanto antes, incluso ese software podrá llegar a producción si el
modelo de negocio lo considera oportuno. Este tipo de ideas están muy alineados con los
conceptos de lean startup, en los que hay que validar el modelo de negocio cuanto antes con
los clientes. Por otro lado está el valor como opción de futuro. Si el software y el equipo son
flexibles y se adaptan al cambio, tendrán mucho más valor que si son fijos y rígidos. Las
prácticas técnicas que se proponen tienen la economía muy presente.
3. Beneficio mutuo: Las tareas tienen que suponer un beneficio para el que las realiza y para el
que se beneficia de ellas. Si no es así, esas tareas acabarán realizándose con menos cuidado
porque no aportan un valor directo al que las realiza. El caso más representativo es el caso de
la escritura de una documentación extensa que explica con detalle el comportamiento de un
sistema. Escribir la documentación no aporta ningún valor concreto al que la escribe, porque
todo el valor será obtenido por el que consulte la documentación en el futuro. En XP se
sustituye la documentación detallada por un conjunto de prácticas que aportan mucho valor al
que las realiza y ofrecen incluso más valor que la documentación al que recibe los resultados
en el futuro. En concreto, en XP se promueve la escritura de test automatizados, la mejora del
diseño de forma continua y la selección de nombres en el código que sean auto-explicativos.
Todas estas técnicas aportan mucho valor al que las realiza, porque facilitan la comprensión y
mantenibilidad del código hoy.
4. Auto-similaridad: intenta aplicar las cosas que funcionan en otros contextos y a escalas
diferentes, porque pueden funcionar también. Esto, sobre todo, se aplica a los tests. Puedes
implementar tests a diario a módulos internos de la aplicación (test unitarios). Pero también
puedes implementar test de integración y de aceptación una vez por semana para verificar que
la integración del módulos y el sistema completo funciona como se espera.

5. Mejora continua: en el desarrollo software nada es perfecto, pero todo es “perfeccionable”.

“Lo perfecto es enemigo de lo bueno” sugiere que algo razonable ahora es mucho mejor que
algo perfecto dentro de una semana. Pero siempre hay que tener como objetivo mejorar y
perfeccionar eso bueno que acabamos de hacer. Por eso una de las prácticas es la mejora
continua del diseño. No se debe sobre-diseñar un sistema, pero a medida que avanza su
desarrollo, su diseño tiene que ir mejorando para que el código se mantenga con calidad.
6. Diversidad: los equipos de desarrollo tienen que tener diferentes habilidades, experiencia,
enfoques. Solo de esta forma el equipo podrá elegir las mejores soluciones en cada caso. Eso
puede ser una fuente de conflictos que tienen que resolverse, por eso XP tiene algunas
prácticas técnicas que favorecen los espacios de comunicación necesarios para resolver esos
conflictos.
7. Reflexión: los buenos equipos no solo hacen el trabajo, si no que también son conscientes
de cómo hacen el trabajo y mejoran de forma continua el proceso con el que hacen el trabajo.
Las retrospectivas en scrum son una práctica concreta orientada a la mejora del proceso. Tener
un espacio para el auto-análisis y la crítica constructiva favorece enormemente al
funcionamiento de un equipo.
8. Flujo: históricamente el desarrollo software se ha realizado de forma discreta en grandes

saltos. Las actualizaciones de software ocurrían cada uno o más años, lo que suponía mucho
riesgo en forma de retrasos y en forma de rechazo por los usuarios. Actualmente es común
que el software se desarrolle de forma continua y predecible. Dependiendo del software
puede ser una o dos veces al año, pero hay otros servicios (como algunas aplicaciones web)
que se actualizan varias veces en el día. Las prácticas relacionadas con la integración continua
están guiadas por el principio del flujo.
9. Oportunidad: considera los problemas con una oportunidad de mejora. Si un cliente se

queja de que una funcionalidad tiene fallos, considéralo como una oportunidad para mejorar
la cobertura de tus tests. Si un programador comete muchos errores programando, favorece la
programación por pares y la revisión del código. Si enfocamos todos los problemas como
oportunidades de mejora, será mucho más probable que el software desarrollado tenga cada
vez mayor calidad con un coste razonable.
10. Redundancia: la redundancia se aplica en muchos contextos de la informática. No se

debería tener un único punto de fallo, ni en los sistemas informáticos ni en los equipos. Por

ejemplo, los tests son una forma de redundancia sobre una funcionalidad implementada. Un
código actúa de una forma y otro código verifica que actúa como debe actuar. La
programación por pares o la revisión del código son una forma de redundancia. La
comunicación continua con el cliente es una forma de verificar lo que se pidió en un primer
momento.
11. Fallo: hay veces que intentar algo y fallar es mucho mejor que tener interminables
reuniones discutiendo las bondades de cada alternativa. Hay gente que denomina “análisis
parálisis” al proceso de sobre-analizar algo elucubrando decenas de variantes y situaciones
cuando en realidad se podrían haber implementado dos o tres propuestas y haber realizado un
análisis empírico, mucho más efectivo. El fallo es una forma de aprender y si se gestiona de
forma adecuada, mucho mejor que el análisis parálisis. El lean startup recomienda fallar rápido
y barato, como forma de validar modelos de negocio.
12. Calidad: la calidad no es una forma efectiva de control. Un proyecto con mayor calidad no
es más costoso que otro con menor calidad. En proyectos pequeños, en forma de prototipos,
los desarrolladores pueden relajar mucho la calidad del código y ganar con ello algo de time-
to-market. Pero en prácticamente cualquier proyecto real la calidad garantiza que el coste del
mantenimiento no se dispara, lo que en el medio plazo reduce los costes y los riesgos del
proyecto. Hay veces que la calidad está reñida con la simplicidad. Una solución más
mantenible puede ser más compleja y costosa que una solución más simple pero menos
mantenible. La regla sería: intenta hacerlo lo mejor que puedas con el tiempo disponible. En la
siguiente iteración se mejorará con el trabajo de la primera iteración como base. Esto se puede
considerar una pérdida de tiempo, pero también es una forma de luchar contra el análisis-
parálisis, aportando valor al cliente desde el principio y reduciendo los riesgos.
13. Pasos de niño: intenta dar los pasos lo más pequeños posibles, eso reducirá los riesgos de
fallo de los pasos grandes. Por ejemplo, pasa los test por cada pequeño cambio de código que
realices. Eso permitirá detectar más rápidamente los potenciales errores que introduzcas. No
esperes dos años a sacar una nueva versión, intenta ofrecer las actualizaciones lo más
frecuentes a los usuarios. A priori puede parecer que los pequeños pasos hacen el desarrollo
más lento, pero, en la práctica, los pequeños pasos permiten mitigar muchos riesgos y los
problemas se solucionan mucho más rápido.
14. Responsabilidad aceptada: la responsabilidad no se puede imponer, solo se puede aceptar

voluntariamente. Las prácticas de XP reflejan este principio. El equipo que tiene que realizar un
trabajo estima el coste de hacer ese trabajo y se responsabiliza de cumplir con esa estimación

lo mejor que pueda. De igual forma, la persona encarga de implementar una historia de
usuario se responsabiliza del diseño, implementación y prueba de dicha historia.
Los principios permiten comprender mejor las prácticas técnicas propuestas en XP.
Además, siguiendo los principios se pueden elaborar nuevas prácticas más adecuadas para
ciertos tipos de proyectos.
3.4.7. LAS BUENAS PRÁCTICAS TÉCNICAS EN XP
Como hemos visto antes, una de las principales diferencias entre XP y otras
metodologías como Scrum es que en XP el peso principal lo tiene el equipo de desarrollo y las
buenas prácticas técnicas que se recomiendan. A continuación os enumero las buenas
prácticas técnicas que XP propone para conseguir un software de calidad de forma frecuente y
con un coste predecible:
 El equipo debe estar junto

 El equipo como una unidad
 Usa radiadores de información sobre el progreso del proyecto
 Trabaja las horas razonables para ser productivo
 Planifica usando historias de usuario
 Margen en la planificación (Slack)
 El ciclo semanal y el ciclo trimestral.
 Programa por pares
 Programación dirigida por pruebas
 Construcción en 10 minutos
 Integración continua
 Diseño emergente
Algunas de estas prácticas son cuestiones más generales de gestión de proyectos y

equipos, mientras que otras son más particulares del desarrollo software, más técnicas (que
aparecen marcadas con * en la lista anterior). A continuación se describirán las prácticas más
generales, dejando las prácticas técnicas para la próxima clase.

El equipo debe estar junto
Según la metodología XP, el desarrollo mejora si se realiza en un espacio abierto y

suficientemente grande para que todo el equipo esté junto. Una de las claves del éxito de un
proyecto es la comunicación entre sus miembros y la sensación de equipo. Y eso se consigue
en gran parte desarrollando juntos. Y no sólo se trata de programar en parejas como veremos
posteriormente, si no más bien en desarrollar en un espacio compartido. El refranero español
lo tiene claro: “el roce hace el cariño”.
En mi experiencia personal, trabajar en la misma sala ha sido muy importante para

conseguir los objetivos del proyecto. Hablando con compañeros todos hemos constatado la
importancia de estar juntos. Esto no quiere decir que trabajar juntos en la misma sala se una
condición imprescindible para desarrollar software de calidad, simplemente que es una
práctica que se ha demostrado que ayuda a la consecución de los objetivos del proyecto.
Obviamente también hay que respetar al resto de compañeros del equipo, mantener
la sala con un nivel de ruido aceptable y evitar interrumpir a los demás cuando están
concentrados en una tarea que requiere concentración.
Otro aspecto importante que hay que tener muy presente es que el número de
personas de un equipo no puede ser muy grande. La experiencia ha demostrado que el
tamaño ideal para un equipo de desarrollo son las 7 personas, pudiendo llegar hasta 9 en casos
excepcionales. En caso de equipos más grandes, tendrán que dividirse en dos para llegar a un
equilibrio entre maximizar la productividad y minimizar la carga de gestión y coordinación
entre los miembros.
El equipo como una unidad
Incluye en el equipo todos los perfiles necesarios para la consecución de los objetivos
del proyecto. Es un forma de decir es mejor dividir a los equipos por proyecto que por tipo de
tareas. La experiencia ha demostrado que es mejor que en un mismo equipo exista una
persona experta en experiencia de usuario, varios desarrolladores y un administrador de
sistemas en vez de tener departamentos de experiencia de usuario, departamentos de
desarrollo y departamentos de sistemas que se encarguen entre ellos de varios proyectos.
Focalizar en un proyecto, con unos clientes concretos y con unos compañeros concretos ayuda
a implicarse con el proyecto, a tener la sensación de equipo y a conseguir mejor los objetivos.
Un equipo no tiene por qué ser constante a lo largo del tiempo, puede cambiar de
integrantes a medida que el proyecto avanza y ciertas tareas dejan de ser necesarias. Por
ejemplo, la persona encargada de UX en un proyecto puede tener menos carga de trabajo en
las últimas iteraciones del proyecto. En ese momento se podrá dedicar a otro proyecto.

Aunque un miembro del equipo llegue un momento que puede estar colaborando con
otro equipo en otro proyecto, hay que intentar evitarlo en la medida de lo posible. A las
personas nos cuesta mucho cambiar de tareas y de objetivos, somos más productivos cuando
tenemos un objetivo claro y todas nuestras acciones están encaminadas a conseguirlo.
Además, colaborando en dos equipos simultáneamente se reduce la sensación de pertenencia
al grupo, lo que redunda negativamente en la motivación y el compromiso.
Usa radiadores de información sobre el avance del proyecto
Cada miembro del equipo tiene que saber cual es la mejor tarea que puede desarrollar
en cada momento por el bien del equipo. Además, cada miembro del equipo tiene que
conocer el estado del desarrollo de la iteración actual y del proyecto en su conjunto.
Esto se puede conseguir de muchas formas. Se pueden usar herramientas software de

gestión de tareas, se puede usar un “rudimentario” excel compartido en el que cada fila
representa una tarea y están organizadas por orden de prioridad, o cualquier otra técnica que
permita a mano la lista priorizada de historias de usuario.
En muchos equipos de desarrollo se pretende que el avance del proyecto sea visible
para todos en un mural. Para ello, utilizan post-its que son fáciles de escribir, desechar y
mover. Cada post-it representa una historia de usuario. Cada historia de usuario se divide en
tareas, y para cada una de ellas también se usa un post-it. Estos post-its son fáciles de escribir
por cualquiera y son fáciles de mover de estado. Es habitual tener una pizarra con columnas.
Cada columna representa el estado de la tarea: Lista, En progreso, Finalizada, Con
impedimentos.
A esta forma de gestionar el avance de los proyectos también se le conoce como visual
managment. El blog XQA de Xavier Quesada muestra muchas técnicas interesantes de gestión
visual. A continuación se muestra una fotografía de un radiador de información típico extraída
de este blog.

El burn-down de Scrum es también un muy buen radiador de información sobre el avance de la

iteración:

Una de las grandes ventajas de los radiadores de información es que el estado del
proyecto siempre es visible para todos. Para los desarrolladores, para el scrum máster y sobre
todo para los clientes, que de un simple vistazo y sin apenas conocimientos técnicos pueden
ver si determinadas funcionalidades ya están implementadas en el sprint actual.
Trabaja las horas razonables para ser productivo
Hay algunas buenas prácticas que deberían considerarse simplemente como sentido
común. Y es que trabajar las horas razonables para ser productivo se debería aplicar en
cualquier contexto. Lo que ocurre es que el desarrollo de software es un tipo de tarea tan
especial que parece que podemos estar programando todo el día simplemente con un poco de
café a nuestro lado. El problema es que llegado a un punto, la productividad cae hasta el punto
de que empezamos a cometer errores que producen más daño que el beneficio que podríamos
obtener por haber trabajado más horas.
En ciertos momentos del desarrollo puede ser necesario “hacer un esfuerzo” y quedarse
algunas horas más, pero eso será un mal síntoma y deberían solucionarse cuanto antes los
problemas que lo provocaron. El trabajo intelectual como el desarrollo de software bajo
mucha presión de forma continuada en el tiempo conlleva inevitablemente al desarrollo de
productos de baja calidad.
Planifica usando historias de usuario
Las historias de usuario se han convertido en el estándar en las metodologías ágiles

para describir de forma concisa y resumida la funcionalidad de un software y guiar el
desarrollo. La metodología XP también recomienda el uso de esta técnica.
No hay mucho más que decir sobre las historias de usuario que no se haya dicho ya a
lo largo del curso, así que no volveremos a repetirnos, si alguno de vosotros tiene alguna duda
o cuestion a debatir os dejo abierto el foro al respecto :)
Margen en la planificación (Slack)
En la planificación pueden incluirse algunas tareas que no sean obligatorias y que

puedan ser eliminadas si no se llega a tiempo. Es importante cumplir los compromisos, así que
conviene tener cierto margen de maniobra en la planificación por si las estimaciones no son
ajustadas.

En algunos proyectos, el equipo o el manager planifican más carga de trabajo de la que

realmente se puede realizar sin comprometer la calidad del producto. Eso crea demasiada
tensión en el equipo que a la larga es perjudicial para el desarrollo del proyecto. Cumplir los
compromisos adquiridos por el equipo es motivador. No cumplir los objetivos es frustrante y
desmoralizador.
En muchas organizaciones este tiempo extra de margen se suele emplear en que los
desarrolladores colaboren en proyectos de software libre que puedan ser interesantes para la
organización. O bien que experimenten con nuevas tecnologías. O simplemente que mejoren
sus habilidades como programadores o gestores.
Google es famosa por permitir a sus empleados que dediquen el 20% de su tiempo a
proyectos de software libre. La empresa madrileña Kaleidos también aplica una técnica similar
con su pi-week.
El ciclo semanal y el trimestral
A diferencia de la metodología Scrum, que recomienda iteraciones de entre 1 y 4

semanas, Kent Beck, en la segunda edición de su libro Extreme Programming Explained
propone hacer iteraciones cortas de 1 semana. Dice que eso permite que el equipo se focalice
en las historias de usuario que tiene implementar en esa iteración. Según indica, una semana
es un marco bastante usado en otros muchos contextos humanos. Por ejemplo, las clases el
IEBS están divididas en semanas, el trabajo se divide en semanas (dejando el fin de semana de
descanso), etc. Esa sincronía entre los días de la semana y las tareas de la iteración hacen que
el trabajo sea más predecible. La principal desventaja de las iteraciones tan cortas es que si
queremos aplicar la metodología scrum con sus reuniones de planificación, demo y
retrospectiva, la semana puede ser demasiado pequeña para que esas actividades no resulten
en un desperdicio de tiempo.
Por otro lado, XP recomienda celebrar ciclos de 3 meses a modo de guía general del
desarrollo cubriendo todas las semanas dentro de esos tres meses.

3.4.8. REFERENCIAS
 Manifiesto Agil
 1996. Smalltalk Best Practice Patterns. Prentice Hall. (ISBN 978-0134769042).
 1999. Extreme Programming Explained: Embrace Change. Addison-Wesley.
 Winner of the Jolt Productivity Award. (ISBN 978-0321278654).
 2004. Extreme Programming Explained: Embrace Change (second edition). Addison-
Wesley. (ISBN 978-0321278654)
 2008. Implementation Patterns. Addison-Wesley. (ISBN 978-0321413093).
 2007. Scrum and Xp from the Trenches. Lulu Pr (ISBN 978-1430322641).

Manual Te GP Agiles

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Manual Te GP Agiles

Caricato da

Copyright:

Formati disponibili

MANUAL

European Open Business School

European Open Business School 2

1.1.1. INTRODUCCIÓN A LA GESTIÓN DE PROYECTOS

Como ya sabéis, este es el módulo de Gestión de Proyectos. Todas las áreas de

En el ámbito empresarial, y en la vida también, queramos o no, estamos habituados a

Planificar un largo viaje en coche, puede considerarse un proyecto en sí mismo y, por

Espero que se haya entendido el concepto. Obviamente, para los conductores

La gestión de proyectos se lleva realizando desde que el hombre es hombre. Se

European Open Business School 3

Una de las primeras constancias de la aplicación de gestión de proyectos

Como todo, las metodologías de gestión de proyectos han evolucionado a lo largo de la

En la actualidad, multitud de aspectos han cambiado desde los inicios de la gestión de

La irrupción de la tecnología y los cambios en el paradigma del trabajo (relación

European Open Business School 4

He preparado esta clase siguiendo un hilo conductor que nos permita ir

Seguiremos la clase trabajando ya sobre la gestión de proyectos. Haremos una

Antes de comenzar ya de lleno con el contenido de la clase, si me permites una

European Open Business School 5

European Open Business School 6

1.1.2. BÁSICOS PARA GESTIÓN DE PROYECTOS

Otro factor fundamental para la consecución de los objetivos del proyecto es la

Para ser un buen profesional y gestionar con éxito un proyecto empresarial, es

Reflexión del profesor:

A su vez, he conocido multitud de profesionales, muy buenos en su ámbito de

¿A qué se debe esto? Bajo mi juicio, se debe principalmente a que no tienen

Para implantar cualquier solución en Internet es necesario controlar o conocer

European Open Business School 7

Tener elevados conocimientos técnicos en tu área de expertise no te ayudara en nada

Un ejemplo sencillo: a nadie en su sano juicio, sin conocimientos mecánicos, se le

 Tolerancia al estrés. Me parece fundamental. Cualquier persona excesivamente

European Open Business School 8

 Experiencia y conocimiento técnico. Un conocimiento del área relacionada con el

Fuente Listado: Elaboración propia y APM (Association for project management)

Reflexión del alumno. ¿Eres el indicado para gestionar tu startup?

European Open Business School 9

empresa y muchos menos en cuanto a la gestión de la inversión que comenzó a llegar a la

Quizás no seas el más adecuado, y es altamente posible que no dispongas de los

European Open Business School 10

Herramienta propuesta por el profesor

Se trata de la imagen que ves a continuación, un círculo numerado con 12 apartados:

 Elaboramos un listado de 12 cualidades (actitudes, aptitudes, conocimiento,

European Open Business School 11

conocimientos, test, etc. En función de nuestras posibilidades, usaremos una u

Un MP debe tener en cuenta multitud de aspectos para gestionar con éxito un

Estos aspectos se pueden encontrar en el denominado “Triángulo de Gestión de

Básicamente, lo que se intenta transmitir a través de esta imagen, es que el PM debe

European Open Business School 12

 Tiempo: se refiere a la cantidad de tiempo disponible para completar el proyecto.

 En un primer momento, hay que identificar el alcance del proyecto, es decir,

European Open Business School 13

siempre la perspectiva correcta y planear tomando en cuenta este triángulo,

European Open Business School 14

Conoceremos en este capítulo las distintas metodologías y herramientas disponibles

Todas ellas, en mayor o menor medida, están orientadas a proyectos empresariales y

Antes de entrar en materia, vamos a conocer la definición formal de “proyecto”:

 "Un proyecto (empresa, startup, producto y/o servicio) es un conjunto de

La Gestión de un Proyecto son las tareas encaminadas a diseñar una planificación

Un ejemplo sencillo: La organización de una mudanza. Pueden parecer proyectos

European Open Business School 15

lugares alquilados a la vez. Si hay retrasos en la mudanza, implicaría un sobrecoste el pagar 2

La recomendación del profesor

A mayor inversión para llevar a cabo el proyecto o a mayor desconocimiento sobre la