CHANGE AGILITY

UNA GUÍA QUE LE AYUDARÁ A PENSAR EN LA GESTIÓN DEL CAMBIO DE

MANERA DIFERENTE
JASON LITTLE
 CONTENTS

1. Persiguiendo coches (¿Por qué este libro? ¿Por qué ahora?)

2. Tu visión de ágil no es igual a la mía
3. Cómo leer este libro
4. ¿Ser o hacer lo ágil?
5. Volverse más plenamente humano
6. Versión Beta 1.0? ¿Qué diablos?

Parte I - Manifiesto de gestión del cambio moderno

1. Tu manifiesto de cambio
2. Personas e interacciones
3. ¿Software de trabajo?
4. Colaboración con el cliente
5. Respuesta al cambio

Parte II - Libro de trabajo - Principios modernos de gestión del cambio

1. Cómo está estructurada la Parte II
2. Cuidar a la gente
3. Bienvenida al cambio
4. Ciclos de retroalimentación cortos
5. Colaboración multifuncional
6. Motivación intrínseca
7. Contacto en vez de tecnología
8. Métricas adaptables
9. Adaptarse al ritmo
10. Proceso de cambio adaptable
11. Mantenlo simple
12. Las personas que escriben el plan no luchan contra el plan
13. Inspeccionar y adaptar
14. Priorizar sus principios

Parte III - Mi opinión - Principios modernos de gestión del cambio

1. Cuidar a la gente
2. Bienvenida al cambio
3. Ciclos de retroalimentación cortos
4. Colaboración multifuncional
5. Motivación intrínseca
6. Contacto en lugar de tecnología
7. Métricas adaptables
8. Adaptarse al ritmo
9. Proceso de cambio adaptable
10. Mantenlo simple
11. Las personas que escriben el plan no luchan contra el plan
12. Inspeccionar y adaptar

Parte IV: Cambiar tu visión del cambio

1. Transformar la forma de gestionar el trabajo de cambio
2. Transformando tu forma de pensar sobre el cambio
3. Transformar la forma en que te integras con equipos ágiles

Parte V: ¿Qué ha cambiado desde Lean Change Management?

1. ¿Qué pasó con The Commission?
2. Un manifiesto para un cambio ágil
Parte VI - Change Wayfinder
Parte VII – Agradecimientos
Notes
 PERSIGUIENDO COCHES (¿POR QUÉ ESTE LIBRO? ¿POR
QUÉ AHORA?)

“P aradójicamente, el camino a seguir no es mirar hacia adelante, sino detenerte

y mirar a tu alrededor” - John Seely Brown

E N 1974, Southwest Airlines estaba en su infancia y al borde del colapso. Necesitaban

vender uno de sus cuatro aviones, pero aún tenían que dar servicio a un horario de cuatro
aviones. La mejor manera de hacerlo era que la gente bajara y subiera al avión lo más rápido
posible.
Así nació el plazo de 10 minutos.
En ese momento, había menos restricciones para los viajes aéreos que en la actualidad. Los
pasajeros estarían esperando en la pista para subir al avión, y la gente seguiría encontrando
sus asientos mientras el avión se alejaba de la puerta.
Para salvar su aerolínea en ese entonces, Southwest tuvo que comprender sus limitaciones
y todo lo relacionado con el desembarque, la preparación y el embarque de vuelos sin
mucha ayuda externa. Tuvieron que crearla desde cero.
Hoy en día, la información es en gran parte gratuita y fácil de obtener. Si necesitamos crear
un programa de mejora continua, desarrollar un proceso ágil de varios equipos o transformar
nuestra organización, Google puede hacer la mayor parte del trabajo por nosotros.
Luego creamos algunas diapositivas, pilares estratégicos y otros se esfuerzan para que las
partes interesadas se sientan seguras de que vamos en la dirección correcta, aunque nadie
sepa exactamente cómo hacer esto.
Crear un esquema de cambio es razonablemente simple. Hay ciertas ideas universales que son
relevantes en cualquier contexto. Por eso es que muchos de los esquemas que puedes
encontrar en Google tienen fases de evaluación, análisis, ejecución y cierre. El ciclo
Shewhart, a menudo atribuido a Deming, de Planificar-Hacer-Verificar-Actuar es el único
modelo que necesitamos, pero como saben, la dificultad está en los detalles.
Cambiar las organizaciones de hoy es más difícil que nunca. Nos bombardean a diario con
nuevos modelos, esquemas y herramientas que prometen asegurar un cambio exitoso y
hacernos sentir bien con un futuro desconocido e incognoscible. Cuando estos modelos,
esquemas y herramientas no cumplen sus promesas después de 12 a 18 meses, el
vicepresidente de transformación ya se encuentra totalmente perdido y entonces una firma
consultora diferente se presenta con su método multiusos basado en los últimos hallazgos de
la neurociencia.
Ya en 2007, el entrenador que me enseñó Scrum contó muchas historias sobre ayudar a una
gran institución financiera a transformarse en ágil, ya pasaron 12 años, y todavía se están
transformando.
En algún momento del camino, hemos confundido la evolución natural que todas las
organizaciones atraviesan continuamente con esquemas de transformación de un solo recurso,
y esto es frustrante para todos.
¿POR QUÉ ESTE LIBRO, POR QUÉ AHORA?
Jerry Weinberg1 influye en gran parte de mi trabajo y de mi línea de pensamiento. Recuerdo
que cuando se le preguntó sobre su contribución más significativa al software, respondió:
“Nunca inventé otro lenguaje de programación”.
Esa es la intención de este libro.
Durante más de 15 años, he ayudado a muchas organizaciones, equipos de personas y
particulares a adoptar prácticas ágiles en software, recursos humanos, gestión del cambio,
desarrollo organizacional, marketing y más.
Quise usar sus historias, diarios e imágenes para mostrar tres puntos de vista principales de la
gestión ágil del cambio:

Transformar la forma de gestionar el trabajo de cambio.

Transformar la forma de pensar sobre el cambio.
Transformar la forma de trabajar con equipos ágiles.

Los esquemas, métodos, manuales de estrategias y procesos de cambio ágil pueden ser
valiosos, pero se basan en la visión y las experiencias de alguien sobre cómo creen que
deberías hacerlo.
Este libro revisa la intención de lo ágil para hacerte pensar por qué quieres hacer que una
gestión de cambios sea ágil. Eso te permitirá crear un enfoque exclusivo que coincida con su
contexto en lugar de intentar conectar la clavija cuadrada de otra persona en el agujero
redondo de su contexto.
En las palabras de Jerry Weinberg 1, una pequeña sacudida puede ser de gran ayuda, y espero
que las historias de este libro te inspiren. Lo diferente de este libro es que este artefacto
estático es solo el comienzo. De manera verdaderamente ágil, este libro vivirá y evolucionará
a través de changewayfinder.com 2.
Si bien es comprensible que queramos que el cambio tenga un comienzo, una mitad y un
final, nunca ha sido así y nunca funcionará de esa manera. Es más bien como una ola causada
por el tira y jala de las mareas organizativas.
Es necesario encontrar la forma correcta de intervenir en el sistema organizativo, en el
momento adecuado, para dar un paso adelante.
Como dijo James Carse 3 antes de que Simon Sinek replanteara sus ideas 4, todas las
organizaciones están jugando un juego infinito, no finito.
 TU VISIÓN DE ÁGIL NO ES IGUAL A LA MÍA

Queremos respuestas; ¡las queremos ahora! Pregúntale a Google “qué es <lo que
sea>” y obtendrás un fragmento de algún sitio web que te dirá de qué se trata.

E s 23 de enero de 2020 y estoy sentado en Helsinki, Finlandia, dando los toques

finales a este libro al final de un viaje en el que realicé un par de talleres de cambio
con mi amigo y colega Andrew Annett.
Para divertirme, busqué en Google “qué es ágil”, esto es lo que encontré:

“Ágil es un enfoque iterativo y de tiempo definido para la entrega de software que crea el
software de forma incremental desde el inicio del proyecto, en lugar de intentar entregarlo
todo de una vez cerca del final”.

Hoy, después de encontrar este libro en una vieja unidad de respaldo en agosto de 2020, lo
busqué en Google nuevamente y esta es la respuesta sugerida por Google:

“El desarrollo de software ágil se refiere a un grupo de metodologías de desarrollo de

software basadas en el desarrollo iterativo, donde los requisitos y las soluciones evolucionan
a través de la colaboración entre equipos multifuncionales autoorganizados. ... Obtenga más
información sobre el Manifiesto Ágil”.

Ambos están centrados en el proceso, pero el segundo al menos menciona el manifiesto, ¡así
que eso es bueno!
Supongo que eso podría ser suficientemente bueno, pero ¿y si me encuentro en el área de
marketing? Aquí está la respuesta de Google a “¿qué es el marketing ágil?”

“En esencia, el marketing ágil es un enfoque de marketing táctico en el que los equipos
identifican y enfocan sus esfuerzos colectivos en proyectos de alto valor, completan esos
proyectos de manera cooperativa, miden su impacto y luego mejoran de forma continua e
incremental los resultados a lo largo del tiempo”.

Un poco vago, pero está bien, supongo. ¿Qué tal para RRHH? Aquí está la respuesta sugerida
por Google de “¿qué es RRHH ágil?”
 “Las retrospectivas también se pueden llevar a cabo con los gerentes de contratación,
particularmente después de un nuevo 'evento de recursos humanos' tales como un ciclo de
revisión de contratación, despido o desempeño. Este es un enfoque 'centrado en el cliente'
que propugna lo ágil. El punto es comprender si el trabajo que está haciendo RR.HH. está
generando el valor deseado”.

Si eres una persona de recursos humanos, olvídate de haber leído eso. Ni siquiera está cerca
de tener relación con los valores y principios de lo ágil. Parece más bien una opinión de
alguien familiarizado con el algoritmo de clasificación de contenido de Google.
De acuerdo, tengo que intentar uno más. Supongamos que soy un comprobador de software.
Aquí está la respuesta de Google de “¿qué son las pruebas ágiles?”

“El Testing es un proceso de prueba de software que sigue los principios del desarrollo ágil
de software. Las pruebas ágiles se alinean con la metodología de desarrollo iterativo en la
que los requisitos se desarrollan gradualmente a partir de los clientes y los equipos de
prueba. El desarrollo está alineado con los requisitos del cliente”.

Vaya, otro incendio en un contenedor de basura, pero supongo que no podemos culpar a
Google por esto. Hay tantas opiniones divergentes sobre lo que es ágil hoy en día; incluso los
robots están confundidos.
Hemos llegado a un punto en el que algunas organizaciones ya no funcionan con agilidad;
están creando nuevas formas de trabajar porque la palabra “ágil” trae demasiado bagaje.

“Lo llamamos un manifiesto porque se trataba de un llamado a la acción basado en nuestras

creencias” - Martin Fowler

La historia del Manifiesto ágil

Antes de pasar por alto el resto de este capítulo pensando: “Sí, sí, sí... manifiesto ágil... Ya lo
entiendo”, tómate un momento para hacer una pausa y explorar la idea. Vuelve a leerlo, toma
nota de lo que es diferente ahora en comparación con cuando lo descubriste por primera vez.
El manifiesto ágil se redactó en 2001 en Snowbird en Salt Lake City, Utah. Diecisiete
creadores de varios métodos ligeros se reunieron y lo crearon porque querían descubrir una
forma mejor de crear software.
Estuvieron de acuerdo en los cuatro valores, crearon la mayoría de los 12 principios durante
el taller y luego los refinaron en lo que se puede leer hoy en http://agilemanifesto.org

Individuos e interacciones sobre procesos y herramientas

Software de trabajo sobre documentación completa
Colaboración del cliente sobre la negociación de contratos
Respuesta al cambio sobre el seguimiento de un plan

He estado usando prácticas ágiles desde principios de la década del 2000 y he estado
ayudando a las organizaciones a avanzar hacia formas ágiles de trabajo desde mediados de la
década del 2000. La palabra ágil inmediatamente llena a las personas con nociones
preconcebidas de colaboración, creando software más rápido / mejor / más barato y mejoras
continuas. Mucha gente pasa por alto algunos puntos críticos:
 1. El manifiesto dice: “Si bien hay valor en las declaraciones de la derecha, valoramos
más las declaraciones de la izquierda”. No ignoramos la documentación o la
planificación; valoramos más una solución tangible, funcional y la adaptación.
2. Los 12 principios derivados de los valores a menudo se ignoran. Si quieres ver
cómo, simplemente busca en Google “agilidad empresarial”. Muchos, incluyéndome
a mí, escribimos sobre esto una década antes de que el término fuera registrado
porque leímos el quinto principio.
3. El contexto importa. Si abstraes el enfoque del software, te darás cuenta de que lo
que decían los autores es universalmente adaptable. Es precisamente la manera en
que Southwest abordó sus problemas en 1974 y la forma en que Henry Ford abordó
la revolución de la fabricación de automóviles a principios del siglo XX. Toyota
merece el crédito por lo que hizo, pero todos sabemos que Henry Ford lo estaba
haciendo primero. Bueno, antes de Henry Ford, fue Oldsmobile quien creó la línea
de montaje. Antes de eso, estoy seguro de que algunas personas estaban produciendo
algo en masa, por lo que no importa quién lo inventó.
4. Las grandes organizaciones tienen chefs que evolucionan continuamente en la
forma en que hacen el trabajo mientras lo hacen. Esa es la naturaleza empírica de lo
ágil y es atemporal: aprende a pensar en tu contexto y estarás bien.

Hay mucho más que decir sobre los conceptos erróneos de lo ágil, pero por ahora, volvamos a
la intención del manifiesto ágil y descubramos cómo podemos adaptarlo al cambio.
Te prometo que, si partes de los valores y principios, y eres congruente con la forma en que
derivas tus prácticas de ellos, desbloquearás el poder de la agilidad.
 CÓMO LEER ESTE LIBRO

A sumiendo que hayas leído los dos primeros capítulos, permíteme ser anti-ágil y
decirte cómo pienso que debes leer el resto del libro. Este libro consta de cuatro
partes principales:

1. La primera parte es un ejercicio para que pienses sobre la manera en que adaptarías
el manifiesto ágil al cambio. A menudo queremos hacer <inserta el nombre de tu
disciplina aquí> más ágil, aplicamos la práctica, pero nos olvidamos de los valores y
principios en los que se basó. Esther Derby 1 dijo una vez: “Aplicamos la práctica,
pero nos divorciamos del principio”.
2. La segunda parte profundiza en los principios. Esto es importante, y a menudo se
pasa por alto. La gente observa los cuatro valores y se detiene allí, perdiéndose de
los fantásticos principios. Te haré memoria con algunas preguntas para que
replantees cada principio desde un enfoque de software a un enfoque de cambio.
3. La tercera parte es donde compartiré mi punto de vista basado en haber venido del
mundo ágil. Desde el año 2000 he trabajado como propietario de producto, Scrum
Master, miembro del equipo, coach interno / externo, entrenador y consultor, y los
valores y principios han dado forma a mi enfoque del cambio frente a lo que he visto
con muchos gerentes de cambio que eligen un método o marco sin considerar su
contexto.
4. La cuarta parte contiene mis puntos de vista sobre los tres puntos del capítulo de
apertura: transformar la forma en que trabaja la gestión del cambio, transformar la
forma en que piensas sobre el cambio y transformar la forma en que se integra con
equipos ágiles.
5. La quinta parte contiene detalles sobre lo que ha cambiado en The Commission, la
empresa en la que se basa la tienda en Lean Change Management y lo que ha
cambiado acerca de cómo veo el cambio después de haber pasado los últimos 6 a 7
años viajando por el mundo, capacitándome y trabajando en varias organizaciones.
6. Las Partes VI y VII son fragmentos de información aleatorios que te dirigen a
recursos en línea y están ahí para agradecer a todas las personas maravillosas que he
conocido e interactuado a lo largo de los años.

Puedes omitir la parte del libro de trabajo, pero espero que no lo hagas. Existe mucha
información falsa sobre cómo aplicar prácticas ágiles en un contexto que no es de software.
Muchas personas que hablan sobre cómo actuar con agilidad en el cambio han aprendido
sobre la agilidad en la fase de adopción tardía. Es decir, los que aprendieron sobre lo ágil
después de 2014 probablemente lo conocieron en grandes empresas a través de grandes
esquemas y pensamientos de procesos.
Consideran lo ágil como una forma de hacer cambios en las personas de manera más difícil y
rápida mediante el uso de mejores procesos. No es su culpa, es la naturaleza de las ideas. Una
vez que salen al mundo, están propensos a ser retorcidos en muchas direcciones.
Escribí este libro para aquellos que quieren hacer una pausa y tomarse el tiempo necesario
para comprender la intención de lo ágil y regresar a un lugar de valores y principios que
guían la forma en que actuamos como agentes de cambio.
He aquí un ejemplo de lo que puedes esperar.
UNA HISTORIA: UN CUENTO SOBRE DOS MENTALIDADES
Hace muchos años, me invitaron a hablar en una conferencia de cambio tradicional. El
moderador empezó la conferencia sobre cómo iban a hacer algo ágil e innovador llamado
Open Space 2 (Espacio Abierto) para comenzar con el programa.
Crearon cuatro áreas de conversación, con temas predeterminados, cada uno con un
moderador. Los asistentes se sentaron en semicírculo con el moderador en el medio. El
moderador hacía una pregunta, alguien la respondía y el moderador la reformulaba y dirigía
la siguiente pregunta.
Eso no fue innovador, no fue ágil y ni siquiera remotamente cercano a lo que es un Espacio
Abierto.
Si este hubiera sido un evento ágil, hubiera sido un espacio abierto adecuado. Hubiera habido
un montón de papeles y bolígrafos en medio de la habitación. El moderador hubiera descrito
las reglas del Espacio Abierto, y ese día hubiera surgido en función de lo que la gente quería
hablar frente a lo que el moderador quería que la gente hablara.
¿Cómo pudieron dos comunidades diferentes utilizar la misma práctica de formas
completamente diferentes?
Fácil.
Ambos ven el mundo a través de diferentes lentes basados en sus valores y principios
rectores. El primero valora el control y la estructura, mientras que el segundo valora la
colaboración y la confianza.
Lo que es peor, después de esa conferencia de cambio tradicional, ahora hay un ejército de
personas que piensa que un Espacio Abierto es algo que no lo es en absoluto.
POR QUÉ IMPORTA

En el libro, The New Kingmakers 3, Stephen O'Grady describe esto en términos de la manera
en que los desarrolladores crean la huella de su primer lenguaje de programación. Eso da
forma a su visión de la programación, por lo que hay tantos desarrolladores de un solo
recurso que dicen tener veinte años de experiencia, pero es el mismo año de experiencia
repetido durante veinte años. Compararán todos los idiomas nuevos con su primer amor
verdadero y nada los convencerá de que otro idioma podría ser mejor.
Esto ocurre con todos los humanos. Nos enamoramos del primer algo nuevo que se alinea con
nuestras creencias, y lo comparamos todo.
Este fenómeno se denomina impronta 4 o síndrome del pato bebé 5 . Así que recuerda, cuando
veas a ese experto en cambios ágiles mostrándote un diagrama de Gantt y refiriéndose a él
como un tablero Kanban, no camines ... ¡Sal corriendo!
DERIVACIÓN DE PRÁCTICAS DE LOS PRINCIPIOS
Si bien el Espacio Abierto es anterior al Manifiesto Ágil en un par de décadas, el undécimo
principio ágil es una base sólida para ello:
Las mejores arquitecturas, requisitos y diseño surgen de equipos autoorganizados.
Eso tiene sentido para el software, pero ¿qué pasa con la historia del comando y control del
Espacio Abierto? Adaptemos ese principio para ajustarlo a la historia:
La mejor experiencia de aprendizaje surge de grupos autoorganizados de personas inspiradas
por un tema.
¿Qué impidió que los organizadores de la conferencia anterior usaran Espacio Abierto según
lo previsto? Fue un:

¿Problema de competencia? ¿Quizás nadie en el comité organizador ha estado en

un espacio abierto adecuado y no sabía cómo funcionaba?
¿Problema de mentalidad? ¿Sería la personalidad más dominante del equipo de
planificación la culpable si las personas pasaran por una mala experiencia?
¿Problema de valores? ¿Se estaban comportando los organizadores de manera
incongruente?
¿Problema de principios? ¿No existían principios de construcción desde los que se
puede operar?
¿Problema del cliente? ¿Tenían nociones preconcebidas sobre su audiencia? Quizás
pensaron que los asistentes los culparían por una mala experiencia si no hubiera
habido suficiente estructura.

Hay muchas razones que podrían haber conducido a la decisión de ejecutar el Espacio
Abierto de la forma en que lo hicieron.
Lo único que sé es que después de haber organizado muchas conferencias y espacios abiertos,
alguien siempre pregunta: “¿Qué pasa si nadie tiene nada de qué hablar?”
Puede que hayas leído eso y hayas pensado “¿Qué tiene eso de malo?”
Bueno, estos cientos de personas confían en expertos para mostrarles una práctica diseñada
para provocar un diálogo significativo. Sin embargo, lo que aprendieron fue una forma
diferente de controlar la narrativa que obligaba a las personas a hablar sobre lo que los
organizadores pensaban que deberían estar hablando.
Volverán a sus organizaciones y realizarán una de las prácticas de manera incorrecta, y luego
se preguntarán por qué no funcionó.
CÓMO DISEÑÉ LA EXPERIENCIA DE LECTURA DE ESTE LIBRO
Diseñé este libro para hacerte pensar, no para darte otro esquema de cambio ágil o manual de
estrategias:

Para mostrarte el manifiesto ágil, para que te familiarices con lo que es y cómo llegó
a ser.
Para que crees un manifiesto de cambio adaptando los valores y principios del
manifiesto ágil al cambio.
Para poner a prueba lo que creaste en un escenario.
Para compartir lo que creo que es la gestión ágil del cambio, junto con historias y
ejemplos de cómo uso el manifiesto ágil para guiar mis acciones.

Revisaré cada valor y principio y te daré ejercicios breves para descubrir cómo aprovechar al
máximo lo que ya existe sin crear un nuevo esquema ni descartar cualquier esquema que
estés usando hoy.
Después de eso, te daré un montón de prácticas e ideas de “lean startup”, ágiles y de
pensamiento de diseño que he usado, completas con imágenes e historias, para que puedas
ver cómo estas ideas se han utilizado en organizaciones reales. Puedes encontrar más en
Change Wayfinder 6.
Finalmente, a lo largo del camino, encontrarás URL para visitar dónde puedes conectarte con
otros lectores para ver lo que han hecho, para que sus compañeros puedan inspirarlo.
Mi objetivo es ayudarte a ver más opciones para impulsar el cambio mirando el cambio a
través de diferentes lentes. Una vez que tengas más opciones y seas más intencional en el
diseño de la intervención organizacional adecuada, el trabajo será más satisfactorio, la gente
será más feliz y el mundo será un lugar mejor.
 ¿SER O HACER LO ÁGIL?

“Queremos usar lo ágil en este proyecto, pero no queremos que lo ágil se interponga
en el camino”.

E sto parece que fue hace toda una vida, pero nunca olvidaré mi respuesta a esa
pregunta aparentemente extraña de uno de mis clientes, el director de PMO, Jack, y
la gerente sénior de desarrollo, Sally, “Bueno, solo hay cuatro valores, ¿cuáles
debería ignorar?”
Ese mismo año, Sidney Crosby estaba levantando su primera Copa Stanley, Avatar estaba en
camino de convertirse en la película más taquillera de todos los tiempos, y el teléfono
insignia de Apple era el 3GS.
Jack y Sally eran los jefes de un departamento de mil personas en una organización de 80,000
personas a la que llamaré Big Co, que quería adoptar la agilidad en todo su departamento. En
realidad, ELLOS no querían, pero alguien más sí. Mirando hacia atrás ahora, ni siquiera
recuerdo por qué se produjo este cambio. Sin embargo, hoy todas las organizaciones quieren
ser más ágiles debido a la presión de los compañeros corporativos, pero en aquel entonces,
quién sabe.
Tenía dos prioridades principales en Big Co.

La primera fue capacitar a todos en el manejo ágil. Así es, todos, desde
desarrolladores a comprobadores, empresarios y entrenadores corporativos, hasta
ejecutivos y gerentes.
La otra se trataba de trabajar como Scrum Master en equipos piloto. Trabajé con más
de 20 equipos de personas, incluido un equipo que no era de software que quería
usar lo ágil para trabajar en iniciativas de procesos de negocios empresariales, por lo
que es seguro decir que esta experiencia fue una experiencia de aprendizaje increíble
para mí.

Además de mí, nuestro equipo de entrenadores en Big Co estaba formado por un entrenador
ágil senior y un entrenador de Programación Extrema (XP).
Dato divertido: El entrenador de XP fue el responsable directo de que asistiera a AYE ese
mismo año, lo que influyó en el camino que tomé. Me dijo que “debería” ir y que “debería
ir a las sesiones que me hacían sentir incómodo”. Si no hubiera conocido a Jerry Weinberg,
Esther Derby, Johanna Rothman, Steve Smith y Don Gray, los presentadores de AYE,
ustedes no estarían leyendo esto y yo probablemente todavía estaría trabajando como
Propietario de Producto en algún lugar. ¡Puedes decidir si eso es bueno o no!
Nuestro enfoque en ese entonces era más o menos el mismo que todavía veo que hacen
muchas organizaciones hoy:

Capacítalos a todos (lo ágil en general, los métodos que decidamos que usarán, etc.)
Ejecuta programas piloto.
Implementa una herramienta de gestión de software ágil.
Despliega y escala.
Empuja agua cuesta arriba con un palo. (OK, esto es una broma, pero aún así).
ADOPCIÓN ÁGIL VS TRANSFORMACIÓN ÁGIL
En aquel entonces, este enfoque era etiquetado como ágil. La gente comenzó a llamarse a sí
mismos entrenadores ágiles, aunque este no era un título de trabajo reconocido en ninguna
organización que yo supiera. Mi título oficial era Consultor Ágil, y todavía recuerdo
claramente haber sido condenado al ostracismo en círculos ágiles por decir que éramos
simplemente consultores especializados en temas ágiles.
El argumento en contra de mi creencia era que había algo más noble y honorable en ser un
entrenador ágil que en un consultor.
En ese entonces, el entrenador ágil deambularía por la organización, libre de las limitaciones
de la jerarquía. Hoy en día tenemos Centros ágiles de excelencia (Agile Centers of
Excellence - COE) con siete niveles de jerarquía:

Entrenador ágil junior

Entrenador ágil I
Entrenador ágil II
Entrenador ágil senior I
Entrenador ágil senior II
Director del programa ágil
Vicepresidente de lo ágil

La transformación ágil aún no existía, porque la comunidad ágil, incluido yo mismo, no tenía
ni idea del cambio organizacional. Lo ágil se veía como algo exclusivo de TI, aunque algunos
pequeños círculos de personas sabían que no lo era. El problema era, además de gritar,
“¡¡¡LA AGILIDAD AFECTA A TODA LA ORGANIZACIÓN!!!” la comunidad ágil no
pudo articular lo que eso significaba.
En ese momento, el Agile Coaching Institute 1 estaba todavía a un año de existir, y no existía
ninguno de los esquemas ágiles que dominan el mercado actual. Scrum se convirtió en el
enfoque ágil más popular porque era el curso de capacitación y certificación más popular que
existía en ese momento.
Mientras el término entrenador ágil estaba empezando a usarse, Extreme Programming (XP)
introdujo el papel de entrenador 2 en los años 90. La responsabilidad del entrenador de XP era
ayudar a los equipos a vivir el manifiesto ágil. Si bien las partes técnicas estaban a la
vanguardia, la atención se centró siempre en el primer principio ágil: Satisfacer al cliente
mediante la entrega temprana y continua de software valioso.
Fuera del mundo del coaching profesional, no puedo encontrar ninguna referencia anterior al
término coach en un contexto de software.
AGILIDAD DEL SENTIDO COMÚN
Unos años antes de empezar a trabajar en Big Co, descubrí Big A ágil por accidente.
Mientras trabajaba en el inicio de mi segunda empresa, usamos stand-ups diarios (Scrum) y
retrospectivas (Scrum), limitando nuestro trabajo en progreso a un gran proyecto y dos
pequeños proyectos al mismo tiempo (Kanban).
Curiosamente, esto sucedió través de mi papá, quien trabajó como fabricante de calderas
durante 30 años. Utilizaron muchas prácticas ágiles durante una época en la que los Broad
Street Bullies dominaban el hockey. Incluso puedes verlo en un Walmart si vas lo
suficientemente temprano en el día. Realizan stand-ups empresariales diarios, al igual que
muchos minoristas, restaurantes y más empresas que no son de TI.
Nuestro equipo en Big Co fue el responsable de nuevos desarrollos, gestión de catálogo de
medios y soporte y mantenimiento, por lo que la forma en que trabajamos funcionó para
nosotros. A medida que nuestra empresa creció de 3 a 30, luego a 200, adaptamos nuestros
procesos desde el equipo de personas hacia arriba, no al revés.
Se sintió natural; fue colaborativo y sencillo, así que una vez que me uní a Big Co, cometí el
error de pensar que el cambio orgánico también podría funcionar. Todavía recuerdo la
ubicación exacta de la oficina de Jack, donde tuve esa conversación inicial que se sintió más
como un ataque preventivo de su parte.
Pasarían un par de años antes de que entendiera lo que decían Jack y Sally:
Si el proyecto se hunde, es nuestro trasero, no el tuyo, ni el del equipo.
La próxima década y un poco vería el ascenso y la caída de varios movimientos ágiles como
la fase de evaluación de la preparación ágil, los debates de “hacer vs. ser”, la fase del
esquema empresarial y la fase del esquema piramidal de certificación.
Ahora diría que estamos en la fase <ágil + función>, que anula el propósito. Si todos nuestros
departamentos funcionales son 100% ágiles, hemos optimizado las partes, no el todo.
Esta es la diferencia fundamental en la forma en que la gente ágil ve lo ágil versus cómo la
gente de cambio tradicional ve lo ágil.
Las personas ágiles han estado haciendo, sin saberlo, un trabajo de cambio organizacional y
han estado buscando comprender cómo darle sentido a lo que ven. Las personas de cambio
tradicional han estado aplicando esquemas y métodos de cambio y ahora quieren aplicar
esquemas y métodos de cambio ágiles.
Uno está centrado en las personas, el otro solo finge estarlo.
Uno se centra en el problema, el otro se centra en la solución de un problema desconocido.
Permíteme aclarar esos últimos puntos.
Todos estamos haciendo lo mejor posible con lo que tenemos 3 en función de quiénes somos y
la manera en que nuestras experiencias han dado forma a cómo vemos el mundo.
Solo porque alguien toma notas en una reunión diaria para satisfacer al gobierno, no lo
convierte en idiota. Creo que la intención de la mayoría de los agentes de cambio, ya sean
entrenadores ágiles, personas de cambio, gente de recursos humanos y más, es buena. A
veces se manifiesta apareciendo como un solucionador sabelotodo, pero la intención siempre
es ser útil.
Los grandes agentes de cambio cambian la parte de mí a nosotros, así que espero que este
libro te brinde ideas y algunos lentes diferentes para ayudarte a lograrlo.
 VOLVERSE MÁS PLENAMENTE HUMANO

L a manera en que nos comportamos como agentes de cambio se deriva de quiénes

somos como personas. Eso incluye cómo crecimos, dónde crecimos, en qué período
crecimos y todas las experiencias personales y profesionales que hemos tenido.
En su fantástico libro, The Organized Mind 1, Daniel Levitin describe cómo cada generación
tiene sus quejas.

Cuando la gente inventó la escritura para realizar un seguimiento del inventario,

algunos pensaron que la falta de almacenamiento en nuestro cerebro nos volvería
estúpidos.
Cuando se inventó la televisión, la generación anterior que creció sin ella pensó que
volvería estúpidos a sus hijos.
Cuando se inventaron las tabletas, los padres que crecieron sin ellas pensaron que
volvería estúpidos a sus hijos.

