Este sitio utiliza cookies propias y de terceros para mejorar tu experiencia en la página. Para habilitar o restringir las cookies activas u obtener más información, haz clic en cookie settings.

Aceptar todas las cookies

E011 - ¿Qué es Agile y por qué clave en la Transformación Digital de una empresa?

07 May. 2018

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 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.»

 

¿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:

  1. Entrega temprana y frecuente
  2. Cross-funcionalidad
  3. Individuos motivados
  4. Mejora continua

 

¿Por qué es clave en la Transformación Digital?

Los modelos de negocio se están transformando. La tecnología no sólo 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 a satisfacer esa necesidad de adaptación.

A continuación la transcripción del episodio en el que vamos desgranando las diferentes razones.

 

[00:00:00.150] [Carlos Iglesias]

Vivimos en la era más disruptiva de la historia de la humanidad. No sólo por la profundidad e impacto en nuestras vidas de las distintas disrupciones tecnológicas que van apareciendo sino también por la alta frecuencia y la velocidad con la que aparecen.

 

[00:00:19.800]

No hay que 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 ni Twitter ni YouTube y ni siquiera existía la palabra podcast.

 

[00:00:37.050]

Los modelos de negocio se están transformando.

La tecnología no sólo 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 cual cualquier organización que se precie tiene su propio departamento TIC o digital o de internet o llámese como se quiera. El problema viene 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 2 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 se convierte en una excusa. Si de una forma u otra eres responsable de la transformación de la compañía donde trabajas, aquí encontrarás la manera de desactivar esos pretextos, ese portazo al cambio, ese “aquí no se puede”.

 

[00:01:56.330]

Este podcast es para todos aquellos que estéis convencidos de que las empresas deben poner al cliente en el centro de la estrategia y a las personas de la organización en el corazón de la misma. Aquí adquiriréis una visión estratégica y a la vez práctica a través de ejemplos y experiencias que os dotarán de argumentos en el idioma favorito de la alta dirección, el lenguaje de negocio. No sólo hablaremos del qué sino también del cómo. Hablaremos de Agile, qué es y por qué es tan importante desde una perspectiva estratégica y competitiva. Soy Carlos Iglesias CEO en Runroom y profesor en varias universidades y escuelas de negocio como Esade, Kschool y BAU.

 

[00:02:44.730]

Bienvenidos al undécimo episodio de “En el mundo real”, el podcast sobre Customer Experience y negocio digital.

 

[00:03:08.970]

Bueno bueno bueno... he de decir que me siento un poquito de depresiones, siento bastante responsabilidad a la hora de hacer este episodio.

 

[00:03:22.470]

Muchos de mis oyentes son reputados Agile Coach, consultores de transformación organizacional, personas con muchísima experiencia y bueno pues eso, que exponerme de esta manera a hablar de un tema como Agile pues ahí noto cierta presión. Por cierto, aprovecho para saludar de forma muy especial a José Manuel Beas, no sólo 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 por lo que respecta a las metodologías Agile en este país, que no es el único. Pero hombre, permitidme que hoy le dedique el programa a José.

 

[00:04:04.120]

Bueno, Agile tiene que ver con el software, esto para empezar. El concepto Agile nace de la voluntad de 17 personalidades que el 17 de febrero de hace 17 años - es decir en 2001 nada menos - pues se van a una estación de esquí de Utah con la intención de reflexionar sobre las mejores formas de desarrollar software y compartir sus experiencias y con esas reflexiones intentar ayudar a los demás, a ayudar a la industria.

 

[00:04:46.670]

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.

 

[00:05:00.440]

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 podcast en vuestras caminatas y entrenos de running me estás diciendo que me habéis reservado para las tiradas largas y que estoy favoreciendo y estoy 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, de acuerdo? Así que nada vamos para allá.

 

Para empezar yo creo que he de arrancar hablando de ese problema, el problema que hay atrofía  en la entradilla. Estoy seguro que es muy común y 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.

 

[00:06:10.880]

