Pequeñas leyes, grandes transformaciones

O de cómo aplicar “Las pequeñas leyes de la vida” a cambios ágiles, digitales y con IA

El despliegue de software en horarios no aptos para personas

Para saber qué y cómo cambiar hay que conocer y entender lo que nunca cambia. Ese es el punto de partida. Nos obsesionamos con anticipar el futuro, con seguir la última moda tecnológica o el marco de trabajo recién publicado. Pero rara vez nos detenemos a mirar lo que permanece, lo que resiste, lo que no se mueve, aunque el mundo gire más rápido. Yo suelo decir que estoy en el oficio del cambio organizacional. Pero, en el fondo, lo que he hecho es aprender cada día a escuchar lo que no cambia en las personas, en los equipos y en las organizaciones, y usarlo como ancla para que el cambio sea posible.

El libro “Lo que nunca cambia” de Morgan Housel me recordó, con anécdotas simples, que las pequeñas leyes de la vida gobiernan más de lo que pensamos. Lo menciono porque he visto que eso mismo ocurre en las transformaciones empresariales: cambian las herramientas, cambian los discursos, cambian los consultores. Pero lo humano sigue ahí, con sus miedos, sus deseos y sus incentivos. Y si olvidamos eso, lo digital y lo ágil y, más recientemente, la IA se vuelven maquillaje pasajero.

Dejé de desarrollar software hace más de dos décadas, pero los problemas más frecuentes en tecnología de entonces venían de desplegar sistemas en unos días y en unas horas inverosímiles, como un viernes por la tarde o un domingo a las 5 a. m. Hoy, con nubes más rápidas y metodologías más sofisticadas, la historia se repite: seguimos sufriendo por desplegar en esas fechas y horarios inauditos para nuestra humanidad. Cambian los escenarios, pero no cambian los patrones. Lo que nunca cambia es más fuerte que lo que creemos controlar.

Por eso he convertido esto de entender lo que nunca cambia en un mantra y en las empresas donde he logrado que esto se acepte como una realidad, el cambio organizacional dejó de ser una carrera por inventar lo que sigue y se convirtió en un ejercicio de diseñar con base en lo que siempre estará ahí. Una empresa que entiende sus constantes humanas no necesita adivinar el futuro, porque sabe que, pase lo que pase, la gente buscará seguridad, autonomía, reconocimiento, sentido y progreso.

Leyes pequeñas que sostienen cambios grandes

Antes de hablar de prácticas, te conviene aceptar algo: las grandes transformaciones no se sostienen en estrategias grandilocuentes, mucho menos en presentaciones coloridas ante la alta dirección, sino en leyes pequeñas que se cumplen día tras día. He estado en ambos extremos. No se trata de discursos inspiradores un jueves por la mañana que olvidamos al lunes siguiente, sino de verdades sencillas que marcan el pulso de cualquier cambio. Son esas pequeñas leyes las que me sirven de brújula cada vez que acompaño a una organización. Cuando logro que sean visibles, todo lo demás fluye con más naturalidad.

La gente sigue siendo gente. No sirve de mucho pedir mentalidad ágil si el sistema invita a trabajar de forma lenta y burocrática. Es más fácil que las personas cambien cuando el entorno les facilita hacerlo. Si trabajar de manera ágil reduce esfuerzo, reduce conflictos y mejora resultados, entonces lo ágil será la primera opción, no un discurso motivacional.

El riesgo que derrumba no siempre se ve. He trabajado en cinco décadas distintas. Y, a propósito de lo que nunca cambia, he visto que los grandes problemas rara vez vienen de una falla monumental y visible. Llegan como una suma de descuidos: una alerta silenciada, un proceso sin dueño, una validación ignorada. Con inteligencia artificial es lo mismo, basta un pequeño error en la formulación de un pedido para que el sistema alucine respuestas y cause daños serios. La prevención está en mirar donde casi nunca se mira.

Lo que se acumula, pesa. Las mejoras pequeñas, hechas con constancia, transforman una organización. Los descuidos pequeños, tolerados por costumbre, también lo hacen. Nada crece en línea recta: todo se compone y se multiplica. De ahí la importancia de medir ritmos, no promedios. De tratar la transformación como un jardín que necesita riego, poda y paciencia.