Estoy seguro de que cuando la IA, la realidad virtual y tener chips incrustados en nuestras
cabezas se conviertan en la norma, esa generación dirá algo similar, “En mi época, no
teníamos un chip de computadora que nos dijera qué hacer ... simplemente lo buscábamos en
Google”
En opinión de Levitin, los seres humanos somos holgazanes y creamos tecnología para
descargar actividades de nuestro cerebro y enfocarnos en problemas más complejos.
Cuanto mayor me hago, más relajado y pragmático me vuelvo, creo.
Recuerdo mi primer trabajo de coaching ágil en el que iban a implementar lo ágil de la
“manera correcta”, sin importar el contexto.
Estoy seguro de que la idea de este libro o de su estructura confundirá a algunas personas.
Esta es la mejor manera en que puedo resumir por qué lo he organizado de esta manera:

Vivimos en una sociedad de soluciones rápidas no inventadas aquí. Todo lo que

necesitas para ser más ágil está contenido en el manifiesto si puedes traducirlo de un
contexto de software a otro de otro tipo.
La forma en que utilizas las prácticas que usas está determinada por los principios
por los que vives, no por los principios de sus creadores.
Esos principios están influenciados por un conjunto básico de valores. Tus valores
son diferentes a los míos, que son diferentes a los creadores de las prácticas que estás
usando.
 Esos valores han surgido del núcleo de quién eres.
La esencia de quién eres es determinada por tu educación.
La esencia de quién eres se ve reforzada continuamente por tus experiencias.

Pero, y esto es grande:

Puedes elegir conscientemente cambiar si te lo propones.
Recuerda la historia del Capítulo 3: ¿Cómo leer este libro? Los organizadores de esa
conferencia fueron personas inteligentes y capaces que no pudieron disfrutar de la libertad y
el poder de un Espacio Abierto adecuado.
Si alguien hubiera podido convencer al resto de los organizadores de darle una oportunidad
para crear un verdadero Espacio Abierto, quién sabe cómo eso habría influido en la gente.
En Lean Change Management, hice referencia a los conceptos básicos del modelo de cambio
de Satir. Aquí te presentaré brevemente otras tres piezas del paisaje de Satir 2:

1. Posturas de afrontamiento
2. Las cinco libertades
3. Siete A: etapas de crecimiento y actualización
POSTURAS DE AFRONTAMIENTO
En el corazón del paisaje de Satir y de toda interacción estamos nosotros, los demás y el
contexto. Otros pueden incluir una pareja, un compañero de trabajo o un grupo de personas.
El contexto es la situación o contenedor de la interacción entre nosotros y los demás.
Apaciguador: Cuando nos ignoramos a nosotros mismos y volvemos el estrés del contexto
hacia nuestro interior. “Oh, lo siento, es mi culpa, haré lo que necesites”.
Culpar: Cuando ignoramos al otro, la tensión del contexto enfocamos hacia afuera. “Idiota,
lo arruinaste, es tu culpa”.
Irrelevante: Cuando ignoramos el contexto y desviamos el estrés del contexto. [En respuesta
al despido de tu compañero de trabajo] “Bueno, ¡supongo que ya no tendrás que levantarte
temprano!”
Super razonable: Cuando nos ignoramos a nosotros mismos y a los demás y solo
consideramos el contexto. “No importa lo que piense cualquiera de nosotros, el cambio debe
realizarse”.
Congruencia: Cuando nos consideramos a nosotros mismos, a los demás y al contexto. “Me
entristece que te hayan despedido, pero no puedo procesar esto ahora, ¿está bien si te llamo
mañana?
LAS CINCO LIBERTADES

1. La libertad de ver y escuchar lo que hay aquí, en lugar de lo que “debería” ser, fue o
será.
2. La libertad de decir lo que sientes y piensas, en lugar de lo que “deberías” sentir y
pensar.
3. La libertad de sentir lo que sientes, en lugar de lo que “deberías” sentir.
4. La libertad de pedir lo que quieras, en lugar de esperar siempre la autorización.
5. La libertad de tomar riesgos en tu propio nombre en lugar de solamente elegir estar
en un lugar “seguro”.

Aprendí de Jerry Weinberg, en AYE, que las cosas son como son, y no como deben ser.
LAS SIETE A
Los siete A se agrupan en tres grupos que representan nuestro proceso interno de cambio,
interactuando con otros y finalmente incorporando el cambio en quiénes somos.
Paz: La paz interna del individuo
Conciencia: Tomar conciencia del deseo de cambiar. Eso podría significar un cambio por
necesidad (mi empresa se fue a la quiebra y me quedo sin trabajo dentro de un mes) o un
cambio debido a la infelicidad con el estatus quo (no me gusta mi trabajo, quiero cambiar de
carrera).
Aceptación: No aceptar el cambio, sino aceptar quiénes somos. Acéptate a ti mismo por lo
que eres, entonces puede ocurrir un cambio significativo.
Autoría: Tomar posesión y darte cuenta de que tienes más opciones de las que habías
pensado inicialmente.
Paz: La paz entre socios en una relación.
Articulación: Comunicar nuestra intención de que queremos cambiar y posiblemente pedir
ayuda a otros.
Aplicación: Practicar los nuevos comportamientos como resultado del cambio.
Activismo: Convertirnos en agentes de cambio que ayuden a las personas a atravesar lo que
acabamos de atravesar.
Paz: La paz entre los participantes en una comunidad mayor.
Altruismo: Ser congruentes (valorarnos a nosotros mismos, a otras personas, dentro de
cualquier contexto).
POR QUÉ ESTO ME IMPORTA
Esto es solo un pequeño salto hacia el modelo de Satir, que creo que es adecuado para este
libro. Recomiendo visitar satirglobal.org para obtener más información. Cuando estamos
conscientes de quiénes somos y lo aceptamos, estamos mejor preparados para integrarnos con
el mundo que nos rodea de una manera más humana.
Volvamos al ejemplo de Espacio Abierto.
Puede parecer que estoy culpando, y esa no es mi intención. De nuevo, recuerda que este
libro tiene la intención de ayudarte a ser congruente con tu comportamiento cuando dices que
deseas ser más ágil en la gestión del cambio.
Supongamos que el organizador principal describió el Espacio Abierto y luego
dijo: ”Ninguno de nosotros ha intentado esto antes, así que no sabemos qué pasará. Nuestra
intención es explorar temas de vanguardia que son importantes para ustedes, por lo que luego
realizaremos una breve retrospectiva para conocer sus opiniones”.
Eso pudo haberlo cambiado todo.
 VERSIÓN BETA 1.0? ¿QUÉ DIABLOS?

A quí estamos en octubre de 2020 y estoy haciendo la revisión final de este libro. Lo
lancé como Beta 0.1 en agosto, obtuve comentarios, validación de las ideas y luego
contraté a un editor de textos adecuado para ayudar. Escribir un libro es sin duda un
gran esfuerzo, con un rendimiento cuestionable.
Quién sabe si a alguien le gustarán las ideas, así que en lugar de hacer lo que hice con Lean
Change Management (conseguir un productor, lectores beta, grupos focales, expertos en
gráficos, edición de textos, edición de estructuras, etc.), decidí escribirlo, limpiarlo con
Grammarly, y simplemente soltarlo.
Este libro salió de mí como una bolsa de leche que gotea. (Sí, en Canadá tenemos leche en
bolsas. Extraño, ¿eh?)
Un animador al que sigo lanzó una serie de televisión de esta manera. Un día apareció la serie
sin bombos ni platillos. Me gusta este enfoque porque con tanto entusiasmo y anticipación,
no hay forma de que el producto esté a la altura, especialmente en el mundo actual.
Lo curioso es que hay algunos errores tipográficos en mi primer libro y algunas personas en
Amazon sienten la necesidad de señalarlos. Si encuentras un error tipográfico y ESA es su
mayor queja, bueno, para mí está bien.
Tengo un CD de un artista importante de la época en que el orden de las canciones en la
cubierta no coincide con el orden real de las canciones. Eso no me hace odiar su música.
Mi punto es que el retorno de encontrar un par de errores tipográficos no vale la pena el
esfuerzo, especialmente con ideas no probadas, así que iré a Google y lanzaré una versión
beta de este libro. Recuerda, ¡sigue vivo a través de changewayfinder.com!
¡NO HAY CORRECTO, INCORRECTO, BUENO, MALO, INTELIGENTE O
ESTÚPIDO!
Ya has leído algunas historias y hay muchas más en los capítulos restantes.
Contaré historias en las que las personas u organizaciones del cambio hicieron cosas que
pensé que no tenían sentido. Vivimos en un mundo obsesionado con hacer las cosas bien la
primera vez.
Demonios, incluso las personas ágiles dirán: “¡Experimenta y fracasa rápido!” Sin embargo,
estas mismas personas castigarán a las empresas por no hacerlo bien la primera vez.
Les cuento estas historias sin señalar con el dedo ni intentar avergonzarlos por hacer lo suyo.
No es mi intención.
Mi intención es ayudarte a encontrar opciones que te permitan encontrar el experimento
adecuado para tu contexto. No evites perturbar el sistema porque será difícil, pero tampoco
perturbes el sistema solo por causar disturbios.
Pienso que todos están haciendo lo mejor que pueden con lo que tienen, en el entorno en el
que se encuentran.
También creo que existen suficientes ideas que, si todos nos detenemos y miramos a nuestro
alrededor de vez en cuando, encontraremos la inspiración adecuada para dejar el mundo
mejor que como lo encontramos.
Espero que este libro te inspire.
 PARTE I - MANIFIESTO DE GESTIÓN DEL
CAMBIO MODERNO

“Vamos a un sprint en una épica. Únete y ayuda al equipo “

Hace muchos años, trabajé con un equipo de marketing que quería adoptar lo ágil. Había
trabajado con sus equipos de TI un año antes, y ahora algunos grupos y divisiones que no
eran de software en esta empresa querían usarlo.
El vicepresidente de marketing y digital quería un entrenador ágil para ayudar a un equipo
piloto a utilizar prácticas ágiles para hacer las cosas de manera más eficaz. Tenía buenas
relaciones con el marketing mientras trabajaba con sus equipos de TI, fue un salto fácil para
mí.
Si eliminas el ruido de la transformación a lo ágil, este es un cambio organizacional típico y
es esencial pensarlo de esa manera.

¿Por qué querían este cambio? ¿Y por qué ahora?

¿Por qué la gente de los equipos de marketing se preocuparía y querría trabajar de
manera diferente?
¿Qué ayuda y apoyo necesitaría la gente? ¿Realmente querrían pedir ayuda para
convertirse en más ágiles?
¿Qué tan transparente debería ser el proceso de transformación?
¿Cómo entras al equipo y cómo empezamos?

Sin importar el cambio, siempre hay una cierta cantidad de preparación que tiene que llevarse
a cabo. Pero esto no tiene que ser una gran producción.
En este caso, los líderes ya decidieron hacer el cambio, por lo que mi enfoque fue simple:

Diseñar un despegue para todo el grupo (vicepresidentes, gerentes y personas del

equipo piloto).
Hacer que los vicepresidentes le expliquen al equipo por qué esto era importante
para ellos y para la organización.
Hablar sobre la aventura épica a la que se iban a lanzar (sprint). (¡Explicaré lo que
 eso significa más tarde!)
Hacer un entrenamiento básico e incorporación del equipo, al que me referiré como
despegue.
Crear un acuerdo de coaching para mí y el equipo, para que todos sepamos qué
esperar, cuáles son los límites, etc.

Antes de continuar, recuerda que dije que los líderes ya decidieron hacer el cambio. Muchos
agentes de cambio caen en la trampa de “tener-que” incluso antes de empezar. Es decir,
piensan que tienen que ejecutar ciegamente la orden dada por los líderes.
Aunque los líderes ya decidieron hacer que el marketing fuera ágil, en este caso sigue siendo
mi responsabilidad desentrañar el problema para resolverlo y orientarlos sobre cómo hacerlo.
Lo más probable es que quieran que los programas de marketing se lleven a cabo más rápido,
por lo que una vez que los equipos de personas se den cuenta de eso, probablemente tengan
una solución simple que no requiera una gran transformación.
Durante el despegue con el marketing, acordamos un proceso sencillo, sin PowerPoint, de
comunicación frente a frente, ciclos breves de retroalimentación y acuerdos de trabajo entre
las personas del equipo.
Un pequeño comentario sobre el tema de PowerPoint. Durante el despegue, bromeé: “Ah, y
no es ágil crear un PowerPoint de 43 páginas con los resultados. Solo los necesito a todos
ustedes (Señalé a todos los vicepresidentes) a que simplemente vengan a esta sala al final de
la semana y les mostraremos lo que hicimos en 30 minutos o menos”. Estuvieron de acuerdo
porque admitieron que nunca leyeron ni les gustó la cultura de comunicarse mediante
PowerPoint.
Entonces, volvamos al movimiento ágil del equipo de marketing.
Comenzamos explorando qué significaba ágil para ellos en su contexto, lo que significaba
comenzar con el manifiesto ágil:
Individuos e interacciones en vez de procesos y herramientas.
Software de trabajo en vez de documentación completa.
Colaboración con el cliente en vez de negociación de contratos.
Respuesta al cambio en vez de seguir un plan.
Hay dos maneras en que usamos este manifiesto. Primero, lo usé como guía para construir el
despegue. Consideré a los vicepresidentes, gerentes y personal como el producto, y si iba a
desarrollar ese producto de manera ágil, ¿cómo lo abordaría?
Segundo, le di al equipo el manifiesto y les pedí que decidieran qué significaba para ellos el
trabajo de marketing. La forma en que trabajamos se derivaría de cómo el equipo vio el
manifiesto en su contexto.
INTERNALIZAR LO QUE SIGNIFICA ÁGIL
“Vamos a un sprint en una épica” - el comienzo de este capítulo suena un poco extraño. Lo
épico significaba proyectos e Historias de usuarios significaba tareas o declaraciones de
trayectorias del cliente. El equipo de marketing utilizó estos términos porque la mayoría del
equipo asistió a la capacitación de Scrum Master y trataron de hacer coincidir lo aprendido
con su realidad:

Ir a un sprint significaba ser asignado a un equipo de marketing multifuncional que

aplicaría Scrum
Sprint en una épica significaba el período de una semana de tiempo en el que
trabajarían en el proyecto.
El dueño de una épica era el propietario del producto

He aquí la parte crucial: Aunque no estaban usando los términos correctos, al menos
estaban tratando de encajar en su contexto. No iba a ser quisquilloso con el idioma.
Recuerden, el propósito de este libro no es enseñarles Scrum, así que, si quieren más detalles,
observen este breve video de Lyssa Adkins. 1
Para nuestros propósitos, aquí hay una descripción general básica de Scrum, supongamos:

Que contamos con un equipo multifuncional con personas que tienen todas las
habilidades necesarias para entregar la solución. Eso incluye administradores de
cambios si es necesario.
Que estamos trabajando en iteraciones de 1 semana.
Que estamos trabajando en un ciclo de lanzamiento de 1 mes (sí, el objetivo es tener
un producto potencialmente disponible al final de cada sprint, pero supongamos que
hay una restricción externa que no podemos cambiar en este momento).
Que con una sesión de planificación de Sprint se inicia la semana
Que hacemos un standup de 15 minutos todos los días para coordinar
Que hacemos una sesión de refinamiento del trabajo pendiente a mitad de la semana
para preparar historias para el próximo sprint.
Que realizamos revisiones de sprint y retrospectivas en el fin de semana

A continuación, es como adaptamos Scrum a la realidad del equipo de marketing:

Teníamos un equipo de marketing multifuncional que representaba a seis

subdepartamentos de marketing.
Usamos sprints de 1 día de duración.
Usamos un ciclo de publicación semanal
Comenzamos cada día con una sesión de planificación de 30 minutos.
Hicimos un standup diario a la 1 pm todos los días
Hicimos una revisión sprint con el propietario de la épica a las 2:30 todos los días,
seguida de una breve retrospectiva
Cerramos el día con una sesión de refinamiento de casos pendientes y retrospectiva
adecuada, solo para el equipo, para estar listos para el día siguiente
Aunque rompimos algunas de las reglas de Scrum, los beneficios fueron idénticos. Nosotros:

No tuvimos nada que entregar a grupos de marketing posteriores, ya que todos los
grupos estaban representados en el equipo Scrum.
Recibimos comentarios rápidos de los propietarios de la épica a pesar de que no
podían estar con el equipo el 100% del tiempo
Ejecutamos un proceso empírico que evolucionó con el tiempo y de un equipo a
otro.
Confiamos en el equipo para autoorganizarnos
LOS RESULTADOS

Completamos en una semana lo que generalmente se tomaba tres meses, según el

vicepresidente de marketing. Esto no fue magia; esto se debió al enfoque y la
eliminación completa de las entregas.
Engendró otros siete experimentos del equipo de marketing, los cuales
funcionaron más o menos de la misma manera, excepto un sprint de lanzamiento al
mercado que fracasó estrepitosamente.
Un cambio en el proceso general del programa de marketing. Crearon una
analogía tipo autopista para gestionar mejor su proceso. Si la incertidumbre era alta,
usaban el carril HOV (también conocido como - sprint en una épica). Si había baja
incertidumbre, por ejemplo, para las iniciativas de comercialización, se mantenían en
la autopista regular.

Esencialmente, para las nuevas épicas, decidieron qué proceso seguir y aprendieron que
seguir como siempre, o el trabajo repetible, no se beneficiaba en absoluto de este nuevo
proceso.
Es por eso que mencioné anteriormente que el sprint de lanzamiento al mercado falló
estrepitosamente. El equipo sabía exactamente qué hacer, cuánto tiempo tomaría y cuánto
costaría. El esfuerzo por cambiar ese proceso fue alto y empeoró la ejecución.
Los enfoques ágiles funcionan mejor cuando la incertidumbre es alta. No significa que no
funcionará para un trabajo repetible y predecible, significa que tendrás que tomar una
decisión. El esfuerzo de cambiar por el bien de tener un proceso consistente en todos los
equipos puede que no valga la pena.
¿Gestión de cambios moderna?
¿Qué tiene de moderno esto? Me parece una buena facilitación. Esta es la diferencia:
En la gestión de cambios tradicional, se:

Crea un mapa de partes interesadas, una declaración de visión, un plan de mitigación

de la resistencia, etc.
Realiza una evaluación de preparación para el cambio con todo el departamento de
marketing (~ 600 personas)
Asigna un director de proyecto para gestionar las cosas
Diseña un libro de tácticas o un modelo de proceso estándar de forma aislada que
todos los equipos usarán
Prueba con algunos pilotos
Extiende si funciona, se ajusta y se extiende si no funcionó
Cierra la iniciativa

En la gestión de cambios moderna, se:

Co-crea un camino a seguir con una conversación facilitada (el despegue que hice
que involucró a todos en el primer experimento)
 Validan las suposiciones (actuar antes, incluir a las partes interesadas al final de cada
experimento y utilizar esos conocimientos para los siguientes experimentos)
Crea un proceso adaptable impulsado por los equipos (su analogía con la autopista)
Ofrece a los equipos la libertad de crear su propio proceso único dentro de un
conjunto de restricciones razonables.
Hace que las personas que participaron en los primeros experimentos se convirtieran
en defensores y 'capacitadores' de nuevos equipos.

La diferencia fundamental es que lo moderno le dio opciones a la organización. Por eso lo

uso. Si hubiera seguido un libro de tácticas ágil estático con ellos, esto hubiera sido el
enfoque equivocado para ellos. Al adoptar la postura de un entrenador y resolver problemas
con el apoyo de las ideas modernas, les di la opción de cómo proceder.
Lo he visto muchas veces a lo largo de los años. La empresa consultora impone su modelo a
la organización y se olvida del contexto. Jerry Weinberg llama a esto dejar caer el cambio a
través del agujero en el piso 2.
El método que utilizo es más como su enfoque de difusión 3, el cual se parece más a agregar
leche al café. Y no, Niels Plfaeging no inventó ese término 4, ¡pero me encanta su trabajo!
CÓMO PASAR DE LO TRADICIONAL A LO MODERNO
En el próximo capítulo, les mostraré especialmente cómo adapté el manifiesto ágil a este
cambio, y cómo el equipo adaptó el manifiesto ágil a su contexto ajeno al software.
Pero primero, quiero que crees un manifiesto de cambio que capture el espíritu del manifiesto
ágil. He realizado este ejercicio en mis talleres desde 2014 y siempre es interesante ver cómo
la gente modifica el manifiesto ágil de un enfoque de software a un enfoque de cambio.
Esta es tu tarea.
Se te asignó la creación de un proceso de gestión de cambios ágil. Utilizando el manifiesto
ágil como guía, ¿cómo lo reescribirías para adaptarlo a un contexto de gestión del cambio?
He aquí algo con qué empezar. El manifiesto ágil dice, software de trabajo en vez de
documentación completa.
Como agentes de cambio, no estamos entregando software, entonces, ¿cómo cambiarían eso?
En el próximo capítulo, te daré instrucciones más detalladas si estás estancado. Observa lo
que otras personas han encontrado en changeagility.org 5. Si eres lo suficientemente valiente,
también puedes compartir allí tu manifiesto que no es de software.
 TU MANIFIESTO DE CAMBIO

¡E spero que no te hayas saltado al capítulo que tiene algunos ejemplos! Supongo que no
importa si lo hiciste, pero siempre me gusta documentar mis pensamientos primero y luego
ver lo que piensan los demás.
Estas son las instrucciones para el ejercicio que hago en mi taller:
Dados los cuatro valores del manifiesto ágil, ¿cómo escribirías un manifiesto de cambio que
capture el espíritu del manifiesto ágil para guiar cómo aborda el trabajo de cambio?
Por ejemplo, el segundo valor del manifiesto ágil es el software de trabajo en vez de la
documentación completa. Suponte que estás trabajando en una reorganización y no estás
entregando software. ¿Cómo cambiarías ese valor para adaptarlo al contexto?
Las reglas de este ejercicio son simples:

Puedes tener la cantidad de declaraciones que desees. No es necesario que tengas

cuatro solo porque el manifiesto ágil tiene cuatro.
Si deseas “aplicar la gestión ágil a los cambios”, tu manifiesto debería reflejar eso de
alguna manera
Después de crear tu manifiesto, te daré un pequeño escenario para probarlo, junto
con un enlace donde puedes ver lo que hicieron otras personas en el mismo
escenario.
LA PARTE DIFÍCIL
¡Es hora de que trabajes un poco! Puede que estés leyendo este libro en un lector electrónico,
así que toma un trozo de papel o una pizarra y piensa en ello.
Compara tu manifiesto con otros en changeagility.org
TEORÍA PROMULGADA VERSUS TEORÍA ADOPTADA
El mundo empresarial actual está contaminado con respuestas fáciles. Podría escribir la
declaración: “No importa lo ágil que sea, las mejores organizaciones se enfocan en los
resultados”, y algunas personas saltarían de sus asientos gritando, “¡¡¡SÍ!!! ¡¡¡Eso es MUY
cierto!!!”
Es interesante y puedes creerlo, pero no es útil.
Ahora que tienes tu manifiesto de cambio, este es tu escenario:
El cambio en el que estás trabajando no va bien desde la perspectiva de tu patrocinador
ejecutivo. Ella te envía un correo electrónico exigiéndote que elabores una hoja de ruta de 12
meses, que incluya todas las actividades y medidas específicas que utilizarás para garantizar
un cambio exitoso.
Te conviene utilizar un enfoque ágil para esto. Piensa o escribe lo que harías basándote en el
uso de tu manifiesto de cambio ágil como guía.
INDIVIDUOS QUE INTERACTÚAN
He aquí una breve historia sobre de dónde vino la inspiración para este ejercicio. Una
organización gubernamental se estaba embarcando en un cambio de varios años que
finalmente afectaría a 8,000 personas. El líder del programa, Jimmy, había visto una charla
que di en una conferencia de cambio local y quería probar algunas de estas ideas ágiles.
Nos reunimos durante un par de horas, y lo más sencillo que acordó hacer fue colocar un gran
muro visible, invitar a las partes interesadas frente a él una vez a la semana en lugar de
informar sobre el estatus y realizar reuniones diarias con el equipo de cambio principal.
Eso es todo: no hubo un gran plan, ni un PowerPoint de 73 páginas ni nada más. Se hizo
hincapié en facilitar las interacciones entre las personas en lugar de centrarse en construir un
proceso de gestión de cambios ágil y complejo. Aquí está el correo electrónico que me envió
más de un año después:
correo electrónico traducido: “Hola Jason, el proyecto va bien. Estamos en camino de
lanzarse en vivo. Estoy seguro de que las cosas no serían tan buenas o no hubieran ido tan
bien sin los principios e ideas del cambio Lean que compartiste con nosotros desde el
principio.
La alta dirección está entusiasmada y acordó retrasar el lanzamiento hasta que las personas
afectadas por el cambio estén listas. Creen que estamos locos por dedicar tanto tiempo a la
gestión del cambio.
me encanta el tablero kanban! He perdido la cuenta de cuántos problemas hemos resuelto y
cuántos baches hemos evitado haciendo una parada semanal de 30 minutos.”
ES TU OPCIÓN
He contado esta historia en muchas organizaciones y algunas han dicho: “Bueno, eso nunca
funcionará aquí... somos una empresa global... bla, bla, bla”.
Eso tiene tanto sentido como decir: “Intenté jugar al hockey; el hockey no funciona”.
Este método funcionó para Jimmy porque él era el catalizador que quería que funcionara.
Influyó en los demás con su energía positiva, y los escépticos se unieron. No era obligatorio,
solo sabía que era mejor para esta situación, por lo que tomó acción.
Desde 2014, he visitado muchas organizaciones en muchas industrias en más de 12 países, y
el patrón siempre ha sido el mismo: Un agente de cambio apasionado que cataliza a las
personas que los rodean para que estas ideas funcionen. Los agentes de cambio que buscan el
próximo proceso mágico o las mejores prácticas rara vez lo hacen funcionar, no por ellos,
sino porque el cambio en el que están trabajando no es necesario.
Nunca he sido fanático del término mentalidad porque creo que se usa como un palo, que
significa “tengo una mentalidad de crecimiento, pero esos idiotas con los que trabajo tienen
una mentalidad estancada, ¿cómo los cambio?”
Algunos dirán que lo que describo en este libro tiene que ver con la mentalidad del agente de
cambio, pero quiero evitar esos términos a favor de mirar el cambio a través de diferentes
lentes.
Recuerda que tienes una opción. Mantente fiel a quién eres y si crees en lo que hay en tu
manifiesto, esto inspirará a otros a abordar el cambio de manera diferente.
Ahora que has creado tu manifiesto de cambio, te mostraré las dos formas en que usamos el
manifiesto ágil para guiar cómo abordé el cambio con el equipo de marketing y cómo lo
usaron para abordar su trabajo no relacionado con el software.
 PERSONAS E INTERACCIONES

Aunque las declaraciones de la derecha tienen un valor, valoramos más las declaraciones de
la izquierda.

M uchos parecen pasar por alto la nota al pie 1 del manifiesto ágil e
inmediatamente sacar conclusiones de que ágil es anti-proceso o anti-
herramienta.
A lo ágil podría importarle menos; son los practicantes ágiles los que hacen esta suposición
basándose en sus creencias. Es por eso que ves tanta divergencia y conflicto entre los campos
ágiles. La gente de Kanban tiene su estilo, la gente de Scrum tiene el suyo, y los pragmáticos
en su mayoría ignoran el ruido y hacen lo que les funcione.
Nos gusta pensar que somos pragmáticos, pero no lo somos. Fui un fanático de Scrum
durante años; luego acepté que en realidad me contrataban para ayudar a la gente a resolver
problemas en vez de instalar métodos.
CÓMO CAMBIÉ MI ENFOQUE HACIA EL CAMBIO
Mencioné el método del “hoyo en el piso” de Jerry Weinberg en un capítulo anterior. Las
personas de más alto rango deciden el cambio y, metafóricamente, lo dejan caer por el
agujero del piso más alto de la organización. Luego se deja a cargo de las personas
encargadas del cambio para garantizar un cambio exitoso.
Con este equipo de marketing, las personas de alto rango decidieron que querían que su gente
trabajara de una manera más ágil, por lo que establecí restricciones basadas en el uso del
primer valor de ágil: individuos e interacciones sobre procesos y herramientas.
La norma sería que yo, el agente de cambio, me vaya y cree un plan, consiga aprobación y
participación, luego entre en modo de ejecución.
En cambio, eliminé ese desperdicio al establecer la restricción de que todo el departamento
debía participar en el despegue. No es que NO haya tenido un proceso; tenía un meta-proceso
abstracto, que era simple y lo suficientemente bueno para co-crear el cambio con todos los
afectados.
Al hacer esto juntos, conversamos sobre temas importantes tales como:

¿Qué espera el equipo del entrenador?

¿Qué espera el entrenador del equipo?
¿Cómo sería el éxito?
¿Cómo sabremos si vamos en la dirección correcta?
¿Qué no vamos a cambiar?
¿Cuáles son nuestros acuerdos de trabajo?

Como teníamos a todos en el despegue, las interacciones entre nosotros ayudaron a los
miembros del equipo a ver lo que era importante para mí, el entrenador y los patrocinadores,
y viceversa.
Creamos nuestro enfoque juntos, hicimos concesiones en donde las necesitábamos y nos
adaptamos cuando tenía sentido hacerlo.
LA FORMA EN QUE EL EQUIPO DE MARKETING CAMBIÓ SU ENFOQUE
DEL TRABAJO SIN SOFTWARE
Seguir este valor fue sencillo para el equipo de marketing. Contamos con representación de
seis divisiones de marketing, por lo que pudimos resolver desafíos entre departamentos a
través de nuestras interacciones.
Normalmente, un equipo haría su parte y la pasaría al siguiente equipo. Cuando terminamos
el sprint en nuestra épica, el vicepresidente dijo que lo que nos llevó dos semanas en el
nuevo proceso, por lo general, se tomaba unos tres meses debido a traspasos y procesos
complicados.
Aunque lo hizo sonar como magia, lo único que hicimos fue reunir un equipo multifuncional,
lo que redujo drásticamente el tiempo de toma de decisiones.
El primer principio ágil es universal; en caso de duda, reúne a las personas en lugar de crear
otro proceso o comprar una herramienta.
OTRA HISTORIA CORTA
He trabajado en muchas organizaciones empresariales que atraviesan una transformación ágil
y, por lo general, se encuentra un centro de excelencia ágil, un equipo de cambio
organizacional, un equipo de gestión del cambio, un equipo de mejora de procesos y, a veces,
dos o tres departamentos más con objetivos superpuestos.
Cuando se trata de cambios, estos equipos terminan compitiendo entre sí, lo que conduce a
crear documentos de gobierno de 700 páginas.
Un banco grande con el que trabajé combinó a personas de todos estos grupos para trabajar
con un propósito y una visión. Contando con personas de diferentes orígenes y áreas
funcionales, tenían diferentes habilidades y conocimientos, lo que permitió que las mejores
ideas salieran a la superficie rápidamente. ¡Aquí es cuando la fricción se convierte en algo
positivo!
Cuando se te asigne un cambio, aquí hay algunas preguntas que puedes hacer antes de iniciar
el cambio:

¿Quién hace esto hoy?

¿Qué está cambiando y para quién?
¿Qué fuerzas en competencia existen? (Por ejemplo, trabajé con un equipo al que se
le dio un objetivo que estaba directamente en desacuerdo con otro equipo, por lo
que, en lugar de simplemente seguir órdenes, desafiamos las suposiciones sobre lo
que se nos pedía que hiciéramos).
¿Qué posibles consecuencias no deseadas existen?
¿Qué tan formales son los procesos existentes? ¿Qué podemos reutilizar? ¿Qué
procesos necesitan ser desmantelados?

El primer valor del manifiesto ágil está diseñado para explorar los límites del sistema, las
normas existentes y las interacciones entre personas, equipos y departamentos. Comencemos
a explorar lo que existe hoy antes de diseñar nuevos procesos o forzar a las personas a usar
nuevas herramientas.
 ¿SOFTWARE DE TRABAJO?

“Cumpliste con todos los requisitos, pero ese software no resuelve mi problema”.