El problema de esto es que el software es complejo, hay muchísima incertidumbre, es muy poco predictivo a diferencia de montar un avión. Montar un avión es complicado, montar un avión! Hombre pues yo no sé cuántos 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 pues es que es complicado. Pero yo sé que tengo que administrar 300 hectopascales en la tuerca del no sé qué, del condensador de fluzo y es al final lo que hace que yo pueda utilizar metodologías predictivas en los procesos industriales. Pero no en el software.

 

[00:07:03.590]

Vamos yo no sé cuál es vuestra experiencia pero en mi experiencia todos los Gantt, todos los diagramas de Gantt que yo he visto no se han 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 de verdad que ninguno de ellos ha cumplido. Y la razón es muy sencilla, las razones porque el software es complejo y no es predecible, porque hay muchísima incertidumbre no sólo en la propia tecnología sino también en el alcance, en la definición del producto en sí mismo.

 

[00:07:41.000]

Qué significa un buscador? Qué quiere decir hacer un buscador? Un buscador puede ser predictivo, puede ser un buscador sencillo, puede ser un buscador que en cada pulsación de una tecla me arroje resultados. 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, de tener controladas las inversiones que hacemos en software pues nos han llevado - a en mi opinión - equivocarnos en la forma en la que intentamos controlar esos proyectos de software.

Intentamos cerrarlo todo.

 

[00:08:22.760]

Habréis oído hablar del famoso “triángulo de hierro” de los proyectos. Si no habéis oído hablar pues básicamente el triángulo de hierro consiste en tener cerrado tiempo. alcance y recursos.

 

[00:08:38.970]

Y así es muy difícil, es muy difícil porque el alcance como os decía es tan 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 al final hasta que no esté hecha, hasta que no esté creada, no estará completamente definida.

Y luego está la incertidumbre respecto a la tecnología, como decía.

 

[00:09:14.480]

A mí me gusta decir que el desarrollar software se parece mucho más al trabajo de un cirujano que de una cadena de producción o de un arquitecto o vete tú a saber de cualquier otro proceso industrial. El software se parece mucho más a eso, a abrir... de repente abres en canal, un cuerpo separas las costillas de las vísceras y dices “madre mía lo que me encontraba aquí” y desarrollar software se parece mucho a eso. En fin nos equivocamos en la forma en la que intentamos controlar los proyectos de software porque intentamos tenerlo todo cerrado y es muy difícil tenerlo todo cerrado y es muy difícil predecir exactamente lo que va a pasar al inicio del proyecto.

 

[00:10:04.640]

El software funciona mucho mejor ir controlando el alcance, los recursos a medida que va pasando el tiempo. En otro episodio ya profundizaremos un poquito más en el concepto de desarrollo iterativo incremental de software, que yo creo que es un concepto que merece mucho la pena entender bien porque para mí es una de las claves de esa capacidad de adaptación al cambio, capacidad de responder al cambio, a esa necesidad que tienen las compañías y que decíamos al principio.

Lo que voy a hacer hoy es intentar sintetizar ¿que es Agile y para qué sirve? en cuatro conceptos.

 

[00:10:52.190]

Sí el primero de ellos voy a hablar de entrega temprana y frecuente de software, entrega temprana y frecuente de valor.

 

[00:11:05.420]

Luego vamos a hablar de “cross-funcionalidad”, el segundo concepto que me parece un concepto muy importante también para entender qué es Agile.

 

[00:11:13.550]

Luego 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 podcast en sí mismos pero sí que para mí son los pilares fundamentales de Agile.

Entrega temprana y frecuente

Empecemos a hablar entonces de entrega temprana y frecuente. Cuando cuando arranca un proyecto -  estoy seguro de que todos los que escucháis este podcast, si estáis interesados en negocio digital querrá decir que en algún momento habéis pasado por algún tipo de experiencia similar - seguro a la hora de arrancar un proyecto digital un producto digital normalmente lo que sucede es que arranca primero toda una primera fase de análisis, la 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.

 

[00:12:29.560]