Las historias mandan más que los números. Un comité puede ignorar un análisis financiero impecable, pero no puede resistirse a la historia de una persona enfrentando a diario la misma frustración. Los números convencen, pero las historias movilizan. Cada transformación necesita relatos breves, claros, capaces de mostrar quién se beneficia y cómo se siente cuando algo mejora.

Un colega me contó hace poco que un comité le negó presupuesto para mejorar un sistema, porque en las cifras no veían retorno. Un mes después volvió con un video: una agente de soporte repitiendo la misma acción manual cuarenta veces al día. La petición era la misma, pero la historia distinta. Y esta vez, aprobaron de inmediato. He estado allí.

Crecer antes de tiempo reduce lo que importa. Nada destruye más un proyecto que escalarlo demasiado pronto. Lo aprendimos con sangre tratando de “escalar ágil” y lo estamos repitiendo con IA generativa: lanzar una solución inmadura a toda la organización puede ser un suicidio. El cambio responsable necesita ensayos pequeños, pilotos controlados, pruebas que permitan aprender sin arrasar con la confianza. Y todo ello toma tiempo.

Las cicatrices gobiernan el presupuesto. Una organización que ha sufrido un susto fuerte nunca vuelve a ser la misma. La memoria emocional pesa más que cualquier discurso. No sirve tratar de borrarla: hay que diseñar con ella. Crear espacios seguros para probar, compromisos reversibles y planes de contingencia que devuelvan tranquilidad.

Construir sobre lo que no cambia. Este es el quid de la cuestión. Los clientes siempre querrán rapidez, claridad, precio justo y confianza. Los empleados siempre buscarán autonomía, maestría y propósito. Invertir en estas constantes es más poderoso que perseguir modas pasajeras. La agilidad pasará, pero la colaboración, la entrega temprana y frecuente, la reflexión y la mejora continua se quedan. Los modelos de IA pasarán, pero los datos limpios, la transparencia y la seguridad se quedan.

La variación da fuerza. Nadie sabe cuál experimento será el ganador. La única estrategia sensata es probar mucho, a bajo costo, y cerrar rápido lo que no funciona. Esparcir semillas y preparar el suelo: algunas no crecerán, otras se convertirán en árboles.

Preguntar siempre: ¿y luego qué? Cada decisión trae consecuencias directas e indirectas. Lo sabemos de sobra: un bot puede reducir a la mitad el tiempo de respuesta, pero aumentar las llamadas repetidas porque las respuestas son incompletas. Antes de celebrar un resultado, hay que preguntarse qué efecto oculto vendrá después.

Un mapa para sostener transformaciones

Una transformación real no depende de planes perfectos. Se construye con equipos enfocados, con ritmos cortos y sostenibles, con datos que muestran la realidad completa, con reglas pocas y claras. Se construye midiendo lo esencial y aceptando que fallar barato es mejor que acertar tarde. Y, sobre todo, se construye diseñando para lo que nunca cambia.

Para mí, un mapa de transformación comienza con algo sencillo: definir con claridad el propósito, y narrarlo en palabras que cualquiera en la organización pueda repetir sin confundirse. Luego, dar a los equipos foco y autonomía real, con límites claros que eviten la dispersión. Después, sincronizar ritmos, cadencias y compromisos, de forma que la empresa respire al mismo tiempo y no como un conjunto de islas.

Ese mapa también incluye algo más profundo: una manera distinta de gobernar. No con controles asfixiantes ni con promesas grandiosas, sino con reglas mínimas, con decisiones rápidas en lo reversible y con más cuidado en lo que deja cicatrices. Y, por encima de todo, con incentivos alineados: porque si los premios contradicen los discursos, la cultura se convierte en hipocresía.

Y hoy por hoy, un mapa de transformación necesita la humildad de los líderes para aceptar que la inteligencia artificial es herramienta y no tótem. Muy poderosa, pero herramienta, al fin y al cabo. Sirve para aliviar dolores y multiplicar capacidades, pero no para tapar vacíos de liderazgo ni excusar la falta de estrategia. La IA es poderosa cuando se usa con datos confiables, con transparencia y con límites claros.

