Reconsiderandoagile PDF

klaus LEOPOLD
Reconsiderando
AGILE
Por qué los equipos ágiles no tienen
nada que ver con la Agilidad Empresarial
IMPRESSUM
4 Reconsiderando Agile
Copyright © 2018, LEANability GmbH, Viena
20 de septiembre de 2019
Texto: Dolores Omann • Ilustraciones: Matthias Seifert • Diseño gráfico: Mario Simon • Traducción: Silvia Morenilla Fernández
La obra, incluida la totalidad de las ilustraciones, está protegida por derecho de autor. Queda prohibido su uso sin el
consentimiento expreso de la editorial. Visítenos en www.LEANability.com o contacte a office@leanability.com para
obtener información legal, otras peticiones, así como pedidos grandes.
ISBN 978-3-903205-55-0
Este libro también está disponible como Actualizaciones
Kindle ISBN: 978-3-903205-56-7 agilitaet-neu-denken.com
Leanpub ISBN: 978-3-903205-57-4 LEANability.com
youtube.com/c/LeanBusinessAgility
twitter.com/klausleopold
CONTENIDO
Prólogo Klaus Leopold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 06
Prólogo José Casal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 08
5
¡Gracias! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Parte 1 | El problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Parte 2 | Las causas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Parte 3 | Primeras soluciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Parte 4 | El resultado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Glosario de términos en inglés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Referencias bibliográficas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

RECONSIDERANDO AGILE
6
S e puede hacer de cada problema un misterio. Actual-
mente existen suficientes patrones y productos ágiles
que convierten cualquier simple percepción en un
desafío que, naturalmente, solo se puede solucionar
con uno u otro método. Sí, yo mismo formo parte de este mundo. Gano
mi dinero dando sensatos consejos a empresas y mi nombre se rela-
ciona con Kanban. Sin embargo, mi objetivo no es hacer las cosas más
complicadas de lo que ya son. Y esta simple visión lo apoya: una
organización ágil no nace cuando se optimiza a tope sus elementos,
los cuales, en la mayor parte de los casos, son equipos aislados entre
sí. Las odiseas ágiles comienzan normalmente con esta optimización
local en la que, simultáneamente, el método ágil elegido se convierte
en el becerro de oro. Aún se intenta dar más importancia a los méto-
dos que a la cuestión de qué es lo que crea valor añadido para el
cliente. Es aquí donde muy a menudo se queda en el camino la
cooperación entre las áreas de desarrollo de una organización y la
gestión empresarial.
Mi intención con este libro es ir al grano y, con el poder de las ilustra-

ciones, entre otros aspectos, expresar de forma clara y manifiesta esta
simple percepción que, ni se puede certificar ni se puede registrar.
En los últimos años me he dedicado a ir de conferencia en conferencia
con mi presentación “Por qué los equipos ágiles no tienen nada que
ver con la agilidad empresarial” y los oyentes siempre comentaban
cómo una y otra vez volvían a toparse con los mismos errores y
tribulaciones de las transformaciones ágiles.
PRÓLOGO I
Pero no espere aquí profundizar en la teoría. Lo que leerá le dará más

bien una visión general de lo que suele fracasar en muchos proyectos
de cambio ágiles, así como simples sugerencias de cómo evitar estos
callejones sin salida o de qué manera corregir el rumbo. No les pre-
sento ninguna solución que sea absolutamente correcta para cada
7
organización. No consideren mi saber como el
saber definitivo. Se permite expresamente
pensar por uno mismo.
Las odiseas
ágiles comienzan
Por consiguiente, este libro presupone un
conocimiento básico sobre la agilidad y los
normalmente con la
mecanismos subyacentes. Tal vez su empresa optimización local
esté preparándose para convertirse en una
organización ágil o usted ya se encuentre metido hasta el cuello en la
transformación y se pregunte qué diablos falla. Si es así, entonces
seguramente encontrará indicaciones útiles en estas páginas. Hasta
quizás se le escape una sonrisa en algún momento; será entonces
cuando haya conseguido mi objetivo.
¡Buena lectura!
Klaus Leopold
8
D urante la última década trabajando como consultor y
formador, un tema que encontramos una y otra vez es
cómo conseguir la agilidad en toda la empresa y más
allá de los equipos de trabajo. Los retos con los que
nos enfrentamos en nuestro trabajo son únicos en cada contexto, pero
todos siguen un mismo patrón. Nuestras empresas sufren de un
problema estructural de comunicación; falta de oportunidades para
aprender y mejorar de una forma sistémica; una visión limitada de lo
que realmente está pasando en la empresa; una carga excesiva de
trabajo y una falta de entendimiento y conexión con las necesidades
estratégicas de la empresa.
Estos son desafíos que nunca vamos a solucionar enfocándonos sólo

en los equipos de trabajo.
En 2015, estaba trabajando con la oficina de gestión de proyectos de

una empresa pública y estábamos buscando formas de cómo mejorar
la gestión del trabajo a nivel de proyectos. En el Kanban Leadership
Retreat de ese año, Klaus Leopold y Katrin Dietze presentaron su
concepto de Flight Levels. Desde el primer momento pude comprobar
como esa metáfora ayudaba a comunicar cómo buscar soluciones a
los retos que muchas empresas tienen y cómo generaba una forma
muy efectiva de mejora sistémica.
PRÓLOGO II
Desde entonces, he estado llevando el concepto de Flight Levels a

organizaciones que buscan la agilidad empresarial y viendo cómo el
modelo ha ido evolucionando con la experiencia que hemos estado
adquiriendo.
Este libro describe la historia de una empresa que descubre Flight

Levels y encuentra un modelo efectivo para la mejorar continua.
No vas a tener recetas específicas, ni encontrar cómo usar una 9
metodología en particular. En cambio, lo que vas a descubrir son
unos principios y patrones que te ayudaran a formular experimentos
y encontrar prácticas que te lleven a mejorar de una forma más
efectiva.
Espero que esta historia, y muchas otras que irán apareciendo en la

Flight Levels Academy, te inspire para buscar tus soluciones a los retos
que afrontas en tu vida profesional.
José Casal
10
D urante los últimos años he estado recorriendo
países y dando charlas sobre “Por qué los equipos
ágiles no tienen nada que ver con la Agilidad
Empresarial” y siempre recibía una respuesta posi
tiva. La mayoría de las veces escuchaba comentarios como: «Eso es
justo lo que nos ha pasado”. Así que pensé: “Quizás debería escribir
un libro sobre el tema”. Pero la cosa no fue tan rápida.
Quien conoce mis charlas tal vez sabrá que soy un gran admirador
del lenguaje ilustrativo. Me apasionan libros como la versión ilustrada
de “Reinventing Organizations” de Frederic Laloux y Etienne Appert,
los cuales resumen reiteradamente las afirmaciones más importantes
del texto con claridad y rotundidad. Tenía claro que el tema de la agilidad
empresarial tenía que estar ilustrado para expresar de la manera más
gráfica posible el disparate ágil que a veces sucede en las empresas.
Y quería ser yo mismo quien lo publicase. Sin embargo, había sub
estimado la dificultad de esta tarea. Creía que necesitaría solamente
a un ilustrador y ya tendría el libro. Esa era la teoría.
En la práctica, encontrar al ilustrador adecuado resultó ser un trabajo

arduo, lo que hace que me sienta aún más feliz por haber encontrado
a Matthias Seifert. Aunque nunca había trabajado en este ámbito,
consiguió entender rápidamente los contenidos, así como traducirlos
en imágenes, manteniendo el equilibrio entre el humor y la seriedad
necesaria.
GRACIAS!
Querría volver a dar las gracias a Dolores Omann, que me acompaña

desde la primera edición de “Kanban in der IT” (2012) ayudándome a
plasmar por escrito mis ideas. Gracias a Matthias Patzak por la intensa
revisión del texto, por haberse tomado el tiempo de analizar cada
palabra y por haber aportado valiosas contribuciones para mejorar
11
la calidad.
Naturalmente, el texto y las imágenes son componentes importantes

de un libro ilustrado, pero sin un diseño sofisticado se quedan en
simples componentes. Mario Simon ha reunido
cada elemento hasta formar un todo, dando
así el último toque a este libro.
114 imágenes
valen más
También me gustaría expresar mi más sincero
agradecimiento a Silvia Morenilla Fernández
que 114 000
por la traducción al español y a Jose Casal por palabras
su revisión y feedback de la versión española.
La cubierta del libro ha sido una tarea bastante ardua y he necesitado

algunos esbozos hasta que adquiriese el alma y aspecto deseados.
Muchas gracias a mi compañera de vida y de trabajo, Katrin Dietze, por
la formidable cubierta y la interminable paciencia que siempre está
dispuesta a ofrecerme.
Klaus Leopold
PARTE 1
El problema
»¡Queremos
12
agilidad!«
Acerca de una empresa que quería
estar preparada para el futuro y
pavimentó el camino hacia allí con
buenas intenciones.
PARTE 1 | EL PROBLEMA
14
E
n realidad, no había nada que pudiera ir mal. 1 La empresa debía estar equipada de cara al futuro.
La alta gerencia había mostrado su compro- Términos como digitalización, internet de las cosas,
miso, se habían aprobado los presupuestos, aprendizaje automático y criptomonedas eran solo al-
los coaches de Agile ya estaban contratados. gunas de las expresiones clave que se repetían conti-
En los últimos meses se había llegado en la nuamente en las discusiones sobre el futuro. El caso
empresa a la siguiente conclusión: “Los demás son más es que no habría futuro para la empresa si continuaba
rápidos”. Ahora estaba claro que la cosa no podía seguir operando en el mercado de forma tan rígida.
así; o se mejoraba de una vez la capacidad de entrega o
Últimamente, la dirección escuchaba con frecuencia ca-
tarde o temprano la empresa desaparecería del mercado.
sos de empresas con problemas similares. En todos los
Nunca habían faltado buenas ideas ni posibilidades para estudios de caso y whitepapers se hablaba de Scrum,
desarrollar el negocio principal, todo lo contrario. Sin Kanban, Design Thinking, SAFe® y de otras prácticas mi-
embargo, hasta que se implementaba una buena idea lagrosas que prometían, todas ellas, enormes mejoras
pasaba demasiado tiempo y la competencia iba ya dos de cara a los problemas planteados. Esta era la solución:
pasos por delante con un producto similar. Aunque los
¡Nos transformaremos en una empresa ágil!
dinámicos competidores no habían alcanzado el mismo 15
nivel de penetración en el mercado, la empresa se había
convertido en los últimos años en un lento seguidor que
incluso tenía dificultades para dirigir el negocio diario y
ya no podía confiar en la fuerte posición de liderazgo
que una vez tuvo. Surgieron alternativas en el mercado,
el número de clientes se estancó e incluso durante algu-
nos meses se redujo.
Tenía que suceder algo, estaba más claro que el agua.

Y la dirección averiguó pronto qué es lo que había que
mejorar:
1 Había que optimizar el Time-to-Market, reducién-

dolo de forma radical en el mejor de los casos.
1 Era importante reconocer e integrar con más anti-

cipación las modificaciones necesarias mediante
un feedback rápido de los clientes. Ello significaba
que los clientes debían estar involucrados en el
proceso de desarrollo con más intensidad que
nunca.
PREPARACIÓN EJEMPLAR 1. Todos los equipos debían tener una disposición

HACIA LA TRANSFORMA- ultidisciplinar. Con ello, los impulsores querían eli-
m
minar posibles dependencias, reducir así el esfuerzo
CIÓN relacionado con la coordinación y los tiempos de es-
pera y mejorar el Time-to-Market. La idea era susti-
Así pues, se animó a 600 empleados de IT a usar méto- tuir equipos organizados hasta ese momento según
dos ágiles para volver a poner en marcha el negocio. Los las disciplinas especializadas por equipos de desa-
impulsores del proyecto habían examinado cuidadosa- rrollo de productos en los que estaban representa-
mente las bases de los diferentes métodos de trabajo das todas las competencias para poder entregar un
ágiles; incluso habían recibido formación y para ellos es- producto.
taba claro: “No obligamos a la organización a usar un
¡Realmente una buena idea! Si se consigue reunir la ma-
nuevo método con el que todos deban trabajar – no se
yor competencia posible, entonces solo puede haber
trata de eso. Para nosotros es importante integrar prin-
ventajas.
cipios y valores ágiles para que tengan un mayor peso en
nuestra cultura y podamos ponerlos en práctica en el día 2. Cada equipo tenía que estar organizado según la pre-
16 a día”. Con el fin de alcanzar este objetivo se encargó a misa: Un equipo, un producto.
los responsables del desarrollo organizacional interno
También esta es una buena idea. Por una parte, esta pre-
implementar un proyecto de transformación de 18 meses
misa ayuda a reducir dependencias; por otra, en la ma-
de duración.
yoría de las organizaciones hay equipos especializados
Y ahí está la gracia: “Implementamos un proyecto en que tienen que trabajar en diferentes productos y pro-
cascada para ser ágiles”. Pero no quiero anticiparme a yectos y raramente pueden trabajar concentrándose úni-
los acontecimientos. camente en una cosa. Eso cuesta tiempo.
Los departamentos y equipos tenían incluso la opción de

elegir ellos mismos el marco de trabajo ágil que prefe-
rían. No obstante, la dirección puso algunas condiciones
marco que debían ser respetadas por todos, ya que los
impulsores del proyecto prometieron el mayor efecto
palanca apoyándose en dichas condiciones:
3. Incluso si los equipos podían elegir ellos mismos el En primer lugar, me parece genial la postura flexible en
método ágil, se debían cumplir los siguientes la elección de los métodos ágiles, pues no todos los mé-
requisitos mínimos: todos son apropiados en cualquier contexto. Aplicado
incorrectamente, ningún método puede mantener sus
a. El trabajo debía ser visible, es decir, gestionado

promesas. Sin embargo, la parte más destacada de los
visualmente.
métodos ágiles, la visualización del trabajo y de los mé-
b. Cada equipo estaba obligado a realizar Standups
todos de trabajo, siempre tiene sentido. En una empresa,
a diario delante de los tableros. cualquier persona debería poder ver en qué trabaja en
cada momento un equipo, un departamento u otra uni-
c. Las retrospectivas periódicas debían proporcio-

dad organizacional, así como dónde surgen problemas.
nar a los equipos una perspectiva sobre las posi-
bilidades de mejora.
d. Se debían establecer dos mediciones como meca-

nismo adicional de retroalimentación para los
equipos y la transformación. No para definir obje-
tivos cuantitativos, sino con el fin de tener otro
17
punto de referencia para valorar la repercusión de
las medidas y mejoras. Las siguientes medidas
debían servir de ayuda:
1 Throughput: Número de unidades de trabajo

que son concluidas en un período de tiempo
determinado (p. ej., proyectos por mes, Histo-
rias por Sprint). En Scrum se conoce como
Velocidad.
1 Tiempo de ciclo: Indica el tiempo que se

necesita para completar el trabajo.
Es astuto combinar esta gestión visual con Standups a los cambios que requieren elementos humanos para lle-
diario, ya que, mediante breves feedback loops es posible gar a ser una empresa ágil, a menudo se olvida el objeto
reaccionar rápidamente ante los visibles cambios o de- económico. Se trata de que la entrega sea mejor y más
seos de los clientes y lograr la coordinación apropiada. rápida. Los resultados de las mediciones deben orientar-
nos. Esto es hoy día aún más importante ya que, con fre-
Es igualmente importante que los equipos paren por un cuencia, lo contado cuenta más que lo logrado.
momento su trabajo operativo para poder analizar cómo
de bien o mal están trabajando, es decir, lo que el equipo
hace en una retrospectiva. En ella se sopesa qué se pue-
de cambiar o hacer mejor en el futuro. Si continúas ha-
ciendo lo mismo de siempre, la probabilidad de que el
resultado siempre sea el mismo es muy alta. Y en cuanto
a las mediciones: ¡Genial! A pesar del entusiasmo sobre
18
¿Qué es un Standup?
Standups son reuniones breves que se suceden con
frecuencia – por ejemplo, diariamente – de pie y de
lante del tablero de tareas o tablero Kanban. En un
tiempo máximo de cinco a quince minutos se discute
sobre lo que hay que hacer para poder concluir el
trabajo, cómo abordar bloqueos y problemas relati
vos a la calidad y cómo distribuir el trabajo en el
equipo. El centro de atención aquí es el trabajo, no
cada uno de los empleados.
¿Qué es una retrospectiva?

Las retrospectivas – volver la vista atrás – tienen
como objetivo pasar revista, de forma colaborativa,
del trabajo que hemos realizado durante un deter
minado período de tiempo y extraer oportunidades
de mejora. El trabajo operativo se expone brevemen
te de manera intencionada para observar desde un
punto de vista neutral nuestros métodos de trabajo,
nuestros procesos, el efecto de las mejoras anterio
res, el feedback de los clientes y colegas, así como el
ambiente en el equipo. Aunque la retrospectiva es el
corazón del proceso de mejora y una de las reuniones
más importantes, muy a menudo se abandona por
que no la ejecutamos bien [Leanability E020, 2017].
EL PROCESO DE Seguramente percibirá cierto sarcasmo en mis palabras,

es porque estoy siendo sarcástico. No creo que se pueda
TRANSFORMACIÓN cambiar la mentalidad colectiva durante una formación
básica de un día; no obstante, requiere un gran esfuerzo
A pesar de ser un observador bastante crítico, he de qui- canalizar a 600 empleados, incluidos directivos, a través
tarme el sombrero. Tras la expresión en boga “transfor- de una formación de estas características. En cualquier
mación ágil” se hacía palpable en esta empresa la seria caso, seguro que se notan los efectos en la cuenta ban-
aspiración de mejorar, pensar y cambiar la forma de ha- caria de la empresa consultora que lleva a cabo estas
cer las cosas. A menudo, las organizaciones ágiles se ha- formaciones.
cen llamar así simplemente porque en alguna esquina se
encuentra un equipo que hace Scrum. En esta empresa,
sin embargo, se efectuaron cambios desde lo más pro-
fundo y se intentó remodelar una gran parte de la orga-
nización según principios ágiles. Al mismo tiempo, se dio
a los equipos la opción de elegir el método según lo que
los empleados consideraban que era más apropiado en 19
sus respectivos ámbitos de competencias. Incluso brota-
ron de mis ojos ágiles lágrimas de alegría. ¿Cómo se eje-
cutaría exactamente la transformación?
Atención: Durante la implementación, los siguientes pa-

sos estaban entrelazados unos con otros y no se suce-
dieron de forma secuencial.
FORMACIÓN
La totalidad de los 600 empleados de IT estuvieron en-
cantados de recibir un curso básico de un día de dura-
ción enfocado a la mentalidad ágil. Quien trabaja con
agilidad y prácticas ágiles escucha a menudo e incluso
interioriza esta idea: no son los métodos ágiles en sí los
factores que impulsan al éxito, sino que es la mentalidad
que se esconde detrás lo que determina la repercusión.
Básicamente, estoy de acuerdo con ello. Pero no se
puede implantar una mentalidad sin más solo porque
lo dice el plan del proyecto: “Atención, establecer
mentalidad ágil… ¡hecho!” Así no funciona.
REORGANIZACIÓN Y
AUTOORGANIZACIÓN
A la hora de reorganizar a los equipos multidiscipli-
nares se tuvo en cuenta la estructura del produc-
to. Para ello, la dirección no procedió de manera
arbitraria, es decir, los empleados no fueron distri-
buidos así como así entre los distintos equipos,
sino que simplemente se determinó qué equipos
eran necesarios para según qué productos. De esta
forma, en vez de efectuar una asignación dirigida des-
de arriba, se organizó una feria. A lo largo de dos días,
los responsables de los equipos podían hacer publicidad
de su equipo en sus estands y anunciar los puestos de
trabajo disponibles. A cada equipo se le había asignado
20 anteriormente, obedeciendo a los enfoques principales
estratégicos, un presupuesto, para poder “comprar” a los
empleados necesarios. Estos tenían la posibilidad de
elegir ellos mismos los equipos en los que deseaban tra-
bajar en el futuro. Según mi opinión, un planteamien-
to genial.
Ya en la feria se discutía y, a menudo, se llega-

ba a decidir sobre la práctica ágil con la que
se quería trabajar en el futuro. Una vez for-
mados los equipos, los miembros de estos
asistían a las correspondientes formacio-
nes. Así, por ejemplo, había un curso de
Scrum Master y Product Owner y cuando un
equipo se había decidido por el sistema
Kanban, podía visualizar en un taller sobre
diseño de sistemas su flujo de trabajo inicial al
mismo tiempo que se iba consolidando.
APOYO EXTERNO
Reorganizar a 600 personas es un programa ambicioso.
Estaba previsto que los empleados de esta empresa hi-
ciesen en breve algo que nunca habían hecho, en parte
incluso asumiendo nuevas funciones. La empresa con-
trató a 16 coaches de Agile para impartir los cursos que
les proporcionasen una perspectiva externa y permitie-
sen a los equipos practicar con el nuevo método de tra-
bajo. A primera vista podría parecer mucho, pero es rea-
lista si se compara con la ambiciosa dimensión del pro-
yecto. A su vez, los coaches externos formaron a once
coaches internos de Agile. En mi opinión, algo muy razo-
nable ya que cuando hay muchos cambios, los nuevos
métodos de trabajo se aplican hasta que los consultores
abandonan la empresa. En vista de los fondos que esta 21
empresa destinó a la transformación, es natural que no
quisieran que sucediese esto.
¿Qué es un taller de diseño de sistemas?

