Vas a chocar y lo sabes: el síndrome del director ciclístico que está aniquilando tu producto

 

Imagen generada por IA

La falacia del superhéroe multitarea

Las carreras de ciclismo me parecen muy emocionantes. Me apasiona verlas. Pero imagina esto: un director deportivo conduciendo a 50 km/h por una carretera sinuosa de montaña, rodeado de miles de espectadores eufóricos, mientras simultáneamente entrega un bidón a un ciclista o una barra energética, grita instrucciones tácticas por radio y calcula mentalmente los tiempos de carrera. Todo esto mientras "conduce" un vehículo de dos toneladas. ¿Suena demencial? Bienvenido al mundo del ciclismo profesional, donde esta práctica suicida se defiende con el argumento más peligroso de la historia empresarial: el infame "siempre lo hemos hecho así".

Esta locura ciclística es el espejo perfecto de lo que está destruyendo silenciosamente nuestras organizaciones tecnológicas. Y no, no estoy exagerando.

En el desarrollo de software moderno, especialmente en entornos "ágiles", vemos el mismo patrón destructivo. El Product Owner que está en cuatro reuniones simultáneas mientras "define" la hija de ruta del producto. El Scrum Máster que facilita retrospectivas mientras programa y hace pruebas "para ayudar al equipo". El líder técnico que hace revisión de código mientras está en una llamada con el cliente explicando por qué el sprint falló... otra vez.

¿El resultado? El mismo que cuando el director ciclista inevitablemente choca: desastre total. Solo que en nuestro caso no son huesos rotos, son productos digitales que nacen muertos, equipos quemados y millones en alguna moneda evaporados en iniciativas que nunca debieron existir.

Pero la multitarea tiene un costo mucho más grave, uno que prácticamente es irrecuperable. Para saber cuál es, por favor, lee mi artículo El verdadero costo de la multitarea en mi Gazafatonario:

El costo de hacer multitarea - Gazafatonario IT

Ahora les hablaré de otro costo oculto en nuestras prácticas tradicionales.

El costo oculto del "Siempre lo hemos hecho así"

Aquí viene la parte que duele: las organizaciones que presumen de ser "ágiles" y "lean" son las peores infractoras. Han convertido los marcos de trabajo en religiones, los roles en títulos nobiliarios y los eventos en rituales vacíos.

Lo escucho a cada rato, con aire de orgullo: "Mi CTO está en las reuniones importantes, revisa todo el código y además lidera la estrategia de IA". Al preguntar: "¿Y cuándo piensa?", el silencio se hace incómodo. Porque claro, pensar no está en el backlog.

La ironía salta a la vista. Lean nos enseña a eliminar desperdicios, pero mantenemos a nuestros mejores talentos haciendo malabarismo con tareas incompatibles. Scrum habla de foco y compromiso, pero nuestros Product Owners están tan dispersos que no podrían reconocer una propuesta de valor ni aunque les pegara fuerte en la cara.

No creas que la IA no va a salvarte, va a exponerte. Y es que, con la explosión de la IA generativa, la situación se vuelve tragicómica. Veo equipos implementando GitHub Copilot mientras su arquitectura base es un desastre o gerentes pidiendo "meter IA" en productos que aún no logran encajar en el mercado.

La IA amplifica. Si tu proceso de desarrollo es caótico, la IA lo hará caóticamente más rápido. Si tu Product Owner no entiende el problema del usuario, ChatGPT le ayudará a no entenderlo con párrafos más elegantes.

El antídoto: separación radical de responsabilidades

Imagen generada por IA

Volvamos al ciclismo por un segundo. La solución es simple: el conductor conduce, punto. Otro miembro del equipo maneja la logística con los ciclistas. ¿Revolucionario? No. ¿Sensato? Absolutamente. En nuestras organizaciones tecnológicas, necesitamos la misma claridad brutal:

El Product Owner debe obsesionarse con el usuario. No con Jira, no con las reuniones diarias, no con el código. Su trabajo es entender tan profundamente al usuario que pueda predecir sus necesidades antes que ellos mismos. Si está en más de dos eventos al día, hay síntomas de intoxicación.

El Scrum Máster facilita, no ejecuta. Si está probando, no está observando las dinámicas del equipo. Es como un psicólogo que está tan ocupado tomando pastillas que no escucha a sus pacientes.

Los desarrolladores desarrollan. No están en reuniones de estrategia de negocio. No están vendiendo al cliente. Están resolviendo problemas técnicos complejos, lo cual, sorpresa, requiere concentración profunda y tiempo ininterrumpido.

Intenta lo siguiente: imagina que cada vez que alguien en tu organización hace multitarea con responsabilidades críticas incompatibles, está literalmente conduciendo un carro a alta velocidad mientras mira el celular. ¿Cuántos accidentes tendrías al día?

