E011 - ¿Qué es Agile y por qué es clave en la Transformación Digital de una empresa?
Suscríbete en: Spotify | Apple Podcasts | Google Podcasts
No se puede hablar de Transformación Digital si no somos capaces de adaptar el software que nos va a dar ventaja competitiva en el mercado, de forma constante, iterativa incremental, incorporando feedback, aprendiendo, siendo soporte para la eficiencia, pero también para la innovación, para la disrupción.
Índice
- ¿Qué es Agile?
- ¿Por qué Agile es clave en la Transformación Digital?
- Los modelos de negocio se están transformando.
- Agile tiene que ver con el software.
- Agile en cuatro conceptos
¿Qué es Agile?
No soy capaz de resumir Agile en un solo episodio, pero sí voy a intentar sintetizar 4 conceptos que considero de gran relevancia:
- Entrega temprana y frecuente.
- Cross-funcionalidad.
- Individuos motivados.
- Mejora continua.
¿Por qué Agile es clave en la Transformación Digital?
Los modelos de negocio se están transformando. La tecnología no solo inventa nuevos modelos, sino que está dando la vuelta literalmente a sectores muy tradicionales.
En este escenario, uno de los mayores retos de nuestras compañías es ser capaces de adaptarse al cambio. Agile viene para satisfacer esa necesidad de adaptación.
Sin tecnología, no hay disrupción. Sin Agile, no hay tecnología capaz de adaptarse a los cambios constantes y cada vez más virulentos y exigentes del mercado.
Vivimos en la era más disruptiva de la historia de la humanidad. No solo por la profundidad e impacto en nuestras vidas de las distintas disrupciones tecnológicas que van surgiendo, sino también por la alta frecuencia y la velocidad con la que aparecen.
No es necesario ser un genio ni un visionario para darse cuenta de ello. Yo desde luego no soy ni una cosa ni otra, pero sí me doy cuenta de que cuando fundamos Runroom en 2003, yo manejaba un Nokia 3210, no existía Facebook, Twitter ni YouTube, y ni siquiera la palabra pódcast.
Los modelos de negocio se están transformando.
La tecnología no solo inventa nuevos modelos sino que está dando la vuelta literalmente a sectores muy tradicionales y tan solo está enseñando la patita en ese escenario. Uno de los mayores retos de nuestras compañías es ser capaces de adaptarse al cambio en mayúscula y esa es la razón por la que cualquier organización que se precie tiene su propio departamento TIC, digital, de internet o llámese como se quiera. El problema llega cuando se da una imperiosa necesidad de velocidad de adaptación a ese cambio. Pero en el mundo real los tiempos que se manejan para lanzar un nuevo producto digital o actualizar una plataforma que nos permita ser más eficientes rondan los dos años e incluso los cuatro años, que estos ojitos lo han visto. Pero en el mundo real... cuando al mundo real le precede un pero, deja de ser un lugar y se convierte en una excusa.
Muchos de mis oyentes son reputados Agile Coach, consultores de transformación organizacional, personas con muchísima experiencia. Por ese motivo siento cierta presión al exponerme de esta manera y hablar de un tema como Agile. Aprovecho para saludar de forma muy especial a José Manuel Beas, no solo por ser un fiel seguidor del programa y no perder la ocasión de compartir y darle visibilidad —muchísimas gracias por ello, José— sino también porque es uno de los pioneros de las metodologías Agile en este país, que no es el único, pero permitidme que hoy le dedique el programa a José.
Agile tiene que ver con el software
Para empezar, Agile tiene que ver con el software. El concepto Agile nace de la voluntad de 17 personalidades que el 12 de febrero de hace 17 años —es decir en 2001 nada menos— fueron a una estación de esquí de Utah con la intención de reflexionar sobre las mejores formas de desarrollar software, compartir sus experiencias e intentar ayudar a los demás y a la industria.
De ahí nace el famoso Agile Manifesto, que no voy a leer porque lo tenéis disponible en la página web más fea del mundo, agilemanifesto.org. Si os sangran los ojos no es mi culpa.
No lo voy a leer por eso y porque, si ya muchos de vosotros me decís que los programas son largos, y que los que acostumbráis a escuchar el pódcast en vuestras caminatas y entrenos de running me estáis diciendo que me reserváis para las tiradas largas y que estoy favoreciendo y ayudando a vuestra salud y a vuestro fitness, pues ya si me meto con el manifesto ágil, apaga y vámonos. Así que hoy va a ser el primer episodio donde hable de Agile y voy a tratar de dar una visión lo más de alto nivel y menos metodológica que sea capaz. ¡Vamos allá!
Para empezar, considero que debo arrancar hablando del problema que introducía en la entradilla y que estoy seguro de que es muy común, que resultará familiar y que, en mi opinión, se debe a que básicamente hemos tomado métodos industriales para desarrollar software. Hemos intentado adaptar los métodos que funcionaban - por ejemplo, para construir un avión - para desarrollar software.
El problema de esto es que el software es complejo, hay muchísima incertidumbre y es muy poco predictivo, a diferencia de montar un avión. Montar un avión es complicado, ¡montar un avión! Yo no he montado un avión en mi vida, y no sé cuántos millones de tuercas y tornillos tiene que tener eso, pero seguro que el proceso industrial de montar un avión o de montar un coche, de montar cualquier aparato tecnológico por muy avanzado que sea, es complicado. Pero yo sé que tengo que administrar 300 hectopascales en la tuerca del no sé qué, del condensador de fluzo y es esto lo que al final hace que yo pueda utilizar metodologías predictivas en los procesos industriales. Pero no en el software.
Yo no sé cuál es vuestra experiencia, pero en la mía con todos los diagramas de Gantt que he visto no se ha cumplido ni uno, y os puedo asegurar que 15 años al frente de una consultora de negocio digital dan para ver muchos «Gantts». Y la razón es muy sencilla: el software es complejo y no es predecible, hay muchísima incertidumbre, no solo en la propia tecnología sino también en el alcance, en la definición del producto en sí mismo.
¿Qué significa un buscador? ¿Qué quiere decir hacer un buscador? Un buscador puede ser predictivo, sencillo, puede ser que en cada pulsación de una tecla me arroje resultados, etc. Y eso implica que hay mucha incertidumbre también en el acuerdo en cuanto a cómo tiene que ser la funcionalidad. El tema es que la necesidad de control, de tener controlados los proyectos, los productos, y las inversiones que hacemos en software nos han llevado —en mi opinión— a equivocarnos en la forma en la que intentamos controlar esos proyectos de software.
Intentamos cerrarlo todo.
Habréis oído hablar del famoso «triángulo de hierro» de los proyectos. Si no es así, el triángulo de hierro consiste en tener cerrado tiempo, alcance y recursos.
Y resulta muy difícil porque en el alcance, como os decía, es muy fácil tener una falsa sensación de acuerdo cuando describimos una funcionalidad en el software. Es muy fácil tener una falsa sensación de acuerdo y tener cada uno una idea distinta. Y podemos invertir muchísimo tiempo en describir esa funcionalidad, pero no estará completamente definida hasta que no esté creada.
Y como decía, también está la incertidumbre respecto a la tecnología.
A mí me gusta decir que el desarrollar software se parece mucho más al trabajo de un cirujano que al de una cadena de producción, o al de un arquitecto, o vete tú a saber de cualquier otro proceso industrial. El software se parece mucho más a eso, a abrir en canal un cuerpo: separas las costillas de las vísceras y dices «madre mía, lo que me he encontrado aquí», desarrollar software se parece mucho a eso. En resumen, nos equivocamos en la forma en la que intentamos controlar los proyectos de software porque intentamos tenerlo todo cerrado, y conseguirlo y predecir exactamente lo que va a pasar al inicio del proyecto es muy complicado.
En el software funciona mucho mejor ir controlando el alcance y los recursos a medida que va pasando el tiempo.
En otro episodio ya profundizaremos un poco más en el concepto de desarrollo iterativo incremental de software, que considero que merece mucho la pena entender bien, porque para mí es una de las claves de esa capacidad de adaptación y respuesta al cambio, a esa necesidad que tienen las compañías de la que habábamos al principio.
Agile en cuatro conceptos
En este pódcast intentaré sintetizar en cuatro conceptos qué es Agile y para qué sirve.
En el primero de ellos voy a hablar de entrega temprana y frecuente de software, o también entrega temprana y frecuente de valor.
Seguidamente, vamos a hablar de «crossfuncionalidad», el segundo concepto que considero esencial para entender qué es Agile.
A continuación hablaremos de equipos motivados, personas motivadas y, por último, hablaremos de Kaizen, es decir, hablaremos de mejora continua. Para mí, estos cuatro grandes conceptos dan para un pódcast en sí mismos, pero también son los pilares fundamentales de Agile.
1. Entrega temprana y frecuente
Empecemos a hablar entonces de entrega temprana y frecuente. Cuando arranca un proyecto —estoy seguro de que todos los que escucháis este pódcast, si estáis interesados en negocio digital, querrá decir que en algún momento habéis pasado por algún tipo de experiencia similar— normalmente lo que sucede es que arranca primero toda una primera fase de análisis, una fase tediosa donde intentamos aterrizar un funcional que suele pesar entre medio kilo y un kilo de folios con todas las funcionalidades descritas.
Imaginemos que el proyecto por ejemplo es un e-commerce. Pues ahí, en ese funcional, describimos todas y cada una de las funcionalidades que debe tener ese e-commerce que necesitamos desarrollar. Este análisis funcional ya ocupa unos cuantos meses, o al menos unas semanas en el mejor de los casos. Pero cualquier proyecto seguramente se va a extender más de un mes porque hay que definir muchas cosas y solo cuando el cliente o los llamados stakeholders, los que tienen que opinar sobre el proyecto y validar que ese proyecto es lo que necesitamos, dan el visto bueno y aceptan ese funcional, es cuando pasamos a la siguiente fase que, a lo mejor típicamente en un proyecto como un e-commerce, sería agarrar ese funcional y transformarlo en una colección de wireframes, una colección de bocetos página a página. ¿En qué consiste cada una de esas páginas? en traducir ese funcional en algo más visual, en algo más digerible. Pero «ese algo más visual y ese algo más digerible» también va a servir para que esos stakeholders acepten que eso es lo que queremos que se desarrolle.
Entre tanto va pasando el tiempo hasta que llega el día en que el cliente o los stakeholders firman con sangre todos y cada uno de esos wireframes y entonces quizá ya estamos en disposición de pasar a la fase de diseño. En esta fase agarramos esos wireframes, los dotamos de un aspecto visual acorde a una imagen corporativa: elegimos tipografías, colores, fotografías y lo vestimos, lo maquillamos, le damos un aspecto visual que funcione. Cuando ya está todo diseñado, pasamos a maquetarlo todo en HTML y, seguidamente, pasamos a desarrollarlo en el back office, etcétera, hasta que llega el día en que desplegamos todo ese código y lo ponemos en producción.
Y ese es el primer día en el cual nuestro cliente, el cliente real, el cliente final utiliza la plataforma. Hasta ese momento el cliente no ha visto nada, el cliente real es el cliente final, los stakeholders creían haber entendido lo que les íbamos a entregar y, de repente, se encuentran cosas como que «oye, pero este desplegable de aquí, esto no tenía que ser interactivo y desplegar todo este...».
—«No, es que esto no me lo dijiste en el funcional. Lo que pone exactamente…».
Y ahí entra la negociación: —«No, perdona es que aquí yo, hombre, yo ya di por hecho que aquí se entendía, esto se sobreentiende, que si...».
—«No, no, no, perdona pero no se sobreentiende nada».
—«Nosotros hemos desarrollado lo que ponía en el funcional, lo que nos pasó el departamento de marketing, o lo que nos pasó el departamento de diseño…».
Al final, lo que sucede en este tipo de proyectos en cascada es que se da una delegación de la responsabilidad del proyecto, del producto y, por tanto, de la entrega de valor. Al final se diluye y se pierde la perspectiva de la entrega de valor porque lo único que nos importa es cumplir con el papel de nuestro departamento. El departamento de análisis, el de marketing, el de UX, el de diseño, el de desarrollo, y cualquier departamento. El foco con respecto a ese comercio, va a ser pasarle su trabajo al siguiente departamento dentro de esa cadena en cascada.
Y ahí queridos amigos, ¿dónde está el valor? ¿Cómo sabemos que lo que estamos desarrollando tiene valor para el cliente final, para nuestro customer? No tenemos ni idea. Se supone que los UX, con mucha suerte si el proyecto parte y la compañía tiene un departamento que le da importancia al UX —que normalmente no suele ser así—, es posible que el departamento de UX haya hecho un montón de tests de usuario al principio y todo el mundo piense que ya está todo validado.
Error. Error. Está todo validado al principio, pero hasta que eso no sale y se testea, ahí es donde vamos a empezar a aprender de verdad. En ese momento con el software real funcionando.
Ahí es donde vamos a empezar a aprender de verdad. Sí que es verdad que podemos minimizar el impacto, antes de producirlo podemos minimizar el riesgo, y podemos hacer mucho estudio. Yo no estoy diciendo que la UX no sea importante, lo es y lo veíamos la semana pasada con Daniel Torres Burriel. Pero yo creo que uno de los problemas que tenemos con la forma en la que estamos integrando la experiencia de usuario dentro de esos ciclos en cascada, es precisamente que la UX está aislada y está localizada en un momento muy concreto del ciclo de vida del proyecto y del producto.
Por lo tanto, Agile apuesta por este primer concepto que quería poner de manifiesto: la entrega temprana y frecuente de valor, entendiendo valor como software funcionando. Hablaremos de proyectos y de desarrollo iterativo incremental en otro episodio porque lo requiere.
2. Equipos crossfuncionales o multifuncionales
El siguiente concepto que quería destacar está muy relacionado con el primero y es la crossfuncionalidad. ¿Se le puede llamar también multifuncionalidad? Hablamos de funcionalidad porque en inglés la palabra es cross-functional teams, equipos crossfuncionales o multifuncionales. Y esto lo hemos comentado ya en otros episodios, la crossfuncionalidad es la necesidad de romper esos silos funcionales. Los silos funcionales en realidad son el porqué de las metodologías en cascada, de esos «Gantts», de esas metodologías predictivas porque el desarrollo de tu proyecto digital tiene que pasar forzosamente por silos funcionales de conocimiento como, por ejemplo, analistas, el departamento de UX, el de diseño, de UI, de frontend, de backend, etc., la única forma que tienes de llevar a cabo un proyecto es en cascada.
Pero, ¿cómo podemos entregar de forma temprana y frecuente software funcionando si no tenemos a un equipo crossfuncional?, es decir con todos esos silos rotos y juntados en un solo equipo que sea capaz de entregar valor y trabajar conjuntamente en una entrega de valor frecuente. Cada semana, cada dos semanas, cada cuatro semanas... está entregando software funcionando con todos sus skills, esas habilidades orquestadas de forma en la que tanto el diseño, como la UX, el frontend y el backend, entre otros, están colaborando para crear ese valor y entregarlo colaborando también con negocio. Por supuesto el negocio tiene que estar durante toda la creación del proyecto.
Eso nos va a permitir la entrega temprana pero funcional. Nos va a permitir ir entregando ese software de forma iterativa incremental y, por lo tanto, incorporar feedback del cliente final. También nos va a permitir que estemos abiertos al cambio que tanto necesitamos. Hemos visto el concepto de entrega temprana y frecuente, hemos hablado del concepto de funcionalidad y de la colaboración de los distintos roles.
3. Equipos motivados
El tercer concepto que quería introducir era el de «los equipos motivados», algo que me recuerda al elefante en la habitación. Muchas compañías, la gran mayoría de las compañías que yo veo que intentan trabajar de forma ágil, que intentan que Agile sea su cultura-objetivo, fallan aquí. Fallan no solo en los silos, sino que fallan en motivar, en que no es posible —desde mi perspectiva, como yo lo entiendo— ser Agile sin tener un equipo realmente motivado. Y aquí podemos hablar de Employee Experience, que es muy importante.
Desde luego lo es la experiencia del empleado, pero a mí me gusta mucho cuando hablamos de motivación. Hay un libro muy conocido de Daniel Pink —que por cierto también hay algunos TEDx, colgaré un video que sintetiza bastante su obra en las notas del episodio de hoy— que se llama «La sorprendente verdad sobre lo que nos motiva», me parece que lo digo bien.
En cualquier caso lo buscaré bien porque lo digo de memoria y os lo apuntaré también en las notas del episodio. Me gusta mucho el concepto que utiliza «Dan Pink», él habla de tres grandes razones o tres grandes pilares de lo que nos motiva.
Él habla de maestría, autonomía y propósito. Vamos con ello, con cada uno de ellos:
- Maestría
¿Por qué tocar un instrumento en nuestro tiempo libre? ¿Por qué dedicamos tiempo a aprender a tocar un instrumento, a tocar mejor el piano, a tocar el violín? ¿A aprender a tener un huerto urbano? ¿Por qué invertimos tiempo en este tipo de cosas? ¿Por qué hay meetups profesionales, after hours? ¿Por qué invertimos tiempo en esto? Porque la medida de progreso y de desarrollo personal y profesional es lo que nos hace felices, sentir que estamos avanzando en algo en lo que nos estamos desarrollando, que estamos ganando habilidades.
Eso nos llena, nos colma. Por eso es muy importante poner foco como compañía en la calidad, el aprendizaje, la maestría, el crecimiento personal y profesional, en tener espacio para ello y para que las personas puedan desarrollar su profesión, puedan aprender, puedan profundizar. La maestría es superimportante.
- Autonomía
Otro de los problemas que ya hemos comentado en algún otro episodio. El otro día discutía con un amigo, Toni Tassani, y él no estaba de acuerdo con una charla que vi. Yo hablaba de la jerarquía en sí misma como un problema y él me decía que la jerarquía en sí misma no es un problema.
Puede que tenga razón mi amigo Tassani. Desde mi visión, la jerarquía en sí misma es posible que no sea un problema, pero la jerarquía tal y como hoy entendemos, la jerarquía organizacional en una compañía, esa visión «Taylorista» de los que piensan, los que hacen y los que planifican, para mí sí que es un problema y una de las razones por las que, por ejemplo, alguna metodología Agile como Scrum prescribe equipos autoorganizados y autogestionados. Ya hablaremos de ello. Cómo es posible llevarlo a cabo —porque esto se está haciendo, señores, no estoy hablando de ciencia ficción—.
En Runroom los equipos son autoorganizados, no tienen ningún jefe que a cada uno de ellos les vaya diciendo «Tú tienes que hacer esto, tú tienes que hacer esto mañana, esto lo quiero para no sé cuándo…». Las jerarquías organizativas, estas pirámides que se dan en nuestras organizaciones, están diseñadas para hacer push. No se habla del Middle Management, que son esas capas intermedias entre el comité de dirección —lo más alto de arriba que son los que deciden la estrategia y qué es lo que hay que hacer y hacia dónde va la compañía, etcétera, etcétera—, y los curritos, los que hacen.
Los que están en esta capa, en el estrato inferior, paradójicamente son los que saben cómo hay que hacer las cosas y son los que en el siglo XXI, en casi todos los trabajos hoy en día, son trabajadores cognitivos. Al menos los que nos afectan respecto al negocio digital somos trabajadores cognitivos, somos trabajadores que trabajamos con el conocimiento.
Nadie mejor que un programador, nadie mejor que un diseñador, nadie mejor que un UX para saber cómo hay que llevar a cabo una aplicación, un e-commerce. Estos Middle Managers, estos jefes intermedios, tienen un rol de hacer push hacia abajo de lo que hay que hacer y eso le viene de arriba y hacer reporting hacia arriba, es decir cómo estamos avanzando dentro de esos diagramas de Gantt, cómo lo estamos haciendo, y eso resta autonomía. Si yo tengo a alguien, ¿cómo voy a pretender yo que mi equipo tenga iniciativa si no le cedo el espacio para tenerla?
Si yo cada día voy allí a explicarles lo que tienen que hacer hoy y para cuando necesito esta nueva funcionalidad y tú te vas a ocupar de esto, tú te vas a ocupar de... ¿cómo voy a pedir que un equipo sea capaz de adaptarse al cambio? ¿Cómo voy a pedir que un equipo tenga visión de negocio? ¿Cómo voy a pedir a un equipo que se auto gestione si yo no lo permito? Y eso es un poco lo que, bueno, entre otras cosas, Agile viene a poner encima de la mesa.
Es necesaria la autogestión. No solo es necesaria. Es más que posible y está demostradísimo que es posible, y lo iremos viendo en sucesivos episodios.
No hablábamos de la motivación, hablamos de Daniel Pink: maestría, autonomía y, por último, Daniel habla de propósito. Aprovecho para meter la cuña y recordar que en el episodio 6 hablamos con Antonio López de Decathlon, hablamos de la Customer Experience en Decathlon y hacíamos referencia a la importancia del propósito en Decathlon.
- Propósito
Una empresa, una compañía no puede tener un único foco que sea ganar dinero. Tradicionalmente ha sido así, pero esto cada vez está cambiando más y más. Para estar motivados necesitamos estar alineados con un propósito estimulante, con un propósito que nos ayude y creo que aquí Customer Experience es clave. Tener esa visión customer centric, entender cómo hay que servir al cliente, entender cómo mi trabajo impacta en la experiencia de mi cliente, cómo puedo aportarle más valor. Eso es fundamental y es fundamental que haya una alineación transversal en toda la compañía respecto a ese propósito. Entonces hablábamos del concepto equipo motivado.
4. Kaizen
Hemos visto entrega temprana y frecuente —estoy haciendo un poquito de recap para que no nos perdamos— la entrega temprana y frecuente, crossfuncionalidad, equipos motivados, y esto es realmente clave en mi opinión. Y por último, otro concepto que para mí es muy importante es Kaizen. Kaizen es una palabra japonesa que significa mejora continua, digámoslo así. Ejemplifica un estado, una cultura que siempre busca la mejora del proceso, hacer reflexión sobre cómo podemos mejorar lo que estamos haciendo, cómo podemos mejorar el cómo lo estamos haciendo y esto para mí tiene muchísimo que ver con todo lo anterior. Tiene que ver con la crossfuncionalidad y con la colaboración.
No podemos mejorar de forma sesgada, tenemos que romper esos silos, tenemos que tener gente motivada que quiera mejorar. La mejora en sí misma es una motivación intrínseca. Pero ojo, a mí también me gusta alertar acerca del Kaizen porque lo he vivido y a pesar de los años que llevamos en Runroom trabajando de forma ágil y sintiéndonos Agile, lo sigo viviendo y lo sigo viendo muy a menudo. Kaizen es un arma de doble filo y hay que tener cuidado porque cuando tú enfocas tu cultura en la mejora continua, cada nueva mejora que haces te sirve para subir un escaloncito y ese escaloncito te sirve para ganar perspectiva y ver todo lo que te queda por mejorar, y eso es peligroso porque a veces se te olvida mirar para atrás y repasar todos los escaloncitos que ya has subido.
Muchas veces nos centramos solo en los escalones que nos quedan.
Cuidado con esto, es importante saber reconocer lo que hemos mejorado y la cultura Kaizen a veces si no está bien gestionada puede generar frustración. Sencillamente quería compartir esta experiencia personal con vosotros. De manera que, entrega temprana y frecuente, crossfuncionalidad, equipo motivado y Kaizen... no soy capaz de sintetizar Agile de una forma más austera y más abreviada para vosotros. Agile es una cultura objetivo, como decían Bea y José Enrique Rodríguez Huerta en una charla —me gustó mucho aquella charla y he hecho referencia en alguna ocasión—.
Para mí esto es lo que significa que Agile es un camino, no es un lugar a donde llegar. Nosotros llevamos diez años intentándolo, porque no dejamos de intentarlo, nosotros trabajamos Agile y llevamos los proyectos de forma iterativa incremental y entregamos valor cada dos semanas, y aun así sientes siempre que es un camino y en el camino está la agilidad, no en el fin. Es una cultura objetivo que por eso cuando se habla de transformación digital también se habla de esa transformación cultural, y por eso es tan importante saber llevar bien la gestión del cambio, porque al ser una cultura lo que nos va a permitir ganar precisamente esa competitividad respecto al mercado y abrazar el cambio y ser capaces de adaptarnos a esa disrupción. Es esa cultura hay que estar muy atento porque no se puede ser ágil en culturas tóxicas como la del palo y la zanahoria, como la cultura del héroe. Ahí no se puede ser ágil.
Agile es una cultura muy determinada
Y ahí es donde falla la mayor parte de implementaciones, y lo voy a decir entrecomillado «implementaciones de Agile» en las grandes corporaciones. Es muy difícil, mucho más difícil que implementar las herramientas, los frameworks, lo más complicado es transformar esa cultura hacia una donde la gente esté motivada, donde haya esa pasión por la maestría, donde los equipos sean autónomos y autogestionados, donde no haya silos, donde el foco sea la entrega de valor y no nuestro bono individual o pasarles por encima de la puerta al siguiente departamento el trabajo que tienen que hacer ellos.
Sin tecnología no hay disrupción.
No se puede hablar de transformación digital si no somos capaces de adaptar el software que nos va a dar ventaja competitiva en el mercado de forma constante, iterativa incremental, incorporando feedback, aprendiendo, siendo soporte para la eficiencia pero también para la innovación, para la disrupción. Sin tecnología no hay disrupción. Sin Agile no hay tecnología capaz de adaptarse a los cambios constantes y cada vez más virulentos y exigentes del mercado. Aún así, ojo, Agile es una condición necesaria pero no suficiente. Esto no va a funcionar de verdad si limitamos a Agile al departamento de sistemas de turno, al departamento digital de turno.
Si solo ponemos el foco ahí, lo que tendremos, en el mejor de los casos, es un silo capaz de entregar producto digital con menos defectos y, con suerte, de forma temprana y frecuente. Pero —y esto lo digo desde mi propia perspectiva— necesitamos elevar la visión, tener una estrategia que abrace a toda la compañía, que nos ayude a alinear a todos los engranajes que hacen que el barco navegue de forma coordinada y efectiva y a eso, queridos oyentes, yo lo llamo Customer Experience.