H e visto esto muchas veces a lo largo de los años. Los equipos se ven obligados a
cumplir con la orden y pierden de vista el problema que se les pidió que
resolvieran.
La gente sabe qué software necesita cuando lo ve. El segundo valor ágil consiste en mostrar
el software en funcionamiento antes, para que pueda adaptarse a las necesidades cambiantes
de la empresa o los clientes.
CÓMO CAMBIÉ MI ENFOQUE HACIA EL CAMBIO
Seguir este valor fue similar al anterior. Durante el despegue, acordamos no usar PowerPoint
para documentar procesos y comunicarnos, lo cual era la norma para ellos.
“Solo envíame el paquete” era el código para “No tengo tiempo para esta conversación”.
Acordamos no documentar absolutamente nada sobre el proceso de cambio, y esto funcionó
debido a la relación y la credibilidad que había creado al trabajar allí los últimos años.
Comprendí la sensación de seguridad al documentar este proceso, pero no era necesario.
Todavía.
LA FORMA EN QUE EL EQUIPO DE MARKETING CAMBIÓ SU ENFOQUE
DEL TRABAJO SIN SOFTWARE
Es fácil para proyectos de software. El equipo crea software; la gente lo usa y da su opinión.
Si no estamos entregando un software que funcione, ¿cómo adoptaríamos este valor ágil?
Durante el despegue, discutimos explícitamente cuál era nuestra versión de software de
trabajo:

Una validación de mercado de la solución.

Un análisis de impacto sobre cómo implementar la solución.

Una vez que discutimos los límites organizacionales y cuál era la definición de “terminado”,
nos pusimos en marcha. Aquí es donde las cosas se vuelven turbias. Cualquier practicante
habilidoso y ágil verá inmediatamente ese segundo punto y gritará, “¡¡¡¡¡HEY ESPERA!!!!
¡¡¡¡¡ESO NO ES ÁGIL!!!!! “ ¡¡¡DEBERÍAS HABER CONSTRUIDO Y PUESTO EN
FUNCIONAMIENTO LA SOLUCIÓN!!! ¡¡¡NO PUEDES OPTIMIZAR LOCALMENTE
ASÍ!!!”
Tendría razón, pero solo en teoría. A medida que lo ágil evolucionó durante las últimas dos
décadas, los profesionales ágiles aprendieron que hay fuerzas sustanciales en la organización
que están en desacuerdo con la entrega ágil.
En este caso, 25 equipos debían participar en la entrega de nuestra solución. Es fácil ser un
agente de cambio de sillón y decir cosas como, “Necesitamos reducir de tamaño nuestras
organizaciones” o “Realmente, ustedes deberían preguntarse por qué necesitan 25 equipos
para hacer algo tan simple”.
Una vez que lo ágil expone este problema a la organización, la organización puede optar por
hacer algo al respecto. Si la reducción es la respuesta, ¿quién decide a quién se despide? ¿Los
entrenadores ágiles?
Es una simplificación excesiva decir que podríamos haber construido un equipo
multifuncional completo para entregar la solución. Podríamos haberlo hecho, pero eso habría
implicado a 12 vicepresidentes reunidos en torno a una reorganización de miles de personas,
lo que supone mucho más trabajo del necesario.
 COLABORACIÓN CON EL CLIENTE

“Haz que tu apretón de manos sea un vínculo más fuerte que cualquier contrato
escrito”. - Steve Maraboli, Sin pedir disculpas: Reflexiones sobre la vida y la
experiencia humana

L os contratos pueden ser complicados. Dedicamos mucho tiempo y esfuerzo a

crearlos para combatir los inevitables escenarios hipotéticos, y generalmente sucede
una de dos cosas:

1. Nunca los volvemos a ver y simplemente trabajamos juntos.

2. Lo usamos como un palo para golpear al otro cuando la relación se estropea.

La mayoría de las veces, lo que sucede es el escenario #2.

En términos generales, los contratos ágiles se tratan de tiempo y costo fijos, mientras que el
alcance se convierte en la variable.
Por ejemplo, una vez fui subcontratado por una empresa de consultoría para desempeñarme
como entrenador ágil para una organización de 300 personas.
Después de una semana, la gerencia no tenía ganas de hacer nada y todavía me quedaban 30
días para cumplir con ellos. El CTO fue un gran apoyo, pero dejó la organización
aproximadamente una semana después, lo que lo hizo aún más difícil. Metafóricamente,
deambulé por el campo buscando problemas que pudiera ayudar a resolver.
Aquellos incluyeron ayudarlos a fusionar sus repositorios de código, automatizar las notas de
la versión, visualizar la historia de la empresa y gritarle a un idiota miembro del equipo que
se estaba comportando como un completo idiota. Nada de eso fue para lo que me contrataron.
CÓMO CAMBIÉ MI ENFOQUE HACIA EL CAMBIO
Como mencioné, los contratos son complicados, pero a veces necesarios. Tengo un contrato
de servicio básico general que utilizo con las organizaciones. Es lo suficientemente general
como para decir que, si mi tiempo y costo son fijos, lo entregable está sujeto a negociación.
En un caso, para evitar la increíble protección de OpEx (gastos operativos) de una
organización empresarial, acordamos llamar a lo que estaba haciendo aumento de proyectos
en lugar de coaching de lo ágil.
Las actividades de ampliación del proyecto se podrían facturar al departamento o proyecto,
mientras que el coaching y la formación se considerarían gastos operativos. Esto último
incitaría el miedo y los disturbios en toda la organización, ya que a nadie se le permitió
aumentar los gastos operativos sin la bendición de las autoridades.
Hubo dos componentes principales que demuestran cómo viví este valor:

1. Les dije explícitamente a los vicepresidentes que mi alcance es lo que sea necesario
y que variará de un equipo a otro. Mi costo y tiempo se fijarán en “X horas
facturables por semana”, punto.
2. Implementé una medida de retroalimentación a través de un Net Promotor Score
(NPS) modificado para determinar si cumplí con el contrato.

Después de cada despegue con los equipos y los equipos de TI con los que trabajé
anteriormente, encuestaba al equipo, que sirvió como la medida de retroalimentación que
mencioné, con estas dos preguntas principales:

1. ¿Qué probabilidades hay de que recomiende tener un entrenador para los equipos
que quieran comenzar con lo ágil?
2. ¿Qué tan probable es que recomiende al entrenador específico que tuvo?
LA FORMA EN QUE EL EQUIPO DE MARKETING CAMBIÓ SU ENFOQUE
DEL TRABAJO SIN SOFTWARE
Esta es una de mis historias favoritas. Mientras hacíamos girar los engranajes sobre algunas
suposiciones, nos dimos cuenta de que necesitábamos comentarios de clientes reales.
Nuestro épico propietario, conocía al gerente del centro de llamadas y usó $ 500 de su
presupuesto para dar cupones a las personas que se quedaran en el teléfono para responder un
par de preguntas después de llamar al soporte.
En 24 horas, recibimos cientos de comentarios que nos ayudaron a cambiar nuestro alcance.
La lección aquí: Los contratos y acuerdos siempre serán necesarios, pero no deben desviar la
atención de hacer lo correcto para el cliente.
 RESPUESTA AL CAMBIO

“L os planes no valen nada, pero la planificación lo es todo”.

***
La sabiduría popular dice que Winston Churchill dijo esto, pero quién sabe. ¡Tenemos un
historial de atribuir citas incorrectamente a las personas equivocadas! 1
La adaptabilidad es esencial para responder a eventos fuera de nuestro control. Esto no
significa que no debas planificar, ni tampoco significa que seas un mal planificador.
Significa que debes saber cuándo adaptarte a las condiciones cambiantes, y especialmente a
aquellas que no puedes controlar. En el mundo actual, las organizaciones tienen menos
control de su futuro de lo que solían tener.
¿Recuerdas la historia de Southwest Airlines? Se adaptaron a las cambiantes condiciones de
viajes y lograron hacerlo sin capacitar a su personal en prácticas ágiles. Mirando a otro
gigante, muchos se centran en la desaparición de Kodak y su falta de adaptación al cambio a
la fotografía digital, pero todavía existen después de 138 años. ¿Cómo lo lograron?
Se enfocaron en otras áreas de su negocio, como cámaras retro, cámaras a prueba de agua y
accesorios móviles para tomar fotos con tu teléfono 2. Aunque Kodak tardó en adaptarse y no
pudo luchar contra los depredadores de las cámaras digitales, continuó ganando dinero
vendiendo y licenciando sus patentes de tecnología, e incluso se ha expandido a nuevas áreas
como la tecnología blockchain y la gestión de derechos digitales.
La lección de esta historia es: No repitas lo que oyes porque se alinee con tus creencias, lee
tú mismo la historia.
CÓMO CAMBIÉ MI ENFOQUE HACIA EL CAMBIO
En el departamento de marketing de Bigco, no cambié nada sobre cómo enfoco el cambio.
Diría que mi enfoque cambió a finales de la década de 2000 cuando me di cuenta de que
ninguna organización me pedía que “los hiciera ágiles” y que los capacitara en prácticas
ágiles.
Me estaban pidiendo que los ayudara a aclarar un problema y a encontrar opciones para
seguir adelante.
Este valor moldeó mi actitud como agente de cambio al enseñarme cómo hacer un plan
“suficientemente bueno” que fuera lo suficientemente flexible como para ser adaptado más
tarde.
LA FORMA EN QUE EL EQUIPO DE MARKETING CAMBIÓ SU ENFOQUE
DEL TRABAJO SIN SOFTWARE
En un capítulo anterior, escribí sobre cómo el experimento de comercialización fracasó
estrepitosamente. Me alegro de que así fuera.
Fue la segunda vez que probamos este proceso de sprint-en-una-épica, y la reacción fue tan
negativa que el departamento de marketing se dio cuenta de que no podían tener un proceso
estandarizado que todos debieran usar.
Por eso crearon la analogía de la autopista. Las personas que formaron parte del segundo
experimento lo odiaron y comenzaron a hablar mal de los demás: “Oh, evita que te arrastren
a un sprint, son horribles”.
En lugar de superar lo que normalmente etiquetaríamos como resistencia, lo usamos como
entrada para adaptar nuestro plan.
Existen debates en la comunidad ágil sobre la utilidad del manifiesto ágil. Algunos dicen que
es atemporal; otros dicen que está desactualizado y algunos dicen que apesta solo porque
diecisiete hombres blancos lo crearon.
Estoy en el campo de “es atemporal”. Creo que cualquier grupo de personas puede ser ágil
sin importar su contexto. ¿Recuerdas a mi papá el fabricante de calderas? Usó prácticas ágiles
en los años 60. Walmart las usa hoy en el comercio minorista, al igual que los bancos
minoristas y otras empresas que no son de software.
La clave es, y esto lo indica el manifiesto ágil, que hay valor en las declaraciones de la
derecha, pero valoramos más las declaraciones de la izquierda.
En la Parte II, voy a cambiar a los doce principios ágiles y haré que los adaptes para cambiar
antes de mostrarte cómo lo hago. La mayoría de los mitos con la invención de lo ágil y
continuo de los nuevos métodos surgieron porque nadie los entendía, o peor aún, ni siquiera
los leía.
 PARTE II - LIBRO DE TRABAJO - PRINCIPIOS
MODERNOS DE GESTIÓN DEL CAMBIO

“Es mejor escribir para uno mismo y no tener público, que escribir para el público y
no tener identidad propia” - Cyril Connolly, The New Statesman, 25 de febrero de
1933

Nunca olvidaré AYE en 2009 cuando Johanna Rothman dirigió un taller de reinvención de
uno mismo. Le dije que pensaba que quería hacer lo que hicieron ella y el resto de los
anfitriones.
“Empieza a escribir”, dijo. Así que lo hice. Empecé un blog llamado más ágil que ágil
porque me volví ágil al revés, además era un gran fan de Rob Zombie y amaba la canción
More Human Than Human.
Eso me llevó a escribir Lean Change Management en 2013 porque pensé que era una historia
interesante que la gente querría escuchar. No había intención de crear talleres, capacitaciones
en línea, comunidades ni nada más.
Aquí estamos hoy, he realizado cientos de talleres en más de 12 países y tengo suficiente
contenido para escribir 5 libros basados en mis experiencias.
Escribir el blog y luego el libro me ayudó a encontrar mi estilo y refinar mi mensaje. Más
importante aún, me dio una vía para expresar mis pensamientos personales sobre el tema. La
escritura siempre ha sido valiosa para mí porque es como una terapia. Me ayuda a encontrarle
sentido a mis pensamientos porque a veces soy un pensador bucal. Todos tenemos principios
por los que vivimos, y uno de los míos ha sido ayudar a las personas a encontrar claridad o
inspiración en algo que los impulse a actuar y hacer que el cambio suceda para ellos.
Entonces, ¿qué son exactamente los Principios de gestión del cambio moderno? Eso suena
lindo en un Tweet, pero ¿qué diablos significa? ¿En qué se diferencian los principios de los
valores?
Ya les he mostrado los valores del Manifiesto Ágil, así que antes de entrar en los principios,
definiré lo que quiero decir con la diferencia entre valores y principios.
Los valores son personales. Pueden cambiar con el tiempo según las experiencias que
tengas, y evolucionarán a medida que aprendas, crezcas y envejezcas.
Los principios se derivan de valores y generalmente son estáticos. Los principios no
cambian, pero nuestras situaciones sí.
En mi mundo, los valores dan forma a tus principios, que influyen en tu forma de actuar. Por
ejemplo, si uno de mis valores es la honestidad, mis principios podrían ser No mentiré y No
esconderé ni retendré la verdad.
Esas son dos cosas diferentes y cada una nos ayudará a actuar en diferentes escenarios. No
mentiré abiertamente, pero podría estar en una situación en la que retener información podría
beneficiarme. Eso iría en contra de mis principios.
Sutil, pero importante.
No quiero obsesionarme demasiado con las definiciones estrictas de valores versus principios
porque nuestros valores, principios y sistemas de creencias son simbólicos y ayudan a
moldear quiénes somos como seres humanos.
El Manifiesto Ágil tiene cuatro valores y doce principios. Por sí mismos, los valores no
brindan suficiente información para ayudarnos a tomar medidas. Se podría decir que solo
mirar los valores de forma aislada podría haber conducido a muchos de los mitos ágiles que
vemos hoy.
¿Has escuchado a alguien en tu organización decir que, “ya no necesitamos documentar
cosas porque somos ágiles”? O, “no necesitamos planificar; podemos cambiar las cosas
cuando queramos porque somos ágiles”.
Yo sí.
En la Parte I: Manifiesto de gestión del cambio moderno, creaste un manifiesto de cambio
que captura el espíritu del Manifiesto ágil. Luego, probaste tu manifiesto en un escenario.
Pudo haber sido fácil saber cómo aplicarlo sin un conjunto de principios diseñados para
ayudar a ponerte en acción, pero imagina que toda tu organización quiere vivir según los
principios ágiles. Sería más difícil porque los valores de cada persona probablemente serán
diferentes.
En los próximos capítulos, te mostraré cómo adaptar los doce principios ágiles al cambio.
Más importante aún, te ayudaré a comprender cómo ciertos principios tienen más peso según
su entorno y qué tipo de cambio está atravesando tu organización.
Aquí es donde comenzamos a movernos hacia las ideas prácticas que desbloquean el poder de
utilizar un enfoque ágil en la gestión del cambio.
 CÓMO ESTÁ ESTRUCTURADA LA PARTE II

C ada uno de los siguientes capítulos seguirá el mismo patrón:

Presentaré el principio ágil y compartiré una breve historia sobre cómo me ha guiado
el principio ágil.
Te pediré que reescribas el principio para que encaje en un contexto de cambio
haciéndote preguntas sobre cómo cambiarías el principio de un enfoque de software
a un enfoque de cambio.
Terminaré con la manera de adaptarlo a un contexto de cambio, y puedes visitar
changeagility.org para ver lo que otras personas han encontrado.

Al final de esta parte, compartiré un ejercicio sobre cómo crear conjuntamente tus principios
y priorizarlos en función de la cultura de tu organización, el tipo de cambio y la composición
de tu equipo de cambio.
¡Aquí es donde las cosas pueden complicarse! Según lo definido en el capítulo anterior, los
principios son estáticos, entonces, ¿por qué deberían ser diferentes para una transformación
ágil o una implementación de software de varios años que cambia radicalmente los procesos
comerciales?
No todos los principios se aplican a cada cambio de la misma manera. Es por lo que he
mencionado que no es posible tener un marco, método o proceso de cambio que lo abarque
todo. La mayor parte del tiempo, estás empezando con elementos universales que
generalmente son verdaderos de un cambio a otro, pero adaptas tu enfoque según el contexto.
Algunos de los principios que verás en este capítulo serán eternos y universales; otros pueden
necesitar ajustes. De cualquier manera, esta es una discusión crítica que se debe tener durante
un despegue con tu equipo de cambio o las personas de tu organización para establecer las
expectativas adecuadas.
Esta es la parte más difícil en cuanto a hablar de principios. Todos sonarán bien, pero ¿por
qué cada organización ágil se comporta de manera diferente si operan con los mismos valores
y principios?
Esa es la pregunta del millón, ¿no?
 CUIDAR A LA GENTE

Nuestra máxima prioridad es satisfacer al cliente mediante la entrega temprana y

continua de software valioso.

V alor ágil: Software de trabajo en vez de documentación completa

Mientras trabajaba como propietario de producto cuando salieron las tabletas por
primera vez, tuve la tarea de crear un nuevo producto. Fue entonces cuando salió al mercado
el primer iPad, lo cual te indica cuánto tiempo hace.
Como las tabletas acababan de salir, pensamos que serían populares, pero no teníamos idea
de cómo se vería un producto para tabletas. En aquel entonces, el diseño web receptivo no
existía, por lo que nuestra primera idea fue un micrositio para clientes de relaciones con
inversionistas (RI). En lugar de navegar a través de grandes sitios web para encontrar
información RI valiosa, estas aplicaciones móviles serían como una guía de referencia rápida
y un escaparate para los clientes de RI.
Entonces, no había una estrategia bien pensada, solo un presentimiento de que las tabletas
iban a ser muy populares, y queríamos estar preparados.
No sabíamos lo que era un software valioso para estos clientes, por lo que este principio se
transformó en:
Mi mayor prioridad es satisfacer al cliente mediante la validación temprana y continua de lo
que es valioso para ellos.
ADAPTAR EL PRIMER PRINCIPIO AL CAMBIO
Comenzando con este capítulo, te haré preguntas que te guiarán a través de cada principio
ágil y cómo adaptarías cada declaración a un contexto de cambio.

1. ¿Cuál es nuestra máxima prioridad como agentes de cambio?

2. ¿Cómo cumplimos con esa prioridad?
3. ¿Cuál es el cambio equivalente a “software valioso”?
4. ¿Qué significaría temprano y continuo en un contexto de cambio?

Eres más que bienvenido a seguir leyendo si estás en modo de exploración, pero si quieres,
vuelve a escribir este principio desde la perspectiva de ser un agente de cambio antes de
seguir adelante.
En la Parte III, compartiré cómo respondí estas preguntas. Si estás impaciente por ver lo que
otras personas han hecho, puedes conectarte con otros agentes de cambio en todo el mundo a
través de changeagility.org para ver lo que han hecho.
 BIENVENIDA AL CAMBIO

B
***
ienvenidos los requisitos cambiantes, incluso tarde en el desarrollo. Los procesos
ágiles aprovechan el cambio para la ventaja competitiva del cliente.

Valor ágil: Responder al cambio en vez de Seguir un plan

¿Recuerdas la historia del capítulo de Colaboración con el cliente sobre el CTO que se fue y
nadie más tenía interés en mejorar las cosas? El CEO había dicho que quería, “150% de
esfuerzo, manos en el teclado en todo momento ... empujar ... empujar ... empujar” en nuestra
primera reunión de actualización semanal.
Me quedaban 30 días de trabajo en ese lugar, así que, aunque incluí esta historia para
correlacionarla con el capítulo Colaboración con el cliente en vez de La negociación del
contrato, encaja aquí.
Pude haber renegociado el contrato para refinar el alcance, pero en cambio, salté de equipo a
equipo, ayudándoles a priorizar las cosas más importantes en las que necesitaban ayuda.
Trabajé en sprints de cambio de una semana que me dieron la estructura suficiente para vivir
esas últimas semanas.
La empresa fue adquirida un par de meses después de que finalizara mi contrato. Siempre
había sospechado que sucedían más cosas de las que sabía y esto lo confirmó.
ADAPTAR EL SEGUNDO PRINCIPIO AL CAMBIO
Utilizando estas preguntas como guía, ¿cómo adaptarías el segundo principio ágil al cambio?

1. ¿Cuáles son los requisitos cambiantes?

2. ¿Es el retraso en el desarrollo el último momento responsable o es irresponsable?
3. ¿Qué pasa con nuestro proceso de cambio que impide la corrección del rumbo?
4. ¿Qué podría cambiar sobre cómo cambiamos que nos haría más adaptables?
 CICLOS DE RETROALIMENTACIÓN CORTOS

Entrega software que funcione con frecuencia, desde un par de semanas hasta un par
de meses, con preferencia al plazo más corto.

V alor ágil: Software de trabajo en vez de documentación completa

He trabajado en algunas organizaciones donde los equipos ágiles han extendido la
duración de sus sprints porque era demasiado difícil hacer las cosas en poco tiempo.
Hoy, de un par de semanas a un par de meses pueden significar dos semanas o un trimestre
completo. Aun así, la idea central de este principio se expande en el primer principio al ser
más específica sobre la parte “temprana y continua”.
Trabajé con una organización de 300 personas con cinco equipos que estaban luchando por
hacer todo el trabajo en un sprint de dos semanas.
Utilizando este principio como guía, decidimos probar los sprints de una semana. Obligaría al
equipo a dividir el trabajo en partes más pequeñas y manejables.
Los equipos admitieron que odiaban eso al principio. Fue insoportable para ellos, pero
acordaron intentarlo durante al menos tres carreras.
Finalmente, decidieron que los sprints de una semana eran mejores que los de dos semanas,
incluso si los sprints de una semana eran más dolorosos. Tenían la sensación de que una vez
que expandían el cuadro de tiempo, sería mucho más probable que lo expandieran luego más
tarde y, potencialmente, se dividieran en sprints de prueba y desarrollo separados.
He trabajado con muchos equipos de cambio en todo el mundo que aplican la idea de usar
sprints. En un caso, uno de los coaches ágiles de esta organización empresarial estuvo
trabajando en una historia de cambio de usuario durante un año: “como PMO, quiero un
proceso de gobernanza ágil para poder gobernar procesos y equipos ágiles”
Suena bien en teoría, pero más de un año y varios PowerPoint después, nada cambió. Si bien
dividir el trabajo en sprints es una buena idea, aún requiere que pienses de manera diferente
sobre cuáles son esos fragmentos. Recuerda, los sprints provienen del marco de Scrum y el
objetivo de un sprint es entregar algo de valor al cliente.
ADAPTAR EL TERCER PRINCIPIO AL CAMBIO
Utilizando estas preguntas como guía, ¿cómo adaptarías el tercer principio ágil al cambio?

1. ¿Qué estamos entregando si el cambio no se trata de crear software?

2. ¿Cuál es un período razonable para mostrar resultados tangibles?
3. Los resultados del cambio pueden llegar mucho más tarde, ¿qué podríamos ofrecer
que demuestre el progreso y que estamos en el camino correcto?
4. ¿Cómo evitamos la trampa de los ciclos de retroalimentación largos porque sabemos
que los resultados tangibles llevarán mucho tiempo?
 COLABORACIÓN MULTIFUNCIONAL

Los empresarios y los desarrolladores deben trabajar juntos a diario durante todo el
proyecto.

V alor ágil: Individuos e interacciones sobre procesos y herramientas

Lo ágil nunca ha sido asunto de TI, y todavía no puedo creer que algunas
organizaciones con las que trabajo no vean esto. La gente cree que significa que la gente de
negocios y los desarrolladores están unidos trabajando febrilmente entre sí durante ocho
horas seguidas todos los días.
ESTE PRINCIPIO SE TRATA DE UNA RÁPIDA TOMA DE DECISIONES.
Suponte que los empresarios y los desarrolladores no trabajan juntos a diario. El trabajo se
retrasa porque los desarrolladores hacen suposiciones sobre las funciones y, cuando los
empresarios se dan cuenta, es demasiado difícil y costoso cambiarlo.
He aquí un ejemplo del mundo real:
Uno de mis antiguos clientes era una gran institución financiera que estaba estructurada de
manera tradicional. Había analistas de negocios de TI (BA) y, eh, analistas de negocios
comerciales (BA de negocios) que informaban a diferentes clientes y partes interesadas. Los
BA de TI tienen sus objetivos (a tiempo, dentro del presupuesto) y los BA de negocios tienen
diferentes objetivos (KPI, métricas de negocios para cumplir, etc.)
Debido a esta extraña dinámica, me tomó tres meses persuadir a los BA de negocios para que
dejaran que los BA de TI y, opcionalmente, el resto del equipo Scrum, asistieran a las
reuniones regulares de revisión de clientes y partes interesadas. La magia sucedió en la
primera sesión, cuando los BA de negocios vieron lo valioso que era que el equipo de BAs en
TI hablara directamente con clientes reales y partes interesadas.
Como recordatorio, la revisión del sprint en Scrum es generalmente donde ocurre esa
interacción, pero en un gran programa que involucra a muchas personas, a veces es una buena
idea tener una revisión del final del sprint y una revisión dedicada diferente de las partes
interesadas o clientes.
ADAPTAR EL CUARTO PRINCIPIO AL CAMBIO
Utilizando estas preguntas como guía, ¿cómo adaptarías el cuarto principio ágil al cambio?

1. ¿Qué problemas están causando los retrasos en la toma de decisiones?

2. ¿Qué estructuras existen que impiden la colaboración interfuncional? (Uno común es
la estructura organizativa).
3. ¿Trabajar juntos a diario es una exageración? ¿Qué es una alternativa razonable?
4. ¿Qué ceremonias existen, o cuáles deberíamos crear, que nos permitan acortar los
ciclos de toma de decisiones?
 MOTIVACIÓN INTRÍNSECA

Construye proyectos alrededor de personas motivadas. Bríndales el entorno y el

apoyo que necesitan, y confía en ellos para hacer el trabajo.

V alor ágil: Individuos e interacciones sobre procesos y herramientas

Si estás familiarizado conmigo o con mi trabajo, sabrás que mi camino fue
marcado por la conferencia Amplify Your Effectiveness (AYE). Fue una experiencia de una
semana para no más de 74 personas, lo cual la mantuvo íntima, organizada por Jerry
Weinberg, Esther Derby, Don Gray, Johanna Rothman y Steve Smith.
Johanna había realizado una sesión de búsqueda de uno mismo una noche en la que
exploramos nuestros patrones a través de un gráfico de línea de tiempo de altibajos. Descubrí
que mi patrón es de exploración. Es decir, nunca seré el empleado de 20 años, siempre
desafiaré el estatus quo y tengo poca tolerancia a las tonterías corporativas. En pocas
palabras, soy un empleado terrible y por eso he trabajado para mí mismo durante 20 años.
En esa sesión, le dije a Johanna que pensaba que quería hacer lo que ella hace en algún
momento del futuro. ¿El consejo que me dio? Empieza a escribir. Dijo que me ayudaría a
encontrar mi voz, lo que es importante para mí y hacia dónde quiero ir. Y tenía razón.
El blog que mencioné en un capítulo anterior que comencé llamado Más ágil que ágil fue
diseñado para no limitarme solo a temas relacionados con ágil. Las grandes empresas
evolucionan mirando a través de una lente amplia, no telescópica, así que tomé el mismo
enfoque con mi blog.
Escribí sobre el uso de Dominar los hábitos de Rockefeller en una organización en la que
trabajaba como Scrum Master y Product Owner. También escribí sobre dinámica de equipo,
experiencia del cliente, desarrollo de productos, puesta en marcha simple y más.
La clave de este principio es comprender lo que te motiva. Decidí empezar a escribir porque
seguí el consejo de Johanna y le pregunté qué podía ayudarme a lograr mis objetivos. Eso
desbloqueó mi motivación intrínseca frente a que alguien intentara motivarme a escribir con
algún impulso externo o recompensa.
ADAPTAR EL QUINTO PRINCIPIO AL CAMBIO
Utilizando estas preguntas como guía, ¿cómo adaptarías el quinto principio ágil al cambio?

1. ¿Cómo encuentras a la gente motivada para ser parte del cambio?

2. ¿Qué podría desmotivar a las personas?
3. ¿Qué ayuda y apoyo necesitan?
4. ¿Qué existe en el medio ambiente que los bloquea?
5. La confianza es una palabra de peso; ¿Qué pasa si cometen errores?
 CONTACTO EN VEZ DE TECNOLOGÍA

El método más eficiente y efectivo de transmitir información hacia y dentro de un

equipo de desarrollo es la conversación frente a frente.

V alor ágil: Individuos e interacciones sobre procesos y herramientas

Si no me sigues en ninguna red social, es posible que no te des cuenta de cómo
surgió este libro. Salió de mi cerebro durante unos días en el verano de 2019, y rápidamente
lo olvidé.
Mientras restauraba una copia de seguridad de una computadora el verano siguiente, la
encontré nuevamente. Cuando lo miré, pensé, qué diablos, dejaré que Grammarly sea mi
corrector de estilo (¡lo siento, Julia! 1), y haré la menor cantidad de trabajo para ponerlo en
producción.
La diferencia en mi opinión de este principio hoy es la pandemia de COVID-19. He trabajado
para mí mismo principalmente desde 2001, así que no ha cambiado mucho para mí en mi
vida diaria, pero todos los agentes de cambio que conozco han mencionado más o menos que
sus iniciativas de cambio se estancaron debido a la pandemia.
La pandemia ha hecho que sea más difícil llamar la atención de personas y equipos porque
quedan agotados después de las reuniones en línea para su trabajo diario y no les queda
energía para realizar el cambio.
En algunos casos, se debe a problemas presupuestarios. Muchas organizaciones perdieron
ingresos y simplemente ya no pudieron pagar a los consultores del cambio.
Otro desafío es la falta de conexión física, por lo que visualizar el trabajo es mucho más
difícil. Como ejemplo, mientras trabajaba en un gran banco dentro de una división de 1600
empleados que estaba iniciando una transformación ágil, el vicepresidente me preguntó qué
deberían hacer primero.
Dije “visualiza el trabajo porque si no puedes ver el trabajo, no puedes manejarlo”. Estoy
razonablemente seguro de que se lo robé a Jon Stahl 2. Visualiza primero, y eso te indicará
cuáles son los problemas correctos que hay que resolver. Así lo hicimos, y cumplió su
propósito. Esto todavía es posible con herramientas, pero es mucho más difícil de hacer y eso
hace que el cambio se mueva aún más lento.
Ese vicepresidente tenía su base en otro país, por lo que lo visitaba durante una semana una
vez al mes. Era curioso lo diferente que se comportaba la gente cuando él estaba cerca. Era
un gran tipo, uno de los mejores y más comprensivos vicepresidentes con los que he
trabajado. Le encantaban las pantallas de información y motivaba a las personas que lo
rodeaban a usarlas. La pandemia se ha llevado esa energía.
ADAPTAR EL SEXTO PRINCIPIO AL CAMBIO
Utilizando estas preguntas como guía, ¿cómo adaptarías el sexto principio ágil al cambio?

1. ¿Quiénes serían las partes interesadas de tu equipo de desarrollo? ¿El equipo de

cambio? ¿Otras personas afectadas por el cambio?
2. ¿Cuál es el riesgo de no tener una interacción frente a frente?
3. ¿Qué tan disruptivo y logísticamente difícil sería? (Pista: Nunca escojas el camino
más fácil porque sea norma cultural. Trabajé en una empresa de telecomunicaciones
grande donde podía ver a todas las personas en un área del piso en sus cubículos
asistiendo a la MISMA reunión en línea porque era más fácil realizar múltiples
tareas).
 MÉTRICAS ADAPTABLES

Un software que funciona es la principal medida de progreso.

V alor ágil: Software de trabajo en vez de documentación completa