Imaginemos que el proyecto por ejemplo es un e-commerce-. Pues ahí en ese funcional describimos todas y cada una de las funcionalidades que tiene que tener ese tener ese e-commerce y que necesitamos desarrollar.Ese análisis funcional digamos que ya ocupa unos cuantos meses, al menos unas semanas en el mejor de los casos. Pero cualquier proyecto seguramente se va a extender más de un mes, definir esa funcional y definir qué es lo que necesitamos porque hay que definir, un montón de cosas, mucha literatura y tan sólo cuando el cliente o los... llamemos los stakeholders, que qué tienen que opinar sobre el proyecto, que tienen que validar que ese proyecto es lo que necesitamos,

[00:13:14.230]

sólo cuando ellos dan el visto bueno y aceptan ese funcional entonces pasamos a la siguiente fase que a lo mejor típicamente en un proyecto como un e-commerce a lo mejor sería agarrar ese funcional y transformarlo en una colección de wireframes, una colección de bocetos página página. En qué consiste cada una de esas páginas. Vamos a 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, este cliente acepte que eso es lo que queremos que se desarrolle.

 

[00:13:57.860]

Entre tanto va pasando el tiempo. Obviamente van pasando las semanas, van pasando los meses cuando ya el cliente, cuando los stakeholders firman con sangre todos y cada uno de esos wireframes, de todos y cada una de esas páginas entonces a lo mejor ya estamos en disposición de pasar a la fase de diseño y en esa fase de diseño pues agarramos esos wireframes, los dotamos de un aspecto visual acorde a un libro de una imagen corporativa o elegimos tipografías, colores, fotografías y lo vestimos, lo maquillamos, le damos un aspecto visual que funcione y cuando ya está todo diseñado pasamos a maquetarlo todo en HTML y cuando ya está todo maquetado pasamos a desarrollarlo en el back office etcétera etcétera etcétera etcétera. Hasta que al final llega el día en que desplegamos todo ese código y lo ponemos en producción.

 

[00:14:57.690]

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…”.

 

[00:15:24.690]

“No, es que esto no me lo dijiste en el funcional. Lo que pone exactamente…” y ahí entra la negociación y ahí 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 que 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…”

 

[00:15:49.740]

Al final lo que sucede en los proyectos, en este tipo de proyectos, los 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 departamento de marketing el departamento de UX, el departamento de diseño, el Departamento de Desarrollo y cualquier departamento. El foco, su foco con respecto a ese comercio va a ser pasarle su trabajo al siguiente departamento, dentro de esa cadena en cascada.

 

[00:16:38.040]

Y ahí queridos amigos, dónde está el valor? Cómo sabemos que lo que estamos haciendo, cómo sabemos que lo que estamos desarrollando tiene valor para el cliente final, para nuestro customer?. Cómo lo sabemos? 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í - pues es posible que el Departamento de UX haya hecho un montón de test de usuario al principio y todo el mundo piense que ya está todo validado.

[00:17:13.930]

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.

 

 

[00:17:27.100]

Ahí es donde vamos a empezar a aprender de verdad. Si 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, la UX es muy importante 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 en que la UX está aislada y está localizada en un momento muy concreto del ciclo de vida del proyecto y del producto.

 

[00:18:08.440]

Por lo tanto Agile apuesta por este primer concepto que quería llevar, que quería poner de manifiesto, la entrega temprana y frecuente de valor, entendiendo valor como software funcionando. Repito hablaremos de proyectos y de desarrollo iterativo incremental en otro episodio porque lo requiere.

Equipos cross-funcionales o multifuncionales

El siguiente concepto que quería destacar va muy en relación con el primero y es la cross-funcionalidad. No sé como se dice bien... multifuncionalidad puede ser? Hablamos de funcionalidad porque en inglés la palabra es cross-functional teams, equipos cross-funcionales o multifuncionales. Y esto lo hemos comentado ya, no es nuevo esto, lo hemos comentado en otros episodios la cross-funcionalidad, 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 es la única forma cuando el desarrollo de tu proyecto digital, el desarrollo de tu producto digital tiene que pasar forzosamente por silos funcionales de conocimiento - como por ejemplo los analistas, el departamento de UX, el departamento de diseño, el departamento de UI, de frontend, el departamento de backend etcétera etcétera etc. - la única forma que tienes de llevar a cabo un proyecto es en cascada.

 

