¿Por qué las empresas Agile no obtienen grandes beneficios?

Agile es vendido como el "maná" de las empresas. Pero muchas empresas han apostado fuertemente por la digitalización y convertirse a Agile, y aunque se observan algunos beneficios, los grandes y famosos resultados prometidos desde Silicon Valley no acaban de llegar. ¿Por qué?

Me gustaría hacerte una pregunta. Estoy seguro de que te suenan empresas que han apostado muy fuerte por un programa de digitalización, transformación a Agile, con mucha inversión, consultoras entrando, nuevas posiciones en el organigrama (me refiero a scrum masters, product owners, agile coaches…) y mucha publicidad alrededor de estos supuestos casos de éxito.

Pero si le preguntas al CEO en la intimidad sobre los resultados de la transformación Agile seguramente te diga “hemos recogido algunos beneficios, pero estamos lejos de recoger los grandes beneficios que oímos desde Estados Unidos, de las historias de éxito de Silicon Valley”. O sin preguntar al CEO. Si te das una vuelta por la empresa y te tomas un café con algunos de sus empleados, muchos te dirán “poco ha cambiado… al final un poco de maquillaje, pero todo sigue siendo parecido a lo de antes”.

¿Por qué pasa esto?

Hay quien piensa que la causa raíz viene de que realmente no se está aplicando Scrum (u otra implementación Agile) de manera correcta. Y esto es cierto con mucha frecuencia (demasiada diría yo). Al fin y al cabo, haciendo Scrum de una manera correcta tienes más posibilidades de entregar más valor que haciendo una solución adaptada de Scrum. Piensa que Scrum “de manual” ha sido probado más veces que la “solución adaptada de Scrum de la empresa X”.

De todas formas, también tenemos que pensar que cuando algo tan tremendamente sencillo como es Scrum no encaja en una organización de una manera natural, nos deberíamos de preguntar “por qué”. Y a eso iremos más adelante.

También podemos pensar que el problema es que en Tecnología se aplica (o se intenta) ser Agile, pero fuera de Tecnología no.

Estoy de acuerdo. Parece que otras partes de la organización siguen hablando el lenguaje de toda la vida y sólo Tecnología empieza a hablar de “entregas cortas, aprendizaje rápido, entrega de valor, etc”. En el resto de la organización, este nuevo lenguaje se puede aceptar más o menos, pero no lo practican como seguidores incondicionales.

¿Pero por qué pasa esto si Agile es tan sencillo, sus principios son tan claros y parece que podría encajar tan bien en cualquier parte de una organización?

En el libro “Inspired” de Marty Cagan, el autor da con una clave fundamental: la mayoría de las empresas hoy en día que dicen ser Agile, realmente sólo son Agile en la fase de construcción de un producto digital. En todo lo demás, sigue un modelo en cascada clásico.

¿Recuerdas el modelo en cascada? Es un modelo en el que cada fase de la construcción de un producto es secuencial e independiente, y por tanto, dice que la mejor forma de crear productos es teniendo especialistas en cada fase que se van pasando la pelota los unos a los otros.

En un restaurante sería algo así como “el responsable de compras, compra; los cocineros cocinan; los camareros sirven los platos” y con esa relación secuencial y claramente separada según especialistas, se acaba dando un servicio o construyendo un producto.

En el modelo Agile realmente tenemos a todas las personas de distintas disciplinas en un mismo equipo para resolver problemas y conseguir objetivos. Puede haber especialistas, pero todos son responsables de conseguir los objetivos.

El problema actual de las empresas es que aunque se auto-denominan Agile, siguen en esencia, el modelo tradicional en cascada en cuanto al ciclo de vida de un producto digital. Me explico.

La construcción de un producto típicamente pasa por las siguientes fases:

  • Primero, se tiene la idea de un producto
  • Segundo, se hace un “business case” para ver si dan los números y tiene sentido invertir presupuesto y esfuerzo en la construcción de esa idea
  • Tercero, convertimos la idea en requisitos, habitualmente liderado por un Product Manager (o mejor dicho, Project Manager) de Negocio
  • Cuarto, construimos el producto
  • Y por último, entregamos el producto