Ese error crítico en producción que costó mucho en ventas perdidas: accidente por conducir distraído. Esa funcionalidad que nadie usa después de 6 meses de desarrollo: choque frontal por no mirar la carretera. Ese equipo estrella que renunció en masa: volcadura por intentar cambiar de carril en zona prohibida.

Las organizaciones que sobrevivirán la próxima década no serán las que tengan la mejor tecnología o los frameworks más modernos. Serán las que tengan el coraje de decir: "Esto que hacemos es estúpido y peligroso, y vamos a parar".

Serán las que entiendan que un Product Owner enfocado vale más que diez "haciendo de todo un poco". Que un equipo de desarrollo con 4 horas diarias de concentración profunda produce más valor que uno en reuniones perpetuas. Que la IA es una herramienta, no una varita mágica.

Mi advertencia final

Si tu organización sigue operando como el director ciclístico, haciendo malabarismo con responsabilidades críticas incompatibles mientras acelera hacia el futuro, la sacudida será inevitable. La única pregunta es: ¿será un raspón del que puedan recuperarse, o será el accidente que los saque definitivamente de la carrera?

El ciclismo profesional puede darse el lujo de ser torpemente tradicional porque el espectáculo vende. Tu empresa no tiene ese privilegio. En el mundo del desarrollo de productos digitales, los dinosaurios no se extinguen lentamente; desaparecen en un trimestre malo.

Así que la próxima vez que veas a alguien intentando ser el superhéroe multitarea, recuerda al director ciclista entregando bidones mientras serpentea entre la multitud. Y pregúntate: ¿realmente queremos esperar al choque para cambiar?

La física no perdona. El mercado tampoco.

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?

Cuando la agilidad se "quema": las verdades incómodas que Alistair nos regaló

Alistair compartiendo historias. Fotos de Rose Restrepo.

Alistair Cockburn es uno de los 17 firmantes del Manifiesto Ágil. Conocí vagamente su método Crystal Clear, pero muy profundamente su enfoque con los casos de uso, base de mi trabajo durante casi una década y que a la postre me sirvió para publicar mi segundo tomo de Asuntos de la Ingeniería de Software. Es autor de sendos libros, autor de El corazón de la agilidad (Heart of Agile) y en años recientes tuve la oportunidad de colaborar con él en la traducción al español de algunas de sus conferencias alrededor del mundo.

A Alistair le gusta viajar y pisa tierras suramericanas cada vez que puede. Ahora incluso tiene más razones para ello, aunque no me corresponde decirlo. Esta vez, en medio de sus vacaciones, tuvimos la increíble oportunidad de conversar con él en una sesión extraordinaria: "Respondiendo preguntas con historias" con Alistair Cockburn, una iniciativa de las Comunidades Ágiles Colombia y el Corazón de la Agilidad Latinoamérica que lideró nuestra amiga Rose Restrepo.

Alistair no llegó con PowerPoints bonitos ni con frameworks de moda. Llegó con historias crudas y verdades que duelen. Y la primera bomba que soltó fue devastadora: la agilidad como término está "quemada". Pero la expresión clave allí es “como término”. Entraré en detalle de esta y algunas otras cosas que mencionó. Seguramente algunos asuntos quedarán por fuera de este resumen, pero al final, enumeraré las conclusiones que leí esa noche al cierre de la sesión.

La dura realidad de una palabra prostituida

¿Saben qué significa que algo esté "quemado"? Significa que ha sido usado tanto para la autopromoción que perdió su esencia real. Cuántas veces hemos visto consultores, gerentes y "expertos" vendiendo agilidad como si fuera el último iPhone, prometiendo transformaciones mágicas que nunca llegan.

Pero aquí viene lo brutal: Cockburn admite que no han encontrado una palabra mejor. Estamos atrapados con un término degradado porque, irónicamente, sigue siendo la mejor descripción de lo que realmente necesitamos.

La solución que propone es elegantemente simple y dolorosamente práctica: el Corazón de la Agilidad reducido a cuatro palabras que cualquier niño puede entender: "Colabora", "Entrega", "Reflexiona" y "Mejora". No necesitas certificaciones costosas para esto. No necesitas frameworks complejos. Solo necesitas estas cuatro acciones, punto.

Para saber más sobre el Corazón de la agilidad, puedes leer mi artículo en: Mis notas sobre el Corazón de la Agilidad - Gazafatonario IT.

La inteligencia artificial: el nuevo elefante en la sala

Y entonces llegamos al tema que nos tiene a todos despiertos por las noches: la IA. Cockburn no se anda con rodeos: "la IA cambiará todos los roles". Project managers, Scrum Masters, coaches, programadores, testers. Todos. Sin excepción.

Pero aquí está la parte que reafirma lo que ya hemos hablado en distintos foros: no se trata de si la IA nos va a reemplazar. Se trata de cómo van a cambiar las conversaciones dentro de las empresas. Porque ahora tenemos una "tercera persona" en nuestras colaboraciones: el ChatGPT, el asistente IA, la máquina que puede generar código en segundos.