Mi llamado a la acción

Yo no creo que las organizaciones sobrevivan por adivinar lo que viene. Creo que sobreviven porque responden mejor cuando lo inesperado golpea. Cambiar con rapidez es valioso, pero diseñar sobre lo que nunca cambia es lo que sostiene. Ese es el verdadero oficio del cambio: aprender a escuchar lo que no se mueve, y desde ahí, moverse mejor.

Así que mi invitación es simple: miren de frente a sus constantes, háganlas visibles, conviértanlas en cimiento. Y luego, construyan cambios encima, sabiendo que, pase lo que pase, hay un suelo firme que no se derrumba. Ese es el cambio que vale la pena.

Es definitivo: el cambio nos excita, lo constante nos sostiene. Quien diseña solo para lo primero vuela; quien diseña también para lo segundo aterriza.

Cuando Scrum se convirtió en el chico malo de la organización

Alguna vez fue el niño mimado. El chico dorado de la agilidad. El marco de trabajo que prometía orden en el caos, foco en el cliente y resultados rápidos. Pero hoy, en muchas organizaciones, Scrum es el culpable favorito. El chivo expiatorio. El "chico malo" al que todos miran con desconfianza cuando las cosas no salen como se esperaban.

En las comunidades de practicantes ágiles y en los foros de discusión se  le “tira toda el agua sucia”, se refieren a Scrum como la mayor estafa metodológica de la historia del desarrollo de software. Se habla de que no solo secuestró el concepto de agilidad, sino que lo violó, lo desfiguró y nos lo devolvió como un frankenstein metodológico que ni siquiera sus creadores reconocerían.

¿Qué pasó?

Scrum nació con buenas intenciones. Como ese nuevo colaborador que llega con ideas frescas, ganas de trabajar en equipo y una pasión por mejorar. Su estructura es simple: responsabilidades claras, eventos bien definidos, entregables tangibles. Parece el recetario ideal para una buena cocina organizacional.

Pero, como con cualquier receta, si los ingredientes son malos, si el chef improvisa o si los comensales no tienen hambre de cambio, el plato no sale bien. Scrum, por sí solo, no es una solución mágica. Y allí es donde empiezan los problemas.

"Scrum no sirve"... ¿seguro?

"Scrum no sirve aquí", dicen algunos gerentes. "Lo intentamos y no funcionó", dicen los equipos. Pero lo que muchas veces no se dice es que:

• Nunca hubo un Product Owner real, con poder de decisión. O era un gerente de proyecto enmascarado y con mucho poder. O simplemente era un ilustre sin presencia.
• El Scrum Master era otro tipo de jefe de proyecto disfrazado. Ni hablar de las empresas donde por decreto, de un día para otro, sin mayor preámbulo, nombraban SM a todos los PM.
• El equipo tenía que seguir haciendo mantenimiento, soporte, incidentes y proyectos a la vez.
• Las retrospectivas eran reuniones de quejas sin acción.
• Las revisiones de sprint eran presentaciones de PowerPoint sobre el “estado” del proyecto.
• El product backlog era una lista de tareas heredadas, no un producto con visión.

Y esas son algunas de las cosas visibles que puedo contar sin que me caigan encima los absurdos de los acuerdos de confidencialidad. Pero la conclusión de todo ello sí es inevitable: como industria, elegimos la comodidad de las recetas sobre la dureza del pensamiento crítico, preferimos comprar certificaciones que desarrollar criterio, optamos por seguir mapas en lugar de aprender a navegar.

Lo diré de otra manera: aplicamos un Scrum “de teatro”. Un simulacro. Como cuando se instala un software de contabilidad pero nadie registra los gastos. El marco estaba, pero no la intención ni la disciplina. Predominaron nuestros egos, nuestra resistencia al cambio, nuestra incapacidad para colaborar genuinamente. Scrum simplemente expuso nuestras heridas más profundas y, en lugar de sanarlas, las infectamos con más burocracia disfrazada de agilidad.