Ahora bien, y aquí está la clave, la fase de ideación, business case y requisitos se hace de la manera tradicional, donde habitualmente Negocio tiene el peso y Tecnología queda, en el mejor de los casos, como un participante secundario. Y esto a pesar de estar desarrollando productos digitales, donde los ingenieros, con su conocimiento de la amplia diversidad de las soluciones tecnológicas actuales, y los diseñadores UX, fundamentales para que el usuario se enamore de las aplicaciones, deberían de tener un protagonismo de primerísimo plano.

Y sólo en la parte de fabricación del producto digital es cuando entra la “Agilidad”, y construimos el producto con Scrum o cualquier otra implementación Agile. Pero no antes, y esto tiene unas consecuencias terribles.

¿Cuáles son las consecuencias?

Son muchas. Una muy clara es que como Negocio son los que están presentes en la fase de ideación, business case y toma de requisitos, siguen siendo los líderes pensadores y decisores, mientras que Tecnología sólo es importante para fabricar y construir. Es decir, los productos digitales se producen como si se tratara de una cadena de montaje tradicional.

Estoy seguro de que te suenan muchos Product Owners (de Tecnología) que no tienen capacidad de decisión, son enviados de Negocio o coordinadores de tickets de desarrollo. No es que Negocio sea el malo de la película, ni mucho menos; simplemente que Negocio son los verdaderos Owners del producto porque son los que han estado liderando las fases de ideación, business case y requisitos. Y con esta situación, las organizaciones ven imposible que Scrum encaje de una manera natural porque el Product Owner de Tecnología siempre parece que va un paso por detrás de Negocio, lo que acaba derivando en la creación de nuevas posiciones “hechas a medida para Negocio” (como por ejemplo Líderes de Tribu, Chief Product Owner y otras) que están por encima del Product Owner “de Tecnología”. Este es un modelo que deja a todos parcialmente satisfechos (Negocio sigue siendo los Owners, Tecnología puede decir que ya son Agile y es cierto que hay una mejora en cuanto a comunicación), excepto al CEO, que apenas recoge los beneficios prometidos porque en esencia, poco ha cambiado en la cuenta de resultados.

¿Pero por qué casi nada ha cambiado en cuanto a rentabilidad?

Porque hay una consecuencia mucho más grave derivada de cómo se idean los productos y se elaboran los business case, al no hacerse con una mentalidad Agile. No me voy a parar a explicar sobre cómo lo hace Google u otras empresas que son realmente Agile (lo abordaremos en otro post) pero Agile sirve para reducir riesgos y su filosofía es de utilidad en otras partes del ciclo de vida de un producto digital, no solo en la construcción

Piénsalo un segundo. En la primera fase, en la de ideación del producto, pensamos al más alto nivel por qué el cliente va a ver como valioso nuestro producto. Son las “hipótesis” principales, los principales riesgos que se asumen y que si acertamos, hace que el producto sea rentable. Pero como fallemos en esas hipótesis… tendremos serios problemas.

Esas hipótesis sin verificar, basadas en absolutamente nada más que la intuición (o en el mejor de los casos, unas encuestas muy básicas o conversaciones muy sesgadas a algunos clientes potenciales), llegan diluidas en forma de requisitos a la fase de construcción, donde habitualmente los equipos sólo deciden en qué orden se hace qué funcionalidad.

Pero esos riesgos asociados a las hipótesis no probadas ya forman parte del producto como si fuera un virus oculto que saldrá en el peor momento.

Y ese es el problema: el virus saldrá. Porque como nos equivoquemos en esas hipótesis (y acertar a la primera en productos digitales es muy muy difícil), tendremos mucha inversión en funcionalidades de un producto que el cliente no va a ver como valiosas y por tanto, no se van a rentabilizar (TCO aumenta, ROI disminuye). Eso acaba derivando a su vez en muchas más presión a los equipos por parte de la Dirección, la Gerencia o el CEO, nuevas fechas de entrega más exigentes, más de “déjate de Scrum y termína esto ya” y números que no salen como habíamos previsto en el Business Case. En definitiva: inversión que no se rentabiliza. El peor escenario. El que más presión genera. Y el que la gente acaba diciendo “esto de Scrum y Agile no funciona aquí; la agilidad es una moda y un cuento; ya haremos Scrum cuando solucionemos los problemas que tenemos encima de la mesa“.