El producto final visible de un taller sobre diseño de
sistemas es un tablero Kanban. La visualización en sí
es útil, pero no es esencial, incluso si esto pudiera
parecer raro. El objetivo más importante en un taller
de estas características es alcanzar un entendimien
to conjunto de cómo un grupo de personas trabajan
juntas en este momento. La visualización no repre
senta un proceso deseado o impuesto, sino lo que
realmente se está haciendo ahora. Este sistema
Kanban actual es el punto de partida para conseguir
mejoras. Por ello es tan importante que los sistemas
Kanban sean diseñados por las personas que los
van a usar.
LOS RESULTADOS TRAS 1 Más del 80 por ciento de los equipos estaban “trans-
DOCE MESES formados por completo” (palabras textuales del ge-
rente de transición) y cumplían las condiciones marco
establecidas: tenían personal multidisciplinar, expo-
La empresa se había fijado un plazo de un año y medio
nían su trabajo de forma transparente – según el mé-
para la implementación de las exigencias mínimas – for-
todo utilizado – en los tableros correspondientes, es-
mación de equipos multidisciplinares, visualización,
tablecían Standups a diario y buscaban oportunidades
Standups, retrospectivas y mediciones. La transforma-
de mejora haciendo retrospectivas de forma regular.
ción en sí fue implantada en la organización en forma de
proyecto. Bajo la dirección de un gerente de transición,
el equipo de transición había planificado exactamente
qué etapas del despliegue de Agile debían de alcanzarse
y en qué momento, así como qué medidas había que
aplicar para conseguirlo. Se estableció e implantó el pro-
yecto “Agile Business”.
22
Una vez transcurridos dos tercios del plazo fijado, los im-
pulsores de la transformación ágil querían evaluar el
progreso del proyecto, por lo que a los doce meses hicie-
ron balance. Parecía que el plan estaba funcionando:
1 Un punto importante para el equipo de transición era En general, había un ambiente positivo. La mayoría de
estar informado sobre el ambiente en los equipos los equipos se atenían a las exigencias, mientras que la
para, en caso necesario, poder aplicar medidas co- visualización del trabajo se aceptó como algo muy útil.
rrectoras. Por esta razón, cada seis meses se llevaban Algunos empleados no llegaron a simpatizar con el nue-
a cabo encuestas dirigidas a los empleados. La en- vo sistema de transparencia y abandonaron la empresa.
cuesta más actual mostró que tanto la comunicación Con ello ya se había contado.
como la coordinación habían mejorado. Los equipos
se mantenían informados unos a otros sobre los avan- Pero parece que en líneas generales la cosa iba bien.
ces conseguidos, lo que hacía cada uno y cómo se dis- ¿Verdad que sí?
tribuían las funciones.
23
MOSTRAD VUESTRAS
CIFRAS
Introducir métricas era una de las condiciones marco TENDENCIA DEL THROUGHPUT DE
que los equipos debían tener en cuenta en la transfor- LOS EQUIPOS SCRUM
mación ágil. El equipo de transición veía cómo los tiem-
pos de ciclo y el throughput habían ido cambiando tanto En primer lugar, el equipo de transición observó cómo
a nivel de equipo como de proyecto, pero no cambiaba la velocidad en los equipos Scrum.
llegaba a entender lo que esos núme-
Un equipo Scrum asume en cada Sprint el compromiso
ros significaban. Determinados mo-
(commitment) de concluir una determinada cantidad de
delos se repetían una y otra vez,
trabajo (en términos de Scrum se habla de la cantidad de
por lo que el equipo de transición
Historias de Usuario o de Story Points). Al término del
seleccionó una serie de resulta-
Sprint se compara cuántos de los trabajos confirmados
dos de medición representativos.
han sido efectivamente entregados. Este resultado se
24 De esta manera se entendía me-
registra en el eje Y (número de Story Points). El
jor lo que pasaba.
resultado es la velocidad o throughput de un
Echemos un vistazo, por equipo durante un período de tiempo
ejemplo, al desarrollo del determinado.
throughput de los equipos
Scrum y a las modificaciones
en el tiempo de ciclo de los
equipos Kanban. A continua-
ción, se plantea la pregunta
de si los proyectos concluían
ahora de forma más rápida.
25
El diagrama muestra la velocidad agregada de los equi- cabo retrospectivas y se emprenden continuamente me-
pos Scrum en esta empresa. La línea de puntos repre- joras, la línea debería ascender constantemente hacia
senta el resultado que se había esperado desde un prin- arriba y nunca hacia abajo.
cipio. Si todo funciona bien en un equipo Scrum, la velo-
cidad debería de ir aumentando de forma continua. Al Pero la tendencia real en los equipos Scrum no tenía
principio, las expectativas con respecto a la velocidad precisamente este aspecto. Los equipos habían tenido
son más bien bajas ya que el equipo debe inicialmente un buen inicio y la velocidad había aumentado conside-
establecerse como tal y adaptarse al nuevo método de rablemente. Sin embargo, la línea se había estabilizado
trabajo. Sin embargo, tras esta fase de iniciación, la cur- drásticamente e incluso había comenzado a descender.
va ya tendría que apuntar claramente hacia arriba para El rendimiento se había reducido en gran manera confor-
después volver a estabilizarse, aunque debería de seguir me transcurría el tiempo.
avanzando de forma ascendente. Si, además, se llevan a
TENDENCIA DEL TIEMPO DE CICLO DE Si se agregan los tiempos de ciclo de varios equipos, es-
LOS EQUIPOS KANBAN taremos ante un buen modelo si la línea de tendencia
desciende. Tal y como hemos visto en el desarrollo espe-
El paso siguiente fue que el equipo de transición exami- rado del throughput, por lo general, también durante el
nara detenidamente el tiempo de ciclo de los equipos tiempo de ciclo se cuenta al principio con una ligera subi-
Kanban. A nivel de equipo es fácil determinar el tiempo da, ya que los equipos se han de acostumbrar a la nueva
de ciclo: para cada trabajo acabado se calcula la diferen- forma de trabajar. Sin embargo, la línea debería de des-
cia de tiempo entre la fecha de finalización y la de inicio. cender considerablemente a continuación. Esto significa
Lo ideal es que los tiempos de ciclo se vayan reduciendo que los equipos concluyen los trabajos de forma cada vez
cada vez más. más rápida, por lo que el tiempo de ciclo se reduce.
26
Aquí es precisamente donde se ponen las esperanzas al

cambiar a métodos de trabajo ágiles. Los consultores
Scrum prometen que se puede entregar más y más
rápido mientras que los consultores Kanban prometen
que los tiempos de ciclo se pueden reducir al menos a la
mitad y que aún se puede esperar incluso más.
Pero los equipos Kanban de esta empresa obtuvieron

otros resultados. Tal y como se esperaba, el tiempo de
ciclo aumentó al principio y después comenzó a des- ¿Qué es la velocidad?
cender, pero de forma insignificante. En realidad, la lí- En Scrum, la velocidad es la medida del throughput de un
nea de tendencia apuntaba hacia abajo, pero la mejora equipo. Indica la funcionalidad que un equipo es capaz de
entregar en un Sprint. La cantidad entregada se mide en
ni siquiera alcanzó el 1 por ciento, es decir, aún estaban Story Points.
lejos de conseguir una reducción a la mitad del tiempo
de ciclo. ¿Qué es una Historia de Usuario?
La Historia de Usuario sirve para formular un requeri
27
Daba igual si se trataba de Scrum o de Kanban, lo que miento, por ejemplo, con respecto a un software pendien
estaba claro es que la capacidad de entrega de los equi- te de desarrollo. En el mundo ágil se ha establecido un
pos apenas se había modificado. Y recordemos cuál era formato simple para expresarlo:
el objetivo de la transformación ágil: un “Time-to-Market Como <tipo de usuario>

más rápido”. necesito <funcionalidad>
para alcanzar <beneficios>
¿Qué son los Story Points?

Los Story Points no reflejan el tiempo invertido en una
historia, sino la complejidad relativa que entraña una His
toria de Usuario. Al valorar distintas historias se determi
nan las cualidades o complejidades de estas relacionán
dolas entre sí.
28
LOS PROYECTOS NO
CONCLUYEN CON MAYOR
RAPIDEZ
Ya el análisis de las métricas de los equipos fue cual- tales como cursos o acompañamiento a través de coa-
quier cosa menos estimulante para el equipo de transi- ches, se habría esperado que el Time-to-Market de las
ción. También estaba la problemática de que faltaban iniciativas descendiera radicalmente una vez que los
valores de referencia; era difícil valorar si la transforma- nuevos métodos de trabajo resultasen más familiares.
ción ágil había tenido un efecto positivo porque no se
contaba con “mediciones cero” antes de la transforma- Y de nuevo pasó el caso contrario. Sí, la reorganización
ción. Los equipos se habían reorganizado completamen- había hecho empeorar el Time-to-Market al principio, tal
te como parte de la transformación, razón por la cual y como se esperaba. Sin embargo, seguía y seguía em-
realmente no era posible determinar si, por ejemplo, el peorando. En otras palabras, los proyectos se entrega-
rendimiento en los (nuevos) equipos Scrum había mejo- ban incluso con más lentitud que antes de la transfor-
rado o empeorado. mación ágil. Era, sencillamente, una catástrofe. 29
Sin embargo, en la empresa había métricas que permi- Se había invertido un montón de dinero en esta trans-
tían comparar el rendimiento antes y después de la ini- formación ágil. La dirección y el equipo de transición ha-
ciativa ágil: el tiempo de ciclo del proyecto. Esta es una bían reflexionado mucho para encontrar el mejor cami-
métrica especialmente importante, puesto que un obje- no. La dirección había tomado importantes decisiones,
tivo claro de la organización consistía en reducir el tiem- todos los equipos se habían establecido de manera mul-
po de ciclo de los proyectos, así como el Time-to-Market. tidisciplinar y se organizaban según los productos. Se
Proyectos siempre había habido, tanto antes como des- había contratado a profesionales para acompañar la
pués de la transición ágil, incluso si los proyectos se transformación y formar a coaches internos. 600 perso-
hacían llamar ahora, para más agilidad, “iniciativas”. Así nas habían aprendido a trabajar con Scrum, Kanban,
pues, se contaba con datos comparables. Standups, retrospectivas y métricas.
En este diagrama podemos ver tres tipos de líneas. La Y ahora, el gran objetivo de poder reaccionar con más ra-
más ancha en la parte izquierda representa el tiempo pidez ante las necesidades del mercado, ¡no solo no se
antes de la transformación ágil. Dado que el Time-to- había alcanzado, sino que además había empeorado! Se
Market no dejaba de aumentar, lo que se puede ver en el trataba de una transformación que hizo que la empresa
movimiento ascendente de la línea ancha, la empresa fuera de mal en peor…
había decidido actuar. Para todos los involucrados esta-
ba claro que esta línea no podía empezar a descender
tras el pistoletazo de salida hacia la transformación de-
bido al período de transición, sino que más bien ascen-
dería. Sin embargo, en vista de los esfuerzos realizados,
30
31
¿QUÉ …. ESTABA PASANDO AQUÍ?

32
PARTE 2 | LAS CAUSAS
PARTE 2
Las Causas
Buscando
escollos
33
Acerca de conclusiones
simplistas, dependencias
ocultas, flujos de valor
crecientes y del poder de
limitar el WIP.
34
H
e leído su libro y me hago una idea de Entonces, una colaboradora del equipo de transición de
cuáles podrían ser las causas de la situa- aquella empresa se puso en contacto conmigo para con-
ción en la que nos encontramos”, dijo la tarme que la agilización de los 600 colegas de IT se ha-
señora al teléfono. En “Practical Kanban” bía iniciado con gran esperanza y que no entendía por
[Leopold 2016] expresé mi descontento qué no había manera de mejorar el Time-to-Market. No
con el mundo ágil porque una y otra vez me volvía a to- pasaba desapercibido el sutil tono de desesperación
par en mis trabajos de consultoría con la misma extraña que se desprendía de su relato ya que había invertido
perspectiva, aquella que consideraba que para alcanzar un gran esfuerzo personal en este proyecto. Había leído
el éxito empresarial una empresa ágil tenía que imponer todos los libros y blogs sobre agilidad, había realizado
a todos los equipos la elección de un método ágil. Así cursos de Scrum y Kanban y siempre estaba a la última.
pues, de la multiplicación de los métodos resultaría algo A mí me sonó muy profesional y meditada la manera en
extremadamente nuevo y rápido. cómo ella y sus colegas habían abordado esta transfor-
mación ágil. A pesar de ello, estaba desbordada por los
Como los equipos resolverán las cosas, nadie tiene en resultados.
cuenta el flujo de valor global. Y mientras que los equi-
pos se apresuran a establecer los límites WIP, a nivel de Me pidió ir a visitarlos para hacerme una idea de la si-
portafolio no cambia nada. Es incluso peor porque, como tuación y, en un taller, volver a repasar las suposiciones
los equipos no empiezan a ser ágiles hasta la fecha X, se y planteamientos con los responsables de la toma de
inician aún más proyectos ya que, claro, gracias a la agili- decisiones, ya que la agilización del área IT había sido 35
dad ahora todo irá más rápido. Los equipos, cuidadosa- un asunto de máxima prioridad. ¿Qué imaginaban los
mente organizados de forma multidisciplinar, tratan de gerentes que sería una empresa ágil cuando comenza-
defender sus límites WIP en Historias de Usuario y ta- ron con este este objetivo? ¿Qué era necesario, desde su
reas, mientras que se ahogan en proyectos. Y como tan perspectiva, para conseguir dicho objetivo? ¿Existía, tras
solo algunos de los responsables de la transformación unas buenas intenciones, un sólido conocimiento sobre
ágil eran conscientes de ello previamente, cada día reci- las relaciones dentro del flujo de valor o se habían subi-
bía llamadas de personas que veían cómo sus esfuerzos do a ciegas al tren de la agilidad? Más tarde solicitaría
hacían aguas y se preguntaban a sí mismos qué había que me mostrasen el trabajo y las métricas de algunos
sucedido. equipos para averiguar bajo qué suposiciones habían
enfocado el tema de la agilidad.
CAUSA 1:
LA TRAMPA DE ESTABLE-
CER CONCLUSIONES SIM-
PLISTAS EN EL PROCESO
DE CAMBIO
Lo que se quería conseguir en esta empresa era un
Time-to-Market optimizado, un rápido feedback de los
clientes y una actitud activa, todo ello acompañado de la
estructura adecuada para poder hacer frente a los desa-
fíos del mañana. Hoy día, las empresas o las personas
raramente poseen el abierto e imparcial entusiasmo de
Gimli. En la película “El Señor de los Anillos: El Retorno
del Rey” dice el enano guerrero: “Certeza de muerte. Mí-
nima esperanza de éxito. ¿A qué esperamos?”
36 Cuando una empresa está a punto de emprender cam-

bios, las personas que la forman quieren saber, por una
parte, adónde van a llegar y, por otra, de qué forma lle-
garán hasta allí. Así pues, se busca seguridad y los pla-
nes ofrecen esta seguridad. Tener un plan es, en reali-
dad, algo bueno. La problemática viene, la mayor parte
de las veces, cuando los responsables se dejan llevar por
conclusiones demasiado sencillas o cuando recurren a
alguna de las muchas recetas que actualmente existen
en la escena ágil.
Durante mis conversaciones con la dirección de esta em-

presa pude igualmente detectar una fuga hacia conclu-
siones simplistas.
Esta organización había dado el giro equivocado nada

más comenzar su proceso de reflexión confundiendo los
medios y el objetivo. Desde el principio se había tratado
de mejorar el Time-to-Market, pero ahora todos discu-
tían sobre reglas absurdas que habían sido escritas años
atrás en algún contexto ágil, lo cual suele pasar bastante
a menudo.
A partir del momento en el que la dirección decide que

los Standups diarios, las retrospectivas, los equipos mul-
tidisciplinares, etc. son una exigencia para la consecu-
ción de los objetivos, la introducción de la metodología
¿Cuál es el resultado de tales conclusiones? La organiza- de trabajo ágil se convierte en el objetivo en sí. Tanto los
ción entera se plantea emocionantes cuestiones como: equipos como la dirección se concentran únicamente en
“¿Puede el Product Owner estar presente durante la re- implantar el conjunto de normas metódicas de forma co-
trospectiva?”, o “¿está permitido que el Scrum Master rrecta. La agilidad se reduce a lo que no debería ser: un
trabaje también de modo operativo en el equipo?”. Y lue- método. Ya no se trata de averiguar lo que la empresa
go vienen las discusiones derivadas de opiniones aisla- saca de ello, por no hablar del cliente, cuyo papel queda
das: “Seguro que no haremos Scrum porque tendríamos relegado a un segundo plano. 37
que trabajar con timeboxes”, o “seguro que no haremos
Kanban porque aquí no hay timeboxes”.
Tales polémicas suelen dejarme

con la boca abierta y únicamente
pienso: “¿¡Cómoooo!? ¿pero qué
tiene esto que ver con los
objetivos que queríais
alcanzar?”.
EL PROCESO DE CAMBIO COMO Proyecto – ya me imaginaba lo que pasaba aquí. Tras la

“PROYECTO” reorganización se debería de haber creado algo total-
mente diferente, algo flexible, adaptable, ¡algo genial!
Antes de comenzar el taller, algunos de los gerentes se ¿No sería mejor planear el proceso de cambio usando los
habían referido a mí como “Klaus, el que nos va a ayudar métodos internos ya en uso para gestionar un proyecto
en nuestro proyecto ágil”. Me contaron cómo lo habían de cambio? Como si la transformación se sucediese pa-
abordado, que parecía que este había dado frutos, espe- sando de un estado al siguiente, especialmente de una
cialmente en lo que se refiere a la satisfacción de los “mentalidad” a otra, teniendo en cuenta la agenda.
empleados, pero que el proyecto ágil se encontraba aho-
ra en una situación extrañamente inestable.
38
También en esta empresa había sucedido lo que había

observado en muchas organizaciones: mientras que la
agilidad vive del principio pull, intentaron diseñarla se-
gún el principio push. En efecto, los equipos involucrados
podían ellos mismos elegir los métodos con los que que-
rían trabajar, o sea, que sí que estaba un poco represen-
tado el principio pull. Sin embargo, todo el proceso de
transformación se había establecido como proyec-
to-cascada con etapas y listas de control. Aunque no soy
partidario de los dogmas, mis mejores experiencias se
basan en el siguiente principio:
39
Principio pull vs. principio push

Los métodos de trabajo ágiles han copiado muchas
cosas del Sistema de Producción Toyota (TPS, por
sus siglas en inglés). Un mecanismo esencial para
dirigir el flujo de trabajo es el principio pull: un equi
po recoge la siguiente tarea de las etapas previas
una vez que tiene capacidad o que ha finalizado
otros trabajos, por lo que no va a exceder sus límites
WIP (volveremos a retomar este punto). Las áreas de
trabajo tradicionales, sin embargo, se concentran
simplemente en empujar el trabajo finalizado hacia
el siguiente paso del proceso (principio push).
EL CAMBIO ES UN NUEVO Un supuesto organigrama ágil surge simplemente cuan-

ORGANIGRAMA – CONFUSIÓN ENTRE do se lanza al aire a los empleados, se les cuelga nuevas
CAUSA Y EFECTO etiquetas y se les deja aterrizar en otro lugar de la orga-
nización. A ser posible, impecablemente organizados en
Como acabamos de mencionar, las personas inmersas en equipos multidisciplinares que, naturalmente, están sen-
situaciones de cambio necesitan algo a lo que agarrarse. tados unos juntos a otros en una sala. Obvio. Si a partir
Quieren ver qué forma adquirirá lo nuevo ya que esto les de ahora Alberto se sienta junto a Carlos y María junto a
da la ilusión de control y predictibilidad, es decir, de se- Ángela, la cosa irá bien. ¡Así sí funcionará!
guridad. Lo más tangible en una reorganización es siem-
pre un nuevo organigrama, razón por la cual los gerentes Desgraciadamente, hoy día hay una serie de modelos de
se aferran a ello firmemente. Esto significa que no son organización prefabricados que intentan mostrar a la di-
los procesos de una organización los que se desplazan rección cómo se hace. En el caso de Spotify no se tenía
hacia el punto de mira del cambio o de la mejora sino la el propósito de entregar un modelo a todas las empre-
estructura. sas de este mundo. Spotify cometió en 2012 el fallo de
40
hablar sobre la organización interna que en aquel mo- En principio, al cliente seguramente le da totalmente
mento resultaba útil para los objetivos que perseguía la igual si el señor Martínez está sentado en la oficina 238 o
empresa [Leanability E020, 2017]. El esquema de esta es- 145 o si forma parte de un gremio o no. Como cliente de
pecie de organización “temporal” y, sobre todo, los ge- Netflix, tampoco me importa qué programadores se
niales conceptos como tribus, capítulos y gremios para sientan juntos y qué tipo de denominaciones de moda
unidades organizacionales se quedaron en el recuerdo tienen. “QUIERO VER PELÍCULA”, esto es lo único que me
de la gente. El modelo Spotify muestra de forma llamati- interesa como cliente. Pero lo que sí que me importa es
va la creación de una organización innovadora y ágil y el funcionamiento de Netflix, que espero que esté dise-
satisface el deseo de poder copiar el éxito. ñado de tal manera que me permita ver las películas en
cualquier momento y sin problemas. Sorprende que los
Lo que pasa es que el mismo Spotify no considera su es- sueldos de los trabajadores de Netflix tampoco sean pa-
tructura organizacional como el secreto de su éxito, sino gados por Netflix sino por los clientes que hacen uso de
como algo extremadamente pasajero y bastante insigni- Netflix. Sin embargo, el cliente no aparece por ninguna
ficante. No es el modelo organizacional lo que hace a parte del organigrama.
Spotify ágil, sino el hecho de que Spotify es ágil y había
elegido durante un tiempo este modelo organizacional Si, en cambio, se centra la atención en los procesos orga-
para afrontar desafíos concretos. Hoy, la empresa tiene nizacionales y se optimizan estos de forma permanente
otra estructura organizacional. Cliff Hazel – coach de dando prioridad a que se cubran las necesidades de los
Agile responsable de Capítulos en Spotify (denominación clientes, puede ser que la estructura organizacional tam- 41
genial, ¡hay que copiarla inmediatamente!) – parafraseó bién cambie en algún momento. Pero entonces, la es-
una vez, durante una conversación que mantuvimos, a tructura estará orientada hacia necesidades y conoci-
Edwards W. Deming [The Deming Institute 2018]: “Cada mientos actuales, no hacia deseos. Así pues, “Agile” es
organización ha sido perfectamente diseñada conforme algo en lo que se convierte la organización como conse-
a los resultados que entrega”. Si una empresa tiene cuencia de su propio desarrollo y no algo que entra en
exactamente los mismos problemas que Spotify tenía en funcionamiento en una determinada fecha.
2012, seguramente se le recomendaría este modelo. O tal
vez no. El éxito depende de la respuesta a la pregunta:
“¿Con qué ganamos nuestro dinero y qué problema
i ntentamos solucionar?”.
Un cambio organizacional debería comenzar
en los procesos organizacionales (kursiv!),
ya que tanto el cumplimiento de los deseos
del cliente como el Time-to-Market son
cuestiones relacionadas con procesos reales,
colaboración y dependencias.
CAUSA 2: Tanto en la dirección como en los equipos se sentía el
TRATANDO CON DEPEN- deseo de cambiar las cosas a mejor. Cuando llegué a
esta empresa, cerca del 80 por cierto de los equipos tra-
DENCIAS ENTRE EQUIPOS bajaban ya con los métodos ágiles que habían elegido, lo
Y PRODUCTOS que nos permitió llevar a cabo discusiones concretas de-