El problema es que esos segundos se convierten en horas o días cuando intentas conectar ese código con la realidad: bases de datos, sistemas legados, integraciones que son más frágiles que una relación de adolescentes. La IA no es magia, es un asistente muy sofisticado que puede "inventar cosas" si no tienes cuidado.

A propósito, no me gustó que haya usado la palabra “persona” para referirse a la IA, pero quizás es asunto de su español no tan perfecto, aunque lo hace muy bien, así que no le reclamé nada en ese sentido.

La métrica que nadie quiere medir (pero debería)

Aquí viene una de las revelaciones más impactantes de toda la sesión. Alistair, que empezó como metodólogo en 1991, nos suelta esta bomba: es imposible medir la productividad de un programador.

¿Por qué? Porque somos demasiado inteligentes para nuestro propio bien. Cualquier métrica que inventes, nosotros encontraremos la manera de "hacer trampa" con ella. ¿Líneas de código? ¿Puntos de historia? ¿Velocidad? Todo es manipulable. Y estoy siendo literal en buena parte de este artículo con los términos y expresiones que él usó, algunas incluso en inglés.

Pero existe UNA métrica que sí importa, una que puede destruir cualquier productividad sin importar qué tan "ágil" seas: las interrupciones por día. Con solo tres interrupciones diarias, tu productividad se va a cero. Y aquí está el problema: nadie quiere medir esto porque significa admitir que nuestras organizaciones están diseñadas para matar la productividad.

Así que te reto, a ti, gerente de proyecto, jefe, Scrum Master, facilitador, coordinador: mide las interrupciones por día a tu equipo y cuéntanos cómo te va. Si el asunto es grave, siempre puedes leer mi artículo illegitimus non-interruptus - Gazafatonario IT.

La fusión de roles: cuando menos es más

Una de las preguntas más prácticas de la sesión fue sobre la fusión de roles: ¿puede una persona ser Product Owner, Product Manager y Project Manager al mismo tiempo? La respuesta de Cockburn fue refrescantemente directa: "No veo ningún problema".

En empresas pequeñas de tres a cinco personas, esta fusión no solo es normal, es necesaria. El purismo de roles separados es un lujo que muchas organizaciones no pueden permitirse. Y honestamente, ¿no es mejor tener una persona que entiende el panorama completo que tres personas que se pasan el día coordinándose?

El Manifiesto Ágil: perfecto pero forzado

Aquí viene otra verdad incómoda: el Manifiesto Ágil fue diseñado para equipos y proyectos, no para grandes empresas. Cuando intentamos forzar sus principios a organizaciones masivas, estamos pidiendo problemas.

Los valores del manifiesto siguen siendo "perfectos, nada cambia", según Cockburn. Pero aplicarlos a una empresa de 10,000 empleados es como usar un bisturí para cortar un árbol: la herramienta es excelente, pero no para ese trabajo.

Micromejoras: la revolución silenciosa

Para las organizaciones tradicionales y estructuradas, Cockburn propone algo que suena aburrido pero es revolucionario: micromejoras continuas y pequeñas. No puedes cambiar una cultura organizacional de golpe, pero puedes mejorar la calidad de una conversación, de una reunión, de una interacción a la vez.

Es menos sexy que una "transformación ágil" completa, pero es infinitamente más real y sostenible. En este sentido, puedes leer mi artículo Microhábitos para macroimpactos: cómo los hábitos atómicos contribuyen a la sostenibilidad de la transformación organizacional – Lucho Salazar e incluso descargar una presentación que hice algún tiempo.

El Project Manager que sobrevive

En este nuevo mundo híbrido, el gerente de proyecto que sobrevive no es el que controla presupuestos o reportes. Es el que se enfoca en tres cosas fundamentales: bloquear interrupciones para el equipo, garantizar la calidad de la comunidad (comunicación, confianza, educación) y publicar el proyecto a los dirigentes.

La función más importante no es la planificación ni el control. Es la calidad de la comunidad dentro del equipo. Porque sin confianza, sin comunicación real, sin educación continua, no hay framework que te salve. Sin confianza no hay comunicación, sin comunicación nunca llegaremos al “Colabora” del Corazón de la Agilidad.

Mi reflexión final

Al final de esta sesión extraordinaria, una verdad emerge con claridad brutal: la agilidad real no está en los frameworks ni en las herramientas de moda. Está en la calidad de nuestras conversaciones, en nuestra capacidad de adaptarnos sin perder la humanidad, y en nuestro coraje para admitir que la mayoría de lo que llamamos "ágil" es solo teatro corporativo.

Y lo que yo derivo de todo esto: la IA cambiará todos los roles, pero si no arreglamos primero la calidad de nuestras conversaciones humanas, solo automatizaremos la mediocridad. Y eso, mis amigos, no es agilidad... es tragedia con mejor tecnología.

¡Gracias, Alistair por una gran conversación!

 