[00:19:44.340]

Pero claro, cómo podemos entregar de forma temprana y frecuente software funcionando si no tenemos a un equipo cross-funcional, 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, con todas esas habilidades orquestadas de forma en el que tanto el diseño como la UX, como el frontend, como el back end etcétera están colaborando para crear ese valor y entregarlo colaborando también con negocio. Por supuesto el negocio tiene que estar durante toda la vida, durante toda la creación del proyecto.

 

[00:20:50.850]

Eso nos va a permitir la entrega temprana pero funcional. Nos va a permitir ir entregando ese software de forma iterativo incremental y por lo tanto incorporar feedback del cliente final y nos va a permitir que estemos abiertos al cambio a ese 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.

 

[00:21:20.560]

Equipos motivados

El tercer concepto que quería introducir era el de “los equipos motivados” y esto es una cosa que yo creo que esto es como el 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 - no es posible ser Agile sin que la gente... sin tener un equipo realmente motivado. Y aquí podemos hablar de Employee Experience y y es muy importante.

 

[00:22:15.110]

Desde luego la experiencia del empleado. Pero a mí me gusta mucho cuando hablamos de motivación... hay un libro que es muy famoso de Daniel Pink - que por cierto también hay algunos TEDx y colgaré un video que sintetiza bastante su obra en las notas del episodio de hoy en carlosiglesias.info/e011 - su libro se llama “La sorprendente verdad sobre lo que nos motiva”. Me parece que lo digo bien.

 

[00:22:54.830]

En cualquier caso lo buscaré bien porque lo digo de memoria y os lo apuntaré también 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.

 

[00:23:10.960]

El habla de maestría, autonomía y propósito. Vamos con ello, vamos que con cada uno de ellos.

Maestría. Por qué por un instrumento en nuestro tiempo libre? Por qué dedicamos tiempo a aprender un instrumento, a tocar mejor el piano a tocar el violín? A aprender a tener un huerto urbano?. No sé, 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 que nos estamos desarrollando, que estamos ganando habilidades.

 

[00:24:12.020]

Eso nos llena nos colma. Por eso es muy importante poner foco como compañía y como la cultura de la empresa poner foco en la calidad en el aprendizaje, en la maestría, en el crecimiento personal y profesional. En tener espacio para ello y tener espacio para que 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 y que yo soy muy pesado y hablo de estos problemas porque de verdad pienso que son totalmente reales. El otro día discutía con un amigo, con Toni Tassani que es un gran amigo y él no estaba de acuerdo en una charla que vi. Yo hablaba de la jerarquía en sí mismo como un problema y él me decía que la jerarquía en sí mismo no es un problema.

 

[00:25:23.970]

Puede que tenga razón de amigo Tassani. Desde mi visión la jerarquía en sí mismo 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 y 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 auto organizados y autogestionados. Ya hablaremos de ello. Cómo y cómo es posible llevarlo a cabo - porque esto se está haciendo señores no estoy hablando de ciencia ficción - .

 

[00:26:06.550]

En Runroom los equipos son auto organizados, no tienen ningún jefe que a cada uno de ellos, a cada una de las personas del equipo 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 -

 

[00:26:52.370]

y los curritos, los que hacen los que están en la capa, en el estrato inferior que 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.

 

[00:27:19.130]

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. Entonces estos Middle Managers, estos jefes intermedios, su rol es 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.

 

[00:28:08.020]

Si yo cada día voy allí a explicarles lo que tienen que hacer hoy y para cuando lo 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 esté 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 ser 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.

 

[00:28:47.200]

Es necesaria la autogestión. No sólo es necesaria. Es más que posible y está demostradisimo que es posible y lo iremos viendo en sucesivos episodios.

 