lante de los tableros.
Una vez que había tanteado la situación en la que se en- A menudo veía tableros estructurados de la siguiente
contraba la dirección y ya disponía de los primeros cono- forma. Por todas partes se leía: “Esperando respuesta
cimientos, proseguí visitando equipos. Me pareció admi- externa”. Cada equipo lo había visualizado de forma dis-
rable que todos ellos, tal y como lo marcaban las condi- tinta, algunos como zona de aparcamiento, otros solo
ciones marco, había realizado su trabajo de forma visible. con una pegatina de bloqueo, pero siempre con la indi-
Daba totalmente igual el equipo que visitase, o había cación de que un equipo no podía seguir a partir de este
una pared de Kanban, un tablero de Scrum o cualquier punto. Se esperaban entregas, información o servicios
otro tipo de visualización. Esto me simplificaba mucho la como, por ejemplo, la activación del Firewall o la modifi-
comunicación con los equipos sobre su trabajo. Así pues, cación de bases de datos en otro producto. En muchos
no discutíamos sobre procesos abstractos sino sobre los de los casos, esto significaba que el proceso debía conti-
tableros que reflejaban su metodología de trabajo. nuar en otro tablero dentro de la organización, pues aquí
42 no se trataba únicamente de dependencias con respecto
a proveedores externos.
43
Me puse a buscar modelos y planteé cuestiones como: Personalmente, me parecen fascinantes los gráficos de
“¿A qué equipos soléis esperar?” o “¿con qué equipo dependencias, aunque, en un primer momento, tanto la
tenéis una mayor interacción de forma regular porque dirección como los mismos equipos se quedaron más
estáis esperando que hagan algo para vosotros?”. Mi ob- bien atónitos. Al fin y al cabo, se debía eliminar el mayor
jetivo era hacer visibles dichas interacciones en gráficos número posible de dependencias. Este era el motivo por
de dependencias, de modo que me puse a trabajar con el que se habían reorganizado los equipos de forma mul-
cada equipo reuniendo los fractales. Y así, de forma tidisciplinar; por ello, cada equipo se encargaba siempre
gradual, se fue formando una imagen que hacía visible de un único producto. Realmente, los equipos no debían
a qué equipos se recurría con más frecuencia. tener que esperar a otros equipos. Y, sin embargo, aquí
se hacían visibles un montón de dependencias que, por
supuesto, hacían aumentar los tiempos de ciclo. Porque
lo que sale de un sistema debe ser priorizado en el si-
guiente sistema. Así, por ejemplo, si el trabajo acaba en
un equipo Scrum deberá esperar al menos un Sprint
hasta ser procesado.
¿QUÉ ES LO QUE NO HABÍAN Naturalmente, se pueden eliminar de la mejor manera

CONSIDERADO? posible dependencias entre equipos y departamentos, si,
por ejemplo, se ofrecen productos o servicios idénticos.
1. Un producto, muchos equipos. Era correcto el hecho Esto es en gran medida factible en el caso de Buurtzorg,
de que cada equipo trabajaba únicamente en un pro- la empresa de atención domiciliaria que Frederic Laloux
ducto en la mayoría de los casos. Sin embargo, a me- describe en “Reinventing Organizations” [Laloux 2016] y
nudo eran necesarios varios equipos para un solo que se ha convertido en el ejemplo perfecto de autoor-
producto, surgiendo así dependencias entre los equi- ganización. El servicio ofrecido es el mismo en cada
pos que colaboran en el mismo producto. equipo y se producen variaciones del producto cuando el
personal cuidador confiere a los servicios su toque per-
2. Dependencias entre productos. Los mismos produc-
sonal. Pero incluso en Buurtzorg persisten vínculos ne-
tos no eran totalmente dependientes entre ellos.
cesarios – dependencias – que van más allá del trabajo
Para efectuar una modificación en el producto 1 se
cotidiano, como las unidades administrativas de organi-
debía igualmente cambiar algo en el producto 2 y, si
zación. Lo mismo ocurre en cualquier otra empresa, es-
en el producto 2 se modificaba algo, también había
pecialmente en marketing, ventas o en el departamento
que hacerlo en el producto 7.
jurídico; no toda empresa puede permitirse tener, por
3. Particularidades del trabajo del conocimiento. Ha- ejemplo, a un jurista en cada equipo. Aparte de ello, al-
blamos aquí de 600 personas de IT. No conozco a nin- gunos asuntos deben ser regulados para toda la organi-
44 zación y no por equipos individuales.
guna organización con más de 30 empleados en el
llamado trabajo del conocimiento en la que no exista
La idea de eliminar las dependencias de una organiza-
absolutamente ninguna dependencia y un solo equi-
ción no es realista. Una organización no es un contene-
po sea capaz de generar el 100 por cien del valor
dor de equipos totalmente independientes unos de
para el cliente. La mayoría de las veces son varios los
otros, al menos no en el trabajo del conocimiento.
equipos involucrados de una forma u otra en la en-
trega de un producto.
Se debería eliminar el mayor número posible
de dependencias. Pero lo más importante es
gestionar de la mejor manera posible aquellas
dependencias que persisten.
45
LA F MÁS RÁPIDA DEL MUNDO

O CÓMO SUBOPTIMIZAR SISTEMAS
Sí, ya sé que me repito. Si ya ha leído alguno de mis otros Observemos el problema tomando como ejemplo un
libros o ha estado en alguna de mis charlas, conocerá de teclado. Supongamos que el producto que ofrecen los
46 sobra esta cita de Russell Ackoff. Pero la verdad es que 600 empleados de IT de esta empresa son cartas. Cada
es totalmente cierto. equipo se ocupa exactamente de una letra.
Como acabamos de ver, en esta empresa siguen existien- ¿Cuál es la base de una carta? Seguro que no es la yuxta-
do muchas e intensivas dependencias a pesar de todos posición de letras de forma aleatoria. Queremos que
los esfuerzos multidisciplinares y medidas de separación nuestras cartas contengan palabras razonables dentro
de productos por equipos. Con la agilización de los equi- de frases razonables que, finalmente, formen un texto
pos no se consigue precisamente una situación mejor. Es razonable. Esta es la exigencia del cliente. Y aquí es to-
posible que un equipo consiga aumentar notablemente talmente irrelevante la rapidez con la que se presiona
su rendimiento y siga mejorando, pero el efecto de estas cada tecla.
mejoras locales no va más allá de las fronteras del pro-
pio equipo. De la misma forma se comporta una empresa. Si cada
equipo usa exactamente una tecla del teclado, para nada
La yuxtaposición de unidades optimizadas a nivel local
importa la rapidez con la que trabaja cada equipo. Inclu-
no da como resultado un sistema optimizado en su tota-
so si tenemos en la organización al equipo F más rápido
lidad, por mucho que sienta decir esto. Todo lo contrario;
del planeta, tan rápido que hasta sale humo del teclado,
si un equipo se optimiza a más no poder, puede incluso
¡la carta no se va a terminar antes!
llegar a alterar la cadena de creación de valor. Sin em-
bargo, de lo que se trata es de crear una cadena de
creación de valor que esté lo más orientada posible a
los deseos de los clientes.
47
Así pues, en una empresa no importa tanto la velocidad caso contrario: hay muchos productos y muchos equipos;
a la que trabaja cada equipo por separado. Si queremos un equipo trabaja en muchos productos y un producto
aumentar el output del sistema tenemos que garantizar necesita de muchos equipos para poder avanzar.
que el equipo oportuno trabaje en el asunto oportuno en
el momento oportuno. Dicho de otra forma: se trata de Por esta razón, el deseo de tener equipos de alto rendi-
dependencias o, mejor dicho, de cómo tratar con ellas. miento me provoca dolor de barriga cuando me doy
cuenta de que nadie piensa en el proceso. La agilidad de
En este sentido, esta empresa se encontraba en una si- una organización no nace cuando se yuxtaponen muchos
tuación de lujo. Por lo general, varios equipos trabajaban equipos ágiles sino cuando existen interacciones ágiles
en un producto y solo algunos trabajaban en más de entre los equipos.
uno. Sin embargo, en muchas empresas la realidad es el
48
CAUSA 3:
UN FLUJO DE VALOR IN-
COMPLETO
Vale, ya habíamos averiguado que había muchas más de-
pendencias de las que se pensaba y que estas no eran
gestionadas. Una cosa me dejaba perplejo siempre que
me encontraba delante de los tableros de los equipos, y
es que estos tableros eran bastante escuetos. Quizás lo
habría podido entender si hubiese visitado un pequeño
local con cinco personas. Lógicamente, no se trata de ver
ahora quién tiene el – proceso – más largo, pero en este
caso, un proceso tan escueto y simple, es decir, un flujo
de generación de valor tan corto me parecía más bien
improbable. Aquí había equipos de entre siete y catorce
personas, las cuales, a su vez, trabajaban en un departa-
mento de IT con 600 empleados, el cual, a su vez, forma-
ba parte de una compañía que duplicaba el tamaño del ¡Está bien saberlo! Juntos incorporamos la integración en 49
departamento en sí. la representación de la generación de valor, de modo
que ahora el tablero tenía el siguiente aspecto:
“Vale, aquí estáis en el desarrollo”, comencé con mis pre-
guntas. “Cuando hayáis terminado con él, entonces ¿está
ya todo terminado y se ha generado la totalidad del valor
para el cliente?” Al principio todos asintie-
ron con seguridad, incluso a algunos se les
escapó un vehemente “sí, por supuesto”.
Tras una breve pausa de reflexión, inter
vino tímidamente otra voz: “Bueno, en
realidad después viene la integración”.
“Pero… ¿después de la integración ya hemos termina- En ese momento eché por un instante el freno. Con
do?”, seguí preguntando. Los miembros de los equipos se los términos “integración”, “pruebas de aceptación” y
quedaron ahora pensando antes de responder. “En reali- “entrega”, teníamos tres pasos visibles en el tablero que
dad, después viene la aceptación por parte del departa- podían repercutir sustancialmente en el Time-to-Market.
mento comercial”. El tablero siguió creciendo para dar Por ello, quería examinar estos pasos de forma más
paso a la prueba de aceptación. detenida y seguí planteando preguntas más profundas:
“¿En qué intervalos se efectúa la integración?” y “¿con
De forma gradual, el equipo se fue haciendo a la idea de qué frecuencia tienen lugar las pruebas de aceptación y
que este tablero tendría que extenderse un poco. Sobre las entregas? Una de las piezas centrales del rompeca-
el siguiente paso no tuve ni que preguntar, me lanzaron bezas empezó a descubrirse prácticamente por sí sola: la
la siguiente frase: “Por supuesto, después tenemos que integración tenía lugar relativamente a menudo, en con-
realizar la entrega”. creto una vez al mes. Pero tanto las pruebas de acepta-
ción como las entregas se realizaban tan solo cuatro
veces al año. Esta es una información absolutamente útil
cuando se trata de mejorar el Time-to-Market. ¿Cómo se
quería llegar antes al mercado de esta manera?
50
NO HAY RÍO SIN MANANTIAL Algunos de los miembros del equipo comenzaron a hacer
sitio en la parte izquierda del tablero porque no paraban
Vale, ya habíamos tratado más o menos el downstream. de surgir columnas nuevas. Entre tanto, me bastó una
Cuando hay un flujo descendente, normalmente también mirada para darme cuenta de todo lo que pasaba en el
hay un flujo ascendente. Se supone que antes de poder upstream. A continuación, paso a describirlo:
empezar con el desarrollo, hay que tomar algunas deci-
siones. Así que planteé la no muy sutil cuestión: “Justo al 1 Primeramente, se recogían las ideas relativas a los
principio del tablero tenéis el backlog. ¿Eso quiere decir productos en un banco de ideas.
que ese es el inicio y antes no pasa nada? Naturalmente
que no era así. “No se puede decir que empieza a partir 1 Dichas ideas se preclasificaban de forma general tras
de aquí. Las tareas pendientes son solo el punto de un primer triaje (selección preliminar).
salida para el desarrollo”. Este fue un dato importante,
así que cambiamos la denominación de backlog por
1 Para las ideas seleccionadas se definían casos de
negocio generales.
“backlog de desarrollo” y seguimos remando en
upstream.
1 El caso de negocio general tenía entonces que esperar
la decisión del comité directivo, el cual valoraba si se
Si había algo como un backlog de desarrollo también te-
debía o no desarrollar una idea.
nía que haber otra cosa, es decir, uno o varios pasos du-
rante los cuales surgieron ideas que, tal vez, incluso fue-
1 Una vez que el comité directivo había dado su visto 51
ron evaluadas. Poco a poco se empezó a desplegar todo bueno, se definía un caso de negocio detallado.
un proceso ante nuestros ojos. “Mira, nosotros lo hace-
mos así”, añadió uno de los miembros del equipo. “Hay 1 El caso de negocio detallado necesitaba la aprobación
un backlog de producto en el que, por decirlo así, se acu- final de un comité.
mulan todas las exigencias del producto. Antes de que
algo acabe en nuestro backlog de desarrollo debemos ¡Uf! Ahora el flujo total de valor había crecido un poquitín
analizar primeramente cada una de las exigencias con el (tomemos aire y pasemos a la página siguiente).
fin de saber cómo y cuándo podemos ocuparnos de ello”.
52
53
53
Hubo un silencio en el equipo. “Vaya, no parece tan ágil”, Sin embargo, esto no tiene nada, pero ABSOLUTAMENTE
apuntó alguien. Exacto. En este proceso se había im- NADA que ver con la Agilidad Empresarial. Y esta no se
puesto precisamente a los equipos de desarrollo la carga implantará mientras que se sigan manteniendo alegre-
de ser más rápidos. Pero los equipos de desarrollo solo mente todas las lógicas de procesos y sistemas anterio-
podían intentar recuperar un poco del tiempo que pre- res, las cuales a menudo actúan a modo de freno. Esta
viamente habían desperdiciado en todo el proceso. Y se organización, a pesar del desarrollo ágil, seguía cojean-
había desperdiciado bastante. do. En este flujo de valor faltaba, de principio a fin, la di-
rección.
El triaje para la preselección de ideas tenía lugar de for-
ma mensual, lo que en principio suena bastante bien. La Agilidad Empresarial surge a través
Pero el comité directivo se reunía únicamente cuatro ve-
de procesos Lean que implementan ideas
ces al año y ¡las decisiones sobre conceptos concretos se
tomaban nada más que una vez al año! Se tardaba una velozmente y permiten así a los equipos
eternidad para que una idea pasara por este proceso de realizar entregas con rapidez.
toma de decisiones hasta llegar al backlog de desarrollo.
Básicamente, transcurrían meses de espera antes de que

se pudiese desarrollar algo. Dicho de otra forma, la efi-
54 ciencia de flujo, o sea, la relación entre el tiempo de tra-
bajo y de espera, fallaba bastante. La dirección se había
esperado un Time-to-Market más rápido al concentrarse
en hacer ágil a un pequeño fragmento, es decir, a los
equipos, pero la Agilidad Empresarial no surge precisa-
mente porque los equipos lleven a cabo rigurosamente
sus Standups a diario o busquen mejoras realizando re- ¿Qué es la eficiencia de flujo?
trospectivas. Esto sería, en todo caso, desarrollo ágil (lo- Por eficiencia de flujo de entiende aquella proporción de
cal), lo cual está bien. tiempo en la que se está trabajando de forma activa dentro
del tiempo de ciclo total de una unidad de trabajo.
CAUSA 4: También en Scrum existe un límite WIP “implícito”. Este es
LÍMITES WIP EN EL el resultado del trabajo en Sprints y el compromiso aso-

ciado a una determinada cantidad de trabajo que se ha
LUGAR EQUIVOCADO de cumplir en un Sprint. Durante un Sprint tampoco se
puede empujar ningún trabajo adicional en el sistema,
Uno de los mayores padecimientos de las organizaciones con lo que queda definido prácticamente un WIP máximo
es el hecho de tenPor eficiencia de flujo de entiende por Sprint. El resultado implícito o explícito de los límites
aquella proporción de tiempo en la que se está trabajan- WIP es, entre otras cosas, que los tiempos de ciclo dismi-
do de forma activa dentro del tiempo de ciclo total de nuyen y la predictibilidad de la finalización del trabajo
una unidad de trabajo. Como ya mencioné, muchas perso- aumenta.
nas de esta empresa se habían ocupado concienzuda-
mente de aplicar métodos y principios ágiles, como, por
ejemplo, entre otros, la limitación del Trabajo en Curso
Lo bonito en esta empresa era que casi todos los equipos
(WIP). Los límites WIP están, por lo general, asociados al
trabajaban con límites WIP explícitos o implícitos. Pero
Kanban ya que en un tablero de Kanban los números en
desafortunadamente esto no parecía servir de mucho.
la parte superior de cada columna muestran la cantidad
¿Estábamos ante una mera ilusión o qué es lo que estaba
máxima de trabajo permitida en el sistema en un momen-
pasando?
to determinado. Fue genial ver que casi todos los equipos
que utilizaban Kanban trabajaban con sistemas limitados 55
Demos aquí un breve giro y abordemos primeramente el
WIP. tema de los límites WIP.
Trabajo en Curso: ¿hablamos de progreso o proceso?

Si ya ha trabajado con Kanban u otros métodos ágiles quizás se
pregunte por qué, en inglés, el término WIP a veces se refiere a
“trabajo en progreso” y otras veces a “trabajo en proceso”.
En un principio, la comunidad Kanban usó el término “Trabajo
en Progreso” ya que la palabra “proceso” tenía una connota
ción negativa en muchas organizaciones.
Yo, personalmente, considero “proceso” una palabra neutra
porque simplemente se limita a describir cómo se trabaja en
una organización. Esta es la razón por la que, de forma muy
consecuente, cuando utilizo el término “Trabajo en Curso”, me
refiero al “Trabajo en Proceso”. La distinción entre proceso y
progreso es muy relevante. El hecho de que el Trabajo en Curso
se encuentre dentro del proceso no quiere decir que haya pro
greso. Ese trabajo puede estar atascado dentro del proceso
sin progresar a ninguna parte.
CÓMO FUNCIONAN LOS LÍMITES WIP, más o menos como se ve en la imagen inferior; del table-
POR QUÉ FUNCIONAN Y QUÉ VENTA- ro cuelgan 200 notas y quizás aún se necesita un segundo
JAS PRESENTAN tablero para que quepan todas ellas. La cuestión es la
siguiente: esta visualización es para volverse loco. Da la
La visualización del trabajo es un primer paso importante impresión de que los diez empleados trabajan realmente
en una empresa a la hora de realizar mejoras. Pero tam- en todas estas cosas. Pero la realidad es bien distinta
bién hay que percibir y entender lo que muestran dichas porque en la mayor parte de las 200 cosas del sistema no
visualizaciones para implementar las medidas correctas. trabaja nadie. Es decir, sí que hay mucho “Trabajo en
De forma clara y visible se puede ver en qué se está Curso” pero poco “progreso”. En la mayoría de los traba-
trabajando, dónde trabaja cada uno y dónde existen jos apenas se da un progreso, a pesar de estar pululando
bloqueos. Sin embargo, cuando visito de nuevas una por el sistema.
empresa, muchas veces veo también demasiado trabajo
en el sistema. Conclusión: en un sistema completamente cargado
(atascado) no se puede saber cuándo se va a concluir el
Imaginémonos un sistema en el que diez empleados trabajo. ¡En tales sistemas no están presentes ni la
trabajan simultáneamente en 200 cosas. El aspecto sería predictibilidad ni el respeto por los plazos!
56
Las personas no son capaces de realizar

múltiples tareas ya que ello significaría
que se puede trabajar de forma activa y
con total concentración en dos cosas al
mismo tiempo. ¿Puede usted realizar
dos tareas completamente indepen-
dientes entre sí en dos portátiles al
mismo tiempo, por ejemplo, escribir dos
historias maravillosas, cada una con
una mano? Seguramente, no. Incluso si
supiera, en algún momento le faltarían
manos con las que poder desempeñar
con ahínco otras tareas adicionales.
Pensamos que estamos realizando ta-
reas múltiples cuando, en realidad, lo
que hacemos es cambio de tareas, es
decir, cambiamos continuamente de un trabajo a otro, Volvamos a nuestro tablero. Si un empleado trabaja en
dejamos tareas sin terminar y, mientras tanto, nadie más una media de 20 cosas, se puede deducir que solo en ra-
trabaja en ellas. ras ocasiones trabajará en una sola actividad. Así pues, 57
no empleará la mayor parte del tiempo en trabajar con-
centradamente en una única cosa; hará más bien un poco
de una tarea mientras deja a medias otras 19. Como no es
solamente un empleado el que trabaja de esta forma,
sino diez, de 200 trabajos se quedan sin acabar 190. Esto
es muy fácil de representar en el tablero. En la parte su-
perior se reflejan solo aquellos trabajos en los que en
este momento alguien trabaja de forma activa. En el cam-
po inferior, en cambio, se representan todos los trabajos
de los que nadie se ocupa en este momento.
La visualización del trabajo nos hace ver las

actuales disfuncionalidades de un sistema. El
verdadero motor de mejora se basa en la limit
ación de la cantidad de trabajo permitida en
un sistema.
A MAYOR EFICIENCIA DE FLUJO, decisión previa de si se ha de implementar una idea

MAYOR RAPIDEZ DEL SISTEMA o no frena enormemente el trabajo activo. Se trabaja
brevemente en algo para esperar una decisión que a
La relación entre el trabajo activo e inactivo en el siste- veces tarda varios meses en llegar.
ma es medible. Al calcular la eficiencia de flujo podemos
realizar afirmaciones sobre qué grado de tiempo de ciclo 2. ¿ Cuánto trabajo hay en el sistema? Cuanto más tra-
se corresponde con tiempo activo de trabajo. bajo se encuentre pululando por un sistema, peor
será la eficiencia de flujo. No es lo mismo estar cam-
Supongamos que el tiempo de ciclo de un trabajo es de biando constantemente entre tres trabajos distintos
diez días. Traducido esto a nuestro tablero, la eficiencia que entre diez.
de flujo nos dice cuántos días de este trabajo han trans-
currido en la zona activa del tablero y cuántos en la zona En resumen: el Trabajo en Curso ejerce una gran influen-
inactiva. Asusta ver que, en la mayoría de las organiza- cia en la eficiencia de flujo. Si una organización quiere
ciones, la eficiencia de flujo es muy baja. Al decir “baja” ser más rápida no debería optimizar en primer lugar el
me refiero a valores por debajo del diez por ciento, es trabajo activo. Este es precisamente el problema de mu-
decir, que solo el diez por ciento del “tiempo de ciclo” se chos sistemas utilizados para mejorar la eficiencia; se
corresponde realmente con tiempo de trabajo activo. concentran únicamente en el trabajo activo y quieren
que este sea más rápido. Partamos de una eficiencia de
58 La eficiencia de flujo viene determinada básicamente flujo del diez por ciento y de que podamos motivar a los
por dos factores: empleados a trabajar el doble de rápido; sin embargo, el
rendimiento del sistema solo aumenta un máximo del
1. ¿Qué tamaño tiene la parte de la cadena de creación cinco por ciento ya que el 90 por ciento del tiempo nadie
de valor que se puede ver? Cuanto mayor sea este trabaja en las tareas. El intento de mejorar rendimientos
tramo, menor será la eficiencia de flujo. Pensemos individuales no nos hace progresar. Más razonable sería
ahora en el amplio flujo de valor de esta empresa dirigir la atención hacia el sistema y comenzar allí a me-
que estamos examinando (véase causa 3). Ya solo la jorar el rendimiento.
REDUCIR EL WIP: Para el siguiente experimento mental partiremos del