La solución es realmente sencilla, al menos de entender: es fundamental abordar la digitalización no sólo en la construcción del producto tecnológico, sino involucrando a los ingenieros y expertos en UX en la fase de ideación de productos digitales y replanteando todas las etapas de producción con nuevas técnicas y mentalidad Agile, fundamental para reducir el riesgo y aumentar las probabilidades de éxito.

8 comentarios en “¿Por qué las empresas Agile no obtienen grandes beneficios?”

  1. En nuestra empresa la gestión es nula y no hay project managers (bueno, haber los hay pero solo para ponerlo en la firma del email). En cuanto a digitalización, la empresa compró licencia de Atlassian (Jira y Confluence), sin embargo, a pesar de obligarnos a utilizarlo en ningún momento se nos hizo training ni se nos dio explicación alguna de como utilizarlo/gestionarlo.

    Se ha hecho (y se está haciendo) digitalización por temas de obtención de las ISO, pero como sucede con dicha herramienta que comento, a efectos prácticos no sabemos utilizar el software. Por tanto, cuál es el punto de la digitalización si no hay primero unas “raíces” en la gestión de proyectos ni equipos-personas.

    Con todo ello viene mi siguiente duda, ¿habría más empresas que dicen seguir el método Scrum-Agile, cuando en verdad solo es por atraer clientes y obtención de alguna ISO?

    1. Hola Rubén, gracias por tu comentario. Por supuesto, hay de todo, pero hacer trampas al solitario te puede dar algún beneficio a corto plazo, pero no los grandes beneficios. La digitalización como forma de ofrecer nuevas soluciones innovadoras a los clientes a través de la tecnología sin Agile es como barrer en el desierto porque tanto la digitalización como Agile buscan lo mismo: ofrecer más valor a los clientes en entornos de alta incertidumbre, donde la experimentación en todas las fases del ciclo de vida del producto digital es clave.

      Y por supuesto, la digitalización y Agile es mucho más que simplemente comprar licencias de Jira 😉

  2. Buenas Carlos,
    Iba a exponer una opinión de Agile/SCRUM en base a mi experiencia pero no tengo mucho más que añadir pues coincido al 100% con tu argumentario.

    Llevo más de 5 años trabajando con metodologías Agile (generalmente SCRUM o Kanban) y el 90% de las veces es el escenario “Aquí hacemos SCRUM pero adaptado a nuestras necesidades y manera de trabajar” lo que significa que han cambiado dos o tres nombres en el organigrama y hacen 2 o 3 reuniones más a la semana pero poco más.

    El punto más sangrante es el que comentas que a los ingenieros de software nos dejan siempre fuera de la ecuación en el momento de toma de decisiones lo que frustra de manera infinita a los perfiles técnicos (da igual el grado de seniority que tengas) y no añade ningún valor real o esa “rentabilidad” que buscábamos inicialmente.

    Hay una frase que digo mucho (de mi propia cosecha) cuando me preguntan por este tema y es “Si el procedimiento (SCRUM) se interpone en el proceso de entrega en cualquiera de sus etapas y es más costoso seguirlo e implementarlo que la metodología que había originalmente, ni es útil ni es Agile”, demasiadas reuniones, demasiados tickets, confluence pages que rellenar y documentar, consultar 2 o 3 fuentes diferentes para para aprobar o implantar buenas ideas, te suena todo esto? Pues ya lo tienes, Agile sin Agile, la venta de humo más grande del siglo XXI.

    No digo que no haya grandes profesionales y geniales SCRUM Masters que realmente consiguen implantar esa mentalidad más allá de su equipo y añadir ese valor que se busca pero tristemente es el “rara avis”.

    1. Hola Jose Miguel, muchas gracias por tu comentario que da para mucha reflexión. Lo cierto es que muchas veces olvidamos (incluyo a los profesionales de Agile, yo el primero) que Agile y Scrum es un “arma” para que las organizaciones sean más rentables y no un fin en sí mismo. Por desgracia, parece que Agile y Scrum se usa más como una palabra de moda y tratar de evitar el sonrojo a la pregunta “¿Pero aún no sois agile?”. La realidad es que al final las organizaciones no acaban de obtener los beneficios que se presuponen. Agile y Scrum tiene unos principios realmente sencillos, pero hay que aplicarlos más allá del maquillaje para recoger los beneficios. Además, tampoco tiene que ser traumático, ni drástico y ni siquiera arriesgado para las organizaciones y los beneficios se pueden recoger de manera clara, en términos de rentabilidad, en muy poco tiempo. Pero… como bien dices, el “maquillaje sin cuartel” acaba dando mala fama a Agile entre los C-Levels.

  3. SCURM, Agile, Kanban, PMP, Cynefin, ToC, DSM….. que tienen todos ellos en común cuando nunca lo has aplicado?
    Exacto! Un cambio de cultura en la empresa.

    ¿Dónde empieza el cambio?
    ¡Correcto! En el soporte y apoyo absoluto del C-Level. Desde arriba hacia abajo.

    Si no está eso, solo habrá frustración. Y a todos los niveles.

    Que es lo que pasa casi siempre?
    1. Que marco de trabajo o metodología NECESITA la empresa?
    2. Si necesitas un marco híbrido, que Software se adapta a tus necesidades?
    3. Un PoC para ver y entender los resultados obtenidos y si se adaptan a las necesidades del negocio

    Quizá voy a decir algo poco popular, pero soy agnóstico respecto a las metodologías o marcos de trabajo. El entorno (equipo, situación, tipo de desarrollo, madurez del equipo) es lo que importa para ver cuál es la metodología que se adapta mejor al contexto. El contexto evoluciona siempre.

    2 ejemplos:
    Montar un centro de datos y hacerlo con Agile/SCRUM tiene poco sentido. Aquí aplicaría Waterfall y/o Kanban.
    Un equipo ya maduro puede cambiar de SCRUM a Kanban para favorecer CI/CD e interrumpir menos el flujo del trabajo.

    1. Muy interesante tu respuesta, David. Por mi experiencia, una de las claves es entender, por ejemplo, Scrum como un marco de trabajo en el que precisamente sus límites, siempre que estén bien conducidos por un Scrum Master, favorecen que los equipos sean más maduros y creen productos más valiosos. Pero como en todo lo bueno, se puede corromper y caer en una simple moda que no da ningún resultado valioso para las empresas.

      1. Tienes toda la razón Carlos. Debe favorecer el crecimiento y la madurez de un equipo para que puedan crear productos complejos y de valor.

        Como sabemos, Scrum es fácil de entender pero difícil de aplicar. Según mi experiencia es difícil de aplicar porque hay que entender precisamente que es un marco de trabajo. Si aplicas Scrum, pero le quitas su esencia, aquello donde reside su fortaleza no puede funcionar.

        En mi opinión también hay que considerar que la guía de Scrum es como que te da “suficientes ganchos para tender la ropa”. Te dice lo justo.

        Si se usa Scrum hay que adaptar el entorno cultural, y sin quitarle su esencia para que funcione. A mi ver, es ahí donde radica el camino real que hay que hacer. Y muchas veces, también el problema por entender.

        Sin el empoderamiento del equipo Scrum y la voluntad del C-Level no habrá resultados valiosos. Pero al menos está de moda 🙂

  4. Hola Carlos: Estoy de acuerdo con tus comentarios. Tal vez la conclusión final que apuntas debería ampliarse más explícitamente recogiendo los puntos claves que mencionas en el artículo. “La solución es realmente sencilla, al menos de entender: es fundamental abordar la digitalización no sólo en la construcción del producto tecnológico, sino involucrando a los ingenieros y expertos en UX….” Añadiría la otra idea clave: además Negocio (el/la que de verdad sabe y decide) debería estar convencido de su rol imprescindible en todos los ciclos de Agile incluido en el desarrollo y entrega de Sprint. Se juega los resultados de “su” negocio, de “su” cuenta de resultados, de “su” NPS de satisfacción al cliente. Solo con un Product Owner que sienta la “propiedad” de la solución y se le evalue por estos resultados puede conducir al exito del producto desarrollado.

Deja un comentario

Tu dirección de correo electrónico no será publicada.

Ir arriba
males, 3d model, isolated

Recibe tu Dossier del Master

Te enviamos por correo electrónico la información del Master en Scrum