Los asistentes deleitándonos con las historias de Alistair. Foto de Dennis Arias.

Suplemento: Notas de Lucho sobre “Respondiendo preguntas con historias, por Alistair”

Sobre “la agilidad murió”

Más allá de agile no hay algo mejor. “Dime si hay algo mejor”.

Sobre IA

¿Quién firma las decisiones?

La IA cambiará los roles, pero ¿cómo se cambian las conversaciones en la empresa?

La IA hace instantánea la agilidad.

Sobre gestión híbrida de proyectos

¿Qué hace o puede hacer un jefe de proyectos sin burocracia?

·       Bloquear interrupciones al equipo

·       Garantizar la calidad de la comunidad (el equipo y su entorno)

·       Publicar el proyecto a los dirigentes.

Sobre varios roles en una sola persona

Product Owner + Product Manager + Project Manager

¡Es normal!

Sobre el Manifiesto Ágil

Fue un resultado orgánico.

Si una persona más o una persona menos hubiese participado el resultado hubiera sido completamente distinto.

Fue una elección por unanimidad.

Había muchas cuestiones, muchos valores, ¡elegimos cuatro! “Puedo vivir con estos cuatro valores”.

Un ejercicio interesante es lograr eso en tu propio equipo.

El Manifiesto fue elaborado para equipos y proyectos. No para empresas, sobre todo grandes.

Sobre Scrum

El Scrum original es ágil. Scrum es un espejo.

Las personas no quieren verse en el espejo porque ven sus problemas. Scrum no propone soluciones.

Sobre empresas o estructuras liquidas

No es posible ser “líquido” en ciertos entornos.

Ser líquido puede ser un impedimento para la agilidad.

Sobre productividad y métricas

Si no miden interrupciones por día a un programador, no tienen nada.

Porque las interrupciones (dos o tres) pueden bajar considerablemente la productividad.

Sobre otros aspectos

Los gerentes quieren dinero e influencia.

Usaron la agilidad para subir sus bonos.

Con la IA es lo mismo.

Lo que puedes hacer es mejorar la calidad de vida en tu entorno.

Podcast resumen

Aquí puedes escuchar este breve podcast con el resumen de todo lo anterior.

El Poder del “¿Y si…?”

 𝗘𝗹 𝗽𝗼𝗱𝗲𝗿 𝗱𝗲𝗹 “¿𝗬 𝘀𝗶…?”

Esta semana, en una reunión de trabajo con un cliente potencial, la dinámica era un déjà vu corporativo: presentación predecible, acuerdos tibios, nadie saliéndose del libreto. Sin pensarlo mucho, quizás impulsado esa curiosidad innata que siempre he tenido, lancé un: “¿Y si en lugar de cerrar esto aquí invitamos a tu cliente a decidir con nosotros en vivo?”. Silencio. Pero sentí que esta vez era distinto. Fue un silencio que hacía espacio. Me di cuenta de que era un silencio que abría puertas.

Y es que, en medio de la rutina laboral, entre informes, entregables y reuniones, hay una pregunta que puede abrir grietas en la lógica establecida: “¿Y si…?”. Dos palabras que son una llave maestra. Porque donde el procedimiento dice "así se hace", el ¿y si...? dice "¿por qué no diferente?".

Vivimos ahogados en eficiencia. Se premia la repetición que funciona, el camino probado. Pero eso también construye ceguera. La costumbre se convierte en trinchera. Es ahí donde el “¿y si…?” funciona como un bisturí: corta la inercia, descompone lo obvio y deja al descubierto posibilidades que nadie ve porque todos están mirando igual.

En mi experiencia, pocas frases generan tanto silencio incómodo en una sala como un “¿y si…?” bien lanzado. Es una bomba chiquita que detona certezas. ¿Y si los clientes diseñaran el producto con nosotros? ¿Y si los lunes fueran sagrados para no tener reuniones? ¿Y si la competencia no fuera amenaza sino insumo?

Es el equivalente a ese colega o socio que, justo cuando crees que ya finalizaron un trabajo, cuando hay una versión final del producto, dice: “¿Y si probamos otro enfoque?”. Al principio irrita. Luego ilumina. Porque la mayoría de las soluciones memorables nacieron de un deslizamiento: alguien se salió del carril.

La analogía es simple: piensa en un escritorio de oficina. Siempre ordenado igual. Los lapiceros a la izquierda, el cuaderno al centro, la taza de café al borde derecho. Ahora, un día, alguien mueve todo de sitio. Y sin darte cuenta, te obliga a mirar de nuevo, a adaptarte, a reevaluar lo que dabas por sentado. Eso es el “¿y si…?”: reordenar el escritorio mental.

Hazlo costumbre. Una vez al día. Al revisar un proceso, al liderar una conversación, al evaluar una decisión. Pregunta: “¿Y si lo hiciéramos al revés? ¿Y si quitamos esto? ¿Y si lo hacemos más simple?”. No siempre cambiarás el mundo, pero entrenarás tu mirada para encontrar lo que otros pasan por alto.