APARQUE EL TRABAJO DELANTE DEL echo de que siempre hay una persona trabajando en
h
SISTEMA las tareas y de que esta persona nunca se bloquea. Su-
pongamos que en nuestro banco de opciones delante
Eso está muy bien, reducir el WIP, pero... ¿cómo hacerlo? del sistema se encuentran tres trabajos – A, B y C. Cada
¿Significa esto rechazar encargos? Para nada, pueden uno de ellos requiere cinco semanas para su implemen-
quedarse tranquilos. El trabajo se ha de sacar del siste- tación. Si trabajamos con un límite WIP de 1, debemos
ma para colocarlo delante de este usando, por ejemplo, decidir si comenzar con el trabajo A, B o C. Hagámoslo
un banco de opciones. por turnos: elegimos A y nos concentramos completa-
mente en esta tarea (B y C permanecen en el banco de
Pero… ¿qué sacamos con esto? Antes, el trabajo estaba
opciones).
en espera en el campo “trabajo inactivo” y ahora se en-
cuentra en el banco de opciones. ¿Cuál es la diferencia?
59
60
Tras cinco semanas hemos completado el trabajo A. Hagamos la siguiente comparación:
Después nos decidimos por B, concentrándonos en esta
tarea; tras diez semanas hemos completado el trabajo B. A: 13 vs. 5 – ¡Un enorme aumento del rendimiento!
Por fin le toca al trabajo C y, una vez nos concentramos
B: 14 vs. 10 – Tampoco está mal
en esta tarea, tras quince semanas hemos completado el
trabajo C. C: 15 vs. 15 – Se queda igual
Realicemos un segundo experimento mental y aumente- La cuestión es que nadie dice que en un sistema limitado
mos el límite WIP a 3, comenzando al mismo tiempo WIP todos los trabajos se van a completar a la velocidad
con los tres trabajos. Entre tanto, sabemos ya que las del rayo (y si alguien se lo ha dicho, mejor que lo olvide).
personas no son capaces de trabajar en múltiples tareas, El hecho es que al cliente A se le va a servir más rápido.
por lo que el empleado trabaja cada semana de forma
alterna en A, B y C. Con esta variante, A se completa tras Por extraño que parezca, a menudo escucho la objeción:
13 semanas, B tras 14 y C tras 15. “¡Pero eso es injusto!”, lo cual viene, más o menos, a tra-
ducirse por: “Es mejor que tratemos mal a todos los
Ahora podemos elegir entre un límite WIP de 3, donde los clientes”. ¿Tengo que decir algo más al respecto o lo po-
tres trabajos tienen un tiempo de ciclo alto, o entre un demos dejar aquí?
límite WIP de 1, donde algunos trabajos tienen un tiempo
de ciclo alto.
Sí que es verdad que he representado la diferencia par- Pero no es a mí a quien tienen que creer, pues fue John D.
tiendo de suposiciones simplificadas. Lógicamente, esto C. Little quien lo constató matemáticamente [Little, Gra-
no significa que se tenga que trabajar siempre en una ves, 2008]. Según la ley de Little, el promedio del tiempo
sola tarea. ¡Con este ejemplo no quiero decir que 1 sea el de ciclo en un sistema en el que entran constantemente
límite WIP ideal! Pero un WIP de 10 es mejor que uno de trabajos resulta del promedio del número de trabajos
100. A ello hay que añadir que el continuo cambio de ta- del sistema dividido por el promedio del throughput.
reas no sale gratis, ya que hay que contar con un enorme
esfuerzo adicional. Incluso si no se incluye dicho esfuer- Se trata de encontrar el límite correcto para
zo adicional, algo queda muy claro: menos WIP implica cada sistema mediante la continua
tiempos de ciclo más cortos.
observación, así como de permitir la entrada
del trabajo en el sistema en una razonable
secuencia desde el punto de vista económico.
61
AGILITÄT NEU DENKEN
Recapitulación:
Por qué me parecen tan La predictibilidad aumenta. Cuando se
realmente buenos los

trabaja paralelamente en varios trabajos se pierde la visión
general del tiempo que realmente se necesita para cada uno
límites WIP de ellos. Al pensar en trabajos paralelos se calculan márge
nes de seguridad temporales para evitar retrasos. Los límites
WIP refuerzan la concentración en pocos trabajos y ayudan
así a identificar el tiempo que realmente se necesita para
cada uno de ellos.
El tiempo de ciclo disminuye.

Al trabajar en menos cosas simultáneamente, aquellas
en las que estamos trabajando concluyen antes. En el El riesgo en la entrega disminuye.
ejemplo de los trabajos A, B, C, el promedio de tiempo Los proyectos suelen estar supeditados a plazos de entrega.
de ciclo con un WIP de 1 es de diez semanas. En el caso Supongamos entonces que usted ha confirmado la entrega de
de un límite WIP de 3, son catorce semanas. El tiempo de los tres trabajos – A, B y C – hasta la semana 13. En el escena
62 ciclo está directamente relacionado con el Time-to- rio 1 del WIP, A se entrega a las cinco semanas y B a las diez
Market. Si queremos que este mejore no podemos evitar semanas, pero para C no hay suficiente tiempo, aunque la
la limitación del Trabajo en Curso. mayor parte del trabajo está listo. En el escenario 3 del WIP,
en la semana 13 no se han entregado ni A, ni B y mucho me
nos C. Trasladada esta situación a la realidad, un poco antes
de llegar a la semana 13 comienza el pánico y se intenta a
toda costa entregar, al menos, algo, aunque sea de peor cali
dad. Un WIP más bajo evita la presión al poder ir entregando
de forma continua.
Los costes de demora disminuyen.

En el primer escenario del ejemplo ABC podemos ya
ganar dinero tras cinco semanas con el trabajo A
porque este ha concluido. En el segundo escenario,
deberán transcurrir 13 semanas. La diferencia temporal Reducen la costosa realización de tareas múltiples. Los lími
de 8 semanas da como resultado los costes de demora. tes WIP evitan que se inicien demasiados trabajos simultá
Si pudiésemos generar en el mercado 10 000 euros neamente y se pierda así la concentración en lo que realmen
semanales con el trabajo A, en el escenario “WIP 3” ya te importa y debe terminar ahora. En este sentido, los límites
habríamos dejado de ganar 80 000 euros. Este es un WIP reducen los costes asociados a la realización de tareas
punto esencial: ¡Los límites WIP tienen un componente múltiples, resultando así un sistema más eficiente.
económico!
LÍMITES WIP –
EL GRAN IMPACTO DE LA LETRA
PEQUEÑA
El hecho de que el 99 por ciento de las empresas no Pero, normalmente, los equipos están asociados a un
lleguen a entender a fondo el concepto de límites WIP entorno empresarial, por lo que también se debe de
seguramente tiene que ver también con la historia de tener en cuenta el tema de los límites WIP en este con-
métodos como Kanban o Scrum. Estos métodos fueron texto. Si se ha de mejorar la productividad de toda la
considerados durante bastante tiempo como plug-ins empresa – la Agilidad Empresarial – hay que conocer la
de alta velocidad para equipos y así se vendieron. De letra pequeña del WIP.
esta forma, los límites WIP se convirtieron en instrumen-
tos de debían limitar la cantidad de trabajo en los equi- Esta es la razón por la que quiero escribir aquí la letra
pos para que estos fueran más rápidos. Esto, en princi- pequeña en tamaño extragrande:
pio, está bien cuando tales equipos no están integrados
en contextos mayores y únicamente tienen que trabajar
para sí mismos.
63
AGILITÄT NEU DENKEN
Ahora, nuestra empresa trabajaba en iniciativas, la pala- Como también estas funcionalidades están compuestas
bra ágil usada para proyectos. ¿Qué pasaba con estas por otros pequeños trabajos parciales, las Historias de
iniciativas una vez que habían sido determinadas? Usuario se dividen finalmente en tareas. Estas se refie-
ren a trabajos que se pueden realizar a lo largo de un
La idea global de la iniciativa se divide, primeramente, en día, por ejemplo.
aspectos parciales, o sea, en Épicas (unidades estimadas
Así es cómo funciona esta empresa. En otras empresas,
de trabajo), cuya suma ha de dar como resultado la tota-
el funcionamiento puede ser totalmente diferente; qui-
lidad del producto. A continuación, un ejemplo abstruso
zás los proyectos se dividen en paquetes de trabajo y los
a modo ilustrativo:
paquetes de trabajo en tareas. Lo único que importa es
la siguiente afirmación fundamental: las tareas extensas
La iniciativa se llama “dominio mundial”.
como, por ejemplo, los proyectos no se realizan en su to-
talidad en un escritorio, sino que se dividen en unidades
Una Épica podría ser: “Conquista Alemania”.
parciales lógicas.
Para poder implementar una Épica son necesarios varios ¿Dónde deseaba ver esta empresa los resultados positi-
pasos más pequeños. La Épica se vuelve a dividir en las vos de los límites WIP? En realidad, quería mejorar el Ti-
siguientes unidades más pequeñas, las llamadas Histo- me-to-Market de las iniciativas.
rias de Usuario, que describen las funcionalidades indivi-
64 Entonces… ¿dónde debía haber limitación?
duales deseadas.
¡Bingo!: en las iniciativas
Y ahora reflexionemos sobre lo que realmente sucedió el mejor asfalto silencioso de alta tecnología sobre el
en esta organización. La responsabilidad sobre la agili- que se puede ir a toda velocidad. Pero no se puede llegar
dad de la compañía recayó, en primer lugar, en los equi- muy lejos en una autovía colapsada, incluso si se pudie-
pos. Fueron los equipos quienes habían limitado sus tra- se correr a 200 km/h. Ya se puede dar con un canto en
bajos - Historias y tareas – mientras que, simultánea- los dientes si es capaz de avanzar a velocidad de peatón
mente, un número creciente de proyectos de arriba no y en absoluto podrá predecir cuándo alcanzará el objeti-
dejaba de amontonarse en el sistema. Y es que los equi- vo. Tampoco aquí tiene sentido gritar constantemente a
pos ágiles a menudo hacían llegar a la dirección la falsa los conductores para que vayan más rápido.
conclusión de que se podían iniciar más proyectos por-
que teóricamente todo debía ir de forma más veloz. Así Así pues, nadie se sorprenderá de que el Time-to-Market
que fue totalmente imposible para estos equipos esta- no mejorase. En realidad, no se limitaron aquellas unida-
blecer alguna mejora en el Time-to-Market porque no des que ejercían influencia en el Time-to-Market, es de-
había cambiado nada en el factor esencial de influencia, cir, las iniciativas. Si no se tiene poder de influencia des-
la cantidad de proyectos en el sistema. de los niveles de equipo, ¿en qué parte de la organiza-
ción se ejerce entonces dicha influencia?
Puede imaginarse esta situación comparándola con una
autovía totalmente colapsada. Las vías (los equipos) es- ¡Otra vez bingo!: en la gestión estratégica de portafolio
tán dotadas de los sistemas de tráfico más modernos y
65
¿QUÉ PROBLEMA SURGE CUANDO Me gustaría exponer los problemas que esta situación
FALTA UNA GESTIÓN ESTRATÉGICA causa con otro ejemplo basado en mi experiencia. Había
DE PORTAFOLIO? diseñado con el comité ejecutivo de una gran corpora-
ción un gigantesco tablero de portafolios sobre cinco pi-
En la gestión estratégica de portafolio se decide qué ini- zarras blancas enganchadas unas con otras. Estábamos
ciativas hay y cuándo han de ser implantadas en la orga- discutiendo delante del tablero sobre cómo se trabajaría
nización. Mientras que en esta empresa se habían modi- en el futuro. “¡Por fin entiendo lo que significa esa cosa
ficado muchísimas cosas a nivel de equipo, al mismo de ahí!”, dejó escapar una ejecutiva, llamémosla Lidia, en
tiempo habían permanecido igual muchos aspectos en el un momento “eureka” en medio de la discusión. En silen-
resto de la organización. En realidad, existían algunos cio, todos la miraron con cara de interrogación. “Venga,
documentos de Excel saturados de información sobre los ¿cómo funciona normalmente?”, continuó. “En mi caso es
que la dirección debatía una y otra vez en diversas ron- así: el lunes tengo una cita de 30 minutos. Viene alguien
das de priorización, pero lo que no había era una verda- que se ha estado preparando durante una semana para
dera estrategia ágil de la gestión de portafolio. Mi hipó- presentarme una idea. Esa persona pone todo su empe-
tesis era la siguiente: al faltar una gestión estratégica de ño y cuando la escucho debo confesar que la idea me
portafolio se iniciaban demasiadas iniciativas en esta parece genial. Tenemos que ejecutar la iniciativa a toda
empresa. costa porque asegura el futuro. El martes viene a verme
una segunda persona que se ha preparado durante dos
66 semanas y presenta una idea, esta vez tal vez incluso du-
rante 15 minutos. Vuelvo a pensar que es una idea genial
y que tenemos que ponerla en práctica. Y el miércoles
tengo de nuevo una reunión”.
Adónde quería llegar: En estas propuestas hay mucho Lidia había señalado claramente dónde estaba el proble-
trabajo preliminar invertido y se tiene el legítimo deseo ma: la dirección ejecutiva decide cada día si se imple-
de que se apruebe la iniciativa. Y, seguramente, estas mentan determinados proyectos o no. Estas decisiones
ideas son realmente buenas. no solamente se toman de forma aislada del resto de co-
legas de la dirección y, sobre todo, de otros empleados
Pero… ¿qué es lo que pasa? Básicamente, Lidia toma el que han de implementar estos proyectos. También se to-
lunes, martes y miércoles tres decisiones individuales e man decisiones sin contar con el resto de proyectos que
independientes, pero para nada se ha tenido en cuenta ya se encuentran implementados.
el contexto de todas las iniciativas ya comenzadas y pla-
nificadas. El WIP de las iniciativas no deja de aumentar por las
decisiones individuales y aisladas. Sin embargo, las ini-
ciativas deberían de ser limitadas.
67
68
YA NO HAY ESPACIO Al dibujar el promedio del throughput del sistema o el
PARA EL DESPEGUE promedio de la “tasa de salidas” de iniciativas del siste-

ma (línea roja inferior), parecía ir todo más o menos bien,
el trabajo se terminaba. Pero si se hacía lo mismo con el
Retornemos, tras esta excursión al mundo de los límites promedio de la “tasa de llegadas” o de inicio, la línea
WIP, a nuestra empresa. que surgía tenía una pendiente considerablemente ma-
yor. Este era un claro indicio de que comenzaban más
Quería examinar mi hipótesis de que “se inician dema- iniciativas de las que concluían. Si no aumentaba el nú-
siadas iniciativas”. Así pues, concerté una cita con la di- mero de empleados al menos en la misma medida, lo
rección. En esta reunión pregunté cuántas eran las ini- cual no era el caso, entonces había un motivo por el que
ciativas que se completaban cada semana. preocuparse.
¿Cómo se podía averiguar esto? En el caso de esta em- Utilizo en este contexto denominaciones como “tasa de
presa fue muy fácil: en todas las iniciativas estaban indi- llegada” y “tasa de salida” de forma muy consciente,
cadas la fecha de inicio y de la finalización. Primero clasi- además de que me gusta, porque esta situación me hace
fiqué las iniciativas según la fecha de finalización sema- pensar siempre en los aeropuertos. Si uno se imagina un
nal y las registré de forma acumulativa en un diagrama aeropuerto, enseguida lo entenderá. Cuando la tasa de
(véase línea “finalizado”). llegadas de aviones a largo plazo es más alta que la tasa
de salidas surge un gran problema. Si todo el espacio en- 69
Tenía buena pinta. La línea ascendía constantemente y
tre las puertas de embarque y las pistas de despegue y
eso significaba que las iniciativas concluían realmente.
aterrizaje está lleno de aviones estacionados, en algún
momento se producirá el colapso.
Lo mismo se puede hacer también con las
fechas de inicio. Volví a clasificar las ini-
ciativas por semanas y registré los resul-
tados de forma acumulativa con una
segunda línea en el diagrama (“iniciado”).
También esta línea era ascendente, aun-
que en este caso esto no era tan positivo.
¿Cuál era el motivo de mi descontento?

En las organizaciones sucede a veces lo mismo cuando Los límites WIP son un medio que persigue igualar la
se inician demasiados proyectos. Claro, cuanto más se tasa de llegadas y salidas o tasa de inicio y conclusión.
hace, más puede ganar la empresa, esta es una conclu- Ayudan a no iniciar más proyectos de los que puedan
sión comprensible. Sin embargo, no se ha razonado bien concluirse en un tiempo determinado que una empresa
del todo. Este desequilibrio entre inicio y conclusión se necesita para poder ser viable.
puede aguantar durante un tiempo determinado. Si ate-
rriza un avión, es decir, un proyecto de más, el sistema No obstante, tras la finalización de este taller dirigido a
empieza a volcarse y hay más trabajo “en curso” del que la dirección, hubo una notable propuesta de mejora. Uno
se pueda finalizar. Con proyectos no concluidos, por una de los gerentes pensó en voz alta: “A partir de ahora no
parte, no se puede realmente ganar dinero y, por otra, realizaremos nuestras evaluaciones de forma aislada en
los clientes empiezan en algún momento a ponerse ner- salas de reuniones, sino que nos encontraremos delante
viosos de tanto esperar por sus productos. Esto es lo que de un tablero con todas las iniciativas actuales y planifi-
había pasado en esta empresa. Como se había perdido cadas. Así podremos ver de qué manera asociar las ideas
mucho tiempo iniciando demasiadas iniciativas, la em- recién lanzadas con lo que ya se está haciendo y lo que
presa había socavado su propia posición en el mercado y está por realizar. Y veremos si existe o no compatibili-
con respecto a los clientes. dad. ¿Debemos comenzar inmediatamente con la iniciati-
va ya que es tan genial y, para ello, parar otra cosa o la
colocamos primeramente en un banco de ideas?
70
¿Necesitamos límites WIP?

Cuando entra en juego el tema de los límites WIP, la direcci Es fácil comprobar si se necesitan límites WIP. Para ello
ón de muchas organizaciones se plantea automáticamente puede usted mismo hacer una breve prueba:
la pregunta de qué proyectos no deben realizarse o deben
ser paralizados. Pero para nada se trata de eso. Los límites P Todos están contentos con el rendimiento de la
WIP no han de obstaculizar proyectos sino apoyar decisio rganización, tanto nuestros clientes como nosotros
o
nes razonables desde el punto de vista empresarial: ¿Qué mismos.
ha de ser lo próximo que se entregue para cumplir los obje ¡Felicidades! Todo está bien, ya ha encontrado el
tivos económicos de la empresa y crear un valor añadido óptimo WIP.
para los clientes? Ello requiere modificar la forma de pen
sar, puesto que en la mayor parte de las organizaciones nos P Todo va demasiado lento. Los clientes se quejan y
hemos acostumbrado a escuchar la siguiente frase: “Sí, es las cifras empresariales dan que pensar.
tamos trabajando en ello”. A mí esta frase me pone nervio Debería reducir el WIP para ganar velocidad.
so. Los empleados no deben estar continuamente trabajan
do, sino entregando. El trabajo cuesta dinero, mientras que P Somos más rápidos en el mercado de lo que nuestros
las entregas lo traen. clientes pueden comprar.
Este es un problema agradable, puede iniciar más
A pesar de todas las dificultades, esta trabajo. 71
empresa estaba muy avanzada en su
forma de pensar. Incluso aunque los
límites WIP hasta ese momento esta
ban en el lugar equivocado, existía,
no obstante, la conciencia de que el
trabajo en un sistema tiene que ser
limitado. Muchas organizaciones no
consiguen dar este salto ideológico y
piensan que les va bien sin límites WIP.
UN PRIMER BALANCE clásica gestión de proyectos, quedando una cuestión
PROVISIONAL esencial sin respuesta: ¿Cuáles son los cambios que

surten efecto y por qué?
Resumamos el motivo por el cual no se habían consegui-

do los resultados deseados en esta empresa. La direc-
ción había tenido muy buena intención con su iniciativa Como la palabra “ágil” hace referencia de manera in-
al cambio y había tratado el tema de la agilidad de forma consciente al término “equipo”, no se había tenido en ab-
ejemplar. Se había esforzado por interiorizar la mentali- soluto en cuenta el hecho de que el punto más fuerte de
dad tras la metodología para, así, sin prisa pero sin pau- palanca en ese momento y en vistas a lo que se debía
sa, seguir desarrollando la cultura de la organización. conseguir no se encontraba a nivel de equipo. El motivo
Pero con la emoción del momento no se había ocupado de por qué no conseguían llegar al objetivo básico
de los mecanismos y dependencias y había intentado in- “mejor Time-to-Market” y de que incluso se estuviesen
troducir agilidad mediante la forma de proceder de la alejando en parte de él tenía cuatro serias causas:
72
Y ESO ES LO QUE HABÍA FALLADO 73

EN ESTA EMPRESA
PARTE 3
Primeras
soluciones
Está volando,
está volando
…una mejora
74
Acerca de tableros de productos,

tableros de estrategias y del
deseo de colaboración a través
de todos los Flight Levels.
PARTE 3 | PRIMERAS SOLUCIONES
75
Ciertamente, no habíamos identificado todos los proble- No solo me llaman para solicitar mi asistencia cuando
mas. Sin embargo, desde mi punto de vista, se habían parece que va a fracasar una transición ágil. A menudo
detectado precisamente los más trascendentales, es de- me incluyen incluso en la planificación de tales proyec-
cir, aquellos que impedían que la empresa diera el gran tos de cambio, en cuyo caso lo primero que hago es pre-
paso hacia la verdadera mejora. sentar el modelo de los Flight Levels.
Como se deduce del nombre, el Flight Level describe la