Hay un par de partes interesantes en este principio. Primero, la palabra principal
muestra que no es la única medida. En segundo lugar, el progreso significa avanzar, no
resultados.
Nos obsesionamos demasiado con los resultados binarios y las mediciones solitarias cuando
se trata de cambios. Es por eso que la gente todavía arroja alrededor del 70% de falla en la
estadística 1. Si estás trabajando para reemplazar una tecnología en la que desmantelarás la
anterior, el porcentaje de adopción no importa. Todo el mundo tendrá que hacerlo sin
importar qué, entonces, ¿por qué seguir usándolo como parámetro de medición?
En los proyectos de software, es más fácil ver el progreso porque se entrega algo tangible. Sin
embargo, en el cambio, los entregables suelen ser invisibles y los resultados se retrasan.
Entonces, a veces inventamos métricas sin sentido solo para tener algo cuando podría ser
mejor tener evidencia e historias anecdóticas que nos digan que vamos en la dirección
correcta.
La clave para utilizar este principio es encontrar el equilibrio adecuado entre diagnósticos y
mediciones, y cambiarlos cuando dejen de ser útiles.
Cuando el cambio está recién surgiendo, los diagnósticos y los ciclos de retroalimentación
cortos son importantes. Más adelante, cuando sepamos más y tengamos más certeza,
podremos refinar estas métricas en función de los resultados que buscamos.
Esto no significa que tengas que omitir las mediciones de resultados al principio;
simplemente no necesitas concentrarte en ellas. Un gran ejemplo es la métrica del valor
ganado. Es una métrica inventada para hacernos sentir bien con el progreso. El valor
entregado en proyectos que utilizan procesos secuenciales es cero, esto es también conocido
como la temida cascada. Todo el valor se gana cuando está en manos de los clientes.
Por el contrario, siguiendo un enfoque iterativo predicado por todos los procesos ágiles, hay
valor entregado consistentemente sprint tras sprint. Eso significa que, si el proyecto se
cancela por cualquier motivo, hay algo de utilidad para el cliente y no solo un montón de
documentos sin terminar.
Es por lo que no me gustan las tarjetas de puntuación y los libros de tácticas, al menos no en
el sentido tradicional. Son estáticos, prescriptivos y no consideran el contexto.
Si empezamos a aceptar que aún no lo sabemos, podemos adaptar las métricas con el tiempo.
Trabajé con una organización de 100 personas que quería que les dijera cómo medirían mi
efectividad como entrenador. Les dije que cualquier evidencia contundente, como defectos
escapados y satisfacción del cliente, sucedería después de que yo ya me hubiera ido ya que
estaba allí con un contrato corto.
Les sugerí que pusieran un cartel en el vestíbulo que dijera cuánto me estaban pagando y les
preguntara a todas las personas con las que interactué las siguientes preguntas:

¿Con qué frecuencia trabajas con Jason? 0 = nada, 5 = todos los días
Cómo te sientes en cuanto a que nuestra organización obtuvo el valor de nuestro
dinero: 0 = pedir un reembolso, 5 = ¡qué ganga!
No lo hicieron, pero usamos un NPS modificado que preguntaba:
¿Qué valor tuvo tener a Jason como entrenador? (0 a 10) ¿Por qué?

El golpe contra NPS siempre parece ser que es solo un número, pero es bastante fácil
preguntarle a la gente por qué pusieron el número que escogieron. En pocas palabras, la
medida que usamos fue simplemente una evidencia anecdótica por una suma de: “Jason nos
ayudó a <hacer esto> y eso nos ahorró aproximadamente una semana de trabajo “
ADAPTAR EL SÉPTIMO PRINCIPIO AL CAMBIO
Utilizando estas preguntas como guía, ¿cómo adaptarías el séptimo principio ágil al cambio?

¿Cuál es el equivalente de cambio del “software funcional”?

¿Cómo se separa “demostrar progreso” de la necesidad de la gente de obtener un
Retorno de inversión y otros indicadores de éxito rezagados?
Si bien el “software funcional” es la principal medida de progreso, ¿qué son las
otras?
¿Cuándo y cómo evolucionaría sus métricas con el tiempo?
 ADAPTARSE AL RITMO

L os procesos ágiles promueven el desarrollo sostenible. Los patrocinadores,

desarrolladores y usuarios deberían poder mantener un ritmo constante de forma
indefinida.
***
Valor ágil: Software de trabajo en vez de documentación completa
En pocas palabras, con este principio se trata de mantener un ritmo sostenible. Es lamentable
que muchos vean que Scrum usa la palabra “sprint” y asumen que se refiere solo a la
velocidad.
El ritmo sostenible se trata de tener la capacidad de mantener un ritmo constante de forma
indefinida. La teoría U 1 se refiere a esto como latidos del corazón.
En mi libro Lean Change Management 2, hablé sobre cómo la Comisión estaba
experimentando tres cambios masivos simultáneamente:

1. Transformación ágil
2. Despidos masivos
3. Una enorme migración tecnológica

Fue una tormenta perfecta, análoga a cambiar el motor del avión mientras volaba.
Este principio se relaciona con lo que los tradicionalistas llaman fatiga del cambio. Hay
demasiados cambios y la gente no puede absorberlos. La desalineación y la falta de cohesión
son los culpables habituales, pero hay otros.
En organizaciones más grandes con equipos ágiles de coaching, cambio, desarrollo
organizacional (OD) y RR.HH., la falta de cohesión ocurre cuando cada departamento está
trabajando en su propio cambio de forma aislada, aunque generalmente hay superposición.
Por ejemplo, los coaches ágiles a menudo se centran en personas del equipo que se sienten
felices, mientras que los de RR.HH. pueden estar ejecutando un programa de satisfacción de
empleados simultáneamente. El equipo está siendo bombardeado por encuestas, información
contradictoria y, a veces, objetivos contradictorios.
Es esencial comprender qué más está sucediendo en la organización que podría distraer a las
personas de dedicar tiempo al cambio.
ADAPTAR EL OCTAVO PRINCIPIO AL CAMBIO
Utilizando estas preguntas como guía, ¿cómo adaptarías el octavo principio ágil al cambio?

1. ¿Cuál es el ritmo natural de cambio de la organización?

2. ¿Qué trabajo del día a día compite con el cambio?
3. ¿Quién está sobrecargado de trabajo?
4. ¿De dónde viene el 'empujón' para el cambio?
 PROCESO DE CAMBIO ADAPTABLE

La atención continua a la excelencia técnica y al buen diseño mejora la agilidad.

V alor ágil: Software de trabajo en vez de documentación completa.

En un contexto de software, este principio trata sobre cómo los equipos de
entrega hacen su trabajo. La excelencia técnica incluye el uso de todas las herramientas de
Extreme Programming (XP) como el desarrollo basado en pruebas, la propiedad colectiva del
código, la programación de pares y más.
A finales de los 90 y principios de los 2000, cuando comencé mi propia empresa de
desarrollo web, usé Active Server Pages (ASP), que usaban Visual Basic (VB) Script. Sin
usar muchas palabras técnicas, el ASP no es un lenguaje de código administrado y el código
está contenido dentro de las páginas web. Eso significa que no hay magia de refactorización
ni herramientas de código inteligentes creadas que se puedan utilizar con los cambios de
forma segura. Si agregaba un campo de datos en un script, tenía que buscar en cada página
ASP el lugar en dónde quería usarlo o cambiarlo.
Accidentalmente causaba daños en los sitios web sin saberlo, y tratar de arreglarlo agregaba
muchas horas a cada proyecto. Estaba harto de gastar todo ese esfuerzo extra, así que construí
mi propio método de pruebas y registros. Luego, cuando hacía un cambio en un lugar, pude
probar rápidamente las partes más importantes de la aplicación. Yo no era tan hábil como
algunas de las herramientas de automatización de pruebas de la actualidad, pero era lo
suficientemente bueno.
Sin enfocarme en las buenas prácticas técnicas, simplemente no había forma de ser ágil, y ese
es el gran error que cometen muchas organizaciones cuando hacen la transición a la agilidad.
Olvidan que el proceso es sencillo; la parte técnica es lo que sustancialmente es más difícil.
Adaptar este principio al cambio será difícil. ¡Con suerte, estás haciendo estos ejercicios
antes de que te muestre cómo los adapté! Es más divertido así (¡yo creo!)
ADAPTAR EL NOVENO PRINCIPIO AL CAMBIO
Utilizando estas preguntas como guía, ¿cómo adaptarías el noveno principio ágil al cambio?

Ágil vs ágil: ¿qué es ser disciplinado y qué es simplemente cambiar las cosas cuando
nos apetece?
¿Cuál es la equivalencia en cuanto al cambio con respecto a la excelencia técnica y
el buen diseño?
¿Cómo sabes si has logrado el cambio equivalente a “excelencia técnica” y “buen
diseño”?
 MANTENLO SIMPLE

La simplicidad, el arte de maximizar la cantidad de trabajo no realizado, es esencial.

V alor ágil: Responder al cambio en vez de Seguir un plan.

Probablemente estés cansado de escuchar mis historias de AYE, ¡pero qué
lástima! ¡Aquí hay otra más!
Jerry Weinberg organizó una sesión titulada Cómo decir que no, y fue tan popular que la
mayoría, si no todos, los que estaban presentes asistieron. Esto fue en un momento en que se
estaba recuperando de un cáncer, estaba en una silla de ruedas y su voz al hablar era bastante
débil.
Recuerdo que me senté en círculo con todos y él empezó con: “Me gustaría que todos dijeran
que no”. Respondimos al unísono: “No”. Continuó diciendo: “¿Fue tan difícil hacer eso?”
Invitó a todos a pensar en un momento en el que quisieran decir que no, pero en cambio
dijeron que sí. Pidió dos voluntarios; uno sería la estrella; el otro sería un actor que
representaría a la persona a la que la estrella quería decirle que no. Los dos voluntarios se
sentaron en el medio del círculo y tuvieron una conversación mientras Jerry dirigía a la
estrella.
Jerry tenía la habilidad de simplificar situaciones complejas. Esta fue una lección de
congruencia. Es decir, comprender lo que la otra persona está preguntando en un contexto
determinado, pero también mantenerse fiel a sí mismo y a lo que necesitas.
Para los equipos de entrega ágiles, decir que no, no es una finalidad. Es más un todavía no
que un no rotundo, y es una forma de priorizar el trabajo. He visto suficientes proyectos con
diecisiete prioridades número uno. (Lo digo en serio.) La mayoría de las veces, estas
prioridades son escenarios hipotéticos o suposiciones no probadas. La naturaleza iterativa de
lo ágil permite aplazar la toma de decisiones centrándose en los elementos de mayor
prioridad.
Eso significa cambiar la conversación a la priorización en lugar de centrarse en lo negativo de
decir que no. En el trabajo de cambio, esto nos ayuda a evitar probar todas las ideas a la vez
al lanzar TODOS LOS CAMBIOS a un equipo u organización, con la esperanza de que
algunos se mantengan.
ADAPTAR EL DÉCIMO PRINCIPIO AL CAMBIO
Usando estas preguntas como guía, ¿cómo adaptarías el décimo principio al cambio?

¿Cómo le dices que no a las partes interesadas que quieren que impulse más cambios
cuando sabes que no es el momento adecuado?
¿Cómo priorizas el trabajo de cambio?
¿Cuánta complejidad agregas a tu cambio o proceso de cambio a través de
suposiciones no probadas o no validadas?
¿Cómo minimizas tu proceso de cambio para poder concentrarte en las personas?
 LAS PERSONAS QUE ESCRIBEN EL PLAN NO LUCHAN
CONTRA EL PLAN

L as mejores arquitecturas, requisitos y diseño surgen de equipos autoorganizados.

***
Valor ágil: Individuos e interacciones en vez de procesos y herramientas
“Las personas que escriben el plan no se oponen al plan”.
Esta es mi cita favorita de Jill Forbes. Trabajaba para National Leasing y utilizaba ideas de
Lean Change Management 1.
Un momento crucial para ella que hizo avanzar el cambio fue cuando ejecutó una sesión de
panel de cambios 2 con el gerente. Ayudó a transferir la propiedad del cambio desde las
personas que ejecutan cambio a las personas afectadas.
Aquí es donde entra en juego el poder de los equipos multifuncionales. En Scrum, el equipo
tiene personas con todas las habilidades necesarias para hacer el trabajo. Eso podría significar
tener desarrolladores, diseñadores, CX / UX, comprobadores y arquitectos en el mismo
equipo.
La clave es tener personas en forma de T, lo cual está evolucionando rápidamente hacia
personas que forman puentes:

Las personas en forma de T tienen una gran habilidad en un área y un puñado de

otras habilidades
Las personas con forma de puente tienen habilidades profundas en un par, o en pocas
áreas, y un puñado de otras habilidades.

Un desarrollador de Java que solo conoce muy bien el Java y tiene un conocimiento
superficial de algunas otras cosas es persona con forma de T. Un desarrollador de pila
completa que conoce muy bien Java, HTML, CSS y Javascript, pero también conoce la
tecnología e infraestructura de bases de datos, tiene forma de puente.
Algunas personas piensan que esto significa que se necesitan personas con múltiples
habilidades que puedan hacer de todo. No es cierto. Esto simplemente significa tener más de
una habilidad especializada para que la autoorganización sea más efectiva.
Un desafío que avanza hacia una cultura que valora a las personas en forma de puente son los
roles y títulos que se les otorgan. He visto miembros de equipos etiquetados como
Desarrolladores Senior Java III que se niegan rotundamente a realizar pruebas o aprender
otras tecnologías porque se les mide en gran parte por la cantidad de código Java que pueden
generar.
Trabajé con una organización que no tenía este problema. Los miembros del equipo
simplemente se llamaban constructores: construían cosas. Algunos se inclinaron hacia las
pruebas, otros más hacia el desarrollo, pero había suficientes personas con múltiples
habilidades para permitirles difundir el trabajo. No dependían tanto del único desarrollador
que sabía cómo cambiar esa parte complicada del código.
Múltiples cerebros son mejores que uno, un equipo de personas tiene mayor probabilidad de
descubrir el camino correcto cuando no se les está ofreciendo una solución.
ADAPTAR EL UNDÉCIMO PRINCIPIO AL CAMBIO
Utilizando estas preguntas como guía, ¿cómo adaptarías el undécimo principio ágil al
cambio?

1. ¿Cuál es el cambio equivalente a la arquitectura, los requisitos y el diseño?

(Sugerencia: no tomes el camino más fácil y digas el plan; todos sabemos que algún
tipo de plan con cierto nivel de detalle es importante)
2. ¿Qué equipos se autoorganizan? ¿El equipo de cambio? ¿La afectación de personas
por el cambio?
3. ¿Qué bardas existen para evitar que la autoorganización caiga en el caos?
 INSPECCIONAR Y ADAPTAR

A intervalos regulares, el equipo reflexiona sobre cómo ser más eficaz, luego
sintoniza y ajusta su comportamiento en consecuencia.

V alor ágil: responder al cambio en lugar de seguir un plan.

En una palabra, retrospectivas. A mi amigo y colega Declan Whelan le gusta
decir que, si solo puedes hacer una práctica ágil, elige retrospectivas porque, sin importar qué
proceso sigas, mejorarás las cosas con el tiempo.
Mientras trabajaba en una organización de 100 personas con una jerarquía plana (sin gerencia
intermedia), el CTO y Scrum Master se quejaron de que el equipo nunca haría mejoras y que
las retrospectivas eran inútiles. En realidad, fueron inútiles debido a la falta de propiedad del
equipo.
El CTO y Scrum Master estaban decidiendo qué mejorar en lugar de dejar que el equipo lo
resolviera. Cuando facilité su siguiente retrospectiva, le pedí al CTO y al Scrum Master que
observaran y no dijeran nada.
Se sorprendieron al escuchar las ideas que se le ocurrieron al equipo. Estas eran ideas en las
que nunca hubieran pensado, pero pensaban que eran ideas excelentes. La primera idea que
eligieron para mejorar fue el standup diario. Los stand-ups tomaban demasiado tiempo y
contaban con demasiados detalles para el equipo, así que hablamos sobre el propósito del
standup. En Scrum, es una ceremonia para planificar un objetivo diario que contribuye al
objetivo del sprint.
El equipo decidió redactar un objetivo diario en su pizarra y probarlo para un sprint. Después
del primer sprint, pensaron que no ayudaba mucho, así que lo refinamos y profundizamos. El
verdadero problema fue que no hicieron una planificación del sprint lo suficientemente
completa, por lo que los detalles que generalmente surgen no aparecieron hasta la mitad o
cerca del final del sprint.
Después de algunos sprints, el equipo aprendió que controlaban qué mejorar y cómo hacerlo.
ADAPTAR EL DUODÉCIMO PRINCIPIO AL CAMBIO
Utilizando estas preguntas como guía, ¿cómo adaptarías el duodécimo principio ágil al
cambio?

1. ¿Con qué frecuencia tu equipo de cambio refleja y refina tu proceso de cambio?

2. ¿Cómo participan las partes interesadas?
3. ¿Qué sucede con las personas afectadas por el cambio?
 PRIORIZAR SUS PRINCIPIOS

El cambio organizacional es como un cubo de Rubik hecho con focos LED que
cambian de color. Puede ser más difícil de resolver con cada movimiento que hagas.

H ay una cantidad de factores que afectan la forma en que abordas el cambio:

¿Qué tipo de cambio es este? ¿Una reorganización? ¿Una transformación ágil? ¿Una
implementación de sistema? ¿Un programa de innovación?
¿Cuál es la actitud de los líderes?
¿Cómo es la cultura en general? ¿Qué pasa con las subculturas dentro de la
organización?
¿Cuáles son las normas organizativas existentes?
¿Cuál es la estructura de la organización?
¿Cómo funciona la influencia?

Si bien hemos analizado los cuatro valores y los doce principios hasta ahora, es posible que
debamos centrarnos en algunos más que en otros.
Hay un gran juego llamado Pocket-Sized Principles1 que ayuda a los equipos a internalizar y
comprender profundamente los doce principios, y estos son los conceptos básicos de cómo
funciona:

1. Preséntale a un grupo de personas los doce principios.

2. Pídeles que resuman cada declaración en tres palabras o menos.

El objetivo es que el grupo de personas se una en torno a un entendimiento común del

principio.
Durante la última década, modifiqué el juego para las organizaciones que querían
transformarse en ágiles o que querían volverse más ágiles con sus prácticas de gestión de
cambios.
Después de completar la primera parte, les hacía estas preguntas:

¿Cuáles de los doce principios serían los tres más importantes para usted?
¿Cuáles de los doce principios serían los tres más difíciles de seguir?
 ¿Cuáles de los doce principios son los que cree que sigue hoy y por qué?

Las preguntas variarían según el contexto, pero el objetivo es buscar la congruencia. Toda
organización dice, y quiere creer, que vive de acuerdo con valores éticos y positivos, y luego
procede a comportarse de manera opuesta.
Un gran ejemplo es la declaración, “valoramos a las personas (seguido de comportamientos
que coinciden con una enmienda faltante), siempre que estén en sus escritorios durante 40
horas a la semana y se adhieran a los objetivos de gestión del rendimiento”.
TODOS DESEAMOS LO MISMO
Me pidieron que pasara una semana capacitando a una división de I + D de 200 personas que
habían estado practicando lo ágil durante un año, pero nunca formalizaron sus prácticas.
Hice este ejercicio con los líderes y todos los miembros del equipo, y aquí están los
resultados:

A LGUNAS COSAS SE DESTACAN .

Primero, ¿por qué el Principio 8, ritmo sostenible, es el más desafiante, pero no es valioso?
Respondieron que la gente se siente con exceso de trabajo, pero les encanta la prisa.
Cualquiera que haya trabajado en una empresa emergente conoce esa sensación. Yo también.
He trabajado para muchos y esa sensación es simplemente increíble. Insostenible, pero
increíble.
Segundo, ¿por qué el duodécimo principio, las retrospectivas, es el más desafiante y valioso?
Respondieron que hacen retrospectivas y obtienen algo de valor, pero no hay nadie que las
facilite, así que gana la voz más dominante.
SEÑALAR CON EL DEDO
Muchas organizaciones hacen esto. La gente de arriba cree que el problema está en los
equipos y los equipos piensan que el problema son las personas de arriba.
Pero ambos quieren lo mismo. Todo el mundo quiere sentirse apreciado, valorado y que
forma parte de algo.
Después de realizar este ejercicio con los líderes y el equipo, estaba claro que ellos querían lo
mismo, así que ahora se convirtió en una elección:

Poner a funcionar los equipos con lo ágil.

Tener un diálogo más significativo para avanzar como organización.

Algunos gerentes eligieron la segunda opción, mientras que otros eligieron la primera opción.
Algunos no hicieron nada. Esto no es una crítica a las personas; recuerdo mi primer puesto de
director, no estaba preparado para ello, así que no habría podido tener estas conversaciones
sin un entrenador.
¿CUÁLES SON TUS PRINCIPALES PRIORIDADES?
En el inicio de este capítulo, mostré algunos factores que deben tenerse en cuenta a la hora de
abordar el cambio.
Con suerte, hiciste los ejercicios del libro de trabajo, pero si no fue así, revisa los doce
principios y elige los tres principales que serían los más importantes para que te concentres
en crear un enfoque más ágil para el cambio.
Luego, elige los tres primeros que serían los más difíciles de seguir, dado tu contexto.
Comparte lo que se te ocurrió y observa lo que hicieron otras personas en changeagility.org
 PARTE III - MI OPINIÓN - PRINCIPIOS
MODERNOS DE GESTIÓN DEL CAMBIO

Hace un tiempo, tuiteé que agregar la palabra ágil a una función (marketing ágil, gestión de
cambios ágil, pruebas ágiles, ventas ágiles, productividad personal ágil) está haciendo perder
el sentido de lo ágil.
Probablemente, esto fue en respuesta a un artículo ridículo sobre cómo transformar su equipo
de ventas en un equipo de ventas ágil y reaccioné.
Como de costumbre, alguien que elige esconderse detrás de un falso identificador de Twitter
que sabe claramente quién soy respondió: “Los que están en casas de cristal ...” como un
comentario obvio a mi primer libro, Lean Change Management.
Respondí: “Bueno, originalmente lo llamé 'Cómo le gusta trabajar a Jason', pero los grupos
focales me dijeron que nadie lo compraría”. Este es el libro sobre cómo me gusta trabajar.
No se trata de brindarte un marco o método a seguir, se trata de transmitir el proceso de
pensamiento detrás de cómo hago para ser un agente de cambio, basado en aprovechar al
máximo los valores centrales de lo ágil.
CÓMO LE GUSTA TRABAJAR A JASON (HOW JASON LIKES TO WORK™)
Perdí la cuenta de cuántas veces me dieron un escenario y luego me preguntaron cómo lo
manejaría. Este libro describe el método de mi locura y te muestra cómo respondí las
preguntas sobre cómo adaptar cada principio ágil al cambio en la Parte II.
Si has estado haciendo los ejercicios hasta ahora, tendrás una mejor idea de lo que hablaré a
continuación. Me inspiré para hacer eso a través de un curso de cambio organizacional que
tomé en el MIT.
Era una mezcla de estudio en línea y autodidacta, y me encantó el formato. El profesor
presentaría un concepto, daría a los asistentes una declaración o un escenario breve y nos
pediría que escribiéramos lo que haríamos y lo que pensamos que podría suceder.
Había que hacer esto antes de continuar, y después de enviarlo, hubo un breve video del
profesor que explica cómo resultó la historia.
Me encantó la idea de aplicar lo que ya sabía y luego hacer que él cerrara la brecha con los
modelos que estaban enseñando, así que pensé que también funcionaría bien en este libro.
Esa es también una de las principales razones por las que se creó changewayfinder.com como
un acompañamiento vivo y continuo de este libro. Hay mucho que puedo aportar, pero hay
mucho más que la comunidad de cambio general puede agregarle. No olvides revisarlo una
vez que hayas terminado este libro.
 CUIDAR A LA GENTE

Nuestra máxima prioridad es satisfacer al cliente mediante la entrega temprana y

continua de software valioso.
¿CUÁL ES MI MÁXIMA PRIORIDAD?

M i mayor prioridad es ayudar a las personas a entender su contexto para que

puedan encontrar opciones para seguir adelante.
¿CÓMO CUMPLO CON ESA PRIORIDAD?
Por defecto adopto una postura de entrenador. Es decir, ayudaré a las personas a descubrir
opciones sin coaccionar, influir o dar consejos no solicitados.
¿CUÁL ES EL CAMBIO EQUIVALENTE A UN SOFTWARE VALIOSO?
Para mí, es la entrega de un momento ¡ajá! medido por una sesión de retroalimentación de
evaluación 0 a 5. Ej.: “Considerando esta sesión, ¿qué valor tuvo para usted de 0 a 5?
Levante la mano, un puño significa 0, 5 dedos significan 5, y si es un 1, ¡juega
decentemente!”
¿QUÉ SIGNIFICARÍA TEMPRANO Y CONTINUO EN UN CONTEXTO DE
CAMBIO?
Para mí, esto se alinearía con el ritmo natural del cambio en la organización y la cantidad de
incertidumbre que trae el cambio.
FORMA DE REPLANTEAR EL PRIMER PRINCIPIO
Nuestra máxima prioridad es satisfacer al cliente mediante la entrega temprana y continua
de software valioso.
Mi mayor prioridad es ayudar a los clientes a entender su contexto a través de frecuentes
conversaciones facilitadas y sesiones de búsqueda de sentido.
FORMA DE GUIAR MIS ACCIONES

En caso de duda, ten una conversación.

Cuando se te pida que crees un mejor plan o hoja de ruta, hazlo de forma co-
creativa.
Responde preguntas con historias para que el cliente pueda relacionar la historia con
cómo podría verse en su organización.
Conectar clientes con otros clientes. Una vez, un cliente empresarial con el que
estaba trabajando quería reorganizar su espacio y querían que yo, el experto ágil, lo
hiciera. En cambio, los llevé a un cliente anterior para mostrarles cómo se vería un
diseño increíble.
 BIENVENIDA AL CAMBIO

Bienvenidos los requisitos cambiantes, incluso tarde en el desarrollo. Los procesos

ágiles aprovechan el cambio para la ventaja competitiva del cliente.
¿CUÁLES SON LOS REQUISITOS CAMBIANTES?

P ara mí, es el alcance del compromiso. Voy a donde se necesita ayuda y no me

preocupo por no poder ayudar a un equipo en particular. Esto también significa
desafiar la falacia de gastos irrecuperables si el cambio se trata de la
implementación de un nuevo sistema. Creo que es mi responsabilidad dejar las opciones
abiertas el mayor tiempo posible.
¿ES EL RETRASO EN EL DESARROLLO EL ÚLTIMO MOMENTO
RESPONSABLE O ES IRRESPONSABLE?
Lo ágil usa la frase último momento responsable para evitar tomar decisiones demasiado
pronto. Hay una línea fina entre eso y ser irresponsable. Para mí, se trata de ayudar a las
personas a tomar decisiones suficientemente buenas con la información que está disponible.
Si creemos que es muy tarde para un cambio específico, aún debemos explorar la posibilidad
en lugar de evitar una conversación difícil.
¿QUÉ PASA CON NUESTRO PROCESO DE CAMBIO QUE IMPIDE LA
CORRECCIÓN DEL RUMBO?
El pensamiento tradicional de gestión de cambios intenta separar la gestión de cambios de la
gestión de proyectos. Eso es lo que a menudo nos coloca en una posición de seguir el plan
cuando la adaptación al cambio es más relevante.
¿QUÉ PODRÍA CAMBIAR SOBRE CÓMO CAMBIAMOS QUE NOS HARÍA
MÁS ADAPTABLES?
¿Son demasiado largos los ciclos de retroalimentación entre lo que está sucediendo para las
personas afectadas por el cambio y las partes interesadas? ¿Tenemos demasiado proceso por
el simple hecho de tener proceso?
Mi regla es tener un proceso de cambio mínimo viable que nos permita enfocarnos en las
personas, no en el proceso.
CÓMO REPLANTEO EL SEGUNDO PRINCIPIO
Bienvenidos los requisitos cambiantes, incluso tarde en el desarrollo. Los procesos ágiles
aprovechan el cambio para la ventaja competitiva del cliente.
Deje las opciones abiertas el mayor tiempo posible y aléjese del resultado para que su opinión
no se interponga en lo que es mejor para el cliente.
FORMA DE GUIAR MIS ACCIONES

Congruencia: Cuando los clientes quieren cambiar las cosas y has pasado mucho
tiempo intentando que funcione, está bien decir: “No me gusta esto ... Pasé mucho
tiempo haciendo XYZ”. Sé fiel a lo que necesitas, pero quédate para negociar.
Exploración de opciones: Definitivamente es más arte que ciencia. Podrías volverte
loco manteniendo cabos demasiado sueltos. Me gusta tener suficientes
conocimientos para crear opciones bien pensadas y, finalmente, experimentos que no
abarcan todo, pero que nos ayudan a tomar una decisión bien informada para seguir
adelante.
Consecuencia de las acciones: Los cambios tardíos tienen consecuencias y no me
refiero a que el cronograma del proyecto diga que llegamos tarde. Me refiero a toda
la refactorización, reentrenamiento y confusión inevitable que sucederá cuando la
organización decida hacer un fuerte cambio de dirección para el cambio. Es
importante hablar sobre lo mala que podría ser la visibilidad del cambio de
dirección. Un problema podría ser que la gente puso su corazón y alma en algo que
los líderes ahora han decidido que no es valioso. ¡Es desmotivador!
 CICLOS DE RETROALIMENTACIÓN CORTOS

Entrega software que funcione con frecuencia, desde un par de semanas hasta un par
de meses, con preferencia al plazo más corto.
¿QUÉ ESTAMOS OFRECIENDO SI EL CAMBIO NO SE TRATA DE CREAR
SOFTWARE?

U na respuesta común a esto es que estamos generando cambios de comportamiento

o mentalidad. Eso puede meternos en un montón de problemas. Comenzaremos a
buscar formas de medir los comportamientos y la mentalidad, que raya en ser la
policía del cambio en lugar de los agentes del cambio.
Me gusta comenzar lo más ligero posible para mostrar algún tipo de entrega o progreso
tangible, que incluye:

Preguntar a la gente desde el principio: “Dado que hemos estado haciendo <este
cambio> durante <este periodo de tiempo>, en una escala de 0 a 5, ¿cree que vamos
en la dirección correcta?”
Cuando la gente no ve el progreso, pregunto: “¿Qué evidencia necesita para ver que
estamos avanzando?”

Los agentes de cambio nunca deben ser dueños del resultado de un cambio. A veces, la
organización espera que todos demuestren que están haciendo un trabajo y, en la mayoría de
los casos, lo que hacemos genera resultados invisibles.
Esto se reduce a las expectativas, asegurándose de haber establecido las expectativas
adecuadas y de tener ciclos breves de retroalimentación al principio del cambio.
¿QUÉ ES UN PERÍODO RAZONABLE PARA MOSTRAR RESULTADOS
TANGIBLES?
Esto es muy difícil con transformaciones ágiles o programas plurianuales. Trabajé con una
organización gubernamental que estaba trabajando en una implementación de SAP de tres
años que a menudo no mostraba ningún progreso durante meses seguidos, pero de hecho
estaba avanzando.
El líder del cambio colocó un gran muro visible y realizó una reunión semanal para las partes
interesadas. Eso fue todo, y fue lo suficientemente bueno en ese momento. No descartó sus
procesos existentes ni intentó cambiar a las personas. Tenía una breve conversación semanal
para hacer visible todo el trabajo invisible.
¿QUÉ PODRÍAMOS ENTREGAR QUE DEMUESTRE PROGRESO?
Si entendemos que el progreso visible es lento desde el principio, necesitamos una mejor
manera de proporcionar esa evidencia. Eso podría incluir:

Resultados de experimentos.
Retroalimentación temprana que provoque una discusión.
Las tendencias del nivel de sentimiento, felicidad y estrés.

Todos queremos una gestión del cambio basada en la evidencia y queremos creer
desesperadamente que es una ciencia.
Al principio, la evidencia anecdótica es suficiente para tomar decisiones. Si sabemos después
de dos semanas que a todos les encanta la nueva forma de hacer las cosas a pesar del estrés y
las incógnitas, eso nos ayuda a seguir adelante.
¿CÓMO EVITAMOS LA TRAMPA DE LOS CICLOS DE
RETROALIMENTACIÓN PROLONGADOS, PORQUE SABEMOS QUE LOS
RESULTADOS TANGIBLES LLEVARÁN MUCHO TIEMPO?
Esta es una trampa en la que caen los agentes de cambio conservadores porque en lugar de
mostrar una evidencia anecdótica y borrosa de que algo está sucediendo, deciden no mostrar
nada excepto para más PowerPoint.
Es fácil posponer las conversaciones incómodas aumentando la duración de los ciclos de
retroalimentación. Es como la idea de tener informes de estado ecológicos cuando comienza
el proyecto.
Tiene sentido que no nos demos cuenta de los riesgos porque aún no hemos hecho nada, pero
¿no es eso peor? Prueba estos:

Iniciar proyectos en rojo: Mi amigo y colega Andrew Annett dice que al inicio de
un proyecto tienes la billetera llena y el cerebro vacío. Comienza tus proyectos en
rojo y habla con las partes interesadas sobre las tres cosas más importantes que estás
haciendo esta semana para avanzar hacia el verde.
Comentarios sobre el ciclo de retroalimentación: Tenga una breve retrospectiva
semanal y haga una encuesta de satisfacción de 0 a 5 con la mano levantada con su
equipo de cambio sobre la eficacia de sus ciclos de trabajo.
¿Qué tan corto es demasiado corto? Existe la posibilidad de que moleste a las
personas al tener ciclos de retroalimentación demasiado cortos. Use sus ojos, oídos y
cerebro para mantenerse perceptivo sobre cómo se sienten las personas y cómo
reaccionan a lo que podrían percibirse como reuniones inútiles para obtener
comentarios que no logran nada.

U NA GRAN PREGUNTA que me gusta hacer es: “¿Crees que vamos demasiado lento?
¿Demasiado rápido? ¿Hay algo que debería estar haciendo que no esté haciendo ahora
mismo?”
CÓMO REPLANTEO EL TERCER PRINCIPIO
Entrega software que funcione con frecuencia, desde un par de semanas hasta un par de
meses, con preferencia al plazo más corto.
Haz visible lo invisible sabiendo que el cambio no cambia tan rápido como las funciones del
software.
FORMA DE GUIAR MIS ACCIONES
Pedir demasiados comentarios, con demasiada frecuencia, puede volverse molesto
rápidamente. Mis reglas sobre los comentarios son:

Comprende qué otros cambios podrían estar compitiendo por el tiempo y la atención
de las personas. A menudo me acerco a otras personas para ver cómo podemos
fusionar o alinear nuestros esfuerzos de cambio, especialmente si hay superposición.
Soy optimista con respecto a la visualización y hago todo lo que puedo para
visualizar el trabajo en persona o virtualmente para tener una única fuente de la
verdad.
Equilibra la evidencia anecdótica del progreso con los resultados (esto es muy
importante desde el principio).
 COLABORACIÓN MULTIFUNCIONAL

Los empresarios y los desarrolladores deben trabajar juntos a diario durante todo el
proyecto.
¿QUÉ PROBLEMAS ESTÁN CAUSANDO LOS RETRASOS EN LA TOMA DE
DECISIONES?

H ay tantos efectos causados por retrasos en la toma de decisiones, que incluyen:

Descubrir demasiado tarde que el cambio es incorrecto, lo que lleva a impulsarlo de

todos modos debido a la falacia de los gastos irrecuperables.
Apatía en organizaciones donde la gente está desesperada para que los líderes tomen
decisiones, pero los líderes quieren reducir la toma de decisiones. Después de un
tiempo, los equipos ceden y terminan tomando decisiones sin ser transparentes sobre
cómo se tomó la decisión.

En el fantástico libro de Johanna Rothman, Managing Your Project Portfolio 1, cuenta una
historia sobre su trabajo como directora de programas. Tenía demasiados proyectos por hacer
y necesitaba que se les priorizara. Ella preguntaba. Y preguntaba. Y preguntaba de nuevo.
Finalmente, dijo algo como: “He decidido priorizar estos proyectos de esta manera por estas
razones en ausencia de una decisión suya”.
La palabra decisión tiene un sentido de finalidad, pero eso no significa que podamos cambiar
de opinión más adelante. Solo necesitamos una decisión para dar un paso adelante.
¿QUÉ ESTRUCTURAS EXISTEN QUE IMPIDEN LA COLABORACIÓN
INTERFUNCIONAL?
La mayoría de las veces, las estructuras organizativas se interponen. A un amigo mío que
trabajaba como entrenador ágil en una gran empresa de telecomunicaciones, el director de la
división le prohibió hablar con cualquier equipo que no estuviera en su ámbito.
Si bien esto es infantil, si miras más a fondo, hay algo más sucediendo aquí. Lo peor que les
puede pasar a los líderes es que son los últimos en enterarse de algo que sucedió en su
departamento.
Tal vez estés pensando, ¿¿“infantil?? Vaya, no se supone que eso esté escrito en un libro
profesional sobre la gestión del cambio”. A lo que respondo, “Señores. Contratamos
personas inteligentes y capaces y las tratamos como niños”. Hacer destacar el
comportamiento infantil es una forma de provocar un cambio en el sistema. A veces
funciona, a veces hace que te despidan, pero cosas estúpidas como esta son una clara señal de
que la organización nunca va a cambiar.
Trabajé en una organización donde varios equipos trabajaban en el mismo programa. Cada
equipo quería cobrar al departamento del otro equipo por asistir a sus reuniones standup para
coordinar el trabajo entre los equipos. Entonces mejor decidieron no colaborar para ahorrar
dinero.
Este es otro comportamiento infantil y estúpido, pero que está arraigado en muchas culturas
organizacionales, especialmente en algunas organizaciones empresariales.
Si bien es necesario respetar las estructuras hasta cierto punto, es necesario desafiar parte de
este comportamiento estúpido.
¿TRABAJAR JUNTOS ES UNA EXAGERACIÓN DIARIA? ¿QUÉ ES UNA
ALTERNATIVA RAZONABLE?
No confundas el trabajo en equipo todos los días con pensar que es necesario realizar una
reorganización completa.

Pregúntales a los equipos si está bien asistir a sus reuniones, crea tu propia reunión
para el equipo de cambio y pídele al líder del programa que asista.
Reutiliza sus reuniones existentes para seguir un formato de stand-up diario o un
formato de café magro.

Hay tantas formas de resolver este problema, y en el fondo está encontrar la cadencia correcta
que le permita tomar decisiones antes.
¿QUÉ CEREMONIAS EXISTEN, O CUÁLES DEBERÍAMOS CREAR, QUE
NOS PERMITAN ACORTAR LOS CICLOS DE TOMA DE DECISIONES?
Toqué esto en el último punto. Todas las organizaciones tienen reuniones periódicas y, a
menudo, agregan más cuando se produce un cambio.
Crea un inventario ritual 2 y descubre cómo reutilizar los existentes antes de agregar nuevos.
Quizás la mejor historia que tengo sobre este principio es trabajar con una organización
multinacional con agentes de cambio en todo el mundo. Algunos eran entrenadores ágiles,
algunos eran consultores de cambio y algunos eran gerentes.
En vez de competir entre sí, como hacen muchos equipos funcionales, trabajaron juntos y se
reunieron tres veces al mes para apoyarse mutuamente.
CÓMO REPLANTEO EL CUARTO PRINCIPIO
Los empresarios y los desarrolladores deben trabajar juntos a diario durante todo el
proyecto.
Los gerentes de cambio, los coaches ágiles, los OD / HR y los gerentes deben unir esfuerzos
creando cohesión entre iniciativas de cambio en competencia
FORMA DE GUIAR MIS ACCIONES
Esto es simple para mí. Me gusta saber qué más está sucediendo en la organización. Es fácil
afirmar ignorancia cuando hay cambios competitivos provenientes de otro departamento,
pero es su deber hacer preguntas:

¿Qué más está sucediendo ahora? Siempre busco entender qué otras fuerzas
compiten con lo que me han pedido que haga.
¿Qué otros cambios sucedieron antes de esto? Es importante comprender la historia.
Si el cambio se ha intentado antes, comenzar con una retrospectiva podría revelar
información valiosa.
¿Quién se encarga de la gestión del cambio hoy? Puede haber varias empresas de
consultoría que realizan cambios y posiblemente equipos de cambio internos, así
como gerentes y personas en los equipos. A menudo intentaré aprovechar mis
esfuerzos y alinearme con otras personas.
Apoyo a las redes informales sobre el cambio, especialmente al vincular a los
coaches ágiles con los equipos de OD, RR.HH. y de cambio. Puede que no necesiten
trabajar juntos todos los días, pero deberían sincronizarse de vez en cuando.
 MOTIVACIÓN INTRÍNSECA

Construye proyectos alrededor de personas motivadas. Bríndales el entorno y el

apoyo que necesitan, y confía en ellos para hacer el trabajo.
¿CÓMO ENCUENTRAS A LA GENTE MOTIVADA PARA SER PARTE DEL
CAMBIO?

E n general, las personas más vocales están motivadas. Eso podría significar que son
increíblemente solidarios o escépticos. Esa es la energía que necesitarás para hacer
avanzar el cambio.
Mantén los ojos abiertos para ver las mudanzas, los bienes muebles y los inmuebles que
tengan energía y aprovéchala.
Por ejemplo, en la organización sobre la que escribí en Lean Change Management,
comenzamos con sesiones informales y los analistas comerciales seguían apareciendo cada
semana. Sabíamos que teníamos gente muy motivada, por lo que trabajamos muy de cerca
con ellos.
¿QUÉ PODRÍA DESMOTIVAR A LAS PERSONAS?
Nunca subestimes la sensación de que te quiten las opciones. Si presionamos demasiado el
cambio, las personas pueden parecer desmotivadas porque sienten que no tienen otra opción.
Otro problema podría ser la incongruencia. Por ejemplo, los líderes quieren que la
transformación ágil tenga éxito, pero no permitirán que los empresarios hablen directamente
con los desarrolladores.
Quizás la personalidad más influyente del equipo está en contra del cambio, pero todos los
demás apoyan el cambio, pero no sienten que puedan hablar.
Nunca saltes a la resistencia en nivel individual; busca primero los efectos sistémicos y la
dinámica.
¿QUÉ AYUDA Y APOYO NECESITAN?
Parte de esto es tu intuición. Mientras trabajaba como Scrum Master, encontré a un miembro
del equipo que dijo en la reunión diaria del equipo: “Ayer trabajé en X, hoy seguiré
trabajando en X. Sin bloqueadores”.
Eso pasó durante tres días seguidos, así que supe que estaba bloqueado, y era mi trabajo
hablar con él después para ver si necesitaba ayuda.
El soporte no solo ayuda y apoya a las personas como agentes de cambio. También se trata de
trabajar en los bloqueadores del sistema que la gente no puede resolver por sí misma.
En una organización, el director no sabía por qué el equipo seguía necesitando más tiempo y
presupuesto para terminar un programa de gran tamaño. Como entrenador, le pregunté al
equipo si podía romper el protocolo y traerle nuestro gráfico de flujo acumulativo (CFD).
El gráfico de CFD mostró que por cada función que terminamos, la empresa agregó dos más.
Le dije al equipo que era probable que se metieran en problemas, aunque yo fuera el que
rompiera el protocolo, pero dijeron que estaba bien.
Sé claro acerca de cómo puedes ayudar y deja que la gente decida para que no parezcas un
reparador.
¿QUÉ EXISTE EN EL MEDIO AMBIENTE QUE LOS BLOQUEA?
Siempre asumimos que las personas no están motivadas cuando no vemos que se produzcan
cambios. A veces están motivados, pero el cambio es demasiado difícil, hay demasiadas
tareas diarias o hay demasiados obstáculos.
Un ejemplo perfecto, es cuando las organizaciones que experimentan una transformación ágil
cambian el nombre de los equipos existentes como equipos Scrum y mantienen a las personas
asignadas a siete proyectos.
Cuando el equipo no cumple, asumimos que se está resistiendo o que está desmotivado. Lo
peor que vi fue un proyecto de ocho personas con un gerente de proyecto, un desarrollador y
seis analistas de negocios en tres zonas horarias diferentes. Aquí está la parte divertida; el
desarrollador se dedicó al proyecto el 8% del tiempo. Se me encomendó la tarea de hacer que
ese proyecto fuera ágil, lo cual fue un esfuerzo inútil porque nadie estaba enfocado en lo que
se necesitaba entregar.
Todas las organizaciones se atascan de alguna manera. Según mi experiencia, generalmente
se debe a factores sistémicos. Por supuesto, algunas personas también pueden no estar
motivadas o pensar que el cambio es estúpido, lo que no ayuda.
¡Bienvenido al apasionante mundo de ser un agente de cambio!
LA CONFIANZA ES UNA PALABRA DE PESO; ¿QUÉ PASA SI COMETEN
ERRORES?

Aprendí un gran consejo del libro de Patrick Lencioni, Getting Naked 1. Uno de los principios
de su modelo de consultoría desnuda, es recibir el balazo por el cliente.
En lugar de esta frase, uso sal de la cárcel gratis, pero como ambas metáforas son negativas,
¡puede que tenga que pensar en una más positiva para mi próximo libro!
No importa, ignora todas estas tonterías sobre aceptar el fracaso, fallar mejor o cualquier otra
declaración de moda que puedas encontrarte. Nunca me han sido útiles. Por eso promociono
la cuadrícula de celebración 2 de Jurgen Appelo . Se centra en la enorme zona gris entre el
éxito y el fracaso, pero en esencia, aprendes de todas las experiencias.
Es más importante dejar que las emociones desaparezcan del supuesto fracaso y luego borrar
la pizarra con una conversación racional.
Siempre que nos enfrentábamos a un problema, a uno de mis gerentes favoritos siempre le
gustaba decir: “¡Muy bien gente, averigüemos cómo sacar la vaca de la zanja!” Fue una gran
manera de hacerle saber al equipo que sí, teníamos un problema, pero no era el fin del
mundo.
¡Una vez más, Jerry Weinberg al rescate! Una vez dijo que el problema no es el problema, y
que a menudo la reacción al problema es el problema.
UNA HISTORIA RÁPIDA
En 2012, me desempeñaba como entrenador ágil senior en una organización, y nuestro
equipo tenía algunos entrenadores ágiles junior. Nuestro equipo siempre trabajó en conjunto
como compañeros, en lugar de como entrenadores junior o senior, así que mientras no le
cuentes a nadie, puedo contarte el siguiente secreto.
Senior y junior son solo etiquetas de división de trabajo y eran una forma de recursos
humanos de pagarnos de manera diferente. Un ejemplo de división del trabajo fue que solo
los entrenadores senior podían hablar con los ejecutivos. Le dijimos a nuestro gerente que
todos los junior debían tener el mismo título para que pudieran tener el mismo salario porque
la diferencia en el título no es útil para el tipo de trabajo que estábamos haciendo.
Para ayudar a explicar esto a la gerencia, realicé una sesión llamada The Product Box 3 para
que los entrenadores junior descubrieran qué los motivaba. Después de eso, el otro entrenador
senior y yo comenzamos a encontrar oportunidades en la organización que los ayudarían a
llegar allí. El gerente habló conmigo y con el otro entrenador senior, decidió cambiar los
títulos, pero nos preguntó si eso dañaría nuestro sentido de estatus, lo cual estuvo bien. Sé
que eso podría ser un problema, pero a ninguno de los dos nos importó.
Después de esa conversación, todos fueron promocionados, y eso fue todo.
Uno de los entrenadores junior me contó lo que le dije a Johanna hace muchos años en AYE.
“Creo que quiero hacer lo que tú haces”. Me ofrecí a trabajar con él para co-desarrollar y co-
impartir una sesión en la conferencia Agile Alliance 4, que, en ese momento, era la
conferencia anual ágil más importante que atraía a unas 3,000 personas.
CÓMO REFORMULO EL QUINTO PRINCIPIO
Construye proyectos alrededor de personas motivadas. Bríndales el entorno y el apoyo que
necesitan, y confía en ellos para hacer el trabajo.
Permite que los promotores hagan su mejor trabajo, elimina los obstáculos organizativos y
hazte a un lado.
CÓMO ESTO GUÍA MIS ACCIONES

• Apoyo a los escépticos: Siempre hay personas que parecen oponerse al cambio.
Podría ser que tengan una mejor idea o podría significar que también odian su trabajo.
Aunque los apoyo, no enfoco mi energía allí, mientras que la gestión del cambio
tradicional dice que debes identificar y superar la resistencia. Es demasiado agotador.
• Habilita los de la mudanza: En el lado opuesto del espectro, y sin ponerme
demasiado político, actúo como un escudo para los promotores. Los promotores son
aquellas personas que apoyan plenamente el cambio y quieren seguirlo. A veces
necesitan un aliado externo que pueda soportar algo de la presión.
• Cambiar mi postura: Mientras trabajábamos en una empresa grande de
telecomunicaciones, nos acercamos al primer grupo de equipos como entrenadores
porque estaban muy motivados para probar prácticas ágiles. Cuando llegó el momento
de la próxima ronda de equipos, le pedí a las personas de la primera ronda de equipos
que contaran sus historias a los nuevos equipos. En lugar de abordar la segunda ronda
de equipos como un entrenador, me acerqué a ellos como instructor.
 CONTACTO EN LUGAR DE TECNOLOGÍA

E l método más eficiente y efectivo de transmitir información hacia y dentro de un

equipo de desarrollo es la conversación frente a frente.
¿QUIÉNES SON TUS PARTES INTERESADAS?
Este principio se refiere a un equipo de desarrollo. Supongamos que eso significa tu equipo
de cambio. Todos los equipos de cambio con los que he trabajado y que querían adoptar una
forma ágil de hacer el cambio tenían reuniones diarias.
Se invitó a las partes interesadas si querían conocer los detalles del día a día y a veces, la
reunión “diaria” ocurría cada dos días, o cada pocos días.
La clave es volver a la intención. ¿Con qué frecuencia cambia la información? ¿Cuál es el
ritmo del cambio? No te comuniques a diario si no es necesario.
Frente a frente, incluso por video es tan rápido y fácil, pruébalo primero y ajusta según sea
necesario.
¿CUÁL ES EL RIESGO DE NO TENER UNA INTERACCIÓN FRENTE A
FRENTE?
Esto es más difícil en un mundo después del COVID. No es solo que la interacción frente a
frente a veces no es posible, sino que también conduce al agotamiento en línea. Cuando
apareció la COVID, todos los expertos remotos se conectaron en línea, seguidos de cerca por
los expertos en fatiga de Zoom advirtiéndoles que no se excedan.
Si operamos en una cultura remota, ¿la ausencia de un diálogo significativo está causando
problemas? ¿Hay demasiados puntos de contacto?
A veces, Slack u otras herramientas de chat en línea son lo suficientemente buenas, así que
usa tu mejor criterio.
¿EN QUÉ SE DIFERENCIA EL RITMO DEL CAMBIO EN UNA CULTURA
REMOTA?
De nuevo, esto está relacionado principalmente con vivir en un mundo post-COVID. Muchos
agentes de cambio que conozco mencionan que sus cambios se han estancado.
Algunos sienten que necesitan avanzar a pesar de los obstáculos. Aunque este principio se
trata de la comunicación frente a frente, no poder tener este tipo de comunicación es una
interrupción que puede ayudarte a reevaluar el cambio en primer lugar.
Si el ritmo se ralentiza y no importa, eso podría ser una señal de que el cambio, en su forma
actual, ya no es lo correcto.
¿QUÉ TAN DISRUPTIVO Y LOGÍSTICAMENTE COMPLICADO SERÍA?
Trabajé en otro banco de gran tamaño que tenía edificios por todo el centro de la ciudad.
Programaría intencionalmente mis días para estar frente a frente con las personas sabiendo
que tendría que caminar mucho. Hacía algo de ejercicio mientras creaba más relaciones.
Haz un esfuerzo adicional para construir una conexión mental más fuerte. Una vez otros 3
entrenadores y yo facilitamos una gran retrospectiva con cuarenta personas en la sala, y otras
60 más o menos en una conferencia telefónica. Sincronizamos una pared física de notas
adhesivas con una virtual, lo que fue resultado de un gran esfuerzo y no es algo que quisiera
hacer con regularidad.
¿Por qué preguntas? ¿Por qué no hacer que todos se comuniquen remotamente? La razón para
hacer esto fue mostrar las posibilidades del equipo de coaching interno. Esta organización
sufría de una condición común llamada imposibilidad-itis. Sugeríamos algo, ellos respondían
con “¡¡eso es imposible!!”
Así que necesitábamos mostrarles cómo quitarse esa ceguera.
UNA HISTORIA RÁPIDA
Antes de la COVID-19, cuando nos permitían salir de casa, trabajaba con una gran empresa
de telecomunicaciones donde la gente de negocios trabajaba en un edificio y el equipo de TI
en otro a unos 40 km de distancia.
Recuerdo nuestra primera revisión de sprint, donde el pobre Scrum Master estaba hablando
por teléfono, paralizando al equipo de negocios mientras los desarrolladores solucionaban un
último error que habría echado a perder la demostración.
Con voz tranquila, decía: “Gracias a todos por venir, estamos a punto de prepararnos y
esperar a un par de personas, así que comenzaremos en unos minutos”.
Luego presionaba el botón de silencio, se inclinaba hacia la puerta abierta de conferencias y
gritaba: “¡¡¡CHICOS!! ¿¡¿YA ESTÁ FUNCIONANDO?!?!?!”
Durante una de nuestras retrospectivas, surgió el problema de la separación física y el equipo
acordó rotar la ubicación de sus sesiones de planificación y revisión del sprint. Para el
siguiente sprint, la gente del centro decidió desplazarse a la parte alta de la ciudad, y en el
sprint posterior, la gente de la parte alta se desplazaría al centro.
Puedes pensar que esto es una pérdida de tiempo, y puede que tengas razón, pero ese no era
tu equipo, ni tu problema, ni el mío. Llegaron a esta solución porque era lo mejor para ellos.
Tu equipo podía hacer esto de forma remota, este equipo necesitaba estar frente a frente para
establecer una conexión más significativa.
Si bien este principio dice conversación frente a frente, eso no tiene por qué significar en
persona. Sí, el equipo con el que trabajé prefería viajar entre ubicaciones, pero si no era
posible hacer eso, la videoconferencia sería mejor que nada.
Eso es importante porque trabajé en otra organización donde nadie encendía sus cámaras para
realizar videollamadas.
Utilizaron una herramienta para video y puentes de conferencia regulares para audio.
Escucharía el pitido de que alguien se unió, pero nadie diría que se unió. Fue divertido y triste
ver cómo la gente en la sala se ponía ansiosa preguntando: “¿Quién se unió? ¿Hola?
¿Alguien se unió?”
Si bien esa es una señal perfecta de un problema con la confianza, nuevamente, la
comunicación frente a frente no tiene por qué significar en persona. Simplemente significa
hacer lo que sea necesario para vernos entre sí como seres humanos.
CÓMO REFORMULO EL SEXTO PRINCIPIO
El método más eficiente y efectivo de transmitir información hacia y dentro de un equipo de
desarrollo es la conversación frente a frente.
La cercanía mental importa más que la cercanía física. Las personas trabajan juntas en el
cambio mejor cuando se ven como personas y, en general, la interacción frente a frente lo
hace posible.
CÓMO ESTO GUÍA MIS ACCIONES

Establecer relaciones: Me tomo el tiempo para establecer relaciones y modelar el

comportamiento que se alinea con los valores y principios de lo ágil.
Modelo el comportamiento: Según la historia de este capítulo, siempre encendía mi
cámara para las videollamadas y me anunciaba en las conferencias telefónicas.
Quiero que todos los demás también hagan eso, especialmente si no es la norma
cultural.
Un toque más humano: Utilizo este principio para trabajar para que la humanidad
vuelva al lugar de trabajo. Si las personas ven a otras personas como, bueno,
personas, es más probable que estén abiertas a comprender diferentes perspectivas.
 MÉTRICAS ADAPTABLES

Un software que funciona es la principal medida de progreso.

¿CUÁL ES EL EQUIVALENTE DEL CAMBIO A UN SOFTWARE QUE
FUNCIONA?

¡E sto es obvio si tu cambio es implementar software! Aun así, existen mejores métricas
al principio, especialmente con la implementación de grandes sistemas en los que
generalmente no se ve nada tangible durante semanas o meses.
Al inicio de un cambio, me gusta usar diagnósticos y preguntar, “¿qué evidencia tenemos que
nos dice que vamos en la dirección correcta?” Ni siquiera tiene que ser una prueba
específica. ¡Los datos difusos son mejores que ninguno, en mi opinión! Por ejemplo:

Puño de cinco: Usando la escala de 0 a 5, ya sea en persona, con los dedos o

mediante encuestas en línea si necesita comentarios de muchas personas.
Ha pasado <todo este tiempo> desde que empezamos a hacer <este cambio>, ¿cuál
es la mejoría hasta ahora? 0 = mucho peor, 5 = mucho mejor
Ha pasado <todo este tiempo> desde que empezamos a hacer <este cambio>, ¿crees
que como organización estamos comprometidos con eso?
Estos son los resultados que buscamos <listar los resultados>, ¿crees que el tema en
que nos enfocamos lo logrará? 0 = necesitamos seriamente un cambio de dirección, 5
= estamos haciendo lo correcto

Hay infinitas combinaciones para estas preguntas. La clave es encontrar las correctas que
proporcionen alguna evidencia de que lo que estamos haciendo es lo correcto, incluso si
todavía no podemos ver nada tangible.

¿Cómo se separa “demostrar progreso” de la necesidad de la gente de obtener un Retorno de

inversión y otros indicadores de éxito rezagados?

Esto es complicado. A la gente le encanta los sistemas de puntuación y las mediciones, y

creemos que eso es lo que quieren los líderes. Puedo prometerte que no es así, incluso si eso
es lo que están pidiendo.
Los líderes y las partes interesadas, como la mayoría de las personas en las organizaciones,
están ocupados. Quieren datos que les ayuden a tomar decisiones.
Todos quieren creer que el tiempo y el dinero invertidos en un cambio lo vale, pero el ROI y
el cambio transformacional son como el agua y el aceite. No se mezclan.
Trabajé en una organización donde los consultores externos publicaron un documento en su
sitio web sobre cómo esta organización usaba su método y encontraron un aumento de
productividad del 400%.
¿Con qué se midió? Eso fue omitido del artículo.
Por supuesto, esta organización gastó fácilmente más de USD$ 2 millones en estos
consultores, por lo que les conviene haber tenido un Retorno de inversión.
Soy un poco cínico acerca de las métricas porque a menudo se usan incorrectamente. Una
buena práctica que yo mismo utilizo es que si la medida es fácil de obtener y medir,
probablemente sea una medida pésima porque no la hemos pensado bien.
SI BIEN EL SOFTWARE FUNCIONAL ES LA PRINCIPAL MEDIDA DE
PROGRESO, ¿QUÉ SON LAS OTRAS?
He mencionado esto varias veces y es mi trabajo sugerir opciones y dejar que la organización
elija:

¿El cambio facilita el trabajo de las personas?

¿La gente es más feliz?
¿Está más satisfecha la gente que paga por los proyectos?
¿Los usuarios finales solicitan menos asistencia?
¿Está disminuyendo el nivel de estrés de los empleados?
¿Estamos aumentando las ganancias?

Usa las métricas piratas de Lean Startup (AARRI):

Adquisición: ¿Cómo nos encontraron los clientes?

Activación: ¿Tuvieron una excelente primera experiencia?
Retención: ¿Regresaron?
Remisión: ¿Les dijeron a otros?
Ingresos: ¿Nos pagaron?
Utiliza OKR (objetivos y resultados clave).
¿CUÁNDO Y CÓMO EVOLUCIONARÍAS TUS MÉTRICAS CON EL TIEMPO?
Usa diagnósticos desde el principio hasta que sepas que la dirección que has tomado es la
correcta.
A medida que aumenta la certeza, convierte las métricas en objetivos a corto plazo y
resultados clave.
A medida que el cambio llega a su fin, reflexiona sobre todas las medidas utilizadas, cuán
útiles fueron y cómo podrías cambiarlas para el próximo cambio.
En este punto, las métricas deberían estar más enfocadas en los resultados, pero aun así,
tendemos a adaptar la métrica para que coincida con el Retorno de inversión que ponemos en
nuestro caso de negocios. Debes decidir si es más importante jugar al juego de los negocios o
hacer algo significativo.
Esa última parte es importante. Mencioné que soy cínico con las métricas, pero a veces es
esencial que la gente se sienta bien porque el esfuerzo del cambio valió la pena.
Usa tu mejor criterio para equilibrar los diagnósticos que te ayuden a corregir el rumbo frente
a las mediciones que justifican la inversión del cambio.
Para mí, se trata de hacer visible lo invisible y brindar a las personas de las organizaciones
opciones para encontrar métricas significativas.
La satisfacción de los empleados, clientes y partes interesadas son siempre mis medidas de
referencia porque la cuantifican con un número (como una puntuación NPS) y también
provocan conversaciones.
Lo peor que puede pasar, es que usemos nuestros libros de tácticas y sistemas de puntuación
como reemplazos para las conversaciones.
CÓMO REPLANTEO EL SÉPTIMO PRINCIPIO
Un software que funciona es la principal medida de progreso.
Los diagnósticos difusos nos ayudan a ver el progreso y nos dan la habilidad de corregir el
rumbo con anterioridad.
CÓMO ESTO GUÍA MIS ACCIONES
Se han prolongado debates durante más de una década sobre cómo medir la efectividad de un
entrenador ágil. Siempre uso un NPS modificado:

¿Qué posibilidades hay de que recomiendes a Jason como entrenador?

¿Qué valor ha tenido tener a Jason como entrenador?
¿Por qué le dio esa calificación?

Esto me dice dos cosas:

1. La gente ve que estoy aquí para ayudar porque hago públicos mis comentarios. Si la
calificación es baja porque no soy útil, pueden despedirme o me iré.
2. Las personas ven una forma diferente de medir cambios complejos y les ayuda a
encontrar métricas más significativas.

He aquí un ejemplo:
 ADAPTARSE AL RITMO

Los procesos ágiles promueven el desarrollo sostenible. Los patrocinadores,

desarrolladores y usuarios deberían poder mantener un ritmo constante de forma
indefinida.
¿CUÁL ES EL RITMO NATURAL DE CAMBIO DE LA ORGANIZACIÓN?

T odas las organizaciones tienen un ritmo de cambio natural. Las organizaciones

grandes cambian más lentamente que las pequeñas, pero todas tienen períodos
específicos en los que dedicar tiempo al cambio funciona mejor que otros
períodos.
Un gran ejemplo es una organización con la que hablé, aunque no trabajé con ellos, quienes
querían iniciar una transformación ágil en septiembre. Eso fue unas semanas después de que
finalizaron su hoja de ruta y presupuesto para el año. Este es un patrón común en
organizaciones más grandes. Agosto es el mes para hacer el plan anual para el año siguiente,
fijar el presupuesto, la plantilla y alinearse con los objetivos de recursos humanos y la gestión
del desempeño.
En su opinión, tenían el dinero preparado, tenían el plan y ahora querían ejecutarlo de manera
ágil. Muy bien, les dije que no funcionaría y que no pueden hacer nada porque hay demasiada
inercia organizativa:

Los mandatos del mismo desempeño no se pueden cambiar.

Las expectativas de las partes interesadas, la junta y los accionistas ya están
establecidas.
Los objetivos comerciales se definen y se asignan a los resultados del proyecto.

La sincronización lo es todo. Si ya completaron el 100% del programa para el próximo año,

acumular un cambio complejo que en su mayoría está en desacuerdo con su realidad actual va
a estresar a todos.
En una organización diferente, de mediados de noviembre a finales de diciembre fue su
temporada alta. No se producirían nuevas funciones o cambios comerciales porque la
temporada navideña fue la temporada de generación de ingresos más crucial.
Para ellos, ese fue un momento perfecto para entrenar y cambiar las cosas, por lo que hubo
tiempo para experimentar y aprender.
Debe conocer los puntos de intervención correctos, lo que normalmente desencadena el
cambio, cómo se acepta el cambio y cuál es el ritmo natural del cambio para la organización.
¿QUÉ TRABAJO DEL DÍA A DÍA COMPITE CON EL CAMBIO?
Una vez más, esto generalmente se debe a una falta de cohesión. Por ejemplo, al principio de
mi carrera de cambio, aceptaba mis órdenes para hacer el cambio y se las lanzaba a un equipo
que no estaba listo.
En muchos casos, los equipos tienen fechas límite para otras cosas que necesitan su atención.
Pasar a un enfoque basado en extracción en una situación en la que hay varios equipos
funciona bien. Los equipos que están listos pueden generar cambios, los equipos que no están
listos pueden demorarse.
¿QUIÉN ESTÁ SOBRECARGADO DE TRABAJO?
Esto contradice mi punto anterior, pero es importante considerarlo. Trabajé para mi primera
empresa emergente en 2000. Pasaría toda la noche una vez a la semana para implementar las
cosas en producción porque era necesario.
A medida que crecimos, contratamos rápidamente a más personas. Algunos de los otros
desarrolladores me persuadieron de ir más lento para poder construir una herramienta
adecuada para automatizar algo que había pirateado.
Finalmente, dejé ir mi ego y escuché.
Algunas personas siempre se opondrán a que les quiten el tiempo, y es nuestra
responsabilidad encontrar el equilibrio adecuado entre dar y recibir.
¿DE DÓNDE VIENE EL IMPULSO DEL CAMBIO?
Hablando de empuje, ¿quién pide el cambio? ¿Por qué lo piden y por qué nosotros, como
agentes de cambio, sentimos que tenemos que presionar?
Crecí practicando deportes organizados, así que desarrollé un profundo espíritu competitivo.
Hay momentos en los que quiero hacer algo solo porque quiero hacerlo.
Este libro es un gran ejemplo. Escribí todo en una semana y bloqueé todo. Hice algunos
ajustes durante la edición, pero el objetivo era hacerlo porque podía redactar estas páginas
con palabras para siempre.
Debes comprender de dónde proviene el impulso y obtener claridad sobre lo importante que
es ir rápido. Todos tienen un jefe, por lo que es probable que las órdenes que recibas de tu
jefe provengan de otra persona. Pregunta:

¿Qué pasaría si detuviéramos este cambio por ahora?

¿Existe una forma menos disruptiva de hacerlo?
¿Deberíamos incrementar la disrupción para que la gente se ponga en acción?
CÓMO REPLANTEO EL OCTAVO PRINCIPIO
Los procesos ágiles promueven el desarrollo sostenible. Los patrocinadores, desarrolladores y
usuarios deberían poder mantener un ritmo constante de forma indefinida.
Aplicar lo ágil al cambio me da la capacidad de equilibrar un enfoque de dar y recibir en el
cambio para que podamos dedicar tiempo al cambio cuando estemos listos.
LA MANERA COMO ESTO GUÍA MIS ACCIONES

Ser consciente de la empresa: Tus ojos, oídos y cerebro son tus aliados más
importantes. Camina y observa cuán cansada o energizada está la gente.
Busca lugares de intervención: Me tomo el tiempo para comprender los rituales y
ritmos existentes de la organización para ayudar a mis clientes a explorar opciones
que equilibren el dar y recibir del cambio. Es probable que pueda aprovechar el
tiempo de las personas aprovechando un ritual existente.
Enfoque basado en extracción: Mencioné esta historia en Lean Change
Management. Uno de los consultores con los que trabajamos comenzó a usar
tableros Kanban de cambios que permitían a los equipos realizar sus cambios cuando
estaban listos. Si un equipo se enfrentara a una fecha límite estricta, los dejaríamos
en paz. Si estuvieran en una pausa, pasaríamos más tiempo con ellos. Si bien es
difícil de cuantificar, esto redujo el estrés con las personas del equipo porque podían
concentrarse en la entrega, no en el cambio. Cuando tenían más tiempo, podían
concentrarse en el cambio. El cronograma se basó en la extracción y en la demanda,
no impulsó en función de un plan prospectivo.
 PROCESO DE CAMBIO ADAPTABLE

La atención continua a la excelencia técnica y al buen diseño mejora la agilidad.

ÁGIL VS ÁGIL: ¿QUÉ ES SER DISCIPLINADO Y QUÉ ES SIMPLEMENTE
CAMBIAR LAS COSAS CUANDO NOS APETECE?

S ería fácil adaptar este principio al cambio interpretándolo como una práctica
óptima.
Podríamos diseñar un proceso magnífico en papel que falla miserablemente en el mundo real,
de la misma forma que un arquitecto puede sobre diseñar una solución que se ve muy bien en
un diagrama.
Esto último es difícil de aceptar. Todos queremos creer que somos el agente de cambio más
competente, pero para mí, este principio se trata más de adaptar el enfoque al ambiente.
Un gran ejemplo es el modelo de fábrica digital que todos los bancos, compañías de seguros
y telecomunicaciones implementaron alrededor de 2014. La mayoría de nosotros,
entrenadores ágiles mayores, sabíamos esto a principios de la década de 2000, pero no había
forma de que escucharan hasta que supieran por qué deberían intentarlo.
Trabajé con una organización que enviaba los requerimientos por correo electrónico de un
lado a otro. Sería imposible para ellos saltar a una práctica avanzada llamada Desarrollo
impulsado por el comportamiento hasta que aprendieran primero una práctica más básica,
como historias de los usuarios.
En contraste, y en otra organización, ya habían pasado por las historias de los usuarios, pero
profesaban ser nuevos en lo ágil. Su nivel de madurez me dijo que no necesitaban algo tan
básico y que estaba bien comenzar con algo más avanzado.
En el cambio, es lo mismo. Si las personas en diferentes departamentos ni siquiera se hablan
entre sí, decirles que necesitan cambiar su forma de pensar probablemente no funcionará.
Encuéntralos donde están en sus mentes y acuerda con ellos un pequeño paso adelante.
¿CUÁL ES LA EQUIVALENCIA EN CUANTO AL CAMBIO CON RESPECTO A
LA EXCELENCIA TÉCNICA Y EL BUEN DISEÑO?
Esta es difícil, y para mí se trata menos de las prácticas. En el software, la excelencia técnica
y el buen diseño nos ayudan a cambiar rápidamente nuestro software de forma segura.
En el cambio, nos ocupamos de la cognición. Eso significa cómo la gente entiende el
propósito del cambio, la dirección en la que vamos y cómo lo estamos logrando. Eso es más
difícil de cambiar en comparación con el software.
Para mí, esto se convierte más en una actitud de tener ciclos cortos de retroalimentación que
nos ayuden a reflexionar sobre el cambio y el enfoque que estamos adoptando para
implementarlo.
¿CÓMO SABES SI HAS LOGRADO EL CAMBIO EQUIVALENTE A
EXCELENCIA TÉCNICA Y BUEN DISEÑO?
De nuevo, esto es mucho más fácil en software. Si una parte interesada quiere agregar un
campo a una página y el equipo regresa con una estimación de seis meses, el diseño
probablemente es terrible.
En el software, tiene pruebas y compilaciones automatizadas que le brindan información
inmediata sobre el estado de su solución. En el cambio, una buena indicación es la cantidad
de gemidos que se escuchan por tener que seguir procesos que no ayudan.
Otro gran indicador es la cantidad de veces que una parte interesada o un miembro del equipo
quiere cambiar algo sobre el cambio y el proceso se interpone.
Supongamos que estás siguiendo el esquema de Scrum que está encuadrado en el tiempo para
sprints de dos semanas. Imagina que algo cambia radicalmente el primer día del sprint,
¿esperarías hasta que el sprint terminara porque ya te comprometiste con una gran cantidad
de trabajo?
CÓMO REPLANTEO EL NOVENO PRINCIPIO PARA EL CAMBIO
La atención continua a la excelencia técnica y al buen diseño mejora la agilidad.
Un proceso de cambio bien diseñado nos da la capacidad de ayudar y apoyar a las personas
sin interferir en el camino por el simple hecho de tener prácticas estandarizadas.
UNA BREVE HISTORIA SOBRE CÓMO GUÍA MIS ACCIONES
Estaba trabajando con una organización que tenía un proceso increíblemente complicado para
incorporar equipos de personas ágiles.
Paso 1: Conversación inicial con Biff. Biff entra con su portapapeles y hace un montón de
preguntas genéricas basadas en Scrum como:

¿Tiene un espacio para el equipo?

¿Tiene un equipo 100% dedicado?
¿Tiene un propietario del producto al 100%?

Paso 2: Biff te entrega a Sally, quien incorpora tu equipo a la herramienta de ciclo de vida de
gestión de proyectos ágil obligatoria.
Paso 3: Sally te entrega a Joe, quien te pone a través del entrenamiento de proceso ágil
estandarizado.
Me detengo aquí para continuar actuando de manera educada. Sí, fue así de malo. Cuando
nuestro equipo habló con ellos, no pasamos del Paso 1 porque estábamos trabajando en un
gran proyecto global de recursos humanos que tenía 11 SME y ningún propietario de
producto.
Nos dijeron que no estábamos autorizados para ejecutar un proyecto ágil.
Así que nos separamos del COE centralizado y se me ocurrió un proceso de cero a listo para
comenzar en 3 días para nuestra división que incluía:
1) Una conversación de 30 minutos con la parte interesada más importante en los sectores
empresarial y de TI
2) Un despegue del equipo que incluye:

Alineación a propósito con la mayoría de las partes interesadas de alto nivel

Introducción general a lo ágil
Introducción general a los métodos ágiles basados en flujo versus basados en tiempo
Acuerdos de trabajo en equipo
Story map y backlog que representan los primeros X meses de trabajo (según el
proyecto)

3) Seguimiento retrospectivo con todos en un mes

Nos alejamos del libro de tácticas autoritario utilizado por el COE y nos dirigimos a una
estrategia adaptada a su propósito con bases en el manifiesto ágil.
Este es un buen diseño y excelencia técnica, en mi opinión. El proceso de despegue fue lo
suficiente abstracto, por lo que los equipos fueron libres de elegir su camino en función de lo
que necesitaran. El proceso de despegue que diseñé resumió el contexto, por lo que no
importaba si era un proyecto de tres meses con un equipo o un programa de tres años con
veinte equipos, acordaríamos la menor cantidad de proceso, acuerdos de trabajo y un
compromiso con el cambio cuando lo necesitáramos. Eso es adaptabilidad.
A medida que utilicé este proceso cada vez más, se hizo evidente un patrón. Los programas y
proyectos más regulados naturalmente tenían procesos más restrictivos. Los proyectos
experimentales y menos regulados no tenían esencialmente ningún proceso, excepto un
acuerdo flexible para validar los supuestos de cualquier manera posible.
El hecho de que estuviéramos de acuerdo con el enfoque, dentro del contexto de cualquier
restricción organizacional, es lo que lo hizo funcionar.
 MANTENLO SIMPLE

La simplicidad, el arte de maximizar la cantidad de trabajo no realizado, es esencial.

¿Cómo le dices que no a las partes interesadas que quieren que impulse más cambios
cuando sabes que no es el momento adecuado?

D esde mi experiencia, las partes interesadas presionan porque su visión de lo que