El ‘¿y si…?’ es la primera contracción de una idea viva. No grita, no empuja, no impone. Susurra. Pero si la escuchas, puede partir tu mundo en antes y después.

Más allá del sprint: ¿Por qué la IA está revolucionando la agilidad y poniendo el mundo empresarial de cabeza?

Más allá del sprint: ¿Por qué la IA está revolucionando la agilidad y poniendo el mundo empresarial de cabeza?

Dos fuerzas transformadoras, la transformación ágil y la inteligencia artificial, están convergiendo para crear una sinergia dinámica que está revolucionando la forma en que las empresas innovan y responden a las demandas del mercado. Al integrar prácticas ágiles con tecnología de inteligencia artificial, las empresas pueden aprovechar información en tiempo real, optimizar procesos y fomentar una cultura de aprendizaje y mejora continuos.

Aclaremos cómo estas fuerzas trabajan juntas para acelerar la innovación y la respuesta del mercado.

La convergencia de Ágil y la IA

Transformación ágil: un resumen

La transformación ágil es más que un método, es un cambio cultural. Basados en valores como la colaboración, la flexibilidad y la orientación al cliente, los enfoques ágiles permiten a los equipos trabajar en ciclos iterativos, ofrecer valor de forma continua y adaptarse rápidamente a los escenarios cambiantes. Los principales beneficios de la transformación ágil incluyen:

·       Mejora de la colaboración y comunicación en equipo

·       Ciclos de retroalimentación más rápidos y desarrollo iterativo

·       Mayor capacidad para adaptarse en función de los conocimientos del mercado

El papel de la inteligencia artificial

La IA, en forma de aprendizaje automático y procesamiento del lenguaje natural, está transformando diversos aspectos de las operaciones comerciales. Desde la automatización de tareas rutinarias hasta la generación de información detallada a partir de datos, la IA se está convirtiendo en una parte integral de los procesos de toma de decisiones. En un contexto ágil, la IA puede:

· Proporcionar análisis predictivos que informen la toma de decisiones estratégicas.

· Automatizar tareas repetitivas, habilitando a los equipos a concentrarse en el trabajo de alto valor.

· Mejorar la priorización de las historias de usuario y el orden del backlog de producto mediante información basada en datos.

· Optimizar las pruebas y el control de calidad a través de la automatización de pruebas impulsada por IA.

Integración de la IA con prácticas ágiles

Mejorar la toma de decisiones con información basada en datos

Una de las principales formas en que la IA mejora la transformación ágil es a través del poder de los datos. Los equipos ágiles dependen de la retroalimentación rápida e iterativa para informar sus ciclos de desarrollo de productos. La IA puede analizar grandes cantidades de datos (desde análisis del comportamiento de los usuarios hasta tendencias del mercado) y ofrecer información que oriente la priorización de las historias de los usuarios y el refinamiento del backlog de producto.

Ejemplo:

Un equipo de productos digitales utiliza análisis basados en IA para supervisar la interacción de los usuarios en su aplicación móvil. El sistema de IA identifica patrones en el comportamiento de los usuarios y sugiere qué funciones son las más valiosas o las que tienen un rendimiento inferior. Durante la planificación del sprint, estos conocimientos ayudan al equipo a decidir qué funciones iterar o priorizar para los próximos lanzamientos, lo que da como resultado un producto que se ajusta mejor a las necesidades de los usuarios.

Automatización de tareas repetitivas

Los métodos ágiles tradicionales enfatizan la iteración rápida y la mejora continua. Sin embargo, las tareas repetitivas, como las revisiones de código, las pruebas y la documentación, pueden ralentizar este proceso. Las herramientas de IA pueden automatizar estas tareas, lo que libera a los miembros del equipo para que se concentren en la creatividad y la planificación estratégica.

Ejemplo:

En un entorno de desarrollo de software, una herramienta de prueba impulsada por IA genera y ejecuta automáticamente casos de prueba durante cada sprint. Esto no solo acelera la fase de prueba, sino que también garantiza que cada iteración sea sólida y libre de regresiones. Como resultado, el ciclo de desarrollo se vuelve más eficiente y el equipo puede implementar software de calidad a un ritmo más rápido.

Optimización del mapeo y priorización de historias de usuario

El mapeo de historias de usuario es una piedra angular del desarrollo ágil, ya que proporciona una representación visual del recorrido del producto y ayuda a los equipos a priorizar el trabajo en función del valor para el cliente. La integración de la IA en este proceso puede mejorar la priorización mediante el análisis de datos históricos, retroalimentación de los clientes y tendencias del mercado.

Ejemplo:

Considere una plataforma de comercio electrónico que utiliza una herramienta de mapeo de historias de usuario mejorada con IA. La herramienta procesa las reseñas de los clientes, los datos de compra y los patrones de navegación para destacar qué características son las más importantes para los usuarios. Sugiere ajustes al backlog de producto, lo que garantiza que las características más impactantes se desarrollen primero. Esto conduce a una estrategia de desarrollo de productos más enfocada y eficaz.

Retroalimentación en tiempo real y aprendizaje continuo

Los equipos ágiles evolucionan gracias a los ciclos cortos de retroalimentación. Las prácticas ágiles cotidianas fomentan las retrospectivas periódicas para reflexionar sobre lo que funcionó y lo que no. La IA puede mejorar estas prácticas al proporcionar retroalimentación en tiempo real, lo que permite a los equipos realizar ajustes durante el sprint en lugar de esperar hasta el final.

Ejemplo:

Un equipo de marketing que ejecuta varias campañas digitales utiliza una plataforma de análisis basada en inteligencia artificial para supervisar el rendimiento de las campañas en tiempo real. La plataforma utiliza algoritmos de aprendizaje automático para detectar tendencias y predecir resultados, lo que permite al equipo ajustar las estrategias sobre la marcha. Esta agilidad garantiza que las iniciativas de marketing sigan siendo eficaces incluso cuando las condiciones del mercado cambien.

Analogía cotidiana: el GPS inteligente para su recorrido empresarial

Imagina que estás de viaje por carretera con un mapa de papel tradicional en la mano. El mapa te da una idea general de la ruta, pero si hay un obstáculo inesperado, un atasco o un desvío, tienes que parar y volver a leer el mapa manualmente, lo que suele provocar retrasos. Ahora, piensa en un sistema GPS moderno que no solo te proporcione la mejor ruta, sino que también se ajuste en tiempo real en función de los datos de tráfico, las condiciones de la carretera y tus hábitos de conducción. Este GPS aprende continuamente de tu viaje y te ofrece sugerencias para evitar retrasos y llegar a tu destino de forma más eficiente.

En esta analogía:

· El mapa de papel representa las prácticas ágiles tradicionales. Si bien proporciona un marco sólido para el desarrollo iterativo y la flexibilidad, carece de capacidades de ajuste dinámico en tiempo real.

· Smart GPS encarna la integración de la IA en las prácticas ágiles. Complementa los principios ágiles con datos en tiempo real y análisis predictivos, lo que garantiza que su proyecto se mantenga en el camino óptimo a pesar de los desafíos imprevistos.

Así como un GPS inteligente ayuda a navegar por rutas complejas con facilidad, las prácticas ágiles mejoradas con IA ayudan a los equipos a navegar por las complejidades de los panoramas modernos de las organizaciones, garantizando cambios más rápidos y una toma de decisiones más informada.

Mejores prácticas para integrar IA y Ágil

1. Comience con poco y aumente gradualmente

Hay cosas que no cambian. Comience con proyectos piloto para probar la integración de herramientas de IA en marcos ágiles. Identifique un proceso o problema específico en el que la IA pueda agregar valor (como la priorización de tareas pendientes o las pruebas automatizadas) y expanda gradualmente su uso en todos los equipos y proyectos.

2. Fomente una cultura de experimentación

Tanto la transformación ágil como la integración de la IA requieren una cultura que fomente la experimentación y el aprendizaje. Incentive a los equipos a probar nuevas herramientas de IA, compartir conocimientos e iterar procesos. Este enfoque no solo mejora la eficiencia, sino que también fomenta la innovación y la adaptabilidad.

3. Invierta en formación y mejora de las competencias

Para aprovechar al máximo las capacidades de la IA, los equipos deben comprender cómo trabajar con estas herramientas de manera eficaz. Invierta en programas de capacitación que mejoren las habilidades digitales y analíticas de los miembros del equipo, asegurándose de que se sientan cómodos y sean competentes en el uso de tecnologías de IA junto con metodologías ágiles.

4. Asegúrese de estar alineado con los objetivos del negocio

La integración de la IA siempre debe estar alineada con los objetivos estratégicos de su organización. Utilice marcos como Objetivos y resultados clave (OKR) para garantizar que las iniciativas ágiles mejoradas con IA contribuyan directamente a los resultados del negocio, ya sea acelerando el tiempo de salida al mercado, mejorando la satisfacción del cliente o aumentando la eficiencia operativa, como siempre, cuidando a sus colaboradores y su entorno.

5. Mantenga la transparencia y la colaboración

Las herramientas de IA generan enormes cantidades de datos y conocimientos. Para maximizar su impacto, fomente un entorno de transparencia en el que este conocimiento se comparta abiertamente con todos los miembros del equipo. La toma de decisiones colaborativa garantizará que todo el equipo comprenda y confíe en las recomendaciones de la IA.

El camino por delante