altura a la que vuela un avión. En función de la altura de
vuelo se modifica el grado de precisión con el que se
puede percibir un paisaje. Si se vuela muy alto, se puede
dirigir la vista hacia el lejano horizonte, pero al mismo
tiempo no se puede distinguir cada detalle del suelo. Por
el contrario, si se vuela más bien bajo es, en cierto modo,
casi posible mirar a través del interior de las ventanas de
los dormitorios, aunque ya no se podrá reconocer, por
ejemplo, la extensión de la superficie de una ciudad.
Así pues, cada Flight Level tiene sus ventajas y particula-

ridades, al igual que sus limitaciones en la medida de lo
que llega a ser identificable.
76
También podemos aplicar el mismo principio en las orga- El modelo de los Flight Levels es un
nizaciones. Gracias al modelo de los Flight Levels pode- instrumento de comunicación usado para
mos averiguar qué nivel de la organización ofrece la me-
identificar el efecto de mejoras específicas en
jor palanca de cara a las mejoras. No es importante la
elección de los métodos con los que se trabaja en cada los diferentes niveles de la organización, así
nivel sino cómo se establece comunicación y coopera- como para averiguar en qué lugar dentro de la
ción entre los Flight Levels y las distintas unidades den- organización tiene sentido o es posible
tro de cada nivel. Si se consiguen mejoras, toda la crea-
potenciar mejoras.
ción de valor empezará a optimizarse, siendo este nues-
tro objetivo final.
77
FLIGHT LEVEL 1: Sin embargo, para generar un valor al cliente, en la ma-
NIVEL OPERATIVO yoría de los casos los sistemas individuales deben coo-
perar entre sí de una forma u otra – “no equipo = isla”.
De ignorar esto y focalizar la optimización únicamente en
Empecemos cerca del suelo. El primer Flight Level perte-
cada equipo por separado, puede surgir el problema de
nece a los equipos que realizan el trabajo diario. Un
la suboptimización. De esta forma, se obtiene un equipo
equipo puede optimizarse, o, mejor dicho, puede optimi-
de alto rendimiento, pero el resultado global de la orga-
zar su flujo de trabajo individual implementando cuatro
nización, es decir, el rendimiento de todos los equipos
acciones esenciales:
juntos permanecerá, en el mejor de los casos, igual,
siendo lo más probable que incluso disminuya.
1 Visualizando el trabajo
1 Usando límites WIP.
1 Integrando de forma rutinaria en su proceso feedback
loops como las métricas, los Standups diarios o las re-
trospectivas.
1 Determinando e implementando mejoras a través de

los feedback loops.
El método con el que trabaja un equipo de cara a, por

ejemplo, desarrollar productos o proporcionar servicios,
78 ya sea de manera ágil o no, es totalmente irrelevante ya
que el modelo de los Flight Levels es independiente de
cualquier tipo de metodología. En una empresa suele
haber más de un equipo y cada uno de ellos prefiere
utilizar un método de trabajo distinto. Por ello, en el
Flight Level 1 de una organización confluirán diferentes
sistemas.
¡Bienvenido al mundo del pensamiento

sistémico! La optimización local conduce
normalmente a la suboptimización global
(véase el ejemplo del teclado de la parte
2). El motivo son las dependencias entre
los equipos; siempre habrá algunas que
no puedan resolverse. Dichas dependen-
cias han de ser gestionadas, lo cual es
tarea del Flight Level 2.
79
FLIGHT LEVEL 2:
COORDINACIÓN
Los equipos aportan su contribución en distintos lugares Al optimizar el proceso de trabajo en todo el flujo de va-
de un flujo de valor, algunos en el desarrollo, otros en el lor disminuyen los tiempos de espera en las interfaces y,
marketing y los terceros en el área operacional. El truco lo que es más importante, los atascos se hacen clara-
está en dejar que cada equipo trabaje en el momento y mente visibles.
en el asunto oportunos. Por ello, en el Flight Level 2 nos
alejamos del nivel de equipo para visualizar el flujo de Lógicamente, cuanto mayor sea la organización más flu-
valor, es decir, el modo en que, por ejemplo, se crea un jos de valor habrá, por ejemplo, en forma de diferentes
determinado producto productos y servicios. Por consiguiente, en una empresa
habrá, por lo general, más de un sistema por Flight Level
El Flight Level 2 gira alrededor de la coordi- 2, existiendo así dependencias entre las corrientes de
valor. Si, por ejemplo, se modifica algo en un producto, a
nación de las actividades que generan valor
menudo se deberá modificar también algo en otro pro-
de Principio-a-Fin, “desde la idea hasta el ducto. En tales casos, aquellos tableros en los que se
resultado”. En este nivel se optimizan las gestionen flujos de valor se colocarán juntos en un lugar
interacciones entre los equipos. para facilitar la visibilidad de las dependencias y poder
así gestionarlas. También aquí se establecen feedback
Importante: entre el Flight Level 1 y el Flight Level 2 debe loops para favorecer la coordinación y obtener conclu-
existir coordinación. Por ello, en el Flight Level 2 ocurre siones de mejora, creándose algo así como una gestión
80 lo mismo que a nivel de equipos en lo que se refiere a la operacional de portafolio.
optimización de la colaboración en un flujo de valor:
1 El trabajo se visualiza.

1 Se establecen límites WIP.
1 Tienen lugar feedback loops regulares, por ejemplo,
Standups y retrospectivas con representantes de los
equipos.
1 Se deducen e implementan oportunidades de mejora

en base a los conocimientos.
81
FLIGHT LEVEL 3: La visión general que se tiene en el Flight Level 3 hace
GESTIÓN ESTRATÉGICA posible dirigir la estrategia de toda la organización, no

tratándose de una microgestión en la implementación
DE PORTAFOLIO operacional. En principio, es un buen problema tener
más demanda que posibilidades de implementación, ya
El portafolio de una empresa se compone normalmente que, de no ser así, una empresa tendría que desprender-
de un gran número de servicios y productos, así como de se de parte de su personal. Sin embargo, aquí surge una
iniciativas estratégicas que sirven para preparar a la em- situación competitiva entre las opciones a nivel estraté-
presa de cara al futuro. Esta combinación es la que se gico de portafolio. Esta desproporción entre opciones y
gestiona en el Flight Level 3. Queremos tener una visión posibilidades de implementación se ha de llevar a cabo
general de lo que ocurre en la empresa, queremos saber de manera explícita, ya que, de otra forma, da la impre-
qué proyectos y qué iniciativas estratégicas interaccio- sión equivocada de que se dispone de un número inter-
nan entre sí y de qué forma, cómo ha progresado la im- minable de recursos. Como no es este el caso, el Flight
plementación, así como si un producto, un proyecto o Level 3 tratará precisamente este tema. Se trata de
una iniciativa aporta algo a la estrategia y alcanza el éxi- seleccionar y combinar de manera acertada proyectos,
to esperado. ¿Se puede iniciar un proyecto o se ha de es- iniciativas estratégicas y productos pendientes de desa-
perar hasta que otro haya concluido? En el Flight Level 3 rrollo para detectar dependencias y optimizar el flujo
se aclaran algunas de las cuestiones más importantes: mediante la cadena de creación de valor en base a los
recursos verdaderamente disponibles.
También a nivel estratégico se vuelve a trabajar con la

¿Cuánto trabajo soporta la organización? visualización, en este caso con un tablero de estrategias.
82
¿Se orienta el trabajo según la estrategia? El diseño depende de cada organización, no existen ta-
bleros de estrategias “estandarizados” y está bien así, a
no ser que la estrategia sea: “Queremos ser una copia
barata de la empresa XY”. Cuanto más grande es una or-
ganización, más sistemas integrará el Flight Level 3, por
ejemplo, en diversas ubicaciones o divisiones. En cual-
quier caso, se recomienda que en un tablero de Flight
Level 3 la estrategia de la empresa y las estrategias par-
ciales queden bien visibles, por ejemplo, las de las dis-
tintas sedes. Lo mejor es que vayan acompañadas de
datos clave que indiquen si las cosas se están desarro-
llando en la dirección correcta o no.
83
Y ahora una petición del inventor: Por favor, ¡no utilice el Los Flight Levels visualizan y organizan de manera
modelo de Flight Levels para restructurar su empresa o sencilla los distintos tipos de trabajo en una compañía.
dividirla en Flight Levels! (al estilo «queremos el modelo Se han de tomar decisiones estratégicas sobre lo que se
Spotify»). va a desarrollar, después viene la coordinación de la
implementación y, finalmente, la entrega. De la misma
El modelo de Flight Levels no es ni un modelo organiza- forma, una organización puede preferir, por ejemplo,
cional ni un modelo de madurez. Que quede claro que el tomar las decisiones en un contacto más estrecho con el
Flight Level 3 no es tres veces mejor o más importante nivel de coordinación en lugar de hacerlo desde la torre
que el Flight Level 1. de marfil. Los Flight Levels 3 y 2 pueden incluso llegar a
fusionarse en un tablero. Existen tantos tipos de
Los Flight Levels se entienden como soporte de pensa-
configuración como empresas.
miento y comunicación y deben únicamente hacerle re-
flexionar sobre qué palancas están disponibles en cada Tampoco es necesario incluir todos los Flight Levels para
nivel (y no me refiero aquí a jerarquías) para la solución cada proyecto. Un tema que únicamente atañe a un e quipo
de un problema. Cada Flight Level tiene una prioridad en la empresa y que puede ser solucionado dentro de él,
distinta. como, por ejemplo, la eliminación de un pequeño pro
blema de calidad no debería colocarse en el tablero de
1 En el Flight Level 3 se trata de priorizar los proyectos estrategias. De forma inversa, estrategias de gran alcance
e iniciativas pendientes según la orientación estraté-
como, por ejemplo, un mejor Time-to-Market no pueden
gica de la empresa.
ser implementadas si toda la responsabilidad recae
sobre los equipos. Un solo equipo de desarrollo pro
1 El Flight Level 2 tiene como tarea dividir los proyectos
e iniciativas elegidos en partes factibles y coordinar el bablemente tampoco podrá decidir si un determinado
trabajo de las unidades operacionales implicadas. producto se puede desarrollar y si para ello se debe
construir, de forma preventiva, una nueva fábrica en
1 Los equipos que trabajan en el plano operacional en China.
el Flight Level 1 vuelven a dividir sus tareas del Si una organización quiere conseguir una mejora, lo
proyecto/de la iniciativa en paquetes más pequeños primero que debe estar perfectamente claro es qué
y entregan. nivel ofrece la mejor palanca para llevarla a la práctica.
Los Flight Levels deben ayudar a identificar el nivel
adecuado. Por lo general, se puede decir:
Cuanto más alto el Flight Level, mayor el

efecto palanca.
85
Si existe la posibilidad de despegar con una transforma- Si hay que practicar cambios en un sistema existente
ción ágil en el Flight Level 3, se debería hacer. Por ello, el porque se ha torcido, primero se debería ver dónde está
único equipo ágil que realmente es necesario al principio el acceso más rápido. Por experiencia, dicho acceso sue-
para llevar a cabo una transformación ágil o una iniciati- le encontrarse en el Flight Level 2. Y es precisamente
va de cambio es un equipo directivo ágil que asuma la aquí donde comenzamos en nuestra tambaleante em-
gestión estratégica de portafolio. Todo lo demás parte presa.
de aquí – se ha de predicar con el ejemplo.
86
MEJORA 1: Para mí era importante que los implicados entendiesen
DAR VISIBILIDAD A LAS una cosa: el cliente ve que hay valor cuando obtiene el
producto que buscaba. Al cliente no le importa para
DEPENDENCIAS Y nada cómo se organizan o estructuran de antemano las
GESTIONARLAS personas que han desarrollado y entregado este produc-

to. No solo no le importa en caso de quedarse insatisfe-
cho con el producto, sino incluso si le ha encantado el
Al analizar el problema, los equipos se habían dado
resultado. Solo le importa el valor que se ha creado para
cuenta de que había dependencias entre ellos mucho
él. Esta es la razón por la que una iniciativa de cambio
más fuertes de lo que habían considerado durante la
ágil no debería comenzar por una reorganización
preparación de los tableros de los equipos. Además, en
estructural.
el futuro seguiría siendo así, es decir, serían varios los
equipos que trabajarían de forma conjunta en un pro-
Se alcanza Agilidad Empresarial cuando se
ducto, con lo que las dependencias no iban a desapare-
cer. Volvamos a recordar la maraña de dependencias que optimiza la entrega del valor para el cliente.
había reinado entre los equipos durante el desarrollo de Tarde o temprano se hace visible lo que es
productos. necesario modificar en la estructura de la
organización.
87
GESTIONAR DEPENDENCIAS ENTRE Si no se pueden eliminar las dependencias, hay que ges-
EQUIPOS: DESARROLLO DE TABLEROS tionarlas. ¿Cómo abordar entonces dicha gestión?
DE PRODUCTOS
En un primer paso, lo que hicimos fue, sencilla y llana-
Si una cosa tiene que estar clara es que nunca va a ser mente, averiguar qué equipos estaban implicados en el
posible que no exista absolutamente ninguna dependen- desarrollo de cada producto. Para ello no se necesitaba
cia entre los equipos y productos dentro de una organi- ser ningún súper detective ya que, al fin y al cabo, la or-
zación. Más bien debería existir el hábito de eliminar de- ganización estaba definida por productos. En base al nú-
pendencias cuando ello sea posible. La compañía sipga- mero de equipos por producto y al tamaño de los equi-
te, una rentable e innovadora empresa alemana de pos se organizaron talleres con todos los implicados o
telecomunicaciones, tiene, por ejemplo, la visión de lle- bien se enviaron delegados de equipo para participar en
gar a ser una empresa sin dependencias [Mois, Baldauf, la elaboración de tableros de productos.
2016]. Todos son conscientes de que esta visión proba-
blemente no llegue a cumplirse en su totalidad, pero la
ven como una tarea permanente en la que trabajar.
88
Visualización. En primer lugar, Limitación. Si se desea, por

los implicados en cada producto ejemplo, conseguir un Time-to-
reflexionaron sobre cómo este Market más rápido hay que
se había desarrollado, cómo co- limitar las unidades de mayor
laboraban los equipos en el pro- influencia. En el Flight Level 2,
ceso de desarrollo y en qué par- esto significa que no hay que
tes del proceso surgían depen- iniciar más de lo que se pueda
dencias, así como qué dirección seguían estas. El concluir. Los delegados de equipo se tomaron muy en
proceso para cada producto se visualizaba en un tablero serio este punto e intentaron definir juntos el volumen
de productos. En el caso de los equipos pequeños nos de trabajo ideal en el sistema para el Flight Level 2.
dimos cuenta de que esta visualización podría sustituir
al tablero de equipos original porque en el tablero de
productos había mucha más información útil, a menudo Feedback loops. Un tablero de
de mejor calidad. Al mismo tiempo, el tablero de produc- productos común no es suficien-
tos les ofrecía una mejor visión contextual. Por ello, te. El tablero en sí no influye
estos equipos empezaron a establecer sus Standups y mucho, simplemente representa
retrospectivas delante del tablero de productos. Como una situación. Por ello, siempre
pude observar en muchas otras organizaciones, los desaconsejo enfocar toda la
equipos grandes, sin embargo, necesitan a menudo sus materia gris únicamente en la
propios tableros debido a la mayor necesidad de coordi- visualización y diseño de bu-
nación dentro de cada equipo. ffers, carriles e impedimentos.
89
“Gestionar dependencias” significa examinar continua-
mente el contenido del tablero y sacar conclusiones de
lo que se encuentra allí representado. Citaré, una vez
más, a Russell Ackoff:
Así pues, se definieron los correspondientes puntos de Las métricas son un feedback loop ideal y ya se utiliza-
coordinación: ban en esta empresa a nivel de equipo. Ahora se introdu-
jeron también a nivel de producto, lo que fue de gran
En la reunión Standup de productos los delegados de ventaja ya que aquí son muy concluyentes. En primer lu-
equipo se reúnen dos veces por semana delante del ta- gar, a nivel de producto la cercanía con respecto al clien-
blero de productos (por ejemplo, siguiendo el principio te es mucho mayor y, en segundo lugar, las mediciones
de rotación) y coordinan el flujo del trabajo en el nivel de ya contienen todas las dependencias. Las mediciones a
cada producto a través del sistema. nivel de equipo solo pueden representar la cantidad de
trabajo que efectúa un equipo en un determinado perío-
En la reunión de reposición se decide conjuntamente qué
do de tiempo. Sin embargo, si se utilizan mediciones
trabajos son los siguientes en entrar al sistema y, sobre
como el tiempo de ciclo y el throughput en el Flight Level
todo, cuánto trabajo entra en el sistema. Para ello, los
2, se puede determinar cuánto “producto” se desarrolla
delegados reflexionan sobre las personas externas e in-
en un determinado período de tiempo, es decir, cuánto
ternas que deben participar con el fin de conseguir la
de lo que se está produciendo realmente se puede
priorización apropiada. Por cierto, en la reunión de repo-
vender.
sición vuelve a funcionar el principio “deja de comenzar,
comienza a terminar” cuando se está en un sistema de
límites WIP. Esta reunión se ha de celebrar una vez finali-
zado el trabajo; antes de ello no hay nada que reponer.
Durante las retrospectivas entre los delegados de los

equipos estos examinan cómo ha funcionado hasta ese
90 momento la entrega colaborativa del valor y deciden si
se podría mejorar algo. Se eligió la retrospectiva como
formato de reunión porque los implicados ya habían
acumulado experiencia en este sentido a nivel de equi-
po. Este es un punto importante ya que en la mayoría de
las organizaciones únicamente se desarrollan retro
spectivas a nivel de equipo, lo cual impulsa la optimiza-
ción local.
¿Más reuniones aún? 1 No todos tienen que estar presentes. En las reuniones
correspondientes al Flight Level 2 (y también al Flight
Por cierto, el centro de la gestión de dependencias median Level 3) participan los delegados de equipo pertinentes
te tableros de productos no son los tableros. Lo importante para encontrar soluciones rápidas. Así pues, solo algu
es que las personas en cuestión hablen entre ellas sobre lo nas personas tienen reuniones adicionales y tampoco
que ven en el tablero; en eso consiste la interacción. Sin em acuden todos los miembros de los equipos. Estas reu
bargo, al haber diversos productos y Flight Levels, al final niones no son encuentros regulares de varias horas en
surge una marea de reuniones adicionales, multiplicándose los que los integrantes hacen presentaciones intermi
los Standups, las reposiciones y las retrospectivas. ¿Hay nables de Power Point. Hablo de reuniones breves y
que torturar a la gente con todas estas reuniones? Haré dos concisas que duran 15 minutos y que, precisamente por
puntualizaciones: ello, hacen posible que en ellas se tomen las decisiones
más importantes.
1 ¿Se han de respetar todas las reuniones que tenían Tanto si es con o sin reuniones existe la necesidad de coor
lugar antes? He conocido divisiones corporativas con dinar. Para evitar estos encuentros claro que está la opción
más de 2000 empleados donde se eliminaron de forma de intercambiarse miles de correos electrónicos o de poner
radical todos los formatos antiguos de reunión. En su se de acuerdo solo entre algunos equipos o incluso de que
lugar ya solo existen Standups, reposiciones y retro cada equipo siga tomando sus propias decisiones sin con
spectivas. El resto de las reuniones tienen lugar, excep tar con los demás. Pero este tipo de soluciones torpes, más
cionalmente, en determinadas ocasiones cuando aún que conseguir alguna mejora,
queda algo por aclarar más allá de estos tres tipos de lo que hacen es requerir
reunión. coordinación adicional.
91
GESTIONAR DEPENDENCIAS ENTRE Una vez que habíamos elaborado los tableros para cada
PRODUCTOS: GESTIÓN OPERATIVA DE uno de los productos examinamos con atención qué de-
PORTAFOLIO pendencias existían entre dichos productos y nos con-
centramos en aquellos entre los cuales había más de-
En los tableros de productos seguía habiendo una parte pendencias de lo usual. Apuesto a que se imaginarán lo
denominada “esperando respuesta externa”. En contra- que hicimos después.
posición a las zonas de aparcamiento bajo el mismo
nombre que habíamos visto en los tableros de equipos, Estuvimos reflexionando sobre la forma de enfocar y me-
aquí, sin embargo, no significaba que se estaba esperando jorar el trabajo en este flujo de valor, para lo que volvi-
a otro equipo que no había concluido aún su parte del mos a dar los ya conocidos pasos:
producto. Las dependencias entre los equipos implicados
Visualización. Detallamos la metodología de trabajo para
en el desarrollo de productos se gestionaban mediante el
estos productos (el portafolio) en un tablero. De esta ma-
tablero de productos (dependencias intraproducto).
nera, las dependencias entre los productos pasaron a ser
Como se puede fácilmente deducir, estas dependencias
dependencias internas que no tenían que representarse
se redujeron enormemente gracias a una gestión activa.
de forma separada porque eran gestionadas a ctivamente
“Esperando respuesta externa” significaba ahora que había gracias a la comunicación a través de mecanismos de re-
una dependencia fuera del flujo de valor del producto troalimentación, como Standups de portafolio. En la ges-
representado, en general hacia otro producto (dependen- tión operativa de portafolio, las dependencias externas
cias entre productos). Tanto si se trata del nivel de equipo son aquellas conexiones e influencias necesarias que es-
o de producto, las dependencias son un lastre. ¿Cómo se tán localizadas fuera del desarrollo de productos (p. ej.
pueden controlar las dependencias a nivel de producto? las dependencias con respecto a proveedores).
92
Limitación. A continuación, nos aseguramos de que el Si se colocaran los tableros para cada producto en una
sistema contuviese la cantidad de trabajo ideal. A nivel sala, cada tablero tendría una columna a la izquierda que
de portafolio estaríamos hablando, por ejemplo, del se denominaría normalmente backlog. Aquí aparecería
número de Épicas. Sobre todo, lo importante era que el una reserva de trabajos pendientes de ejecución para
trabajo entrase en el sistema siguiendo una secuencia cada producto. Lo ideal es que esta reserva de trabajos
razonable de criterios previamente acordados. Uno de se coloque por orden de ejecución en base a determina-
los criterios más relevantes para la priorización era, dos criterios, como la priorización. No obstante, de esta
según mi opinión, el resultado deseado que se esperaba forma solo se gestionan las dependencias dentro del flu-
de un trabajo. jo de trabajo de un producto.
Feedback loops. De nuevo se crearon oportunidades Si queremos gestionar las dependencias entre varios
para hablar de lo que mostraban los tableros de produc- productos, sería buena idea llevar todos los productos a
tos. De esta forma se podían gestionar bien las depen- un tablero común y, como resultado, dotarlos también de
dencias e identificar oportunidades y necesidades de un backlog común.
mejora. Más concretamente, los feedback loops consta-
ban de retrospectivas y métricas de portafolio. Así, por ¿Qué pasa entonces si cada producto tiene su propio
ejemplo, para la gestión operacional de portafolio era backlog? Si, por ejemplo, concluye un trabajo para el
interesante saber cuántos días había aumentado el tiem- producto 3, el equipo pertinente arrastraría el trabajo
po de ciclo como consecuencia del tiempo de espera por situado en la fila inmediatamente superior y, simple
dependencias externas. En el caso de que aún no está mente, continuaría sin tener en cuenta los flujos de valor
usando métricas orientadas al valor a nivel de equipo, al de los productos 1 y 2. Como se suele decir: ¡Sálvese
menos a nivel de portafolio las mediciones no deberían quien pueda! 93
centrarse en la cantidad que
fue entregada sino en el
outcome económico de la
entrega. ¿Diez funcionalidades
a 1000 euros o una funcionali-
dad a 10 000 euros?
Con un backlog común para diferentes productos se No hay motivo para preocuparse cuando situaciones
debe seguir en todo momento la regla de que hay que como la de que un producto tenga que esperar un tiem-
arrastrar siempre el trabajo situado en la fila inmediata- po por detrás de todos los demás se dan solo de vez en
mente superior. Entonces puede ocurrir el caso de que cuando. Prestaría mayor atención si esta situación suce-
se concluya un trabajo para el producto 3 pero que el diese a menudo, lo cual podría ser un indicador de que el
trabajo con mayor prioridad en el backlog común perte- conocimiento en la organización no está repartido de
nezca al producto 1 porque, desde el punto de vista em- forma óptima para tratar las prioridades empresariales.
presarial, este sea más importante. Por consiguiente, Lo que vemos aquí vuelve a ser ejemplo de suboptimiza-
aquellos equipos que trabajan en el producto 3 estarían ción local vs. optimización global a un nivel más alto. Si
durante un tiempo sin nada que hacer. cada producto tiene su propio backlog, la distribución
desigual del conocimiento en la organización no se per-
La primera pregunta que nos deberíamos plantear ante cibe. Los equipos de productos se optimizan solo en su
tal situación sería: “¿Podemos ayudar a otros equipos?” propia área, lo que no ha de ser necesariamente lo mejor
Probablemente esto no sea posible porque quizás en los para la totalidad de la organización.
equipos se aplican tecnologías diferentes. En este caso,
la alternativa sería que el equipo “en paro”pudiese tra- La ventaja del backlog común en la gestión de varios
bajar mientras tanto en realizar mejoras o tratar asuntos productos es que este tipo de anomalías se hacen visi-
para los que nunca suele haber tiempo. bles y dan opción a preguntarse si la estructura de por-
tafolio existente fomenta o ralentiza el éxito empresa-
rial. La cuestión es la siguiente:
94
Independientemente de si visualiza la situación o no, su En el caso de esta empresa no conseguí que adoptaran
empresa se encuentra de una manera u otra en esta si- mi propuesta de backlog común y tampoco pasa nada.
tuación. Prefiero entonces situarme siempre frente a los No obstante, la idea se encuentra en el banco de ideas
problemas, puesto que solo así se activa el cerebro en de cara a futuras mejoras.
modus “búsqueda de soluciones”.
95
96
MEJORA 2:
INTEGRAR EL UPSTREAM
Agilidad Empresarial significa que una empresa se sabe Como es tan bonito, querría volver a recordarles la ima-
adaptar a los cambios en el mercado y a las exigencias gen de un flujo de valor real en esta empresa. Al exami-
de sus clientes. Cuando la respuesta de una empresa se nar más a fondo lo que pasaba en el upstream se veía
limita a la agilización de un departamento o incluso de cómo se acumulaba un proceso de revisión y aprobación
solo algunos equipos es que no ha entendido el desafío. tras otro antes de que los colegas de desarrollo pudie-
Por supuesto que se pueden aplicar prácticas ágiles úni- sen empezar a trabajar.
camente en el desarrollo de productos, pero esto solo
tiene un efecto limitado, tal y como hemos visto en esta
empresa. Si los equipos ágiles chocan con los límites de
una organización que no es ágil en su totalidad, se que-
darán estancados en algún punto y no podrán alcanzar
los objetivos fijados. Así será más fácil apuntar a un cul-
pable, aunque esto no ayudará en absoluto a la empresa
ni a sus clientes.
97
LAS TRES TRAMPAS DE TIEMPO EN 1. LOS PRESUPUESTOS ANUALES