¿Falló Scrum o fallamos nosotros? O la traición del factor humano

Scrum no falló. Lo que falló fue la implementación, la interpretación y, muchas veces, la cultura. Implementar Scrum sin entender su filosofía es como comprarse una bicicleta de montaña para ir a la oficina con tacones o corbata. No es que la bicicleta sea mala. Está mal usada.

Scrum exige compromiso, transparencia, inspección y adaptación. Y eso duele. Duele para los que prefieren el control jerárquico. Duele para quienes temen la retroalimentación real. Duele para quienes quieren resultados sin cambiar comportamientos. Duele para quienes quieren seguir usando Jira como si fuera una máquina de crear agilidad. Duele para quienes convirtieron las reuniones diarias en reportes de estado glorificados.

Muchas empresas cayeron en la trampa de "agilizar" sin transformar. Adoptaron Scrum como si fuera una nueva metodología, no un nuevo paradigma. Siguieron funcionando igual, solo que ahora con "Daily", "Sprint Review" y post-its de colores. Pero el miedo al error seguía. Y el castigo al fracaso. Y la falta de visión de producto.

¿Y entonces, cómo hacer que Scrum funcione?

Con el tiempo aprendí que no se trata de "aplicar Scrum". Se trata de vivirlo. De entender sus principios y adaptarlos con madurez. No te voy a dar soluciones inentendibles de consultoría, te dejaré algunas claves prácticas, cosas que puedes empezar a hacer ya mismo si tienes la convicción, la entereza y, claro, la autoridad para hacerlo:

1. Ten un verdadero Product Owner: Con foco, con visión, con capacidad de decir "no". Sin eso, el backlog es solo una lista de deseos sin rumbo.
2. Empodera al equipo: Scrum no es para robots ejecutores. Es para equipos que piensan, deciden, construyen. Deja que respiren.
3. Invierte en un Scrum Master real: No un jefe encubierto, ni un facilitador que toma notas. Un verdadero agente de cambio que desafíe al status quo.
4. Haz del Sprint Review un momento de verdad: Invita al cliente. Muestra avances. Recoge feedback real. No te escondas detrás de informes.
5. Que la retrospectiva no sea un ritual vacío: Cambien cosas. Experimenten. Fallar está bien si se aprende rápido.
6. Mide lo que importa: No cuentes historias por contar. Mide valor entregado, impacto, aprendizaje. No velocidad. No "burn down".
7. Haz menos, pero mejor: La trampa de la multitarea es la asesina del enfoque. Scrum te da ritmo. Respétalo.

Además, Scrum supone que sabes hacer bien lo que haces usando Scrum. Practica y promulga a los cuatro vientos la excelencia técnica, la reflexión (inspección y adaptación) y el mejoramiento continuo. No persigas la metodología perfecta, lo que debes hacer es construir mejores equipos, mejores culturas, mejores personas. Hemos sido como alcohólicos buscando la bebida perfecta cuando el problema no era qué tomábamos, sino que estábamos tomando.

Mi llamado a la acción

Necesitamos entender que el método, Scrum o cualquier otro, es solo una herramienta, no el fin en sí mismo. Prioricemos resultados sobre rituales. Sigamos las reglas, pero aprendamos a romperlas inteligentemente. Desarrollemos hábitos profesionales sólidos: comunicación honesta, colaboración genuina y entrega continua de valor. Con estos hábitos, cualquier marco de trabajo, incluyendo Scrum, funciona. Sin ellos, ni siquiera el más perfecto de los métodos nos salvará.

Scrum no está muerto. Está evolucionando. Y necesita aliados que entiendan que su poder no está en los eventos, sino en los principios. Scrum se convirtió en el "chico malo" porque lo empujamos a ese papel. Porque lo implementamos sin convicción. Porque quisimos que resolviera problemas que en realidad eran culturales, no metodológicos. Dejemos de usarlo como escudo y empecemos a usarlo como espejo.

El fracaso de muchas personas, equipos y organizaciones con Scrum no fue técnico, fue emocional. No entendimos que la agilidad no era una herramienta, era un espejo. Y muchos no estaban listos para mirarse. ¿Lo estás?