Es una hipótesis, pero algunos estamos yendo ya en esa dirección: la fusión de métodos ágiles e inteligencia artificial no es una tendencia pasajera, sino un cambio fundamental en la forma en que las organizaciones abordan la innovación y la capacidad de respuesta al mercado. En Experimentum ya lo estamos haciendo. A medida que las empresas sigan avanzando en su transformación digital, aquellas que integren con éxito estos enfoques estarán mejor posicionadas para responder a la dinámica del mercado, innovar rápidamente y mantener una ventaja de la que puedan sacar provecho.

Únete a la conversación

¿Cómo aprovecha su organización la IA en sus prácticas ágiles? ¿Qué desafíos o éxitos ha experimentado? Comparta sus opiniones y únase a la discusión en los comentarios a continuación.

Del caos a la sinfonía: Armoniza a tu equipo antes de que todo suene mal

Del caos a la sinfonía: Armoniza a tu equipo antes de que todo suene mal

Durante 37 años he trabajado con o acompañado a cientos de equipos y miles de personas y he tenido la oportunidad de crear con ellos productos asombrosos. Incluso he escrito y publicado libros en los últimos 15 años, una operación que siempre se logra colaborando en equipo. Es bastante satisfactorio cuando entregas al público algo en lo que has sido minucioso y le has dedicado buena parte de tus mejores momentos.

Pero también he estado allí cuando las cosas no han salido bien. No es solo tu desilusión, es la de todo un grupo de personas que se han desempeñado de la mejor manera posible para lograr un objetivo y no ha sido posible. He estudiado mucho este fenómeno de cuando las cosas no terminan bien para un equipo o para una empresa. Después de todo, las heridas físicas y hasta mentales causadas por estas caídas saltan a la vista.

Precisamente, una de las causas más frecuentes, casi endémicas, de tales decepciones es esta de la desalineación de los equipos. Y voy a empezar a explicarte de qué se trata con un ejemplo muy común. Es como cuando intento llevar a cabo un plan de salir a cenar con mi esposa y mi hija. Parece algo sencillo, ¿cierto? ¡No te apresures!

He estado en medio de ambas cuando una lleva soñando toda la semana con comida italiana mientras la otra quiere sushi porque es más digno de Instagram. Yo, en cambio, solo quiero un buen bistec porque he tenido una larga semana y necesito algo más sustancioso. En el debate emergen argumentos de que los ñoquis son un alimento reconfortante, pero hay un contraataque diciendo que el sushi es más ligero y saludable. Ni hablar de cuando trato de ser el pacificador sugiriendo un restaurante de carnes con opciones de sushi, porque te dicen: “¡Eso no cuenta como sushi de verdad!”.

Esto es esencialmente un desajuste de equipo en su forma más evidente. Todos compartimos el mismo objetivo general (cenar juntos), pero las diferentes perspectivas (comida reconfortante versus comida de moda versus comida saludable), objetivos específicos disímiles (satisfacer antojos versus comidas dignas de Instagram) y alcances discordantes (satisfacción inmediata versus experiencia culinaria) convierten todo en un caos.

¿Les suena familiar? Este tipo de desajustes ocurren todo el tiempo en los equipos y, si no se resuelven, pueden hacer que hasta las tareas más sencillas resulten agotadoras. Por suerte, al igual que en mi familia, un poco de empatía, alineación y compromiso pueden salvar el día y tal vez incluso llevar a descubrir el mejor restaurante de cocina fusión de la ciudad.

Tres formas de desalineación en los equipos

Mi historia de la cena malograda captura la esencia de los desajustes que a menudo vemos en los equipos: perspectivas diferentes, objetivos diferentes y alcances diferentes.

Diferentes perspectivas: el “elefante en la habitación”

Surgen diferentes perspectivas porque cada uno tiene su propio "enfoque" moldeado por experiencias, conocimientos y prejuicios personales. Esta es la clásica historia de los ciegos que describen un elefante: uno siente la trompa y dice que es una serpiente, otro agarra la pata y afirma que es un árbol, mientras que el que toca la cola piensa que es una cuerda. Todos tienen razón, pero no están alineados.

Este tipo de desalineación se caracteriza principalmente por:

·       Opiniones contradictorias a pesar de datos compartidos.

·       Desafíos para comprender “por qué” alguien lo ve de manera diferente.

·       Con frecuencia una fuente de frustración es: "¡¿Cómo es posible que no lo entiendan?!"

Es un hecho, las personas estamos programadas para interpretar las situaciones en función de nuestra experiencia y función. Un programador se centra en el código, mientras que alguien de mercadeo ve el impacto en el cliente. Ninguno de los dos está equivocado, pero ambos carecen de una visión completa. Es lo que alguna vez llamé “dicotomía peyorativa”. ¡Todavía recuerdo aquella reunión!

Diferentes objetivos: el tira y afloja

Se presentan distintos objetivos cuando los miembros del equipo priorizan diferentes resultados. ¿Recuerdan lo del sushi o la comida italiana? Es así. No se puede complacer a todo el mundo, a menos que se encuentren puntos en común. Los equipos se enfrentan al mismo tira y afloja cuando los individuos o los grupos tienen objetivos contrapuestos.