EL UPSTREAM: DEMASIADO CREAN LOTES DEMASIADO G
RANDES
TRABAJO, DEMASIADO EXACTO,
DEMASIADO INNECESARIO Una vez al año tiene lugar en las organizaciones la gran
batalla de los presupuestos. La dirección tiene que apro-
El hecho de que el proceso de upstream incluyese mon- bar o rechazar las ideas basadas en los conceptos pre-
tones de pasos no sería nada malo de por sí si estos pa- sentados. Este conjunto de ideas reunidas durante un
sos fuesen rápidos. En el caso concreto de nuestra em- largo período de tiempo mata cualquier Agilidad Empre-
presa, transcurrían varios meses entre las reuniones de- sarial, por no decir que la realidad casi nunca se atiene a
lante del tablero, donde se juzgaban y evaluaban ideas. un plan anual. Con los presupuestos anuales solo se pue-
Con toda probabilidad, estos pasos se habían implanta- de reaccionar una vez al año. Imaginémonos esto en un
do en algún momento con la mejor intención y tampoco tablero a nivel de portafolio. Todo lo que se encuentra
se trataba de eliminarlos de un plumazo. dentro de las opciones elegidas en el backlog pasa el 1
de enero a la columna de “compromiso”, o sea, se tiene
Por lo general, es mejor examinar este tipo de procesos que implementar. El 01.01 queda fijado lo que se ha de
preliminares para averiguar lo que realmente es redun- entregar el 31.12. A pesar de ello, se tortura a los equipos
dante y lo que eventualmente se podría acortar o resu- con inútiles discusiones sobre métodos y exigencias
mir. Básicamente, me encuentro con tres problemas a la como “tenéis que hacer backlog groomings, limitar vues-
hora de ampliar el flujo de valor en el upstream. tros WIP y trabajar con Sprints”. Si ya se ha decidido lo
que se tiene que entregar, resulta totalmente redundante
todo este polvo de hadas ágil que no tiene absolutamen-
98 te ningún efecto, especialmente en lo que se refiere a la
Agilidad Empresarial. Por ello, la agilidad de los equipos
no tiene nada que ver con la Agilidad Empresarial.
Cuando hablamos de Agilidad Empresarial nos

referimos a las entrañas de la organización. Los
tiempos de reacción se han de acortar y se ha
de comenzar por un nuevo proceso de presu-
puestación, es decir, “reposición”. A modo de
ejemplo, si se quiere poder reaccionar a los cambios
de forma mensual, debería haber también intervalos de
reposición cada mes. ¡Esto no significa que cada mes
haya que empezar algo nuevo! Aquí también rige el prin-
cipio de que primero hay que entregar y tener en cuenta
los límites WIP durante la reposición. El truco está en
desmenuzar bien los trabajos para que puedan generar
valor en el mercado a la mayor brevedad posible.
2. COLEGAS QUE HACEN DE

PROVEEDORES
Asimismo, lo que a menudo impide que haya Agilidad de un instituto financiero. Tardaron cinco días en eva-
Empresarial es la relación entre los diferentes departa- luar que el departamento de IT necesitaba un día para
mentos de la empresa. De forma similar a una relación implementar una característica determinada. Lo mismo
con proveedores, los departamentos, a modo de de siempre: estimación de precios. Costó 80 000 euros
ejemplo, dan “un encargo” al departamento interno de estimar que el precio de una funcionalidad era de 30
IT y quieren saber con exactitud lo que les va a costar. 000 euros. Una vez aprobado el encargo, el departa-
Esto conlleva un lento proceso basado en estimaciones, mento se retira, deja trabajar a los proveedores inter-
aprobaciones y nuevas estimaciones, como ocurre en el nos y se vuelve a interesar cuando hay un resultado.
caso de los encargos solicitados externamente. En Todo menos ágil, ya que de otra forma estaría claro que
primer lugar, el papel empleado sale demasiado caro dentro de la misma empresa en realidad se trabaja
porque, al final, la estimación se desestimará. El ejem- conjuntamente en la búsqueda de soluciones para los
plo más representativo que me viene a la mente es el clientes externos.
99
3. ESTIMAR ALGO QUE DE TODAS

FORMAS SE HA DE HACER
No solo se produce una desmesura de estimaciones so- No defiendo la idea de no realizar ninguna estimación.
bre lo que se quiere hacer, sino, irónicamente, también Pero lo que sí creo es que el esfuerzo invertido en las es-
de lo que se tiene que hacer. Los directivos de un institu- timaciones necesita ajustarse a determinados límites si
to financiero me relataron que, de acuerdo con la norma- queremos que la empresa se vuelva ágil. Una estimación
tiva interna de la empresa, tuvieron que estimar con debe ser tan exacta como necesaria y no lo más exacta
enorme precisión el coste de una determinada medida. posible. Para poder tomar decisiones a favor o en contra
“Estimamos 567 300 euros”, me dijeron, llenos de orgullo. de una idea, lo único que se necesita es una magnitud
No me pude contener y les pregunté si implementarían aproximada. Solo se sabrá si una idea tiene futuro o no
la medida tanto si costaba 10 000 euros como si costaba cuando se muestre al cliente algo que pueda valorar.
diez millones. “Naturalmente, tenemos que hacerlo por-
que es un requisito legal”.
100
UN MEJOR TIME-TO MARKET

GRACIAS A DECISIONES FRECUENTES
Y A UNA MEJOR COLABORACIÓN
Basada en los procesos de upstream, Agilidad Empresa-
rial significa: Estuvimos hablando con los colegas implicados en el
upstream en el “área de negocios”. Enseguida entendie-
1 que las reposiciones tienen lugar según el principio ron que se desperdiciaba un tiempo muy valioso en los
pull y respetando los límites WIP (¡!) y se desarrollan procesos de decisión y estaban dispuestos a simplificar
en apropiados ciclos que ajustan el nivel deseado de algunas cosas. Hasta ese momento, se preseleccionaban
Agilidad Empresarial; las ideas nuevas una vez al mes; seguidamente, las ideas
escogidas se escribían en casos de negocio, siendo apro-
1 que una estimación de magnitudes aproximadas badas o rechazadas de forma trimestral. Finalmente, la
basta para empezar;
aprobación de los conceptos detallados solo tenía lugar
una vez al año.
1 que no solo se estiman los costes y el trabajo sino,
sobre todo, el beneficio y los ingresos;
Volví a visualizar en un tablero los pasos anteriores del
proceso de preselección con los representantes del up
1 que un concepto ocasiona el mínimo gasto posible
de papel y, en vez de eso, permite resultados reales a stream y estuvimos discutiendo sobre lo que realmente
la mayor brevedad posible; era necesario. Tras algunas discusiones resultó que a los
representantes les bastaba tener conceptos generales
1 que se implica al cliente lo antes posible en cualquier para poder decidir si una idea debía ser implementada o
parte del proceso de desarrollo. no. El objetivo mismo de la implementación era implicar
101
al área de negocio de forma mucho más estrecha que
Si después resulta que, tras un período de tiempo pre antes, por ejemplo, mediante la participación en los
determinado, una idea no va en la dirección correcta, Standups, con el fin de poder reaccionar antes en el caso
¡estupendo! Si se da el caso contrario, ¡también genial! de que un desarrollo no fuese por el buen camino.
Así no habremos gastado el dinero en estimaciones, sino
que habremos desarrollado una parte del producto y De los cinco pasos originales en el upstream quedaban
habremos aprendido algo. finalmente solo dos: “Caso de negocio general” y “espe-
rando aprobación”. Nos pusimos de acuerdo para que la
La cuestión no es cuántos pasos abarca una aprobación o el rechazo de los conceptos generales tu-
cadena de valor en el upstream sino qué viese lugar cada dos semanas, por supuesto, siempre
que los límites WIP en la implementación lo permitiesen
velocidad alcanzan dichos pasos hasta llegar
al haberse concluido el resto de los trabajos. Desde mi
a las unidades de valor evaluables (ideas, punto de vista, esta fue una de las decisiones más im-
conceptos, etc.). portantes que haría posible en el futuro la Agilidad Em-
presarial en esta compañía.
102
Sin embargo, el factor tiempo era para mí solamente un 1 Adicionalmente, se introdujeron retrospectivas con-
aspecto. Por supuesto que la toma de decisiones a un juntas de forma regular.
ritmo bisemanal en lugar de anual influye enormemente
en el Time-to-Market. Pero aquí había ocurrido algo mu-
1 Se eligieron métricas que mostraban una imagen
exacta del número de proyectos y de productos que el
cho más importante y es que se había creado una visión
conjunto de la organización podía conseguir, desde la
integrada del desarrollo de los productos. Ya no existía
idea hasta la conclusión, así como del tiempo que se 103
lo de aquí el negocio y allí el desarrollo. Estas áreas se
necesitaba para ello
habían fundido y trabajaban juntas en el mismo bando
para que la organización fuese capaz de sobrevivir y los Agilidad Empresarial significa conseguir la
clientes pudiesen obtener mucho antes lo que realmente
mayor rapidez posible desde la idea hasta la
necesitaban.
entrega al cliente. Esto funciona si una
Este crecimiento en equipo se apoyaba, sobre todo, en organización no está dividida en grupos de
los feedback loops, los cuales tenían lugar de forma re-
personas dando órdenes y grupos de personas
gular entre las diferentes áreas de especialización y el
desarrollo de productos en el departamento de IT: ejecutando órdenes, sino que, en lugar de ello,
se ocupa de hacer desaparecer progresiva-
1 Los Standups se desarrollaban ahora con los repre- mente la delimitación entre “nosotros” y
sentantes de las áreas de especialización delante de
los tableros de productos. “los otros”. La superación y eliminación de
dependencias recíprocas puede contribuir al
crecimiento cohesivo de la organización.
La multidisciplinariedad
no tiene nada que ver con la
estructuración de los e
quipos
Todo esto suena muy romántico, ¿verdad? Pero, en realidad, En primer lugar, esta competición debe desaparecer, lo que
nos encontramos ante un enorme cambio. Y es que… ¿por seguro no será tan fácil tal y como se puede deducir del
qué deberían de unirse las áreas de especialización? ejemplo de esta empresa. Se trata de un proceso cultural
que comienza ya en la fase de reclutamiento: “No contrate
La delimitación entre “nosotros” y “los otros” es un proble habilidades, contrate actitud”, esta debería ser la máxima.
ma fundamental que ha evolucionado históricamente y que Claro, el conocimiento técnico es importante, pero también
surge en cualquier tipo de organización. Su origen son los es mucho más fácil adquirir competencias técnicas que mo
grupos escindidos que se suelen organizar por áreas de dificar una actitud. Los equipos multidisciplinares no son
especialización, separándose entre sí y con respecto a toda para nada el Santo Grial de la agilidad, mediante el cual
la organización. Las peticiones y los resultados, por lo ge desaparecen, por arte de magia, todos los puntos de fric
neral, se “entregan” (o, más bien, se lanzan) a otras unida ción de tipo social que existen entre las unidades de rendi
des cuyos puntos de vista y exigencias puede que sean to miento de un flujo de valor; a veces, simplemente, se trasla
talmente distintos a los del propio departamento. Las áreas dan de lugar. Reunir distintos enfoques dentro de un mismo
especializadas actúan de forma provocadora con respecto equipo es, al menos, mejor que centrarse en rendimientos
al desarrollo de productos, los desarrolladores de software individuales o en el rendimiento individual de cada silo
son mejores que los tester de software, las áreas de espe especializado. Si hablamos de centrarnos en la generación
104
cialización observan a todos los demás simplemente como de valor integrado y orientado al cliente estamos ante una
proveedores, y así sucesivamente. diminuta gota en medio del inmenso océano.
El intento de agilizar una empresa no necesariamente supo La multidisciplinariedad es una mentalidad empresarial y
ne que esta mejore. Los equipos multidisciplinares son ge no una estructuración organizacional de los equipos. Signi
niales e importantes, lo cual no significa que desaparezcan fica poder crear un entorno en el que esté bien, o incluso se
antiguos prejuicios. Ahora tenemos a un equipo multidisci desee, trabajar con un rendimiento bajo a nivel local siem
plinar A que rinde más que el equipo multidisciplinar B. En pre y cuando ello sea útil para el rendimiento global de la
lugar de silos funcionales, ahora tenemos silos multidisci organización. Es decir, no basta con que todos los emplea
plinares. ¡Felicidades! Al reducir dependencias y reunirse los dos estén agarrados a la misma cuerda, también tienen que
equipos por productos, el producto Y, naturalmente, será tirar en la misma dirección.
más estúpido que el producto Z. Y visto desde la perspecti
va del portafolio, arriba hay solo imbéciles integrales. Los
bonus van de maravilla para consolidar las aversiones e in
cluso agravarlas. De esta forma solo se optimizan partes
sueltas de una organización, no importando para nada la
creación de valor para el cliente.
105
MEJORA 3: Sin embargo, involucrar a la alta gestión no siempre r esulta
GESTIÓN ESTRATÉGICA fácil. El costoso conocimiento de los estudios de ADE está

muy arraigado en sus cerebros. Pero una empresa ágil no
DE PORTAFOLIO necesita administradores de empresas a la cabeza de la
organización sino líderes empresariales. Si la participación
La Agilidad Empresarial no funciona cuando en una orga- de la alta gerencia fracasa, suele ser por una falta de capa-
nización surgen islas ágiles mientras que la lógica de los cidad y disposición a la reflexión crítica. Muchos altos eje-
procesos de alrededor permanece igual y determinados cutivos viven, a menudo de forma involuntaria, en un ver-
grupos se excluyen a sí mismos de la realización de prác- dadero celibato de formación continua. Esto se debe a que
ticas ágiles. La Agilidad Empresarial comienza desde muy ellos, en contraposición a los deportistas de élite, se en-
arriba ya que sigue siendo la alta gerencia quien, en la cuentran en un estado constante de competición y no se
mayoría de las organizaciones, asume la responsabilidad toman tiempo para el aprendizaje, es decir, para adquirir
de tomar las decisiones de tipo estratégico. En el escena- las aptitudes necesarias de cara a competir, lo cual puedo
rio ágil son muchos los que defienden la opinión de que entender en muchos casos. Muy a menudo, los gerentes
las organizaciones han de gestionarse sin ninguna jerar- van de reunión en reunión, están totalmente sobrecarga-
quía. Para mí está fuera de discusión el hecho de que mu- dos y reciben presión por todos lados. A pesar de todo
chas organizaciones son demasiado jerárquicas; sin em- esto, son ellos los que deben hacer de pilotos en este viaje
bargo, no pienso que se pueda funcionar sin ningún tipo ágil para evitar que no sea solo dinero lo que se lance por
de gestión. Hasta la decisión “trabajamos sin jerarquías” la borda en el abismo de la suboptimización local.
ha de ser tomada por alguien, y no creo que ese alguien
La ilusión de tener una capacidad más rápida de respuesta
sea la persona encargada del mantenimiento del edificio.
en el mercado aumenta y, a pesar de ello, aún se siguen ce-
106
lebrando las rondas presupuestarias anuales. Lo que debe-
ría pasar y lo que pasará a lo largo de un año se evalúa des-
de la perspectiva de un determinado momento en el tiem-
po. Posteriormente, se desencadena una enorme ola de
dinero y proyectos que debería repartirse en calmados ríos,
lo cuales, a su vez, deberían empujar a la orilla nuevas ideas
y productos. En la naturaleza, cuando las olas gigantes se
adentran en el interior de la tierra no provocan más que de-
vastación. Dentro de la organización, esto genera un ciclo
agotador. Cuando la ola alcanza los departamentos, estos se
encuentran, normalmente, con poco personal y saturados.
Cuando la ola se retira, hay muchos empleados alrededor
que se quedan de brazos cruzados y esperan a que llegue la
siguiente ola gigante. Lo importante es que a principios de
año todos saben ya en lo que no trabajarán la tarde del 17
de agosto, o sea, en lo que pone en el plan anual.
Una verdadera Agilidad Empresarial integra

el upstream y el downstream en una única
cadena de valor con el fin de generar un flujo
de trabajo rápido y constante. Dicho de
otra forma, estrategia, operaciones,
desarrollo y entrega trabajan en
estrecha colaboración y, sobre
todo, con el mismo fin. Para que
esto funcione, la alta gerencia ha
de encontrarse también a bordo.
107
¿CÓMO FUNCIONA UNA GESTIÓN En un sistema organizacional, únicamente la relación

ESTRATÉGICA DE PORTAFOLIO? existente entre las iniciativas empezadas y las conclui-
das tiene un efecto directo en el Time-to-Market. La ges-
El motivo de que en nuestra empresa el Time-to-Market tión estratégica de portafolio tiene como tarea mantener
no funcionase como se había planificado estaba muy el equilibro correcto en dicha relación y orientar estas
claro. Mientras que los equipos de desarrollo habían li- iniciativas según la estrategia general. Para orientar el
mitado su Trabajo en Curso de la mejor forma posible y, trabajo de toda la organización según la estrategia, la
sobre todo, dejándose la piel en ello, a nivel estratégico alta gerencia debe estar dispuesta a comunicar a los em-
se seguía iniciando alegremente una iniciativa tras otra. pleados, de forma explícita e inequívoca, tanto la estra-
Y esto mismo es lo que ocurre en muchas empresas que tegia como cada una de las iniciativas que van surgiendo
quieren volverse ágiles. Esta forma de proceder provoca en la organización. Por ello, al igual que en los otros
dos circunstancias: confusión y saturación. Echemos la Flight Levels, también con la alta gerencia establezco los
vista atrás: ya conocidos tres pasos con el fin de poner en marcha la
gestión estratégica de portafolio:
1. isualización. Todas las unidades que generan valor

V
en la organización se llevan a un tablero común. En el
Flight Level 3 se trata, básicamente, de proyectos o
iniciativas. Se comunica de forma explícita cómo se
trabaja en estas unidades mediante cuestiones
como: en qué criterios se basa la evaluación de las
ideas relativas a los proyectos, qué aspectos aportan
108
algo a la estrategia y cuáles no aportan nada, cómo
son los procesos de selección y de decisión y cuándo
se considera, por ejemplo, que una iniciativa ha sido
exitosa, de dónde salen las ideas y propuestas de las
iniciativas o en qué se está trabajando y dónde den-
tro de la empresa.
2. Limitación. En un segundo paso, se ha de encontrar