[00:29:08.000]

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.

 

[00:29:33.950]

Una empresa, una compañía no puede tener un único foco que sea ganar dinero. Vamos si que puede. Tradicionalmente ha sido así, pero esto cada vez 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 a toda la compañía respecto a ese propósito. Entonces hablábamos del concepto equipo motivado.

 

[00:30:32.140]

Kaizen

Hemos visto entrega temprana y frecuente - estoy haciendo un poquito de recap para que no nos perdamos - la entrega temprana y frecuente, cross funcionalidad, equipos motivados - y esto es realmente clave en mi opinión. Y por último otro concepto que para mí es muy importante que es “Kaizen”. Kaizen es una palabra japonesa que significa mejora continua, digámoslo así. Ejemplifica un estado, una cultura de siempre buscar la mejora del proceso, siempre 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 cross-funcionalidad, tiene que ver con la colaboración.

 

[00:31:31.750]

No podemos mejorar de forma sesgada, tenemos que romper esos silos, tenemos que tener gente motivada para que quiera mejorar. La mejora en sí mismo es una motivación intrínseca, mejorar es una motivación intrínseca en sí misma. 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, a pesar de ello lo sigo viviendo y lo sigo viendo muy a menudo. Kaizen es un arma de doble filo. Kaizen es una navaja con dos filos y hay que tener cuidado porque cuando tú enfocas tu cultura en la mejora continua, enfocas tu cultura en mejorar, cada nueva mejora que haces te sirve para subir un escaloncito y es 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 escaloncito que ya ha subido.

 

[00:32:39.120]

Muchas veces nos centramos solo en los escalones que nos quedan.

 

[00:32:42.180]

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, puede generar frustración. Sencillamente quería compartir esta experiencia personal con vosotros. De manera que entrega temprana y frecuente, cross- funcionalidad, equipo motivado y Kaizen... no soy capaz de sintetizar Agile de una forma más austera y más 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 a aquella charla - es una cultura objetivo.

 

[00:33:31.730]

Para mí esto es lo que significa es que Agile es un camino, no es un lugar a donde llegar. Nosotros llevamos diez años y digo intentándolo porque no dejamos de intentarlo, nosotros trabajamos Agile y llevamos los proyectos de forma iterativo 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, digamos. 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 y 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 puede ser ágil.

 

[00:34:44.000]

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, es transformar esa cultura hacia una cultura 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".

[00:35:28.040]

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 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.

 

[00:36:23.230]

Si sólo 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.

 

Y hasta aquí amigos. Este episodio de mi podcast “En el mundo real”, el podcast sobre experiencia de cliente y negocio digital.

 

[00:37:14.230]

Muchísimas gracias por escuchar.

 

[00:37:16.480]

Ya sabéis que para mí es súper importante saber qué pensáis, qué os ha parecido, os ha aportado algo, tenéis alguna experiencia relacionada... Así que me encantaría que sigáis dejándome esos feedbacks ya sea con un comentario en la página del episodio carlosIglesias.info/e011, donde por cierto vais a encontrar un montón de recursos de utilidad y de documentación de referencia del episodio. O mejor aún a través de una reseña en iTunes, en eBooks o la plataforma que utilicéis, acompañado de unas estrellitas unos links. Lo digo siempre, perdonadme que sea pesado pero es que de verdad para mí es súper importante.

 

[00:37:52.330]

Porque estas plataformas utilizan estos sistemas para dar visibilidad a los podcast y para mí ganar visibilidad es lo que va a hacer que se pueda ampliar aún más esta gran conversación que espero mantener con todos vosotros oyentes. Un fuerte abrazo y os espero en el mundo real.

 

¡No te pierdas ni un episodio!

Suscríbete en iTunes  Suscríbete en Spotify

Consulta el listado completo de todos los episodios del podcast Realworld de Carlos Iglesias sobre Customer Experience y Negocio Digital.

Carlos Iglesias

Chief Executive Officer & Founder

Agile Digital Intelligence