Lo que he visto que ocurre incluye:

·       Desacuerdos sobre lo que es "más importante".

·       Prioridades mal alineadas conducen a un desperdicio de energía.

·       La gente tira en direcciones opuestas, por ejemplo: “¡Necesitamos velocidad!” versus “¡Necesitamos calidad!”.

De primerísima mano sé que los objetivos están influenciados por los roles de los miembros del equipo, los incentivos y las definiciones individuales de éxito. Sin una visión compartida, las prioridades personales se imponen. He visto Product Owners presionando para que se lance un producto rápidamente, mientras que el equipo de desarrollo aboga por que se realicen más pruebas. Es el clásico debate de "rápido versus impecable".

Diferentes alcances: el efecto zoom

Los alcances definen cuán estrecha o amplia es nuestra perspectiva de una situación. He conocido personas que se obsesionan con los pequeños detalles mientras que otras los desestiman como si "no fueran gran cosa". De hecho, ahora que lo pienso, yo mismo he estado en ambos lados del disco. Los equipos experimentan esto cuando los individuos operan en diferentes "niveles de zoom": algunos piensan estratégicamente, otros tácticamente.

Eso es una desalineación del alcance. Si te has encontrado con algunas de estas escenas, también has estado allí:

·       Alcance limitado: "Vamos a solucionar este error".

·       Amplio alcance: "¿Cómo encaja esto en nuestro roadmap anual?"

·       Tensiones entre la corriente o dirección táctica y la estratégica del equipo o de la empresa.

El alcance también depende de las prioridades y la responsabilidad. Un desarrollador tiene la tarea de solucionar el problema de hoy, mientras que el CEO tiene en mente la participación de mercado del próximo año.

¿Y la solución?

Tengo que admitir que soy mejor resolviendo desajustes de equipos de trabajo que los emocionantes y románticos conflictos  familiares tipo sushi versus espagueti. Igual me divierto con estos y me hacen muy feliz.

Pero primero buscamos la causa raíz. ¿Qué tienen en común estos tipos de desalineación de equipos? En general, se deben a:

·    Brechas en la comunicación: con frecuencia, las suposiciones reemplazan las conversaciones reales.

·   Falta de contexto compartido: las responsabilidades y la experiencia de las personas determinan lo que consideran relevante.

·    Naturaleza humana: somos naturalmente centrados en nosotros mismos y se necesita esfuerzo para ver más allá de nuestra propia perspectiva. Esta es la raíz más compleja de todas.

Hay más orígenes, pero estos son los más comunes. En ocasiones, vas a necesitar acompañamiento para resolver estos trances, pero para ir del caos a la cohesión puedes empezar:

Creando un entendimiento compartido: incentiva a las personas a compartir sus perspectivas abiertamente. Ayuda a que todos vean el problema en su conjunto, no solo sus partes. Por ejemplo, en las reuniones, utiliza la regla “¿cuál es tu opinión?”, donde cada uno comparte su punto de vista antes de llegar a las conclusiones.

Alineándolos en torno a un objetivo común: facilita debates para identificar objetivos compartidos. Una "estrella del norte" sólida alinea las prioridades en pugna. Aquí, por ejemplo, los OKR (objetivos y resultados clave) juegan un papel fundamental para que los objetivos finalmente sean explícitos y visibles para todos.

Aclarando los alcances: aumenta y reduce la perspectiva entre todos. Analiza las prioridades inmediatas (logros a corto plazo) y cómo se relacionan con los objetivos más extensos (visión a largo plazo). Y,

Fomentando la empatía: adquiere el hábito de tener en cuenta las responsabilidades y las prioridades de los demás. Esto disminuye los juicios y fomenta la colaboración. Me ha ido bien con las dinámicas tipo “ponerse en los zapatos del otro” durante las retrospectivas o en cualquier otra sesión necesaria.

Aplico algunas de estas prácticas con mi esposa y mi hija cuando se trata de salir a divertirnos o decidir dónde cenar. En la historia que les compartí, después de un entretenido tira y afloja, ¡terminamos eligiendo comida de mar! Es algo que conecta con nuestras raíces y que siempre nos ayuda a encontrar un punto en común. Si esto es posible en mi familia—donde las decisiones a veces parecen un cónclave de las Naciones Unidas—créanme, también es posible alinear a tu equipo de trabajo.

Llamado a la acción

No es más por esta vez. Los desajustes son naturales, pero no insalvables. Fomenta la comunicación abierta, la alineación en torno a objetivos armónicos y el equilibrio de alcances. Con esto, los equipos pueden transformar la fricción en combustible. Ya sea que se trate de una sencilla cena familiar o de un proyecto de trabajo, la magia ocurre cuando todos reman en la misma dirección. Y, si todo lo demás falla, ¡siempre hay hamburguesas para cenar!