la cantidad óptima de unidades generadoras de valor
que la organización puede soportar. A nivel de estra-
tegia, “unidad generadora de valor” significa que
cuando el proyecto o la iniciativa ha concluido y ate-
rriza en la última columna del tablero, se debería po-
der ver allí el resultado alcanzado en el mercado. Una
vez que los proyectos o iniciativas han concluido en
este sentido y siempre que el WIP lo permita, podrán
comenzar otros nuevos.
3. F eedback Loops. Si toda la organización se orienta El diseño concreto de estos pasos puede, debe
según la estrategia, también los representantes de y ha de ser distinto en cada organización.
cada nivel han de integrarse en el ciclo desde el pro-
También se modificará a lo largo del tiempo
ceso de búsqueda de decisiones hasta la medición
de éxitos. Por esta razón, todos ellos participan en en base a las necesidades de la empresa y de
Standups y retrospectivas. Asimismo, en la gestión sus clientes.
estratégica de portafolio rige el mismo principio que
en el resto de niveles: pintar una vez en el tablero de
estrategias no es suficiente. El truco está en ver las
oportunidades de mejora y establecer las medidas
necesarias, lo cual no significa mejorar el tablero
sino el trabajo a nivel estratégico.
109
EL TABLERO DE ESTRATEGIAS Observemos primero la parte izquierda del tablero de

estrategias que he creado junto con la alta gerencia de
Llegados a este punto, reitero: aquí no muestro el esta empresa. Perfectamente visible, a la izquierda del
tablero de estrategias que se puede implementar en todo, se escribió de forma breve y concisa la estrategia
todas las empresas de este mundo y del universo. Aquí empresarial, mientras que en la siguiente columna se
muestro un tablero de estrategias que se adecuaba desglosaron las métricas de la empresa. Si la estrategia,
únicamente a esta empresa y en un contexto único y por ejemplo, decía que la cuota de mercado en Asia de-
concreto. bía de aumentar, la correspondiente métrica “cuota de
mercado Asia” tenía que ser capaz de reflejar clara
Puede servirle de inspiración, pero… mente estos cambios. A partir de ese momento, en los
¡copiar está expresamente prohibido! tickets de los proyectos e iniciativas que se desplazaban
por este tablero se hacía siempre constar la métrica
estratégica empresarial sobre la que se debería ejercer
influencia. Así es como se alcanza la orientación estra-
tégica de la organización. Ahora está claro para todos
no solo en lo que trabajan sino, sobre todo, por qué se
trabaja en ello.
110
Independientemente de ello, los principios en los que se Finalmente, describimos en el tablero los pasos a seguir
basa la creación de un tablero a nivel estratégico son los para los distintos tipos de trabajo. La parte más emocio-
mismos que para el resto de los niveles. Primeramente, nante se desarrolló en la zona derecha del tablero. Per-
identificamos qué tipo de trabajos hay que realizar en la mítanme una breve interrupción: la diferencia funda-
gestión estratégica de cartera. En un segundo paso, nos mental entre la gestión operacional cartera y la gestión
planteamos la cuestión de cómo se han de ejecutar es- estratégica de cartera es el horizonte temporal. Mientras
tos trabajos. que en el marco operacional todo gira alrededor de lo
que se está implementando ahora, la estrategia también
Junto con la alta gerencia habíamos identificado dos trata con lo que va a suceder en un futuro. Naturalmente,
tipos de trabajos: esto supone un gran desafío ya que la mirada hacia el
futuro a veces está llena de contradicciones. ¿Por qué
1 Las iniciativas eran las responsables de traer dinero a hemos de apostar? ¿Por lo que ahora mismo nos trae di-
la organización, es decir, esencialmente productos y
nero o por las medidas que tal vez den fruto dentro de
soluciones para los clientes.
algunos años? Es necesario tomar en consideración estas
reflexiones en la gestión estratégica de portafolio. Por
1 Las inversiones definían proyectos no urgentes pero
necesarios que no tenían ningún beneficio directo consiguiente, en este nivel se considera más el outcome
para el cliente pero que ejercían una influencia de que el output. En la gestión estratégica de portafolio se
fondo. Así, por ejemplo, un cliente de Netflix no com- considera el outcome en vez del output.
pra un software de automatización de pruebas sino
un servicio de streaming que no le dé problemas. Ya
se encarga Netlix de la infraestructura necesaria.
111
En la mayoría de los tableros de este mundo, tras colum- ¿De dónde venían, en realidad, las ideas para los proyec-
nas denominadas, por ejemplo, “en desarrollo” se en- tos e iniciativas en esta empresa, o sea, para “los gene-
cuentran otras con términos lapidarios como “concluido” radores de dinero?” En gran parte provenían de los equi-
o “done”. En esta empresa era distinto. El término “con- pos, ya que estos eran los que se encontraban más cerca
cluido” servía para designar un proyecto o una iniciativa del cliente y conocían mejor sus necesidades. Por esta
una vez que con ello se había alcanzado lo que se tenía razón, la mayoría de las veces los equipos evaluaban ya
que alcanzar. Para averiguarlo es necesario el empleo de en los casos de negocio generales lo que se podía alcan-
métricas, así como la obtención de feedbacks por parte zar con la implementación de una idea o qué métricas
de los clientes y usuarios de un producto. Es posible que empresariales se podían mejorar. Asimismo, estos casos
haya que practicar posteriormente modificaciones deri- de negocio tenían que estar diseñados de forma que fue-
vadas de los feedbacks. Por ello, tras la fase de desarro- se posible decidir en 90 días si la probabilidad de que se
llo, aún había tres columnas en el tablero estratégico de alcanzase un resultado en cuanto a la capacidad de res-
esta empresa: “medir y mejorar el éxito”, “ajustar y mejo- puesta en el mercado era o no alta. Es decir, la idea no
rar” y “resultado (no) conseguido”. tenía que ser implementada en su totalidad en 90 días,
sino que tras este período de tiempo se debía entrever
una tendencia al éxito. Los casos de negocio generales
se llevaron al banco de ideas evaluadas, donde empeza-
ron a confluir cada dos semanas todas las personas que
aportaban ideas con el fin de discutir con el resto de co-
legas sobre los pertinentes ajustes estratégicos.
112
FEEDBACK LOOPS EN LA GESTIÓN En nuestra empresa, la alta gestión participaba en los

ESTRATÉGICA DE PORTAFOLIO Standups junto con los representantes de la gestión
operacional de portafolio del Flight Level 2. Se había pla-
Los formatos de reunión en la gestión estratégica de neado que estas reuniones tuviesen lugar cada dos me-
portafolio son los mismos que en el resto de los niveles. ses, pero ya durante el primer Standup cambiaron bas-
Primero estaría el Standup estratégico de portafolio en tante los planes. En el tablero se acumuló tanta informa-
el que tienen lugar actualizaciones para averiguar cómo ción que uno de los gerentes soltó al momento: “Cada
avanzar con los proyectos y las iniciativas en la organizados meses no tiene ningún sentido”. No podía estar más
ción, así como dónde existe, dado el caso, necesidad de de acuerdo con él; sin embargo, mi afirmación durante la
actuar. Aquí lo que se hace, por decirlo de alguna mane- consabida ronda presupuestaria anual provocó gran es-
ra, es, a través de los correspondientes representantes, tupefacción: “Creo que deberíais reuniros al menos una
subir información de los Flight Levels 1 y 2 y llevar de re- vez por semana, o más bien dos. Incluso después de ha-
greso a la organización las decisiones que han sido to- ber procesado esta ola.”
madas teniendo en cuenta la estrategia. Así es como
funciona un alineamiento estratégico continuo.
113
Tal vez se pregunte el porqué de una cadencia tan corta. Las reuniones importantes deberían celebrarse con asiduidad
El Standup estratégico de portafolio es una reunión du- A los empleados de las organizaciones les gusta quejarse de las
rante la cual se toman (o se deberían tomar) decisiones reuniones; ello tiene que ver, en parte, con la manera de organi
precisamente cuando estas son necesarias. Recordemos zarlas. Pero también observo de cerca con qué asiduidad se
celebran realmente las reuniones importantes. En general, resulta
el resultado obtenido cuando los gerentes tomaban de- que los intervalos son demasiado largos. Las decisiones tomadas
cisiones de forma aislada (véase parte 2): se inician cons- durante estas reuniones pierden valor porque la gente se ve
tantemente más proyectos de los que la organización obligada a tomar constantemente decisiones (aisladas) entre
reunión y reunión.
soporta. Cuanto mayor es el intervalo entre los Standups
de estrategia, mayor es el peligro de caer en esta tram-
pa. Incluso si se realizan reuniones en intervalos men-
suales, la probabilidad de que tras una semana sea ne-
cesario volver a tomar una decisión urgente es muy alta,
con lo que la tentación de no esperar hasta el siguiente
Standup es grande. Esperar volvería a ser cualquier cosa
menos ágil.
Recomiendo mantener Standups estratégicos

de portafolio cada semana para poder tomar
las decisiones necesarias de forma puntual y
en el contexto del proyecto en curso.
114
Las retrospectivas también tienen como misión mejorar Al igual que indico en otros puntos de este libro, les rue-
la colaboración a nivel de gestión estratégica de porta- go, por favor, que no se dediquen simplemente a copiar
folio. Sirven para que aquellas personas que trabajan los intervalos de las reuniones, independientemente del
con el tablero de estrategias se reúnan regularmente nivel del vuelo. No existen reglas universales para ello,
para pasar revista de los sucesos acaecidos durante un aunque sí me gustaría darles la siguiente indicación:
período de tiempo. Nos referimos aquí a la alta gerencia
y a los representantes de los Flight Levels 1 y 2. Acorda- Al principio tiene sentido asistir más a menu
mos que las retrospectivas debían tener lugar una vez al do a cada una de las reuniones y talleres para
mes. Como lector/a atento/a seguro que habrá notado
hacerse una idea de cuál es la frecuencia
que para mí las retrospectivas en todos los niveles de la
organización son algo genial. Cliff Hazel de Spotify dice ideal. Pero no organice reuniones que ocupen
en una entrevista que mantuve con él que, si pudiese in- toda la tarde; estamos hablando de 15 minutos
troducir solamente una cosa en una empresa, serían re- por reunión si, por ejemplo, esta tiene lugar
trospectivas. Ellas son el motor de una organización en
dos veces por semana.
proceso de aprendizaje, o sea, de una organización ágil.
Finalmente, acordamos también una revisión de estrate-

gias de forma regular. Si en alguna parte es importante
que las cosas se hagan bien, eso es a nivel de estrategia,
ya que la organización no debe perder demasiado tiem-
po con temas que no llevan a ningún sitio. Por tanto, los
puntos importantes de la revisión se referían a cuestio- 115
nes tales como en qué nivel de desarrollo se encontraba
la empresa, cómo había cambiado la posición en el mer-
cado y el mercado en sí, cómo se comportaban los com-
petidores o si la estrategia debía ser modificada a conse-
cuencia de eventuales cambios. En un principio, llegamos
al acuerdo de celebrar la revisión de estrategias en un
intervalo trimestral.
La empresa sigue su camino. Si alcanza o no los objetivos

que se ha fijado depende ahora de cómo de grande es la
tentación de volver a caer en antiguos hábitos y formas
de pensar. Pero al menos habíamos sido capaces de
crear unas condiciones fundamentales junto con las per-
sonas del equipo de transición que habían mostrado su
compromiso.
116
117
Naturalmente, aún quedaban algunas cosas que se podían modificar en esta empresa. Pero mi trabajo había terminado por
el momento. El hecho de que hubiésemos sido capaces de establecer las mejoras más importantes en el Flight Level más
alto me hacía confiar en que esta empresa podía seguir sola de aquí en adelante. El mensaje había sido captado:
118
LA AGILIDAD EMPRESARIAL NO ES UN DEPORTE

DE EQUIPO, ¡ES UN DEPORTE DE EMPRESA!
119
PARTE 4
El resultado
¿Cuál fue el
resultado final?
Acerca de objetivos finalmente
alcanzados, métricas empresaria-
les satisfactorias y un camino
que no tiene final.
120
PARTE 4 | EL RESULTADO
121
122
A
pesar de pertenecer a la categoría de Tres años después de haber conseguido juntos remontar
“consultor de empresas”, siempre me re- el fallido intento de transformación, fui invitado por la
sulta un placer llegar a no ser necesario. dirección para ver el desarrollo que la empresa había
En general, se requiere mi ayuda en dos experimentado desde aquel momento. Y me gustó mucho
tipos de situaciones; bien cuando una lo que escuché.
empresa da los primeros pasos en dirección a una mayor
Agilidad Empresarial o cuando ya ha recorrido un buen TIME-TO-MARKET REDUCIDO, ¡BRAVO!
tramo sola y tropieza. En ambos casos suelo seguir en
contacto con la empresa o con la gente una vez que he Ser más rápido en el mercado era el gran objetivo de la
completado el trabajo preliminar. Continuamente me empresa y por lo que había luchado muchísimo. Tres
encuentro con empleados, por ejemplo, en conferencias, años más tarde, al fin había cambiado todo. Las iniciati-
que me cuentan cómo ha seguido la cosa. A veces también vas concluían ahora una media de siete meses antes,
solicitan mi opinión con respecto a alguna medida pre- alcanzando así más del doble de rapidez. El objetivo del
vista o incluso me invitan después de un tiempo a un Time-to-Market más rápido había movido otras piezas
taller de mejoras. del puzle, lo que hacía que estuviese mucho más claro
qué otras cosas había que cambiar también para alcanzar
Y así fue el caso de esta empresa. Una vez que habíamos el objetivo. El efecto secundario positivo fue que, gracias
establecido los pasos fundamentales que he descrito en a la observación precisa de las debilidades que se iban
este libro, la dirección y los empleados continuaron haciendo visibles, se habían producido importantes
básicamente solos. Habían entendido lo que se necesitaba mejoras en otras áreas.
para alcanzar la Agilidad Empresarial y qué mecanismos
estaban implicados. Cuando surgían problemas no se DE NUEVO A LA CABEZA DE
lanzaban a lo loco a hacer “seudoagilidad”, sino que LA INNOVACIÓN
primeramente examinaban las causas e intentaban
entender la correlación con el fin de poder así encontrar Tres años antes ya había signos de que las start-ups, con
soluciones individuales para la empresa en lugar de su fuerza innovadora, echarían fuera del mercado a esta 123
emplear recetas ya hechas. Los empleados con los que empresa consolidada. Una vez que habíamos creado el
hablé durante los meses siguientes a mi aportación me tablero de estrategias se nos ocurrió una idea simple
contaron que en la empresa se había puesto en marcha pero eficiente durante una de las usuales reuniones de
un profundo cambio cultural. Dijeron: “Hemos alcanzado mejora: para cada nueva iniciativa se aclararía, mediante
mucho, pero, entre tanto, sabemos que nunca llegare- un código en color, si el outcome ayudaría a diferenciarse
mos al final. El desarrollo siempre continúa”. de la competencia o si solo se conseguiría estar a su ni-
vel lo más rápidamente posible. Al principio, el ratio en-
tre innovación y productos “yo también” era cualquier
cosa menos tranquilizador. Sin embargo, tres factores
determinantes comenzarían a modificar el rumbo de las
cosas:
1. Toma más rápida de decisiones. Una de las primeras Por cierto, gracias a los feedback loops a lo largo de di-
medidas tomadas había sido, por un lado, acortar de versos Flight Levels y a la toma rápida de decisiones es-
forma radical el exageradamente extenso proceso de tratégicas, se puso en marcha un proceso cultural. La
toma de decisiones que tenía que transcurrir antes empresa era anteriormente una aglomeración de silos.
de que la gente de IT pudiese comenzar a trabajar. En un lento proceso dirigido de forma centralizada, los
Hoy día, las buenas ideas ya no permanecen almace- silos empresariales aislaban su innovación y la empuja-
nadas, sino que se implementan más rápidamente, ban a los silos de IT, donde se efectuaba la implementa-
bajo consideración de los límites WIP y de la orienta- ción. El departamento de IT quedaba relegado a un sim-
ción estratégica. Por otro lado, también había sido ple papel de proveedor, un centro de costes.
necesario sustituir la toma de decisiones difíciles,
llevada a cabo en reuniones en petit comité celebra- Hoy día, la innovación viene de toda la organización, en-
das ocasionalmente, por Standups regulares, así tre otros, de los empleados de IT. La dirección ha tomado
como conseguir transparencia mediante tableros de conciencia de que también los desarrolladores de pro-
estrategia. Los Standups han llegado a convertirse ductos se encuentran muy cerca del mercado, por lo que
en parte de cada empleado y a la dirección le resulta su percepción del desarrollo tiene especial relevancia.
más fácil mantener una visión general. Por supuesto, determinadas decisiones se siguen toman-
do de forma centralizada, pero el proceso hasta la deci-
2. alor para experimentar. Ahora la empresa se atreve
V sión no se dirige ya de esta forma. Los empleados se
simplemente a probar las cosas en lugar de especifi- sienten escuchados y vuelven a entender por qué hacen
car cada idea hasta la extenuación. Para la gente de lo que hacen.
la empresa este era uno de los ejercicios más difíci-
les, pues experimentar y fracasar son conceptos que
van unidos. Admitir ante uno mismo y ante los demás
que algo no funciona era un desafío cultural. Incluso
la alta gerencia tuvo que aceptar primeramente que
124
lo fallos son una forma de éxito si uno se toma el
tiempo de examinarlos y aprender de ellos.
3. F eedback más rápido. Al acortarse radicalmente el

Time-to-Market, las reacciones de los usuarios sobre
un producto se recibían con mayor brevedad que an-
tes, siendo posible efectuar cambios en el producto
tras un feedback loop.
ALINEAMIENTO ESTRATÉGICO MAYOR EFICIENCIA

La gestión de cartera, es decir, la orientación consecuen- Al inicio del proceso de transformación la empresa tuvo
te de todas las iniciativas según la estrategia, fomentó que constatar que, desgraciadamente, la Agilidad Empre-
considerablemente una conciencia de la propia efectivi- sarial no puede funcionar si solo una parte de la organi-
dad en la empresa. En la parte izquierda del tablero de zación asume la responsabilidad. Por otra parte, las
estrategias se sigue colgando la estrategia, claramente áreas de responsabilidad fuera del desarrollo de pro-
formulada y desglosada en métricas empresariales defi- ductos, como por ejemplo Control de gestión, RR. HH. o
nidas. En los tickets de todos los trabajos que van pasan- Compras, siguen reglas totalmente distintas. Mientras
do a lo largo de la implementación a través de la empre- que el desarrollo de productos es esencialmente com-
sa y, por consiguiente, a través de las manos de los em- plejo, las funciones administrativas son a menudo com-
pleados que trabajan que esta área, se puede leer qué plicadas [comp. Snowden, Boone 2007 y Stacey 2000]. En
métrica empresarial se emplea o se ha de emplear. Los los últimos cuatro años también se ha trabajado en las
empleados involucrados saben así lo que son capaces de interacciones ágiles, por ejemplo, con límites WIP y feed-
lograr. Gracias a ello, se crea un ambiente que orienta y back loops. No obstante, el punto de mira es mucho más
arrastra a todos los demás. Así pues, la mayor parte de la eficiencia. Las capacidades de los empleados y el Slack
los empleados entiende adónde quiere llegar la empresa Time resultante mediante la aplicación de límites WIP se
y según ello puede actuar. empleaban y emplean deliberadamente para automati-
zar y mejorar continuamente procesos rutinarios con
métodos simples como el Kamishibai (véase recuadro).
¿En qué consiste el Kamishibai?

Kamishibai es, en realidad, un teatro narrativo japonés 125
basado en tarjetas con imágenes. El Sistema de Producción
Toyota desarrolló una técnica de visualización para proce
sos recurrentes basada en este método. En un tablero se
visualizan las tareas a realizar en tarjetas colocadas en
columnas organizadas por día, semana o mes y según el
ritmo del proceso. En el anverso de la tarjeta aparece el tipo
de tarea, mientras que en el reverso se describe el modo
de llevarla a término. Cuando una tarea está lista, la tar
jeta simplemente se cuelga en la columna “concluido”.
Kamishibai hace de miniauditoría ya que se insta a los que
ejecutan los trabajos a seguir los procesos y, de esta forma,
estabilizarlos. Pero al mismo tiempo tienen que estar
pendientes de lo que se puede mejorar. Así pues, la mejora
de procesos no es tarea de un único auditor sino de todos
los empleados [Leanability E018, 2017].
En general, este método ha aportado más calma y más DESARROLLO DE LAS CIFRAS
trabajo relajado a la organización. Sin embargo, esto fue FINANCIERAS DE LA EMPRESA
durante algún tiempo un arma de doble filo ya que el pa-
pel de los empleados que anteriormente habían salvado Sí, las cifras. ¿Ha valido realmente la pena este gran esfuerzo
proyectos y procesos de forma heroica en calidad de ágil? Me referiré a cuatro parámetros.
fuerzas especiales del Cuerpo de Bomberos había sido
ahora relegado al de simples trabajadores rutinarios y
1 A lo largo de la transformación en esta empresa, en algún
momento se llegó a la conclusión de que era conveniente
eso no les gustaba. Este punto afectó a la estructura de
cuantificar el “Cost of Delay”. Dicho de otra forma, se tra-
los empleados, pues, quien quería podía cambiar a otras
bajó para determinar el impacto financiero en la empresa
áreas de la empresa para seguir desarrollando sus apti-
cuando un producto salía al mercado más temprano o más
tudes, mientras que otros se marchaban. El problema de
tarde. Los cálculos mostraron que con un Time-to-Market
ser tan eficiente que hasta los empleados dejen la em-
más rápido se conseguía ahorrar cerca de diez millones de
presa por ello puede parecer una agradable ventaja,
euros anuales en costes de demora. Es muy simple, si los
pero es un problema. Ahora se contrata a gente para los
productos salen al mercado siete meses antes, el dinero
procesos rutinarios que se sienta bien en este ámbito.
también entra siete meses antes a las arcas.
Este cambio constituyó un desafío durante algún tiempo,
pero, a fin de cuentas, se trataba de un cambio necesario
1 Ello nos lleva al volumen de negocios. A pesar de las difi-
y muy eficaz. cultades existentes, el volumen de negocios anual de la
empresa experimentaba un crecimiento de entre el dos y
PUNTO DE MIRA EN EL OUTCOME EN
el cuatro por ciento, incluso antes de la transformación
LUGAR DE EN EL OUTPUT
ágil. Sin embargo, en los últimos dos años las ventas ha-
Cuando se quiere tener Agilidad Empresarial se debe bían aumentado de manera drástica, suponiendo en el
prestar atención al resultado y a su efecto (outcome) y año precedente cerca del 25 por ciento.
no a la cantidad (output). En nuestra empresa, la agilidad
126 ya no se centra en la gran cantidad de iniciativas aporta-
1 Los beneficios se habían triplicado durante los últimos
tres años. El motivo fue, por una parte, el crecimiento del
das. Ahora, de forma previa, se reflexiona mucho más -
volumen de negocios, y por otra, simultáneamente, la re-
incluso los empleados que aportan ideas - sobre qué ini-
ducción de los costes gracias a una mayor eficiencia.
ciativa contribuye a algo y en qué medida, así como so-
bre dónde se debe establecer el punto de mira. Una sola
1 La capitalización bursátil se había duplicado generosa-
iniciativa puede aportar mucho más que otras tres jun- mente: de 3400 a 7100 millones de euros.
tas. Ya solo tener en cuenta esta consideración constitu-
ye un paso importante. Hay que admitir que resulta difí- Sería demasiado trivial afirmar que estos aumentos se han
cil medir los efectos de este enfoque en la evolución del debido únicamente a la Agilidad Empresarial que se implan-
volumen de negocio y los beneficios. Pero el hecho es tó. Naturalmente, se deben seguir tomando las decisiones
que el volumen de negocios ha aumentado y es de supo- correctas desde el punto de vista estratégico. No obstante,
ner que la pieza del puzle “punto de mira en el outcome” puedo decir que las medidas adoptadas contribuyeron
ha contribuido notablemente a ello. notablemente al éxito.
127
128
RESUMIENDO... ¿CÓMO utilización de los empleados»”. Yo les felicito por la lista
PUEDE CONSEGUIR QUE de tareas pendientes con pósits, si bien no todos los
puntos donde se coloca un pósit son ágiles. El trabajo de
SU EMPRESA SEA ÁGIL? la alta gerencia consiste en reflexionar profundamente
sobre lo que realmente significa Agilidad Empresarial,
El objeto de la historia descrita en este libro consiste en qué problemas se han de tratar aquí y, sobre todo, cuál
servirle de inspiración. Quizás su empresa ya se encuen- es su papel en este proceso.
tre en proceso de transformación y se haya vuelto a en-
contrar con algún que otro problema. Si es así, espero
entonces haber sabido mostrarle el camino para poder
encontrar la solución. Tal vez su empresa se encuentre a
un paso de comenzar con el proceso de transformación y
usted se haya dado cuenta de que alguna que otra re-
flexión previa podría llevarla hacia la dirección equivoca-
da. Independientemente de dónde se encuentre, me
gustaría volver a resumir una vez más los puntos a los
que debe prestar atención si el objetivo de su organiza-
ción es la Agilidad Empresarial.
Aviso legal: ¡No se trata de un listado exhaustivo ni sigue