debería ser la realidad no coincide con lo que ven.
Es posible que no vean suficiente progreso, lo que podría llevarlos a creer que el equipo de
cambio no está haciendo nada o es demasiado pasivo.
Esta es una oportunidad perfecta para cambiar la conversación hacia la priorización. Si no
crees que sea el momento adecuado, demuéstrales que la gente no está preparada o que hay
cosas más importantes en las que hay que trabajar.
La visualización ayuda mucho aquí. Es difícil justificar la sensación de que los equipos están
sobrecargados de trabajo o sobrecargados con el cambio, por lo que, si de alguna manera
puedes visualizar lo que está en progreso, puedes elegir priorizar el día a día con el trabajo de
cambio.
¿CÓMO PRIORIZAS EL TRABAJO DE CAMBIO?
He hecho esta pregunta cientos de veces en mis talleres. ¿Cómo sabes en qué deberías estar
trabajando?
Suena como una pregunta tonta, pero cuando los agentes de cambio piensan en esto, la
mayoría de las veces se trata de una intuición.
Sí, hay un plan establecido y se están realizando actividades o experimentos, pero hacer lo
correcto casi siempre se basa en una intuición.
¿Tienes alguna forma de priorizar el trabajo de cambio? Hay muchas formas en que los
equipos de entrega ágiles hacen esto utilizando técnicas antiguas como las encuestas de Kano,
MoSCoW (Must, Should, Could, Won't) y nuevas técnicas como la puntuación de temas para
las historias de los usuarios.

¿Cuánta complejidad agregas a tu cambio o proceso de cambio debido a suposiciones no

probadas o no validadas?

Me pregunto: “¿Estoy (o estamos) agregando o cambiando un proceso por el proceso en sí,

o es realmente valioso?” Hablé con una gran organización que buscaba desarrollar un nuevo
esquema de cambio. La meta era investigar lo suficiente para crear un marco global al que
todos se adherirían. He visto innumerables organizaciones grandes hacer lo mismo.
Haga que un par de personas pase meses evaluando métodos, en teoría, creando PowerPoint,
libros de tácticas y mejores prácticas y luego te preguntes por qué sus agentes de cambio han
perdido la capacidad de pensar en el momento.
No digo que sea valioso tener algo, estoy diciendo que cuanto más complicado hagas tu
proceso de cambio, es menos probable que la gente piense en lo que está haciendo.
¿CÓMO MINIMIZAS TU PROCESO DE CAMBIO PARA PODER
CONCENTRARTE EN LAS PERSONAS?
Proceso de cambio mínimo viable. ¡Esta es una bonita frase para ti! Con toda seriedad, el
cambio es mucho más un arte que una ciencia. La actitud, personalidad y temperamento que
tengas como agente de cambio es el factor más importante.
Si valoras la estructura y el control, es más probable que veas el cambio a través del lente del
proceso y te pierdas lo esencial de las personas. Si valoras la colaboración y las personas, es
más probable que veas el cambio a través de un enfoque centrado en las personas y te pierdas
las estructuras esenciales.
Al igual como abogo por la creación conjunta del cambio, abogo por la co-creación del
enfoque del cambio por parte del equipo de cambio.
CÓMO REPLANTEO EL DÉCIMO PRINCIPIO
La simplicidad, el arte de maximizar la cantidad de trabajo no realizado, es esencial.
Proceso de cambio mínimo viable. No permitas que el proceso se interponga en el camino de
la atención a la gente.
UNA HISTORIA SOBRE CÓMO ESTO GUÍA MIS ACCIONES.
Tengo el mal hábito de aburrirme rápidamente. A veces, cuando trabajo con contratos más
largos o como empleado, me gustaría cambiar las cosas por el simple hecho de cambiar.
Mientras trabajaba en The Commission, la organización que mencioné en Lean Change
Management , me aburría con nuestras reuniones diarias. No parecía que siguieran siendo
valiosas para las personas con la energía que pensé que estaba viendo.
Manteniéndolo simple, publiqué un rotafolio de satisfacción pidiendo a las personas que
marcaran un punto en el gráfico que definiera qué tan útil pensaban que era el standup desde
0, nada valioso, hasta 10, súper valioso.
Resulta que todo estaba en mi mente. A la gente todavía le gustaba, así que, en lugar de
cambiar el proceso, lo dejé pasar y seguí adelante.
En otra ocasión, estábamos sincronizando nuestro gigantesco tablero Kanban físico con una
herramienta electrónica y creando complicadas listas y hojas de cálculo para rastrear riesgos.
Hicimos esto porque los consultores externos lo hicieron antes de que se creara nuestro
departamento. Como soy la persona más holgazana del planeta, quería ver si necesitaba
hacerlo, así que hice un experimento.
En lugar de enviar el enlace a la herramienta, la hoja de cálculo y la lista en nuestro correo
electrónico de actualización, envié un enlace a la herramienta en línea y una hoja de cálculo
en nuestro sitio de Intranet. Estaba rastreando el enlace para ver cuántas personas le hicieron
clic.
Resulta que menos del 1% de la gente lo vio y no había una regla de gobierno que dijera que
necesitábamos toda esta complejidad. Después de dos semanas de ejecutar este experimento,
dejamos de actualizar la herramienta y las hojas de cálculo. Proclamamos el tablero físico
como una única fuente de la verdad. Simple y fácil.
 LAS PERSONAS QUE ESCRIBEN EL PLAN NO LUCHAN
CONTRA EL PLAN

Las mejores arquitecturas, requisitos y diseño surgen de equipos autoorganizados.

¿C uál es el cambio equivalente a la arquitectura, los requisitos y el diseño?

Relaciono este principio con el capítulo de cambio adaptable. En organizaciones que cuentan
con equipos ágiles de coaching, cambio, OD, Comunicaciones, Mejora de Procesos y
RR.HH., es fácil que sufran falta de cohesión.
En términos generales, los coaches ágiles tienen más probabilidades de ser relajados y seguir
la corriente en comparación con las personas de comunicaciones que podrían ser más rígidas
y estructuradas. Por supuesto que esto no es una gran verdad, pero debes saber que cada
grupo tiene su propia visión distinta de cómo debería ocurrir el cambio.
En lugar de trabajar unos contra otros, diseñen juntos un enfoque para el cambio. Trabajé con
una gran organización en la que hicimos precisamente eso. Estos grupos trabajaron juntos en
una variedad de cambios, todos en el contexto de una transformación generacional. Eso
significa que no vieron su transformación como un proyecto de un año, lo vieron como la
próxima década de evolución para su organización.
Cuando llegó el momento de planificar la cumbre anual 1, los entrenadores ágiles, los
consultores de cambio, los recursos humanos, la gente de comunicaciones y yo trabajamos
juntos para crearla.
Confiamos en la diversidad de perspectivas para crear nuestro enfoque en lugar de seguir un
método, esquema o manual de estrategias.
¿QUÉ EQUIPOS SE AUTOORGANIZAN? ¿EL EQUIPO DE CAMBIO? ¿LA
AFECTACIÓN DE PERSONAS POR EL CAMBIO?
Como agente de cambio, trabajo muy duro para llevar la perspectiva del cambio de la
organización a las personas afectadas para que puedan descubrir cómo lograrlo juntas.
Los equipos de cambio con los que trabajo crean sus acuerdos de trabajo, incluida la visión
de su equipo, cómo organizarán el trabajo, cómo y cuándo se reunirán, y todas las cosas
buenas que se platican durante los despegues del equipo.
Al principio del cambio, albergar Espacios abiertos 2 y Sesiones poco estructuradas 3 son
perfectos para aprovechar al máximo los equipos autoorganizados. Te ayuda a descubrir qué
temas son los más importantes para las personas y es probable que te den un montón de
mejores ideas en las que quizás no hayas pensado.
¿QUÉ BARDAS EXISTEN PARA EVITAR QUE LA AUTOORGANIZACIÓN
CAIGA EN EL CAOS?
En un extremo, la autoorganización sin restricciones es caótica. Por ejemplo, mientras
trabajaba como propietario de producto en una organización, no había un presupuesto de TI
establecido y el director ejecutivo quería capacidades de redundancia y conmutación por error
para nuestra solución SaaS. El director de tecnología y arquitecto construyó una
monstruosidad de infraestructura que casi llevó a la empresa a la bancarrota.
En el otro extremo, demasiadas limitaciones no permiten pensar de manera creativa. Por
ejemplo, en una gran organización financiera, el COE ágil había decidido que todos los
equipos usarían Scrum. Cuando el departamento en el que estaba trabajando empezó a utilizar
Kanban, nos dijeron que no era un método admitido, y no se les permitió usarlo.
Como me dijo una vez Jerry Weinberg, no sabes cuál es la línea hasta que la cruzas. Cuando
se trata de colocar las bardas adecuadas, la clave es saber cómo reaccionarán los líderes
cuando se cruce la línea.
Como lo mencioné anteriormente, la reacción al problema se convierte en el problema.
CÓMO REFORMULO EL UNDÉCIMO PRINCIPIO
Las mejores arquitecturas, requisitos y diseño surgen de equipos autoorganizados.
Invita a personas a la fiesta, pídeles que bailen y dales la opción de no participar
UNA HISTORIA SOBRE CÓMO ESTO GUÍA MIS ACCIONES.
Hay un momento adecuado y un momento inadecuado para la co-creación. Si bien escribí
este libro en el verano de 2019, reescribí esta parte en agosto de 2020 debido a la COVID-19.
Probablemente hayas notado que estoy pasando de un simple consejo a través de viñetas a
historias más largas en estos últimos capítulos.
Estamos a una semana de volver a la escuela y la escuela secundaria de mis hijos tiene 2500
estudiantes. En mi provincia natal de Ontario, hay más de dos millones de estudiantes
matriculados en escuelas primarias y secundarias públicas. Eso significa que hay cerca de
cuatro millones de padres, tutores o cuidadores que tienen mejores ideas sobre cómo el
gobierno debería abordar la apertura de escuelas de manera segura. Agrega los 130,000
maestros y aproximadamente 7,500 administradores escolares, y tendrás un cambio
enormemente complejo en tus manos.
Desde una perspectiva de cambio, aquí tienen sentido más restricciones. Aunque nuestra
junta escolar es excelente para recibir comentarios y revisar según sea necesario, ellos
decidirán cómo hacerlo y eso es probablemente lo mejor. Ya es bastante difícil lograr que
cinco personas en una fiesta se pongan de acuerdo sobre los ingredientes de un pastel o una
salsa, no hay ninguna posibilidad de que la junta escolar descubra cómo unir a cuatro
millones de personas en un plan de regreso a la escuela.
Esta es mi forma prolija de decir que mi enfoque es dar a la gente una opción. He estado
dirigiendo mis propios negocios desde principios de la década de 2000, y créeme; hay días en
los que me encantaría que otra persona pensara por mí. Me encantaría ejecutar un montón de
tareas siguiendo lo que me diga el entrenador o consultor. Al final del día, es más
satisfactorio para el sentido de responsabilidad saber que las cosas que van bien o mal se
deben a decisiones que tomé conscientemente.
Volviendo a hacer cambios en un entorno sin software, hace muchos años, presenté una
versión de un día de mi taller en una conferencia. ¡Pasamos más de una hora haciendo que las
personas se autoorganizaran en equipos! Puedes leer un relato más detallado de esta historia
en mi blog4, pero por qué tomó tanto tiempo se redujo a dos cosas principales:

1. La gente pensó que era MI taller y se suponía que YO debía DECIRLES cómo
aprender y qué hacer.
2. Había baja tendencia hacia tomar acción por parte de las personas en la sala.

Después de que finalmente se autoorganizaron en equipos, una persona dijo: “Sabes, siempre
decimos que la gente no hará nada hasta que se lo digamos, ¡pero eso es exactamente lo que
te hicimos a ti!”
La lección: A veces necesitas provocar a las personas a que actúen, a veces necesitas dejar
que se organicen por su cuenta y otras veces, les das las tareas para que las ejecuten.
La clave es que las personas afectadas por el cambio deben tener la opción, así que dásela.
 INSPECCIONAR Y ADAPTAR

A intervalos regulares, el equipo reflexiona sobre cómo ser más eficaz, luego
sintoniza y ajusta su comportamiento en consecuencia.
¿CON QUÉ FRECUENCIA TU EQUIPO DE CAMBIO REFLEJA Y REFINA TU
PROCESO DE CAMBIO?

E ste es difícil en organizaciones más grandes donde la adherencia al proceso es más

importante. Eso no es necesariamente algo malo. Una vez trabajé con un equipo de
recursos humanos donde el vicepresidente dijo que lo ágil nunca funcionaría para él.
Mientras estuve leyendo la declaración, dijo que prefería arruinar la nómina de 80,000
personas siguiendo el proceso, en vez de correr el riesgo de probar algo nuevo.
Bien, lo acepto. Probablemente yo mismo tendría la misma actitud en su puesto.
La mayoría de los equipos de cambio con los que he trabajado hacen toda la definición del
proceso de cambio por adelantado, obtienen la aprobación de los líderes, crean guías, sitios
de intranet, manuales, imparten capacitación y más.
No estoy diciendo que algo de eso no sea valioso, pero crea una sensación de tener que seguir
el proceso porque se invirtió mucho dinero en darle vida.
Luego, cuando surge algún problema, la primera pregunta es siempre: “¿Seguiste el
<proceso X?>”
Uno de los mejores equipos de cambio con los que he trabajado está basado en una gran
compañía de seguros, y tienen un enfoque de cambio que es el adecuado para este propósito.
Es decir, tienen muchas piezas diferentes para elegir. Suena como un libro de tácticas, pero
no lo es.
Por ejemplo, cuando la incertidumbre es extremadamente alta, como cuando quieren crear un
programa de innovación, utilizan el proceso de hablar con ellos.
La responsabilidad recae en el agente de cambio para saber cómo tener una conversación bien
facilitada en lugar de entrar con un portapapeles y una lista de puntos de conversación de un
libro de tácticas.
Utilizo esta técnica con equipos ágiles. Se llama un medidor de satisfacción y hago que el
equipo haga una lista de todas las prácticas que hacen y califique cuán efectivas son de 0 a
10. Luego, elegimos un área de enfoque, profundizamos y descubrimos cómo magnificar lo
bueno o arreglar lo malo.
Puedes hacer lo mismo con tu equipo de cambio de forma trimestral o semestral.
¿CÓMO PARTICIPAN LAS PARTES INTERESADAS?
Soy fanático de invitar a las partes interesadas a cualquier ceremonia, como planificación,
stand-ups y retrospectivas. Te garantizo que ninguna parte interesada está mirando tus pilares,
diagramas de cambio y otros artefactos. A menos que hayan sido anteriormente un agente de
cambio, en cuyo caso, es posible que solo quieran mostrarte lo mucho que saben.
Este no es solo un ejercicio para refinar el enfoque hacia el cambio, sino que también brinda a
las partes interesadas una ventana a su proceso de pensamiento para que comprendan cómo tú
y tu equipo toman decisiones.
Otro beneficio es que, si estás utilizando prácticas ágiles como visualizar tu trabajo, usar
stand-ups o hacer retrospectivas creativas, pueden llevar esas prácticas a otras áreas de la
organización, o mejor aún, al equipo ejecutivo.
Nuevamente, al igual que la co-creación con las personas afectadas por el cambio, dales una
opción y permíteles optar por no participar.
¿QUÉ SUCEDE CON LAS PERSONAS AFECTADAS POR EL CAMBIO?
Mientras trabajábamos en una gran empresa de telecomunicaciones, nos acercábamos a
nuestro sexto aniversario de iniciar una transformación ágil. Veinticinco equipos estaban
practicando de manera ágil y realizamos retrospectivas mensuales a las que todos los equipos
podían unirse.
Así es como decidimos cuáles eran los experimentos correctos en el contexto del lienzo de
estrategia organizacional 1.
Para el aniversario de los seis meses, hicimos una retrospectiva asincrónica masiva que tomó
poco más de una semana y que respondió a la pregunta definitiva: Hemos estado seis meses
intentado ser ágiles, ¿deberíamos continuar?
La respuesta fue sí. Eso llevó a un nuevo capítulo, donde hicimos un inventario de lo que
hicimos, lo que sucedió y lo que podríamos hacer a continuación.
Eso no solo cambió los experimentos que hicimos, sino que también cambió la forma en que
abordamos el cambio.
CÓMO REPLANTEO EL DUODÉCIMO PRINCIPIO PARA EL CAMBIO
A intervalos regulares, el equipo reflexiona sobre cómo ser más eficaz, luego sintoniza y
ajusta su comportamiento en consecuencia.
Tómate el tiempo necesario para detenerte y comprender cómo se sienten las personas con
respecto al cambio, pensar en cómo puedes cambiar el cambio y cómo abordarlo.
UNA HISTORIA CORTA ... O DOS
En enero de 2012, mi equipo ganó un concurso de fin de semana de empresa emergente
magra 2. Hasta entonces, estaba haciendo y entrenando equipos en retrospectivas, pero la
puesta en marcha magra agregó otra dimensión a mi pensamiento. El punto clave que
recalcaron fue ir a hablar con los clientes. En cuanto al cambio, eso significa salir de detrás
de las bambalinas y ver de primera mano qué ayuda y apoyo necesitan las personas antes de
ejecutar sus suposiciones.
Asumimos que nuestro enfoque para el cambio es el correcto. Asumimos que sabemos más y
conocemos la mejor manera de hacerlo. Todos somos parciales de alguna manera, y yo estoy
fuertemente predispuesto a ofrecer a las personas una opción.
Por defecto adopto una postura de facilitación y coaching, y a veces ese no es el enfoque
correcto. En una gran organización financiera, ese enfoque no funcionó porque era demasiado
incompatible con cómo funcionaba el cambio.
Tuve que presionar más, lo que siempre sentí que estaba mal, pero al mirar
retrospectivamente con frecuencia, obtuve comentarios que me ayudaron a modificar mi
enfoque.
Una de mis oportunidades de aprendizaje favoritas fue trabajar con Andrew Annett en una
retrospectiva de gerentes. Comenzó escribiendo una pregunta simple en la pizarra:

“¿Qué estás tolerando?”

En vez de realizar una retrospectiva típica, el objetivo era tener una sesión de exploración con
lo que los gerentes sentían que tenían que hacerla, solo porque los entrenadores estábamos
allí.
Probablemente fue una de las mejores conversaciones que he tenido. Fue muy honesta y
cruda.
Si bien mencioné que las retrospectivas te ayudan a reflexionar sobre el cambio y cómo estás
haciendo el cambio, también es una ceremonia esencial detenerse y hablar con la gente sin
sentir que tienes que mejorar algo solo porque el proceso dice que debes hacerlo.
LA MANERA COMO ESTO GUÍA MIS ACCIONES
Encontrar el equilibrio: Demasiada retroalimentación y reflexión puede llevar a una
parálisis de decisiones. El concepto de inspeccionar y adaptar es tan antiguo como la misma
humanidad. Aunque se le atribuye a Deming, el ciclo PDCA (Planificar-Hacer-Verificar-
Actuar), o también llamado ciclo Shewhart, es todo lo que necesitas. Lean Startup (Empresa
emergente magra) redujo esa idea al ciclo de tres pasos Construir-Medir-Aprender, y lo
reduciré aún más a un ciclo de dos pasos: ¡Actuar-Reflexionar!
 PARTE IV: CAMBIAR TU VISIÓN DEL CAMBIO

“Puedes cambiarte a ti mismo y puedes cambiar la situación, pero absolutamente no

puedes cambiar a otras personas. Solo ellos mismos pueden hacer eso”. - Joanna
Trollope

En el capítulo de apertura mencioné tres cosas que la mayoría de la gente considera cuando
quiere ser más ágil en la gestión del cambio:

Transformar la forma de gestionar el trabajo de cambio

Transformar la forma de pensar sobre el cambio
Transformar la forma de trabajar con equipos ágiles

He sido propietario de producto, Scrum Master y miembro del equipo en equipos ágiles. He
sido coach ágil interno y externo, y he trabajado como agente de cambio organizacional en el
cambio de procesos de negocio y cambio organizacional.
De todas esas experiencias, ser propietario de un producto tuvo el efecto más profundo en
cómo veo el cambio.
Veo el cambio como un producto y las personas afectadas por el cambio como usuarios
finales. ¡Eso definitivamente suena extraño, considerando mi punto de vista sobre dar
prioridad a las personas!
Lo que quiero decir es que cuando trabajaba como propietario de producto, aprendí mucho
más rápido yendo a las oficinas de los clientes y trabajando en el descubrimiento de
productos con ellos. Esa fue la mejor manera de probar mis suposiciones sobre el producto.
Ver de primera mano cómo era la vida de nuestros clientes en el trabajo fue fundamental para
descubrir la mejor manera de evolucionar los productos existentes y de crear otros nuevos.
Y antes de eso, mi experiencia trabajando como agente de soporte técnico en un centro de
llamadas global me puso en el camino de ser un ayudante.
Esa fue la forma prolija de decir que siempre he visto el cambio como una función de
servicio. Es decir, estoy aquí para servir a las personas y a la organización. Eso no significa
que yo haga lo que ellos quieran, significa que debo ayudarlos a descubrir cuál es el cambio
correcto, cómo hacerlo y dejar de lado la mayor cantidad posible de mis propios prejuicios.
Ha sido extremadamente difícil para mí trabajar en algunas organizaciones empresariales que
ven el cambio como un conjunto de prácticas y pasos estructurados y estandarizados. Si bien
entiendo por qué quieren marcos gigantescos que lo abarquen todo, esto es demasiado
restrictivo y frustrante y simplemente no funciona.
Si eres nuevo en el cambio ágil, o en lo ágil en general, probablemente será difícil ver el
cambio de manera diferente. En estos capítulos finales, dejaré de hacerte preguntas y pasaré a
ofrecerte consejos que espero que encuentres valiosos para construir un puente entre lo que
ya sabes y cómo podría ser para ti hacer el cambio más ágil.
 TRANSFORMAR LA FORMA DE GESTIONAR EL TRABAJO DE
CAMBIO

E ste es el más fácil de los tres. Las prácticas ágiles existen desde hace décadas.
Aunque el Manifiesto ágil se creó en 2001, eso no significa que nadie haya
colaborado de manera significativa antes de eso. Siempre he dicho que todo en el
ecosistema ágil ya ha sido creado, lo cual es cierto si miras lo suficientemente profundo. El
manifiesto tomó ideas atemporales y organizó las palabras de manera diferente haciéndolas
más accesibles a las masas.
Me gusta pensar en esta sección como el conjunto fundamental de ideas que son una
necesidad absoluta. Si no puedes implementar estas prácticas simples y efectivas en su
organización, las otras dos serán mucho más desafiantes.

Visualiza tu trabajo. Si bien es más difícil visualizar físicamente el trabajo con

notas adhesivas y pizarras blancas en un mundo posterior a la COVID, el objetivo es
tomar decisiones sobre el trabajo, viéndolo, y tener una única fuente de la verdad.
Decidir sobre procesos basados en el flujo o en cajas de tiempo: Caja de tiempo =
aplicar Scrum, Basado en el flujo = aplicar Kanban. Aún mejor, usa ambos.
Scrumban o Kanban-um si quieres ponerle una etiqueta, pero haz que el trabajo fluya
según el valor y mantén una cadencia regular de ceremonias importantes
Comprometerse con las retrospectivas independientemente del proceso que
utilices.
Organizar una reunión diaria e invitar a las partes interesadas.

Un proceso más sencillo libera tu cerebro para pensar en cosas más complejas y ayuda a que
te concentres en las personas del cambio.
VISUALIZA TU TRABAJO
Aquí hay un ejemplo de un muro de transformación ágil que usé en un banco grande:

Recuerda, las personas ágiles no están a favor de la visualización ni en contra de las

herramientas por alguna una visión anarquista. Es más difícil administrar el trabajo cuando no
podemos verlo. Visualizar el trabajo conduce a mejores conversaciones y toma de decisiones.
Aunque puede parecer como trabajo adicional, el propósito de visualizar el trabajo es
diferente. No está diseñado para reemplazar documentos o wikis que contienen más detalles.
Te guiaré a través de los ejemplos de los muros de transformación ágil del banco:
La primera imagen muestra la coordinación de múltiples cambios en los que estaba
trabajando el equipo de liderazgo en paralelo:

Programas de personas y cultura dirigidos por RR.

'Cosas ágiles' planeadas por mí
Programa de mejora de procesos
Programas o proyectos técnicos y de arquitectura
Junto a eso estaba la pared con el programa Kanban con todos los programas de alto nivel
que estaban llevándose a cabo. (No puedo mostrarte el programa visual exacto debido a
asuntos de privacidad, pero no te preocupes, habrá muchos ejemplos en
changewayfinder.com que puedes consultar).
La segunda imagen muestra los detalles sobre la transformación ágil que incluyen:

Finalidad de la visualización: Para que la gente sepa lo que está mirando

Programas o temas principales: Cada uno de estos incluyó el propósito y quién está
trabajando en él.
Actualización del estado (¿Cómo va? Columna): Los adhesivos grandes de colores
(que se muestran a continuación) con una fecha y una nota. Rojo = bloqueado, Verde
= bueno

Aquí hay una imagen más cercana de la sección de actualización de estado:

Cómo ayudó esto:

Eliminó los informes de estado complicados porque no eran necesarios.

Mostró a la gente que se estaba produciendo un cambio. Algunas personas me hacían
preguntas al respecto, a otras no les importaba.
Me responsabilizó y demostró que utilizo las técnicas que les pido a otras personas
que utilicen.

Finalmente, aquí hay un par de imágenes de cerca que muestran algunas ideas para visualizar
detalles de nivel inferior:

Notas adhesivas azules: Última actualización e información de programación.

Notas adhesivas rojas: Un bloqueador indicando detalles sobre por qué está bloqueado.
Indicadores de progreso: Se nos ordenó usar la herramienta de radar Agility Health, que
creo que es muy buena, si se usa correctamente. Esto mostró que, de los 16 equipos, nadie la
llegó a usar y no se programó nada. Eso probablemente parezca extraño, pero la nota
adhesiva se colocó en la columna En progreso porque yo estaba haciendo un trabajo
exploratorio.
DECIDE A FAVOR DE TIME BOX, FLOW ... ¡O AMBOS!
Scrum es un proceso encuadrado en el tiempo (time-box) que te ayuda a mantener el ritmo.
El desafío de solo usar Scrum para administrar el trabajo de cambio es averiguar cuál sería el
producto potencialmente entregable al final del sprint. Esto es fácil en software, difícil en
cuanto al cambio.
Kanban permite que te enfoques en el valor primero y sacar más trabajo a medida que
completas el trabajo.
Siempre uso ambos porque:
Con Scrum: Me gustan los ritmos y hacer uso de las ceremonias encuadradas en el tiempo,
como la planificación de sprints, las reuniones diarias, las revisiones de sprint y las
retrospectivas.
Con Kanban: No me comprometo con dos semanas de trabajo de cambio como dice Scrum,
sino que, al contrario, trabajo en flujo y uso los finales de los libros de las ceremonias de
Scrum para ver cómo progresan las cosas.
COMPROMETERSE CON LAS RETROSPECTIVAS
Esta es, por mucho, la práctica ágil más importante que se puede utilizar. Sea cual sea el flujo
de proceso que elijas, utiliza las retrospectivas para reflexionar sobre lo que funciona y lo que
no y cámbialo.
Recomiendo encarecidamente RetroMat 1 para encontrar un montón de técnicas increíbles, así
como el libro 2 de Agile Retrospectives de Esther Derby.
REALIZAR STANDUPS DIARIOS
Reúnete frente a tu visualización, ya sea en persona o virtualmente, e invita a grupos externos
como la PMO (Oficina de gestión de proyectos), auditoría o cumplimiento, recursos humanos
o cualquier grupo que necesite estar al tanto de lo que está sucediendo.
Hay una diferencia entre un Scrum stand-up y un Kanban stand-up:
Scrum: Se hacen 3 preguntas: ¿en qué trabajaste ayer, en qué trabajarás hoy y qué te está
bloqueando?
Kanban: Comenzando desde la columna directamente a la izquierda de finalizado, analiza lo
que se necesita para completar lo que hay en esa columna para habilitar el flujo.
Conté esta historia en mi último libro, ¡así que disculpa si es una repetición para ti! En The
Commission, la empresa del libro, invitamos a la PMO empresarial a nuestras reuniones
empresariales y documentaron todo lo que necesitaban. No intentamos cambiarlos,
simplemente les proporcionamos una forma más sencilla de ver lo que estaba sucediendo con
el trabajo relacionado con TI.
PROCESO DE CAMBIO MÍNIMO VIABLE
Estas técnicas básicas son las más conocidas en el mundo actual. Cuando comencé a
visualizar el trabajo a principios de la década de 2000, la gente pensaba que estaba loco. Me
gustaría decir que es porque quería ser más innovador en la gestión del trabajo, pero en
realidad era porque era súper holgazán y quería liberar mi cerebro para concentrarme en el
trabajo importante en lugar de tratar de obtener esa maldita hoja de Excel formateada
correctamente.
CÓMO DESAFIARTE A TI MISMO Y A TU ORGANIZACIÓN:
Mencioné que el argumento en contra del uso de grandes muros visibles es que las personas
que están acostumbradas a los grandes cronogramas y documentos de proyectos ven esto
como una duplicación del trabajo.
Lo que no entienden es que los detalles en sus grandes paredes visibles deben ser mínimos.
Esto está diseñado para almacenar solo los detalles necesarios para tener una conversación
que permita una rápida toma de decisiones. No está diseñado para reemplazar documentos
más detallados. Aunque, en mi opinión, siempre debes cuestionar la necesidad de estos
documentos, ¡pero eso es una plática para otro día!
Otro argumento en contra, especialmente en un mundo post-COVID, es que no podemos
hacer un gran muro visual si todos estamos a distancia. Hay herramientas para hacerlo más
fácil, pero recuerda, la intención de la pared visible es doble:

Ser una única fuente de verdad.

Fomentar conversaciones significativas que nos ayuden a tomar mejores decisiones.

Siempre hay algún tipo de actividades de gestión de proyectos que deben realizarse. Algunas
son valiosas y otras son simplemente hábitos que tenemos, pero no sabemos por qué.
Una buena práctica para desafiarte a tí mismo y a tu organización es auditar tus procesos y
artefactos:

Qué tan útil es <este proceso> para nosotros de 0 a 10, y ¿por qué?
Pregunta a las partes interesadas qué tan útil es este proceso o artefacto para ellos de
0 a 10 y por qué.
Habla con la PMO o la gente de gobernanza y averigua qué necesitan (lo más
probable es que es solo tu jefe quien se quiere cubrir su trasero).

No interrumpas las cosas solo por molestar. Si estás muy regulado y te auditan con
frecuencia, haz lo que sea necesario para manejar eso, ¡pero al menos desafíalo!
 TRANSFORMANDO TU FORMA DE PENSAR SOBRE EL
CAMBIO

U n amigo mío dijo una vez que las únicas personas que se resisten al cambio son los
gerentes de cambio.
Estoy de acuerdo con eso. Estoy atado a las prácticas que me gustan, todos lo estamos. Todos
estamos predispuestos hacia una visión nuestra de lo que creemos que funciona. Ningún
proceso, método, libro de tácticas o esquema cambiará eso a menos que aceptemos que son
nuestra actitud y nuestras experiencias las principales causantes de cómo vemos el cambio.
Estas son las reglas por las que vivo y las preguntas que me hago a mí mismo, porque soy una
persona muy competitiva y un autonombrado fanático del control. A veces me concentro
tanto en la meta que puedo perder de vista mis propios comportamientos. Por cierto, declarar
cuáles crees que son tus prejuicios es una buena práctica para integrarte con una nueva
organización o equipo. Siempre les digo a los clientes que me encanta la energía que trae el
cambio y que a veces puedo ser optimista, pero la intención es mejorar las cosas, aunque a
veces parezco abrasivo.

¿Qué ocurre con mi comportamiento y enfoque que podría estar causando lo

que estoy observando? Por ejemplo, si creo que la gente se está resistiendo al
cambio, ¿qué tiene mi enfoque que podría ser un factor?
¿Quiero ganar porque quiero ganar, o estoy presionando hacia el mejor interés
de la organización? Tuve la mala costumbre de asumir que las organizaciones que
querían ser más ágiles querían realmente ser más ágiles. Presionaba y presionaba, y
luego me di cuenta de que querían ayuda para aclarar problemas y ayudarlos a
resolverlos. Comprende lo que se te pide que hagas.
¿Estoy siendo congruente? Por ejemplo, todos tenemos un punto de ruptura y solo
comprometeremos nuestros valores hasta ese punto. Si siento que no estoy siendo
congruente, me despido.
¿Soy el agente de cambio adecuado? Por ejemplo, no trabajaré con bancos,
seguros, telecomunicaciones o cualquier empresa que no se alinee con mis valores.
Esto no es un golpe contra ellos ni contra mis amigos que trabajan allí. Esta es
simplemente mi elección de querer enfocar mi energía en otra parte. Dicho esto, el
trabajo transaccional está bien. El trabajo transaccional es un entrenamiento donde
los capacitaré en prácticas de cambio ágiles y modernas, pero no los consultaré ni los
asesoraré directamente.
¿Con quién en la comunidad ágil y del cambio estoy completamente de
acuerdo? Quienes sean, ¡deja de leerlos y seguirlos! Ok, eso probablemente suene
extraño porque algunos de ustedes probablemente estén de acuerdo con mis escritos.
El caso es que no sigas a nadie ciegamente porque ya estás de acuerdo con él. Busca
personas que desafíen respetuosamente tus creencias.
 • Pruébalo. Algunas de las ideas de este libro pueden ser amenazantes. Declara tu
intención de experimentar con las personas interesadas para que comprendan por qué
vas a hacer lo que estás a punto de hacer. El valor de esta convicción te traerá
resultados.

Para mí, lo más importante es que tratar de ver el cambio desde diferentes perspectivas es lo
que me ayudó a disfrutar más del trabajo. Lo que me ayudó a llegar a esta conclusión es que
este fue el patrón de ver a tantos agentes de cambio con los que he trabajado a lo largo de los
años dejar organizaciones que los estaban haciendo miserables.
Cuando disfrutaba más el trabajo, era más probable que ayudara a otros a disfrutar más de sus
trabajos. Suena cursi, pero es verdad.
Supongo que podría decirse que este capítulo trata sobre cambiar tu comportamiento como
agente de cambio, en lugar de centrarte en conseguir que otras personas cambien su
comportamiento.
Después de viajar por el mundo desde 2014 y encontrar patrones, se destacaron cinco
patrones universales que ayudaron a los agentes de cambio a ver el cambio de manera
diferente. Usamos la visión tradicional de lo que es una buena gestión del cambio:

Crear urgencia: Esto incluye la horrible y espantosa frase, “creando una plataforma
en llamas”. Por amor al universo, deja de usarla. El origen de la frase se trata
literalmente de una plataforma petrolera en llamas donde la gente salta o muere.
Obtén participación: Esto significa que hemos decidido el cambio, que tenemos el
plan perfecto y ahora necesitamos que la gente participe.
Comunicarse: Esto generalmente se manifiesta en técnicas de transmisión, como
boletines, ayuntamientos con preguntas escritas y sitios de intranet o carteles
colgados en las paredes.
Ejecución: Gestionar el cronograma y ejecutar las tareas.
Mitigar la resistencia: Prepara un plan para lidiar con esos humanos molestos que
se resisten al cambio.

Descubrí que esas cinco cosas son importantes, pero podemos ver cada una de ellas de
manera diferente. Decidí llamarlas las Cinco Universales del Cambio 1 y no se trata de lo uno
o lo otro, se trata de equilibrar cuándo usar el enfoque más adecuado.
Co-creación en vez de conseguir la participación: Te enfocarás en la diversidad de
pensamiento y la inclusión. Esto significa invitar a la gente a la fiesta, pedirles que bailen,
pero dejar que puedan excluirse en vez de intentar convencerlos para que se unan.
Diálogo significativo sobre la transmisión: Utilizarás reuniones no estructuradas y otras
prácticas que fomenten el diálogo para descubrir lo que las personas necesitan y quieren, en
vez de transmitir planes de comunicaciones a las personas.
Causa y propósito o creación de urgencia: Reunirás a las personas en torno a un propósito
común, sabiendo que no todos querrán acompañarte en lugar de tratar de mantener la
urgencia en las personas coaccionando o intimidándolas.
Experimentación sobre la ejecución de tareas: Te darás cuenta de que a veces el objetivo
es aprender, no ejecutar tareas y fomentar una cultura de aprendizaje seguro, que es un giro
positivo en la declaración de que es seguro fallar, lo cual induce a la mediocridad.
Respuesta al cambio en vez de resistencia al cambio: Te darás cuenta de que lo que
denominas resistencia es la respuesta natural que tiene la gente al cambio. Esos son los datos
que necesitas para dar forma a tu cambio de manera diferente, en vez de culpar cada falla a la
resistencia o a la falta de aceptación.

Estos Cinco Universales no se tratan de que esto está bien, o eso está mal. Se tratan de saber
cómo equilibrarlos saliendo de tus creencias y mirando el contexto a través de diferentes
lentes.
Encontrarás más detalles sobre estos Cinco universales en Change Wayfinder, ¡pero el
próximo libro que los explora con mucho más detalle ya está en proceso!
En resumen, se trata de cambiar tu visión del cambio y elegir las piezas que mejor se adapten
a tu contexto.
Cambiar el lente con el que observas el cambio requiere que uses las herramientas más
importantes que tienes: Tus ojos, oídos y cerebro. ¡Gracias a mis amigos y colegas Ro Gorell
y Charlotte Mawle por esto!
 TRANSFORMAR LA FORMA EN QUE TE INTEGRAS CON
EQUIPOS ÁGILES

T ransformar la forma en que te integras con los equipos ágiles es

razonablemente simple y similar al primer punto sobre la transformación de la
forma en que gestionas el trabajo de cambio. La diferencia es que controlas la
manera en que se gestiona el trabajo de cambio. La integración con equipos ágiles requiere
que te alinees con la forma en que funcionan, lo que podría significar que debas cambiar la
forma en que administras el trabajo de cambio de alguna manera.
Primero, algunos precursores:

Cambiar de ver lo que haces como agente de cambio, desde un punto de control
hacia un punto de función de servicio. El equipo ágil está generando valor
directamente, tú los estás apoyando para que lo hagan sin obligarlos a seguir tu
ejemplo.
Considérate como un controlador de tráfico aéreo para que puedas visualizar las
partes móviles de los programas ágiles y vincular las actividades de los equipos
ágiles a lo que tu organización necesita.
Integrar y visualizar tu trabajo de cambio en el flujo de trabajo del equipo ágil.
(Por ejemplo, pregúntale al equipo si puede asistir a su planificación, revisiones de
sprint y standup como observadores).
Siéntate a hablar con el equipo si hay algún cambio comercial sustancial. (Por
ejemplo, si el equipo ágil está reemplazando un sistema que requiere que se vuelvan
a capacitar 10,000 personas, debes participar diariamente).
No impongas tu punto de vista y proceso sobre el equipo ágil. Adapta e integra tu
proceso de cambio en el de ellos.
Eres el puente y el conector entre el equipo ágil y la organización en general. Tus
mejores amigos son los Scrum masters y los coaches ágiles. Trabaja con ellos, no
contra ellos.

Habrá traslapes entre tu rol como administrador de cambios y Scrum master, coach ágil,
gerentes, gerentes de proyectos y programas. Cada uno puede informar a través de diferentes
jerarquías, por lo que puede haber bastante complejidad, duplicación de documentación y
procesos.
En el capítulo Transformar cómo gestionas el trabajo de cambio, te sugerí que auditaras tus
propios procesos y artefactos para ver qué es y qué no es útil. Haz lo mismo aquí, pero con
todas las funciones de apoyo involucradas con el equipo ágil.
QUÉ DEBES ESPERAR
Los coaches ágiles pueden ponerse muy a la defensiva cuando un extraño intenta intervenir
en cómo están trabajando. En realidad, debería decir que los coaches ágiles sin experiencia
pueden ponerse muy a la defensiva. En 2015, estaba en Melbourne organizando un montón
de talleres y, por suerte, hubo una reunión ágil y una reunión de gestión del cambio dos
noches consecutivas.
Se me pidió que hablara en ambos sobre la gestión ágil del cambio y el patrón fue
interesante:
Encuentro ágil: “Esa maldita gente del cambio, tratando de entrar y pasar por encima de
nuestro equipo, imponiendo sus puntos de vista sobre cómo debemos trabajar. ELLOS. NO.
LO. ENTIENDEN”.
Reunión del cambio: “Esos malditos entrenadores ágiles, que interrumpen a toda la
organización y no tienen ni idea de cómo afectan a la organización en general. ELLOS. NO.
LO. ENTIENDEN”.
La reunión ágil fue la primera, así que sabiendo que estaría a dos puertas de distancia la
noche siguiente en la reunión de cambio, le pedí a un grupo de entrenadores ágiles que fueran
sin invitación a la fiesta.
Para resumir, la versión ágil a la que se estaban introduciendo los gerentes de cambio eran
prácticas estructuradas y estandarizadas de las grandes firmas consultoras. Eso les hizo creer
que ágil era solo otro conjunto de estándares que tenían que seguir. Un gerente de cambios
dijo que, debido a que estaban realizando una gestión de cambios ágil, tenían que escribir
todos sus documentos en formato de historia de usuario: Como gerente de cambios, quiero
<lo que sea> para poder <obtener un resultado>.
La conversación fue fantástica y ambos bandos estuvieron de acuerdo en que buscaban los
mismos resultados, pero no habían considerado lo que necesitaba el otro bando.
Esta ha sido mi misión desde 2014. Conectar las comunidades de cambio, ágil, OD y RR.HH.
porque todos queremos lo mismo, a veces nos olvidamos de hablar entre nosotros.
¡SÉ UN MOTOR ÚTIL!
Conviértete en una persona útil y en un enlace para todas las cosas de la organización que
normalmente se ignoran. Debes ayudar al equipo ágil a comprender cómo intercambian con
el resto de la organización porque puede parecer que no les importa cuando no están
conscientes de las olas que están creando.
Te podrías decepcionar de que no exista un diagrama de proceso sobre cómo hacer esto.
Desde mi experiencia, una conversación con el equipo ágil es la mejor manera de empezar y
estos son los puntos que más importan:
Comprende su contexto: ¿En qué espacio se encuentra el equipo de entrega ágil? ¿Quiénes
son sus clientes? ¿Cómo es su calendario de lanzamientos? ¿Cuál es el impacto en la
organización? (Por ejemplo, ¿hay cambios sustanciales en los procesos comerciales? ¿Se
requiere una formación sustancial? ¿Cómo se ven afectados el marketing, las ventas y otros
equipos por lo que están produciendo? ¿Hay implicaciones en cuanto a soporte al cliente?) -
Puedes ver cómo esto puede complicarse rápidamente.
Comprende sus procesos: ¿Cuándo se llevan a cabo las revisiones de sprint, demostraciones
de partes interesadas, exhibiciones de clientes, sesiones de grupos focales, etc.? Alinea tus
esfuerzos con esos ritmos.
Aclara bien lo que necesitas: Al igual que necesitas comprender su contenido y procesos,
ellos necesitan comprender los impactos organizacionales. La diferencia es que los procesos
ágiles se basan en la extracción y lo que se entrega se basa en el ritmo del equipo. Si bien es
natural que la empresa se esfuerce, tú mismo debes ser el puente y la voz de la razón entre la
empresa y la TI, especialmente si existe una fuerte separación entre los dos.
Educa a la organización: Ponte en contacto con el entrenador ágil, si el equipo tiene uno, y
educa a la organización sobre la importancia de una integración más estrecha entre el negocio
y la TI. En una organización, nuestro equipo de entrenadores llamó esto nuestro programa de
alcance. Inspiramos a RRHH, aprendizaje y desarrollo, equipos ejecutivos y más para
mostrarles cómo simplificar y coordinar mejor. El punto clave es que fue su elección. Les
hicimos conscientes de lo que podíamos hacer, y nos llamaron cuando lo necesitaban y lo
deseaban.
Esta es una forma de educar a la organización sobre cuán interconectado está todo:
Este tablero Kanban gigantesco, sorprendentemente feo, muestra cada idea y pieza de trabajo
que se almacena en el cerebro colectivo de esta organización.

La sección del extremo izquierdo: Nuestros principios, el propósito de esta

visualización y quiénes son nuestros clientes.
La cuadrícula verde: Un mapa de ideas, no compromisos. Los carriles se alinean
con los flujos de ingresos y las principales áreas de productos. Las columnas son, de
izquierda a derecha: T3 2014 | T2 2014 | T1 2014 | Este trimestre. Las notas
adhesivas amarillas en la columna This Quarter (Este trimestre) tienen etiquetas
adhesivas pequeñas de colores. Esas notas adhesivas muestran los equipos que
necesitan trabajar en esas cosas.
La sección central: Detalles de nivel medio, como épicas, diagramas de flujo de
trabajo y otros detalles de nivel medio que surgieron de las sesiones de
descubrimiento de productos.
La sección del extremo derecho: Detalles del sprint por equipo. Eso mostró
exactamente en qué estaban trabajando los equipos.

Aquí hay un primer plano de la sección del extremo izquierdo:

En una pared diferente visualizamos la historia de la empresa:

Esto mostró:
 Una instantánea del estado actual, número de clientes, cantidad de datos, etc.
Cronología de los principales hitos y eventos, como cuándo se incorporaron nuevos
clientes, cuándo se lanzaron nuevos productos, premios y eventos importantes de la
industria.

Trabajé con Leandog y Jon Stahl en esto. En su opinión, cuando visitas empresas de
productos que tienen productos físicos, entras en su oficina y ves lo que hacen. Cuando
visitas empresas de software como esta, no ves nada y no tienes idea de lo que hacen.
Los empleados deben sentirse orgullosos de sus logros y este muro estaba en el vestíbulo
delantero para que todos lo vieran cuando entraran, al igual que los clientes.
Finalmente, estas dos últimas visualizaciones muestran los viajes del cliente y de los datos a
través de la organización y todo sobre su tecnología y herramientas:
¿POR QUÉ ESTO ES IMPORTANTE PARA LOS AGENTES DE CAMBIO?
Sencillo. Se trata de ayudar a las diferentes áreas de la organización a comprender los
contextos de los demás. La foto superior mostraba el flujo de datos y el cliente a través de la
organización y se utilizó para solucionar problemas y ayudar a comprender el esfuerzo
aproximado de realizar cambios. Las cintas de la foto muestran el flujo de datos y las notas
adhesivas amarillas del extremo derecho muestran las pantallas físicas en las que aparecen los
datos.
La foto de abajo expuso por qué había confusión sobre las funciones: demasiados sistemas
rastrearon esas cosas. De hecho, esta fue la organización técnicamente más competente en la
que he trabajado y se movieron tan rápido que generar notas de la versión fue un problema.
Generar notas de la versión es aburrido, pero importante. Los equipos técnicos siempre tenían
un trabajo más complicado, así que me hice cargo de ese proyecto. Yo era su entrenador ágil
y, como solía ser desarrollador, ayudé a automatizar un informe simple que se enviaría a
cualquiera que quisiera ver lo que vendría en la próxima versión y lo que se acababa de
publicar.
Las personas ágiles a menudo se burlan de Jira. La burla les toca a ellos. Esta compañía usó
Jira y si no lo estuvieran usando, no habría podido proporcionar datos instantáneos a la
sección comercial.
ENCUENTRA TU METÁFORA
¿Recuerdas los operadores de centralita? Yo no, ¡pero sé que existieron! Eran el vínculo entre
la persona que llama y el destinatario de la llamada. Eso es lo que hacen los agentes de
cambio, actúan como enlace entre dos grupos, como departamentos y personas, gerencia y
empleados, etc.
Si esa metáfora no te funciona, ¿qué tal un controlador de tráfico aéreo? Se sientan en lo alto
y ven cómo todo está interconectado entre sí.
Si esa no es una buena metáfora, ¿qué tal los navegantes de coches de rally? El conductor
está enfocado en conducir, el navegador está enfocado en ayudarlos a ser conscientes de su
entorno y de lo que se avecina.
La forma en que ves tu papel como agente de cambio es la pieza central de cómo puedes
cambiar mejor tu pensamiento y enfoque para el cambio.
 PARTE V: ¿QUÉ HA CAMBIADO DESDE LEAN
CHANGE MANAGEMENT?

Cuanto más cambian las cosas, más permanecen iguales. - Tom Keifer

En 2009, cuando escribí la publicación del blog que cambió mi vida, no esperaba
embarcarme en una búsqueda mundial para explorar por qué algunas personas estaban
haciendo que el cambio funcionara, mientras que otras se quedaban estancadas.
Hoy en día hay tantas distracciones con nuevos acrónimos, modelos, esquemas, diagramas de
aspecto extraño y guías paso a paso basadas en la opinión de alguien sobre cómo ellos ven el
cambio.
Los seres humanos tenemos la necesidad de comprender las cosas. Cuando escribo o creo
diagramas y videos explicativos, es mi forma de transmitir cómo veo el mundo del cambio.
No es más cierto que el punto de vista de otra persona, y cuando la gente me pregunta,
“¿Cómo implemento Lean Change Management?” Lucho con la forma de responder.
Cuanto más profundicé en responder esa pregunta, más encontré ideas atemporales y
universales que importan más que un nuevo diagrama o modelo.
Un gran ejemplo es cómo Alan Mulally abordó el cambio en Ford 1. Según su entrevista con
el MIT, una reunión semanal fue la pieza central de su estrategia.
Hizo que los jefes de departamento globales se reunieran semanalmente y:
“Cada semana, nos reuníamos y dábamos la vuelta al mundo. Analizamos todos los riesgos y
oportunidades y los entornos comerciales. Analizamos nuestra estrategia. ‘¿Todavía tiene
sentido? ¿Hay algún cambio que debamos hacer?’ Luego miramos los detalles de nuestro
plan ... Actualizas constantemente tu sentido de la realidad, pero no solo yo lo hago, es todo
el equipo”.
Te animo a leer la entrevista completa si quieres ver cómo alguien trasciende la última moda
con buenas capacidades de liderazgo probadas y verdaderas.
Lean Change Management consistía en tener el proceso de cambio más sencillo y eficiente
posible que permitiera a los agentes de cambio centrarse en lo que importa en lugar de seguir
un proceso.
Si tu proceso de cambio es ágil y simple, es más probable que los agentes de cambio piensen
en la mejor manera de hacer avanzar el cambio.
Si tu proceso de cambio es inflado y complicado, es más probable que los agentes de cambio
sigan el proceso según lo prescrito.
GESTIÓN DE CAMBIOS MODERNA
Estoy seguro de que algunos de ustedes pueden haberse quejado ante esa frase y pueden estar
pensando: “¿No dijiste antes que deberíamos detenernos y mirar a nuestro alrededor en
lugar de inventar algo nuevo?”
Sí, sí lo hice. Pero estas etiquetas no importan. Solo las uso para darte una idea de mi manera
de pensar.
Lo que me quedó claro después de viajar por el mundo y conectarme con tantos agentes de
cambio es que había ciertas ideas universales que los guiaron para facilitar cambios más
significativos. Esas ideas universales fueron los Cinco universales del cambio que mencioné
en el capítulo Transformando tu forma de pensar sobre el cambio.
Piensa en un buen amigo que tengas. Ahora piensa en cuándo conociste a esta persona y
cómo se desarrolló esa amistad.
¿Cómo sucedió?
¿Compraste un libro de tácticas sobre cómo cultivar una relación? ¿Seguiste un esquema,
método o guía de proceso paso a paso de las mejores prácticas que garantizarían una amistad
exitosa? ¿Qué métricas implementaste para medir el éxito y garantizar el Retorno de
inversión del tiempo invertido?
¡Por supuesto que no! Eso suena tonto. Las verdades universales para establecer y mantener
una relación con otra persona son análogas a las verdades universales sobre la forma en que
ocurre un cambio significativo.
Descubrí esas verdades viajando por el mundo y encontrando lo que era importante para los
agentes de cambio. Recopilé desafíos de cambio de cientos de talleres y aquí está la vista
categorizada de lo que los agentes de cambio querían aprender más:

de arriba a abajo:

propósito
herramientas y habilidades modernas
inspiración y liderazgo
motivación
alineación y co-creación
cambio de cultura
cambio general
resistencia
ágil
 Todos los demas

Algunos ejemplos de los desafíos de cambio más comunes que enfrentan las personas son:

¿Cómo pueden ser amigos la gestión ágil y del cambio?

¿Cómo puedo utilizar herramientas más ágiles / magras en el cambio?
¿Cómo puedo lograr que los líderes / gerentes / partes interesadas participen en el
cambio?
¿Cómo puedo superar la resistencia al cambio?

Esto me hizo dar cuenta de que el cambio ágil, el cambio magro, el cambio moderno y
cualquier otra etiqueta de marketing es solo eso, una etiqueta. Este libro es un gran ejemplo,
lo llamé Change Agility (Agilidad en el cambio) para llamar la atención sobre mis ideas.
Sin embargo, ese es solo el punto de entrada. Cuando escuchas el término ágil, o agilidad, tu
cerebro ya está generando suposiciones sobre lo que trata este libro. Si tu cerebro te dijera
que se trata de cómo aplicar un nuevo proceso para ser más ágil en el cambio, probablemente
odiarías este libro. Aunque, probablemente no hayas leído hasta aquí, ¡así que es un punto
discutible!
Las etiquetas vienen y se van. Con el tiempo, la gente se cansará de cambio ágil, cambio
magro, cambio moderno y cualquier otra etiqueta, y pasará a otra cosa.
Larry Smith, profesor adjunto de la Universidad de Waterloo, dijo:

“Cuando los consultores comienzan a usar el término, la idea se convierte en un

producto básico y en declive, y pronto será reemplazada por otra cosa”. Esto fue en
una conferencia de intraemprendedores, y siguió diciendo: “En 50 años, esta
conferencia seguirá siendo importante, pero se llamará de otra manera porque estas
dos ideas fundamentales nunca cambiarán: competencia e innovación. Cuanto más
innovamos, más competencia creamos. Cuanta más competencia creamos, más
necesitamos innovar”.

En los capítulos finales de la Parte V, compartiré una historia sobre lo que sucedió con The
Commission cinco años después. También compartiré una variedad de manifiestos de cambio
ágil recopilados de varios talleres en todo el mundo. Estos mostrarán que no importa de qué
país sean los agentes de cambio o el tamaño o la industria de las organizaciones a las que
sirven, todos tenemos los mismos desafíos y todos compartimos puntos de vista similares
sobre lo que significa ser más ágil en la gestión del cambio.
 ¿QUÉ PASÓ CON THE COMMISSION?

M e mantuve en contacto con la gente de The Commission a lo largo de los años

porque siempre es bueno ver cómo evolucionan las cosas, especialmente
porque pasé un año de mi vida allí. Todas las empresas que he visitado y en
las que he trabajado han mejorado con el tiempo, pero las conversaciones de 'fracaso' parecen
dominar las redes sociales porque es más divertido hablar de ello.
Como seres humanos, amamos el drama. A mi amigo Andrew Annett le gusta decir que
nuestros cerebros son como velcro cuando se trata de cosas malas y como teflón cuando se
trata de cosas buenas. Recordamos lo malo y siempre olvidamos lo bueno.
No voy a profundizar en el mito del 70% de fallas en la gestión del cambio, o las 8
disfunciones principales, u otras tonterías, porque todo es una tontería. No importa cuán
pequeños sean, los cambios organizacionales son demasiado complejos para destilarlos en un
resultado binario de éxito o fracaso.
Algunas personas me han preguntado si la transformación en The Commission fue un éxito y
siempre respondo de la misma manera:
Cuando me fui, las cosas estaban mejor que cuando empecé y siguen evolucionando.
Es fácil para mí intervenir y ver cuánto progreso se ha logrado, así que me senté con un par
de personas en The Commission en 2018 para escuchar más sobre lo que había cambiado.
Uno de ellos dijo:
“Si hubieras escrito este libro hace dos años, habríamos llorado [contándote lo que pasó
desde que te fuiste], pero las cosas están bastante bien ahora y están mejorando” .
LAS GRANDES COSAS

Cambios de CIO en los últimos seis años.

El equipo QMO no existe, y los entrenadores y Scrum masters ahora se sientan en
los flujos de entrega.
Todavía usan Lienzos de Cambio cuando es necesario.
Siempre visualizan el trabajo, aunque la gigantesca placa Kanban empresarial se ha
extinguido (las placas ahora son todas electrónicas y se centran en proyectos y
servicios).
El programa de modernización se puso en marcha con la cantidad de problemas que
podría esperar de un programa de modernización de 3 años diseñado para pasar de la
tecnología de mainframe a una pila de tecnología moderna. Algunos todavía culpan
a los 'ágiles' de todos sus problemas relacionados con esta modernización.
La gestión del cambio ya no es una ocurrencia tardía; sucede al inicio de un proyecto
cuando es necesario
Los grupos de entrega se han alineado en torno al cliente.
En la reorganización más reciente, para ciertos puestos, las personas tuvieron la
oportunidad de postularse para nuevos puestos.
La gente de EX-QMO todavía recibe ayuda de varias partes de la organización para
facilitar los ejercicios de Lego Serious Play, retrospectivas y más.
La jerarquía creció en un momento como resultado de un liderazgo diferente y luego
retrocedió como resultado de un nuevo liderazgo.
Se está creando un nuevo método de entrega con un consultor de cambio externo, el
grupo de gestión del cambio recién formado y líderes seleccionados.
EVOLUCIÓN CONTINUA
No existe tal cosa como una progresión de cambio lineal del estado actual-> transición->
estado futuro. Solo hay una evolución continua que tiene reflujos y flujos de energía a los que
me referiré como las Ondas de Cambio. Cada onda eleva la organización a nuevas alturas y
desde los albores de la organización, así es como evolucionan todas las empresas.
The Commission y todas las demás organizaciones que he visitado evolucionan de acuerdo
con este mismo patrón:

texto en la imagen:
Lado izquierdo: seguir el proceso, mejores prácticas
Medio: enfoque personalizado, más claridad sobre el problema
lado derecho: cambio que es significativo

A PARTE : Se pueden encontrar más detalles sobre The Waves of Change (Ondas de Cambio)
en changewayfinder.com - Cuando escribía este libro, estaba a medias; ahora está listo y
terminado. Puedes pensar en estas ondas como niveles de madurez, con la diferencia de que
cada onda en cada organización significa algo diferente. Un modelo de madurez asume una
progresión lineal de un estado a otro, independientemente del contexto. Cualquier
organización determinada puede pasar por 2 o 3 ondas para alcanzar el segundo nivel de
cualquier modelo de madurez que esté intentando conseguir.
Primera onda de cambio: Más superficial por naturaleza, objetivos y visión poco claros, sin
propósito convincente, fuerzas sistémicas opuestas (mandatos de desempeño en desacuerdo
con los resultados, etc.).
Las cosas mejorarán, pero sobre todo el proceso y las mejoras menores, enmascaradas con
palabras de marketing de los consultores o del equipo de cambio.
Ejemplo: En The Commission querían instalar un proceso ágil. Sabíamos que producir lo
incorrecto más rápido no era útil, pero tenían que pasar por esta onda.
Cambio de la segunda onda: Frustración porque no lo hicimos bien la primera vez y
escepticismo, pero más voluntad para cambiar las cosas.
Durante la segunda onda, habrá más claridad sobre el problema que debe resolverse y las
preguntas sobre por qué abordamos la primera onda de la forma en que lo hicimos. El cambio
complejo siempre se ve más claro en retrospectiva.
Ejemplo: En The Commission, pasamos de equipos funcionales a equipos multifuncionales
una vez que la organización se enteró de que esto sería más efectivo en lugar de hacer las
funciones más ágiles. Esto no hubiera sido posible desde el principio debido a las malas
relaciones entre algunas funciones.
Tercera onda de cambio: Más enfoque en los empleados y el cliente en vez de un enfoque
interno. Aunque se habló de esto en la primera forma, se adoptó la teoría, ahora se está
llevando a cabo.
Ejemplo: ¡Alerta de spoiler! La fábrica digital, los hackatones y los programas de innovación
comenzaron a ocurrir años después de la primera transformación.
El cambio de pasos y fases lineales hacia la gestión de la energía de la onda es difícil. Los
agentes de cambio capacitados desarrollarán un sexto sentido para saber cuándo es el
momento adecuado para intervenir.
Notarán que cuando la onda está disminuyendo, es una gran oportunidad para reducir la
velocidad, reflexionar y revisar el propósito del cambio original para inyectarle una nueva
vida. Si bien nos gusta planificar antes y reflexionar después de la fase de ejecución, la
realidad es que avanzarás a través de múltiples ondas dentro de la fase de ejecución. Evita la
necesidad de mantener el rumbo solo porque se siente repugnante pensar en todo el tiempo y
el dinero gastado hasta ahora.
Nunca es demasiado tarde para revisar de nuevo el propósito y recuerda que, si eres un agente
de cambio externo, tu participación en la historia de la organización se limita al primer acto,
mientras que los empleados afectados por el cambio participarán en los tres actos.
EL EQUIPO DE INNOVACIÓN
Cuando empezamos en The Commission, teníamos tableros Kanban funcionales. Cuando el
desarrollador tomó un ticket para terminar, tuvo que subir al octavo piso y ponerlo en la cola
del equipo de prueba. Después de eso, el trabajo se coordinó en nuestras reuniones
empresariales de pie. Al principio de esas reuniones, la hostilidad era la norma: “¡Llego tarde
porque TÚ me diste requisitos de mierda!”
Eventualmente, la organización se dio cuenta de que moverse hacia equipos multifuncionales
era mejor, pero tenían que pasar por este dolor para verlo.
Cuando creamos la primera área de trabajo co-ubicada en un espacio abierto, la gente se
asustó. Estaban acostumbrados a la seguridad de su cubículo privado, tenían mucho espacio
en el escritorio, dos monitores y mucho espacio de almacenamiento. El primer espacio
colaborativo abarrotó a la gente en un espacio tan reducido que prácticamente se codeaban
con sus vecinos.
En el transcurso de un año, migraron de equipos funcionales a equipos multifuncionales
(Onda 1) y, finalmente, a espacios de equipo colaborativos más abiertos (Onda N). Podría
haber sido necesario 7 u 8 ondas de cambio para pasar de equipos funcionales a espacios
colaborativos. Recuerda que estas no son fases, son evoluciones naturales que ocurren
durante un período de tiempo que respeta el ritmo natural de cambio de la organización.
Después de esas ondas de cambio, la siguiente evolución fue la creación de equipos de
innovación y lograron cosas increíblemente maravillosas:
• Implementaron hackatones en los que una aplicación finalmente entró en producción.
• Eliminaron a un MVP sin que los miembros del equipo fueran crucificados por ello, porque
los primeros comentarios demostraron que no era correcto construirlo.
• Un equipo conjunto de negocios y TI (llamado Digital Factory (Fábrica Digital), que es la
novedad de copiar de muchas organizaciones grandes) implementó una aplicación en
producción y ganó un premio en el sector público.
Para revisar rápidamente las ondas de cambio, todas las organizaciones saben que necesitan
innovar de alguna manera. Todas las organizaciones saben que la transferencia de software
entre los departamentos es terriblemente ineficiente, pero hasta que la dificultad de continuar
con el status quo supere la dificultad del cambio, no actuarán.
Cuando comencé en The Commission, no había posibilidad de que hubieran aceptado la
necesidad de crear equipos de innovación porque los departamentos funcionales ni siquiera
estaban colaborando todavía. La división de TI era análoga a una planta de fabricación,
entrega los widgets de una función a otra y verifica la calidad al final.
COPIAR, PEGAR, AJUSTAR
Al igual que mi audaz declaración de que el cambio ocurre en ondas, las organizaciones
mejoran cuando imitan a otras organizaciones. En The Commission, la empresa no estaba
contenta con lo que se estaba entregando, y la gente de TI no estaba comprometida con la
división de servicio al cliente, por lo que su comprensión del cliente se limitaba a lo que
ordenaba la sección comercial.
Cambiamos la conversación a cómo ellos podían cambiar las cosas, por lo que benefició a los
usuarios finales, lo que causó una diferencia radical en el enfoque de los cambios de
estructura y proceso.
Los ejecutivos de nivel C visitaron otras organizaciones que estaban haciendo cosas que ellos
querían hacer. Este es un patrón que he visto en tantas organizaciones. Ven ejemplos de lo
que les gusta de artículos de noticias o historias en Linked In y se comunican con los líderes
de esas organizaciones para compartir historias. Si has trabajado para numerosas empresas de
telecomunicaciones, bancos o compañías de seguros, notarás que su funcionamiento es más o
menos el mismo. Esto se debe a que las mismas personas pasan de una empresa a otra
copiando y pegando ideas, procesos y herramientas que les gustan.
Es tentador comprar modelos operativos de grandes firmas consultoras y cuando estaba en
The Commission, esa era la norma. Contrata la mejor empresa de consultoría, subcontrata
todo o compra una guía de mejores prácticas. Esta vez lo hicieron de manera diferente,
enfocándose en lo que beneficiaría a los clientes finales e involucrando a líderes
seleccionados desde adentro.
EL ESQUIVO CAMBIO DE CULTURA
Cuando la gente dice que no se puede transformar a menos que cambie la cultura, esto, mis
amigos, es un intento de cambiar la cultura. ¿Es una cultura transformada? Por supuesto que
no. Algunos tipos de organizaciones siempre tendrán un cierto tipo de cultura dominante,
pero pueden crear focos de grupos contraculturales.
 UN MANIFIESTO PARA UN CAMBIO ÁGIL

E s de esperar que a estas alturas hayas creado tu manifiesto de cambio ágil. Aunque
podrás compartir y comparar en changeagility.org, aquí hay algunos pensamientos e
ideas de un par de clases en varias partes del mundo.
A menudo me preguntan: “¿Quién hace bien este cambio ágil?” Lamento dejar fuera a
algunas gentes, pero es Finlandia. Los finlandeses tienen la habilidad de ser increíbles en casi
todo.
Recuerdo mi primera incursión en el mundo ágil hace más de 10 años cuando la palabra ágil
significaba algo. Los primeros en adoptar lo ágil encontraron cuatro valores simples y 12
principios atemporales que reforzaban sus creencias con un llamado a la acción sobre cómo
podrían mejorar sus organizaciones.
No es ningún secreto que la fiebre del oro está en marcha para capitalizar el marketing ágil, la
gestión ágil del cambio, el reemplazo ágil de papel higiénico y la agilidad comercial. Pero
imagino que es bastante confuso para las personas nuevas en lo ágil descubrir cómo analizar
todo el ruido, el marketing y la confusión para comprender qué diablos significa.

Cuando comencé a aprender sobre lo ágil, había seis libros, un manifiesto y las mismas nueve
personas en cada encuentro. Era sencillo. Hoy en día, hay 72 esquemas y decenas de miles de
expertos que afirman tener experiencia en lo ágil, por lo que no es de extrañar que, si quieres
aprender sobre lo que es ágil, termines totalmente confundido.
He tenido miles de personas a través de mi taller de cambio, y hay un ejercicio que instruye a
las personas a crear un manifiesto de cambio ágil que capture el espíritu del manifiesto ágil.
El objetivo de este capítulo es compartir algunos ejemplos para aquellos que creen que el
futuro de la gestión ágil del cambio no tiene nada que ver con estándares, esquemas y
modelos de procesos. Seguro, estas cosas emergerán, esa es la belleza de un mundo
capitalista, pero todas están perdiendo el sentido.
La razón por la que digo eso es porque mi taller de cambio generalmente atrae a entrenadores
ágiles, empleados que han sido seleccionados para hacer que un cambio funcione, o
practicantes tradicionales del cambio que ya han trabajado de manera ágil durante toda su
carrera sin darse cuenta, pero quiero rellenar con algunas piezas que faltan.
Como recordatorio, aquí está el manifiesto ágil:
• Individuos e interacciones en vez de procesos y herramientas
• Software de trabajo en vez de documentación completa
• Colaboración con el cliente en vez de negociación de contratos
• Responder al cambio en vez del seguimiento de un plan
Es decir, si bien hay valor en los elementos de la derecha, valoramos más los elementos de la
izquierda.
Ahora bien, he aquí algunos ejemplos de cómo la gente en mis talleres se ha adaptado al
cambio:
DE UN GRUPO EN BÉLGICA:

Adopción de la incertidumbre en vez de la reducción del riesgo

Facilitar consideraciones en vez de decirle a la gente qué hacer
La colaboración general hace posible la resolución de problemas complejos
Co-creación en vez de decisiones jerárquicas
Colaboración general en vez de la optimización local
DE UN GRUPO EN FINLANDIA:
estos son los puntos enumerados en la imagen.

Individuos e interacciones en vez de procesos y herramientas

Acción diaria en vez de documentación completa
Transparencia y autogestión en vez de una estricta coordinación y micro gestión
Respuesta al cambio en vez de seguir un plan
DE OTRO GRUPO EN FINLANDIA:
estos son los puntos enumerados en la imagen.

Comprensión en vez de técnicas y herramientas.

Colaboración en vez de informar
Empoderar a las personas en vez de administrar personas
DE UN GRUPO EN VANCOUVER, CANADÁ:

Resultados en vez de estructuras y procesos

Empoderamiento del equipo en vez de jerarquía
Comunicaciones bidireccionales periódicas en vez de proclamaciones
Compromiso con la educación o el aprendizaje continuos a través de una
capacitación única.
DE UN GRUPO EN LOS EE. UU.:

Halar en vez de empujar

Tacto en vez de tecnología
Orgánico en vez de un guion
Crecimiento en vez de perfección

Un grupo incluso hizo su manifiesto de cambio con Lego:

LO QUE ME ENCANTA DE ESTE EJERCICIO ES QUE HACE QUE LA GENTE
PIENSE DENTRO DE SU PROPIO
contexto. Subestimamos el poder del significado personal cuando se trata de cambios.
Creemos que un conjunto de estándares y nuevas certificaciones ayudarán. No lo harán.
Si tienes curiosidad y eres lo suficientemente serio acerca de querer aprender sobre la gestión
ágil del cambio, no te limites a lo que tu asociación profesional dice que debes aprender, ¡ve
a explorar!
DÓNDE APRENDER SOBRE LA GESTIÓN ÁGIL Y DEL CAMBIO
Mi mejor consejo para ti, como agente de cambio que eres nuevo en lo ágil, es que aceptes un
trabajo de Scrum Master en una organización pequeña. Creo que es la mejor forma de
experimentar la verdadera agilidad.
Es difícil aprender lo ágil hoy en día porque la mayoría del contenido que encontrarás está
relacionada con organizaciones empresariales y proviene de personas que lo ven como un
proceso porque eso es todo lo que saben.
Lo más probable es que si tu primera experiencia con lo ágil proviene de una organización
grande, estás viendo la tercera o cuarta onda de lo ágil, es decir, lo ágil en grandes empresas.
Aunque esa es la naturaleza de la evolución de todas las ideas, se perderá la oportunidad de
experimentar lo que es trabajar con un equipo increíble que crea soluciones increíbles para
los clientes.
Echa un vistazo a Agile Uprising 1 y busca en Google el movimiento de recuperación ágil 2.
Un amigo mío, Ryan Lockhard de Agile Uprising, entrevistó a los 17 firmantes del
manifiesto en 2016 y es una serie fantástica que revisa la intención de lo ágil y explora cómo
ha cambiado la agilidad desde 2001. Notarás que usé la palabra intención a menudo en este
libro. Es importante comprender por qué y cómo surgieron estas ideas, internalizarlas y basar
tus acciones en torno a ellas. No es una visión de cultista, aunque pueda parecerlo.
El Movimiento de recuperación ágil (Take-Agile-Back) fue creado por Tim Ottinger, un
practicante ágil conocido y respetado, en 2014. En su opinión, lo ágil se convirtió en un gran
negocio y orientado a procesos. A la excelencia técnica se le redujo prioridad, o en algunos
casos se dejó aparte, y a lo ágil se le succionó el alma.
Tanto Agile Uprising como los movimientos de recuperación ágil merecen una mirada para
ayudarte a comprender que lo ágil valora más las declaraciones del lado izquierdo del
manifiesto, pero reconoce que las declaraciones de la derecha siguen siendo importantes.
Hay extremistas en todas las disciplinas. Hay personas fuertes del lado izquierdo del
manifiesto que se sienten personalmente atacadas por la evolución ágil hacia un gran
esquema piramidal de certificación y negocios.
Por otro lado, hay personas sólidas del lado derecho del manifiesto que solo conocen la
agilidad como una gran empresa porque no comenzaron a aprender sobre ella hasta después
de 2012, cuando comenzaron a surgir las grandes empresas ágiles.
Aprende de ambos lados, pero definitivamente revisa la intención del manifiesto.
 PARTE VI - CHANGE WAYFINDER

He mencionado el Change Wayfinder muchas veces. Para cuando leas esto, estarás lleno de
grandes ideas, prácticas e historias más útiles que te inspirarán a pensar de manera diferente
sobre el cambio.
También reiteraré que cuando escribí este libro en el verano de 2019, había planeado agregar
un montón de historias cortas que podrías usar como inspiración.
Mientras hacía la edición final, decidí no hacer eso. En su lugar, decidí publicar estas
historias, prácticas e ideas en línea en changewayfinder.com para que todos puedan acceder a
ellas sin comprar este libro. Es parte de mi creencia que compartir una evolución continua de
ideas es más importante que vender un libro, así que las dividí en cosas separadas. De esa
manera, puedes consultar las historias en línea sin el libro o comprar el libro y obtener acceso
gratuito a la comunidad en línea. Y no te preocupes, sigue leyendo para descubrir cómo
obtener tu acceso gratuito, ¡parte de mi agradecimiento por comprar la versión beta del libro!
LA PÁGINA DE INTERNET DE CHANGE WAYFINDER
Antes de contarte cómo obtener acceso gratuito, quería compartir la historia del nombre The
Change Wayfinder . Creo que la disfrutarás.
Mientras ves la película, The Rise of Skywalker, durante su viaje para encontrar al emperador,
Rey se atasca. Necesita ayuda y busca un rastreador de rutas que la ayude. Sí, es así de
simple. Pensé que la idea de un rastreador de rutas era genial y quería usarlo en el futuro. Así
es como surgió el nombre.
Ahora, volvamos a tu acceso gratuito:
Dirígete a changeagility.org. Ingresa el código: starwars y tendrás 3 meses para explorar
Wayfinder en la comunidad de Modern Change.
Mi última década y un poco de trabajo como agente de cambio me ha demostrado que las
personas necesitan más ayuda y apoyo a solicitud.
Necesitan ayuda para crear claridad para poder avanzar. Los esquemas, métodos, manual de
tácticas y métodos estáticos no tienen en cuenta el contexto. ¡Un GPS, o rastreador de rutas,
sabe que hay un río frente a ti que no vas a poder cruzar con el automóvil!
Recuerda, el cambio no es un viaje, es más como serpentear continuamente a través de la
niebla. Un rastreador de rutas puede ayudarte a despejar la niebla hasta cierto punto, pero el
destino final siempre cambiará.
ESTO ES LO QUE ENCONTRARÁS EN THE CHANGE WAYFINDER:
Para los grandes pensadores: Los grandes pensadores necesitan grandes ideas que desafíen
sus propias creencias sobre cómo ven el cambio. Empieza a explorar conceptos de cambio
modernos y otras grandes ideas y filosofías que pueden ayudarte a probar diferentes lentes
para ver tu cambio.
Para los pensadores prácticos: Elige entre una variedad de actividades ágiles, empresa
emergente magra, pensar en diseños, coaching y entrenamiento. Todos cuentan con opciones
para adaptarlo a su contexto e historias de inspiración para que puedas ver quién los probó y
cómo funcionó.
Para quienes buscan inspiración: Copia, pega, modifica. Los humanos imitan lo que ven y
lo ajustan a su contexto. Inspírate con las historias de agentes de cambio de todo el mundo
que están modernizando y contextualizando su enfoque del cambio con acciones concretas.
Lo organicé de esta manera por algunas razones:

He escuchado un millón de veces a lo largo de los años, “Sí, suena genial en teoría,
pero no puedo hacer eso”. Las historias en Wayfinder brindan una prueba social de
que ES posible.
Chefs: Hay muchos agentes de cambio asombrosos a los que simplemente se les
debe inculcar que piensen en el cambio de manera diferente.
Nuevos agentes de cambio: Cuando era nuevo e inexperto, me hubiera gustado tener
algo como esto para señalarme hacia una idea o práctica.
He visto que los líderes de pensamiento del cambio experimentados y
autoproclamados se equivocan por completo con los conceptos básicos de la agilidad
porque se subieron a la onda ágil durante la fase de escalamiento empresarial y del
“yo también” corporativo. No pretendo culpar a estas personas, pero es mejor que
aprendas sobre el cambio ágil de los entrenadores ágiles. Lo siento. Piénsalo de esta
manera. Si tienes tu propio negocio, ¿deseas recibir asesoramiento y servicios
contables y fiscales de alguien que haya sido contador o de alguien que haya leído
un libro sobre contabilidad?

Sobre todo, quería que pudieras encontrar inspiración en función de quién eres y de lo que
necesitas. Si tu entorno exige más estructura y control, elige prácticas diseñadas para eso.
Si deseas hacer oscilar el péndulo hacia la co-creación, el pensamiento de diseño y las
prácticas de cambio ágil, sé que encontrarás algo.
Para terminar, terminaré este libro con una cita de mi amigo Don Gray. ¡Sí, otra historia de
AYE! Dirigió una sesión llamada Reading the River y la premisa era:
“Nada con la corriente de la organización”.
A menudo, como agentes de cambio, especialmente agentes de cambio ágiles, queremos
interrumpir. Hay un momento y un lugar para nadar con la corriente y un momento para
nadar contra ella.
 PARTE VII – AGRADECIMIENTOS

Primero y, antes que nada, nuevamente, las buenas personas que organizaron AYE y PSL,
que sin duda me salvaron la vida:

Don Gray, Esther Derby, Johanna Rothman, Jerry Weinberg y Steve Smith

Espero que sepan lo mucho que me cambió la vida la experiencia de esos eventos.
¡Gracias a todas estas personas y disculpas a los que olvidé!

Sue Johnston y Andrew Annett: No hago más que preguntarme cómo estructuraría
Sue una conversación, y cuál es esa palabra que Andrew usará para darle sentido al
universo entero.
Los miles de agentes de cambio que he conocido a lo largo de los años en talleres y
organizaciones internas, todos los facilitadores de LCM y miembros de la
comunidad de los que aprendo a diario.
Colin Mulholland: Tu historia del desayuno me hace sonreír todos los días.
Dawna Jones: Tu capacidad de pensar más allá me sorprende todos los días
Julia Borgini por encontrar 2,943 errores en la versión 0.1 que necesitaba fusionar de
nuevo en Vellum.
Los autores del Manifiesto: Aunque el mundo siente la necesidad de golpear a los
creadores solo porque son 17 hombres blancos, sigo pensando que es atemporal e
inspirador.
Cynthia Barlow: Uno de mis entrenadores que me ayudó a darme cuenta de que está
bien ser yo mismo.
Jean Mclendon y Hugh Gratz: Por la maravillosa experiencia Satir. Güey, tengo
mucho trabajo por delante.
Doc Norton: Nos hemos conocido un montón de veces, pero eres una gran persona y
me inspiras
Jon Stahl: No hemos trabajado juntos por un tiempo, pero fuiste una gran influencia
en cómo veo lo ágil
¡A todas las personas a las que les agradecí en Lean Change Management!
Jurgen Appelo: Tu creatividad siempre ha sido una inspiración para mí
Trevor Owens: Por esa primera experiencia de Lean Startup Machine que hizo
preguntarme cómo usar Lean Startup en el cambio
 George Carlin, además de un montón de otros comediantes (incluidos los de los que
ya no se nos permite hablar), eras un mago con palabras que hacen pensar a la gente.
Esta es una lista de personas que he conocido a lo largo de los años que me inspiran
con su pasión por hacer del mundo un mejor lugar (sin ningún orden en particular)
Esther Lind, Tabatha Cooper, Eva-Lotta Nordling, Line Degner, Andrew Guy,
Adriana Girdler, April Jefferson, Aaron Dignan, Mark Raheja, Gitte Klitgaard, Mike
Edwards, Dave Dame, Shahin Sheidaei, Mark O'Donovan, Barb Heller, Maria
Racho.
Sobre todo, a mi esposa y a mi familia que me salvan la vida todos los días.

Ah, y si te olvidé, de nuevo, ¡lo siento! No podría actuar más canadiense, supongo.
NOTES
1. PERSIGUIENDO COCHES (¿POR QUÉ ESTE LIBRO? ¿POR QUÉ AHORA?)
1  1 https://geraldmweinberg.com/
2  2 http://changewayfinder.com
3  3 https://en.wikipedia.org/wiki/Finite_and_Infinite_Games
4  4 https://simonsinek.com/product/the-infinite-game/
 3. CÓMO LEER ESTE LIBRO
1  1 https://www.estherderby.com/
2  2 https://en.wikipedia.org/wiki/Open_Space_Technology
3  3 https://thenewkingmakers.com/
4  4 https://en.wikipedia.org/wiki/Imprinting_(psychology)
5  5 Baby Duck Syndrome - https://en.wikipedia.org/wiki/Imprinting_(psychology)#Baby_duck_syndrome
6  6 https://modernchangemanagement.com/change-wayfinder/
 4. ¿SER O HACER LO ÁGIL?
1  1 https://www.agilecoachinginstitute.com/
2  2 What is Extreme Programming - https://ronjeffries.com/xprog/what-is-extreme-programming/
3  3 Kerth’s Prime Directive https://retrospectivewiki.org/index.php?title=The_Prime_Directive
 5. VOLVERSE MÁS PLENAMENTE HUMANO
1  1 The Organized Mind - https://www.penguinrandomhouse.com/books/313653/the-organized-mind-by-daniel-j-levitin/
2  2 Based on the work of Virginia Satir, I’ll point you to Jean McLendon - https://www.satirsystems.com/JeanMcLendon.
en.html (o satirglobal.org )
 PARTE I - MANIFIESTO DE GESTIÓN DEL CAMBIO MODERNO
1  1 Scrum in 10 minutes by Lyssa Adkins https://www.youtube.com/watch?v=_BWbaZs1M_8
2  2 “The Hole-in-the-Floor Model”
Extracto de: Gerald M. Weinberg. “Becoming a Change Artist.” (Página 20 del eBook)
3  3 “Diffusion approach to change”
Extracto de: Gerald M. Weinberg. “Becoming a Change Artist.” (Página 18 del eBook)
4  4 Change is like adding milk to coffee - Niels Pflaeging https://www.linkedin.com/pulse/change-more-like-adding-milk-
coffee-niels-pflaeging/
5  5 http://changeagility.org
 2 . PERSONAS E INTERACCIONES
1  1 Es decir, si bien hay valor en los elementos de la derecha, valoramos más los elementos de la izquierda. -
www.agilemanifesto.org
 5. RESPUESTA AL CAMBIO
1  1 https://www.darwinproject.ac.uk/people/about-darwin/six-things-darwin-never-said/evolution-misquotation
2  2 https://www.kodak.com/en/consumer/home
 7. CONTACTO EN VEZ DE TECNOLOGÍA
1  1 Julia Borgini es amiga desde hace mucho tiempo y editora de mi primer libro, ¡espero que no esté enojada conmigo!
Pero, por supuesto, ya que estás leyendo Beta 0.2, ¡sabrás que ella corrigió esta versión!
2  2 http://leandog.com
 8. MÉTRICAS ADAPTABLES
1  1 Is the 70% Failure Rate a Myth? http://www.agilecoach.ca/2013/08/23/70-failure-rate-myth/
 9. ADAPTARSE AL RITMO
1  1 Otto Scharmer - Theory U https://www.ottoscharmer.com/theoryu
2  2 Lean Change Management: http://leanchange.management, Jason Little, 2013
 12 . LAS PERSONAS QUE ESCRIBEN EL PLAN NO LUCHAN CONTRA EL
PLAN
1  1 Meaningful Change at National Leasing: https://leanchange.org/2016/11/how-to-make-change-matter-using-change-
canvases/
2  2 Lean Change Management – Change Canvases http://leanchange.org/canvases
 4. COLABORACIÓN MULTIFUNCIONAL
1  1 Managing Your Project Portfolio: Johanna Rothman https://www.jrothman.com/books/manage-your-project-portfolio-
increase-your-capacity-and-finish-more-projects/
2  2 changewayfinder.com tiene instrucciones para hacer esto
 5. MOTIVACIÓN INTRÍNSECA
1  1 Table Group - Getting Naked by Patrick Lencioni https://www.tablegroup.com/books/getting-naked/
2  2 Celebration Grid by Jurgen Appelo https://management30.com/practice/celebration-
grids/#:~:text=Celebration%20Grids%20are%20a%20visual,learn%20something%20from%20our%20failures.
3  3 https://leanchange.org/2017/01/combining-innovation-games-and-lean-change-management/
4  4 From Stone Age to Agile - Ardita Karaj and Jason Little http://fromstoneagetoagile.com/
 11. LAS PERSONAS QUE ESCRIBEN EL PLAN NO LUCHAN CONTRA EL
PLAN
1  1 I’m Part of an Inspiring Future https://leanchange.org/2016/07/creating-alignment-for-enterprise-transformation/
2  2 Open Space Technology - https://en.wikipedia.org/wiki/Open_Space_Technology
3  3 Lean Coffee - http://leanchange.org/leancoffee
 12 . INSPECCIONAR Y ADAPTAR
1  1 Lean Change Management Strategy Canvas - https://leanchange.org/resources/canvases/
2  2 5 Big Takeaways from LSM Toronto - http://www.agilecoach.ca/2012/01/31/4-big-takeaways-from-lean-startup-
machine-toronto/
 1. TRANSFORMAR LA FORMA DE GESTIONAR EL TRABAJO DE CAMBIO
1  1 https://retromat.org/en/?id=84-98-26-61-92
2  2 https://www.estherderby.com/books/
 2 . TRANSFORMANDO TU FORMA DE PENSAR SOBRE EL CAMBIO
1  1 http://modernchangemanagement.com
 PARTE V: ¿QUÉ HA CAMBIADO DESDE LEAN CHANGE MANAGEMENT?
1  1 http://leadership.mit.edu/rare-find-alan-mulally-complete-leader/
 2 . UN MANIFIESTO PARA UN CAMBIO ÁGIL
1  http://agileuprising.com
2  2 https://www.infoq.com/articles/taking-back-agile/