un orden particular! Además, algunos pasos se han de
seguir en más de una ocasión.
COMIENCE ARRIBA DEL TODO

El primer equipo ágil debería ser la alta gerencia. Y con el 129
término ágil me refiero a realmente ágil. Deberá ir más
allá de la palabrería y la generosa delegación de la
responsabilidad de la transformación a las jerarquías

más bajas: “¡Tenéis nuestra bendición, avanzad y haceos
ágiles! Esto no tiene nada que ver con nosotros”. Cuando
me llaman para extinguir fuegos en empresas que se
quedan atascadas precisamente con sus transformacio-
nes ágiles, los gerentes me suelen mostrar con orgullo
sus aptitudes de visualización. “Disponemos de un table-
ro de tareas con el que administramos nuestras tareas
de gestión. Seguidamente trabajamos con los tickets
«elaborar presupuesto anual» y «controlar el nivel de
LA AGILIDAD COMIENZA CON EL PRO- PUNTO DE MIRA EN LOS OBJETIVOS Y

CESO DE CAMBIO NO EN LOS MÉTODOS
No se puede implementar una nueva forma de trabajar y Durante la Segunda Guerra Mundial, la población de
de pensar en una fecha determinada. Todos los proyec- Melanesia tenía a los soldados americanos que caían del
tos de transformación exitosos que he visto hasta ahora cielo por dioses que traían cosas milagrosas consigo.
ya han experimentado durante el mismo proceso de Tras la retirada de los americanos faltaba la reposición
cambio muchos aspectos que deseaban alcanzar final- de “cargo” y los habitantes de las islas comenzaron a
mente. ¿Debería la organización practicar el principio imitar las actividades que habían visto hacer a los solda-
pull? Entonces, a los trabajadores se les debe igualmente dos en los campos aéreos. Esperaban que así pudiesen
permitir “arrastrar” el cambio. ¿Deben los equipos reali- regresar los dioses. De ahí viene el término “culto de
zar entregas que aumenten progresivamente? Entonces cargo”. En algunas empresas, el término “Agile” se con-
no se deberían escribir planes de transformación a dos vierte en un tipo de culto de cargo. Se adora el método,
años. El cambio de empujar a arrastrar significa encon- pero no el objetivo. Da completamente igual si un
trar aliados, hacer marketing de la idea y que esta los Standup dura 5 o 20 minutos. ¿Quiere conseguir que su
entusiasme. empresa sea ágil o únicamente desea introducir en su
empresa una metodología de trabajo ágil?
130
LA AGILIDAD NO ES UN ASUNTO DE IDENTIFICAR FLIGHT LEVELS

EQUIPOS
Si la Agilidad Empresarial no es un asunto de equipos,
Quien quiere conseguir Agilidad Empresarial dirige el debería saber identificar el Flight Level de su organiza-
punto de mira hacia la creación de valor, es decir, hacia ción donde poder dirigir cada problema. ¿Se deben fina-
los procesos organizacionales y no hacia la estructura lizar las iniciativas con más rapidez? Entonces, en primer
organizacional. Está claro que se necesitan equipos para lugar, se ha de limitar la cantidad de iniciativas y no opti-
que el proceso funcione, pero no tiene sentido optimizar mizar un equipo. ¿Qué se ha de hacer a lo largo de la ca-
equipos a toda costa ya que los mejores equipos aportan dena de creación de valor para extraer el máximo desde
bastante poco en procesos malos. Desde un punto de la idea hasta el resultado? Para ser capaz de pensar de
vista sistémico, es mucho más eficaz tener grandes forma tan integral es absolutamente necesario que la
procesos con equipos malos. alta gerencia esté a bordo. De otra forma, en algún mo-
mento se topará con un techo de cristal que le impedirá
seguir adelante.
131
GESTIONAR DEPENDENCIAS Y límites WIP” significa entender el impacto que tiene cada
ELIMINARLAS (EXACTAMENTE EN WIP y a veces esto puede significar volver a aumentar el
ESTE ORDEN) WIP o simplemente dejarlo como está (véase cuestionario
al final de la parte 2).
Acostúmbrese al hecho de que siempre habrá dependen-
cias en una organización, independientemente de cómo 3. Feedback loops regulares. Las empresas no se agili-
esté estructurada. Realmente, intento emplear con mo- zan porque no haya nada mejor que hacer. Las transfor-
deración palabras como “siempre” y “nunca”. No tiene maciones ágiles persiguen objetivos concretos y, en este
ningún sentido copiar la estructura mágica de otra em- sentido, ayuda entender dónde se encuentra uno en ese
presa, incluso aunque parezca que esa es la solución. In- momento. Así pues, se necesitan feedbacks de experien-
téntelo mejor con interacciones ágiles. De este modo, a cias y de la forma más regular posible. Las métricas
lo largo del tiempo se van haciendo visibles aquellas de- muestran claramente si una medida provoca algún efec-
pendencias que bloquean el flujo de trabajo y ello le per- to o no, lo que permite decidir si progresar más o menos
mitirá reflexionar de forma concreta sobre cómo elimina- en una tarea o abandonarla por completo. Otro clásico
ras o atenuarlas. feedback loop consiste en hablar unos con otros. La con-
versación es una de las invenciones más geniales de la
INTEGRAR EL MOTOR DE LA AGILIDAD humanidad. Puede probarlo alguna vez. En un contexto
EMPRESARIAL LEAN EN CADA FLIGHT empresarial resulta aún más brillante hablar con las per-
LEVEL sonas adecuadas en el momento adecuado y sobre los
temas adecuados. Esta es precisamente la interacción
Supongamos que ha identificado los distintos Flight Le-
ágil con la que le llevo torturando desde el comienzo de
vels en su empresa. Tanto si se va a crear un tablero de
este libro.
equipos, de productos o de estrategias, los siguientes
cuatro pasos deben ser integrados en cada Flight Level: 4. Mejorar. Todo lo que ha hecho en los primeros tres
pasos refleja simplemente el último estado del error. Por
132 1. Hacer referencia explícita al trabajo y los procesos. El
tanto, no invierta demasiada energía en encontrar a la
trabajo del conocimiento es casi siempre invisible y, por
primera la perfecta visualización, el perfecto WIP o las
tanto, difícil de entender. En un tablero se puede ver en
perfectas reuniones para dejarlos así por siempre. No
lo que se trabaja y cómo se trabaja. Sin embargo, lo
existe un absoluto y correcto “lo que sea”, sino lo ade-
esencial es representar los procesos existentes y no los
cuado en este momento. El truco tras la Agilidad Empre-
requeridos o los deseados. Se puede progresar mejor si
sarial es la mejora. Por ello, comience a “hacer” lo antes
se parte del statu quo.
posible, reflexione sobre su hacer y mejórelo.
2. Gestionar el WIP a conciencia. Los límites WIP consti-
tuyen uno de los elementos de control más poderosos.
Ejercen influencia en muchas variables de cuyas interac-
ciones resulta la Agilidad Empresarial, por ejemplo, en el
Time-to-Market o en la previsibilidad. Ello no significa
por fuerza que el WIP tenga que disminuir. “Establecer
134
Glosario
de términos
en inglés
135
GLOSARIO DE TÉRMINOS EN INGLÉS
Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Lista ordenada de todo el trabajo pendiente
Backlog Grooming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . R eunión en la que el Product Owner y el equipo se reúnen

para refinar el Backlog del producto y añadir, retirar o
reestimar Historias de Usuario
Buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A
mortiguador o colchón de trabajo
Cost of Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Costes de demora
Downstream . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Corriente descendente durante la ejecución
Feedback Loops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bucles de retroalimentación
MVP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Abreviatura de “Minimal Viable Product” (Producto

Mínimo Viable)
Outcome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C
onsecución de unos resultados buscados y ligados a un
objetivo de negocio
Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . R
esultado de un proceso derivado de la aplicación de
unos inputs a un sistema
Plug-in . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A
quella aplicación que, en un programa informático, añade
una funcionalidad adicional o una nueva característica al
software
136
Pull . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sistema de arrastre
Push . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sistema de empuje
Slack Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Margen

de tiempo del que disponemos para realizar una
actividad sin retrasar el proyecto. También denominado
“tiempo de holgura”.
Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Iteración de tiempo fijo (concepto usado en Scrum)

GLOSARIO DE TÉRMINOS EN INGLÉS
Standup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Breve reunión de sincronización del equipo frente al

tablero Kanban
Start-up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . S
ociedad que, pese a su juventud y falta de recursos,
consigue obtener resultados en el mercado y pasar a un
siguiente nivel estructural al ser impulsada por otros
inversores o absorbida por empresas ya consolidadas
Story Point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . U
nidad de medida relativa usada para expresar una
estimación del esfuerzo total que se requiere para
implementar completamente una unidad de trabajo
Timebox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . T écnica consistente en establecer un tiempo fijo para

cumplir una serie de tareas y alcanzar un objetivo dentro
de un proyecto. También denominado “caja de tiempo”
Time-to-Market . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . T iempo comprendido desde que un producto o servicio

es concebido hasta que está disponible para el usuario
final
Throughput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ratio de entrega
Upstream . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Corriente ascendente durante la ideación
Whitepaper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D
ocumento informativo y promocional que puede formar
parte de las comunicaciones de marketing sobre un
producto o servicio 137
WIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Abreviatura de “Work in Process” (Trabajo en Curso)

138
REFERENCIAS BIBLIOGRÁFICAS
REFERENCIAS
BIBLIOGRÁFICAS
[Laloux 2016] [Snowden, Boone, 2007]
Laloux, Frederic: Reinventing Organizations: An illustra- Snowden, David J.; Boone, Mary E.: A Leaders’s Framework
ted Invitation to Join the Conversation on Next-Stage for Decision Making. In: Harvard Business Review,
Organizations. Nelson Parker 2016. noviembre 2007.
https://hbr.org/2007/11/a-leaders-framework-for-
[Leanability E018, 2017] decision-making
Leanability Videoblog: Lean Business Agility E018 –
Kamishibai. [Stacey 2000]
https://bit.ly/2ORVF0B Stacey, Ralph D.: Strategic Management & Organisational
Dynamics. The Challenge of Complexity. 3.ª edición,
Financial Times 2000.
[Leanability E020, 2017]
Leanability Videoblog: Lean Business Agility E020 – [The W. Edwards Deming Institute 2018]
The Spotify Model. The W. Edwards Deming Institute: Quotes by W. Edwards
https://bit.ly/2OOILjM Deming
http://quotes.deming.org/authors/W._Edwards_Deming/
quote/10141
[Leopold 2016]
Leopold, Klaus: Practical Kanban: From Team Focus to
Creating Value. LEANability PRESS 2016.
[Little, Graves, 2008]

Little, John D.C.; Graves, Stephen C.: Little’s Law. In:
Chhajed, Dilip; Lowe, Timothy J. (eds.): Building Intuition.
Insights from Basic Operations Management Models and 139
Principles. Springer US 2008, pág. 81-100
[Mois, Baldauf, 2016]

Mois, Tim; Baldauf, Corinna: 24 Work Hacks ... auf die wir
gerne früher gekommen wären. sipgate GmbH 2016.
BIBLIOGRAFÍA
RECOMENDADA
Aportaciones seleccionadas sobre la Agilidad Empresarial Flight Levels
Mis reflexiones sobre la Agilidad Empresarial. Podrá leer- At which Flight Level does innovation start?
las accediendo a mi blog
www.LEANability.com https://bit.ly/2DYXzJy
Nuevas entrevistas con especialistas que practican la Lean Business Agility E007: Flight Level 2 at AutoScout 24
Agilidad Empresarial. Las podrá encontrar de forma re-
https://bit.ly/2IXke9z
gular en mi videoblog
https://www.leanability.com/de/category/video-blog/ Lean Business Agility E026: Medical Device Development,
Flight Levels and Scrum https://bit.ly/2QRj4PJ
Podcast: Flying at Portfolio Level https://bit.ly/2CLzAxW
Límites WIP
WIP Limits Must Die https://bit.ly/2E9nFdP
Flow Exercise: Building Paper Boats
https://bit.ly/2waOHuU
140
BIBLIOGRAFÍA RECOMENDADA
Libros recomendados
Christensen, Clayton M.: Competing Against Luck.

The Story of Innovation and Customer Choice. Harper
Business 2016.
Doerr, John: Measure What Matters. OKRs – The Simple

Idea that Drives 10x Growth. Portfolio Penguin 2018.
Goldratt, Eliyahu M.: The Goal. A Process of Ongoing

Improvement. North River PR Inc 2014.
Kaltenecker, Siegfried: Self-Organising Enterprises.

Leanpub 2017.
Liker, Jeffrey: The Toyota Way to Lean Leadership.

Achieving and Sustaining Excellence through Leadership
Development.
Marquet, L. David: Turn The Ship Around! A True Story of

Building Leaders by Breaking the Rules. Portfolio Penguin
2015.
Moore, Geoffrey A.: Escape Velocity. Free Your Company’s

Future from the Pull of the Past. Harper Business 2011.
Reinertsen, Donald G.: The Principles of Product 141

Development Flow. Second Generation Lean Product
Development. Celeritas Pub 2009.
Ries, Eric: The Lean Startup. How Constant Innovation

Creates Radically Successful Businesses. Portfolio
Penguin 2011.
Taleb, Nassim Nicholas: Antifragile. Things that Gain from

Disorder. Penguin 2013.
OTROS LIBROS
Kanban Change Leadership

Creating a Culture of Continuous Improvement
Klaus Leopold, Siegfried Kaltenecker
John Wiley & Sons Inc

1.ª edición 04/2015 - traducción de “Kanban in der IT”
304 páginas, también disponible como kindle
ISBN: 978-1119019701
Kanban in der Praxis

Vom Teamfokus zur Wertschöpfung
Klaus Leopold
Hanser Verlag
1.ª edición /2016
237 páginas, también disponible como kindle
ISBN: 978-3-446-44343-3
35,00 €
Practical Kanban
142 From Team Focus To Creating Value
Klaus Leopold
LEANability Press
1. edición 11/2017 - traducción revisada de
Kanban in der Praxis
353 páginas, también disponible como Kindle
y en leanpub como EPUB, Mobi y PDF
ISBN: 978-3-903-20500-0
26,00 €

Reconsiderandoagile PDF

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Reconsiderandoagile PDF

Cargado por

Copyright:

Formatos disponibles

klaus LEOPOLD

Copyright © 2018, LEANability GmbH, Viena

Este libro también está disponible como Actualizaciones

Kindle ISBN: 978-3-903205-56-7 agilitaet-neu-denken.com

Leanpub ISBN: 978-3-903205-57-4 LEANability.com

Prólogo Klaus Leopold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 06

Prólogo José Casal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 08

Parte 2 | Las causas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Parte 3 | Primeras soluciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Parte 4 | El resultado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

Glosario de términos en inglés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

Referencias bibliográficas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

Mi intención con este libro es ir al grano y, con el poder de las ilustra-

Pero no espere aquí profundizar en la teoría. Lo que leerá le dará más

Estos son desafíos que nunca vamos a solucionar enfocándonos sólo

En 2015, estaba trabajando con la oficina de gestión de proyectos de

Desde entonces, he estado llevando el concepto de Flight Levels a

Este libro describe la historia de una empresa que descubre Flight

Espero que esta historia, y muchas otras que irán apareciendo en la

En la práctica, encontrar al ilustrador adecuado resultó ser un trabajo

Querría volver a dar las gracias a Dolores Omann, que me acompaña

Naturalmente, el texto y las imágenes son componentes importantes

La cubierta del libro ha sido una tarea bastante ardua y he necesitado

Tenía que suceder algo, estaba más claro que el agua.

1 Había que optimizar el Time-to-Market, reducién-

1 Era importante reconocer e integrar con más anti-

PREPARACIÓN ­EJEMPLAR 1. Todos los equipos debían tener una disposición

Los departamentos y equipos tenían incluso la opción de

d. Se debían establecer dos mediciones como meca-

1 Throughput: Número de unidades de trabajo

1 Tiempo de ciclo: Indica el tiempo que se

¿Qué es una retrospectiva?

EL PROCESO DE Seguramente percibirá cierto sarcasmo en mis palabras,

Atención: Durante la implementación, los siguientes pa-

Ya en la feria se discutía y, a menudo, se llega-

¿Qué es un taller de diseño de sistemas?

Aquí es precisamente donde se ponen las esperanzas al

Pero los equipos Kanban de esta empresa obtuvieron

el objetivo de la transformación ágil: un “Time-to-Market Como <tipo de usuario>

¿Qué son los Story Points?

¿QUÉ …. ESTABA PASANDO AQUÍ?

36 Cuando una empresa está a punto de emprender cam-

Durante mis conversaciones con la dirección de esta em-

Esta organización había dado el giro equivocado nada

A partir del momento en el que la dirección decide que

Tales polémicas suelen dejarme

EL PROCESO DE CAMBIO COMO Proyecto – ya me imaginaba lo que pasaba aquí. Tras la

También en esta empresa había sucedido lo que había

Principio pull vs. principio push

EL CAMBIO ES UN NUEVO Un supuesto organigrama ágil surge simplemente cuan-

CAUSA 2: Tanto en la dirección como en los equipos se sentía el

Y PRODUCTOS que nos permitió llevar a cabo discusiones concretas de-

¿QUÉ ES LO QUE NO HABÍAN Naturalmente, se pueden eliminar de la mejor manera

LA F MÁS RÁPIDA DEL MUNDO

Básicamente, transcurrían meses de espera antes de que

CAUSA 4: También en Scrum existe un límite WIP “implícito”. Este es

LÍMITES WIP EN EL­ el resultado del trabajo en Sprints y el compromiso aso-

Trabajo en Curso: ¿hablamos de progreso o proceso?

Las personas no son capaces de realizar

La visualización del trabajo nos hace ver las

A MAYOR EFICIENCIA DE FLUJO, decisión previa de si se ha de implementar una idea

REDUCIR EL WIP: Para el siguiente experimento mental partiremos del

realmente buenos los

El tiempo de ciclo disminuye.

1 Había que optimizar el Time-to-Market, reducién-

1 Era importante reconocer e integrar con más anti-

PREPARACIÓN EJEMPLAR 1. Todos los equipos debían tener una disposición

d. Se debían establecer dos mediciones como meca-

1 Throughput: Número de unidades de trabajo

1 Tiempo de ciclo: Indica el tiempo que se

LÍMITES WIP EN EL el resultado del trabajo en Sprints y el compromiso aso-

¿Cuál era el motivo de mi descontento?

1 Determinando e implementando mejoras a través de

1 El trabajo se visualiza.

1 Se deducen e implementan oportunidades de mejora

GESTIONARLAS personas que han desarrollado y entregado este produc-

LAS TRES TRAMPAS DE TIEMPO EN 1. LOS PRESUPUESTOS ANUALES

2. COLEGAS QUE HACEN DE

3. ESTIMAR ALGO QUE DE TODAS

MEJORA 3: Sin embargo, involucrar a la alta gestión no siempre r esulta

1. isualización. Todas las unidades que generan valor

2. Limitación. En un segundo paso, se ha de encontrar

3. F eedback más rápido. Al acortarse radicalmente el

Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Lista ordenada de todo el trabajo pendiente

Backlog Grooming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . R eunión en la que el Product Owner y el equipo se reúnen

Cost of Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Costes de demora

Downstream . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Corriente descendente durante la ejecución

Feedback Loops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bucles de retroalimentación

MVP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Abreviatura de “Minimal Viable Product” (Producto

Push . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sistema de empuje

Slack Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Margen

Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Iteración de tiempo fijo (concepto usado en Scrum)

Standup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Breve reunión de sincronización del equipo frente al

Timebox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . T écnica consistente en establecer un tiempo fijo para

Time-to-Market . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . T iempo comprendido desde que un producto o servicio

Throughput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ratio de entrega

Upstream . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Corriente ascendente durante la ideación

WIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Abreviatura de “Work in Process” (Trabajo en Curso)