Implantando Agile: Algunos errores habituales y tips para evitarlos

abril 29, 2019

Por Aurora Ferrándiz y Félix Bragado

Vivimos una revolución etiquetada como 'Transformación Digital', a la que todo el mundo se quiere apuntar. En todas las empresas se añade el apellido 'Transformación Digital' a alguna iniciativa interna de mayor o menor calado. El mercado les ha dicho que tienen que adaptarse, que hay nuevos players más rápidos, más eficientes y más enfocados al cliente, por lo que o cambias o te arriesgas a desaparecer.

Las empresas han sondeado el entorno, han visto lo que hace la competencia e incluso lo que se hace en otros sectores. Internet, las redes sociales y las publicaciones especializadas están llenas de casos de éxito de transformación digital en muchas de esas compañías.

Muchas de estas empresas comienzan su transformación digital por la misma área: IT. Es un área muy acostumbrada a los cambios y, además, al incluir la palabra “digital”, parece necesario que la iniciativa se comience por aquí o incluso que se lidere desde estas área por medio de la figura del CTO, que tradicionalmente es el Chief Technology Officer, pero que en algunas empresas se ha convertido en el Chief Transformation Officer.

Eso sí, dentro de las iniciativas que se están llevando a cabo en las compañías hay una que se repite en todos los casos: una evolución hacia una empresa más Agile, cambiando los procesos y adaptando la forma de trabajar.

Pero ¿por qué ahora todo el mundo quiere ser ágil en IT? Una de las principales razones es porque vivimos en un mundo con una incertidumbre muy alta y no hay una respuesta clara a las siguientes preguntas:

  • ¿Los requisitos y el alcance en general están bien definidos y acotados por todas las partes?
  • ¿Hemos realizado un proyecto similar en el pasado y contamos con planes y lecciones aprendidas que nos puedan ayudar?
  • ¿Lo que hoy es cierto y está documentado seguirá siendo cierto mañana?

Sin embargo, la realidad dentro de esas áreas de IT suele ser la siguiente: es un área que muchas veces se ve como "un mal necesario", suele estar saturada de trabajo, cuenta con muchos proveedores muy especializados en conocimientos técnicos y dispone de una composición de roles y perfiles que es difícil de entender. Sobre sus hombros tienen responsabilidades como la continuidad del negocio y la actualización constante de todos sus activos tecnológicos, sin los cuales las empresas no podrían competir en el mercado actual.

La iniciativa de Transformación Agile suele comenzar por sus equipos, a los que se les pide que cambien su forma de trabajo para que ésta sea más ágil. Además, se les indica que depende del éxito de esta iniciativa el que luego se expanda al resto de la organización.

Las áreas de IT, con el CTO y el CIO a la cabeza, hacen una incursión en el mercado, buscan al mejor partner que se pueden permitir para ayudarles a arrancar la iniciativa y comienzan esta transformación sin olvidar que el trabajo tiene que salir adelante. Y es en esas primeras iniciativas cuando comienzan a surgir los problemas. Introducir una cultura Agile en una compañía (no decimos en IT, decimos en una compañía) es un cambio profundo que requiere una Gestión del Cambio con mayúsculas. 

Pese a los casos de éxito que a todos nos gusta leer en prensa, no es oro todo lo que reluce. El camino es arduo y difícil y las empresas tienen que tener claro que el Valle del Desespero nos va a afectar, tanto a nivel individual como a nivel colectivo.

Sin entrar en detalles del Valle del Desespero, las empresas y las personas que trabajan en ellas tienen que ser conscientes de que todo cambio conlleva un esfuerzo. Y las empresas tienen que ser conscientes de que los resultados de un cambio corporativo llevan su tiempo y esfuerzo. Hemos encontrado muchas piedras en nuestro camino que nos han llevado a escribir este artículo, en el que describimos los motivos por los que estas iniciativas no siempre funcionan en las empresas o equipos, identificando algunas de las dificultades que hemos encontrado en nuestros proyectos.

Podemos agrupar esos motivos en tres categorías, dependiendo de dónde está el foco de las dificultades:

Organizativas

Las empresas tienen claro que quieren convertirse en empresas Agile y que tener ese tipo de cultura es interesante, pero en muchos casos no están preparadas para un cambio de este calado. El cambio de mentalidad y de procesos impacta en toda la compañía y no sólo en los equipos de IT. Es importante que este cambio se entienda como algo estructural, que va a aportar beneficios a la empresa y no que se hagan por una moda.

Hay muchos tópicos que pueden derribar una iniciativa de este estilo, como "Nosotros siempre lo hemos hecho así" o "Esto de Agile está bien para una Startup, pero no para nosotros". Así, hay muchas personas contentas con su estado dentro de la organización y que buscan la menor ocasión para desacreditar el proyecto. En este caso concreto, los mandos intermedios tienen que estar convencidos de que un giro de la empresa en este sentido es adecuado. Si no están convencidos, se convertirán en resistentes y lograrán que estás iniciativas no tengan éxito.

Asimismo, el proyecto tiene que tener un apoyo claro de la dirección, para que cuando aparezcan esas resistencias haya un mensaje corporativo que de soporte a la iniciativa Agile. Junto a este soporte tiene que ir la lógica inversión en tiempo, personas y otros recursos para llevar el éxito a la iniciativa. Muchas de ellas mueren porque los implicados no disponen de tiempo para dedicar a la transformación Agile.

Por último, uno de los grandes valores consiste en que el proceso sea más transparente para todos los implicados, sobre todo para las personas que se van a beneficiar de las nuevas iniciativas, productos o servicios desarrollados bajo esta forma de trabajo. Si no se logra esta transparencia, estaremos perdiendo uno de los grandes beneficios que nos proporciona el Agilismo y aparecerán excesivos niveles de control y burocracia que acabarán minimizando el impacto de la iniciativa.

Conocimiento

Muchas de las personas que quieren comenzar en estas iniciativas tienen más o menos claro qué quieren hacer, pero no cómo hacerlo. Necesitan comprender los valores y los principios descritos en el Agile Manifesto, pero no sólo saber el contenido, sino tenerlo interiorizado y aplicarlo en el día a día. Lo mismo ocurre con los frameworks que se pueden aplicar: no es lo mismo conocer el framework (La Guía de Scum tiene 22 páginas) que ser capaz de aplicarla correctamente y con éxito. Es más, cuando vemos que los equipos que empiezan a trabajar de esta manera empiezan a estar listos para desprenderse de nuestro tutelaje, siempre surge el mismo miedo a quedarse solos: "cuando te vayas, nos dejarás tu teléfono, ¿no?". Y la respuesta que solemos dar es la misma: "cuando tengas dudas de cómo actuar, mira los principios y valores del Agile Manifesto. Si está en contra, no lo hagas".

En muchos casos se habla del nivel de madurez de los equipos de desarrollo, pero hemos visto equipos con muchos años de experiencia que no son capaces de trabajar bajo estos modelos, por no ser capaces de adaptarse a una nueva forma de trabajo.

Centrándonos en los equipos que implementan el agilismo en IT, y más concretamente en Scrum, un punto que hemos encontrado que complica mucho su implantación es la falta de proactividad en determinados roles para asumir que ya no hay un jefe de proyecto que me diga qué hacer, sino que tengo que asumir mi responsabilidad y dar un paso adelante para responsabilizarme por el trabajo a hacer y terminarlo.

También es complicado el concepto de multicapacidad. Lo ideal es que todos los miembros del Development Team sepan hacer de todo, pero si eso no es posible, al menos todas las capacidades necesarias para desarrollar el proyecto deben estar presentes dentro del equipo. Si no hay nadie con capacidad para desarrollar la capa visual (Síndrome de ¿Dónde está mi Front?) o para realizar pruebas de software (Síndrome de ¿Dónde está mi tester?), por poner dos ejemplos, será imposible que el equipo entregue un incremento de producto al finalizar un Sprint.

Fake Agile

También nos gusta llamarlo en muchos casos "maquillaje Agile". Se trata de hacer algunas cosas, de cara a la galería, pero en realidad seguir trabajando como siempre y que nada cambie. Esto se ve con mucha crudeza en los equipos de IT que empiezan a trabajar con Scrum. Normalmente se comienza cometiendo un error con el piloto sobre el que aplicar un framework Agile: Se coge un proyecto clave, con fechas críticas de entrega y alcance cerrado. Y, entonces, el comentario que aparece suele ser: "¿Pero esto de Agile no es que se desarrolla más rápido?". Esto también viene de un entendimiento erróneo de Extreme Programming, donde se define que se puede hacer mucho en muy poco tiempo.

Situaciones a solventar

Vamos a ver qué problemas podemos encontrar con cada uno de los elementos que define Scrum, ya que es uno de los frameworks más utilizados dentro del mundo del Agilismo y para acotar el contenido de este artículo.

  • Un caso que se da frecuentemente es que el Product Owner espera que se entregue todo lo definido en el Product Backlog en cada uno de los Sprints, independientemente de los elementos seleccionados para este Sprint. Al finalizar cada Sprint esperan un producto completo, totalmente funcional, sin entender el modelo iterativo e incremental en que se basa Scrum.
  • Los Product Owners no dedican el tiempo suficiente a validar las entregas constantes que el Development Team va haciendo durante el proyecto, lo que compromete la validez de las entregas y la oportunidad de tener un incremento terminado (Done) con valor para el negocio.
  • Otro problema importante que nos encontramos es que los Product Owner no son de negocio, sino personas que trabajan dentro de los equipos de IT. La capacidad de decisión en muchos casos está limitada y no siempre conocen el mercado o tienen tiempo para refinar adecuadamente el Product Backlog. Un caso extremo que hemos vivido ha sido escuchar la frase: "No habéis sido capaces de entregarme lo comprometido", en donde se demuestra que el Product Owner no se siente parte del equipo, aunque esta frase da para detectar una buena cantidad de problemas en el equipo. Al final, el equipo identifica al Product Owner como un jefe, ya que es el receptor de la entrega y el validador final del sprint y del producto completo.
  • En muchos casos tampoco se transmite el valor real que tienen las ceremonias y se acaba por no respetar la duración y la celebración de las mismas. 
  • En las ceremonias de Sprint Planning se prioriza siempre lo que no se ha terminado en el Sprint anterior, porque no se hace un trabajo de refinamiento en el Product Backlog durante el Sprint. El tiempo dedicado es, en muchos casos, insuficiente, lo que hace que el detalle de las Historias de Usuario no sea claro y no se pueda comenzar a trabajar con ellas de manera inmediata.
  • Las Scrum Dailys se vuelven a veces discusiones eternas en las que no se respeta el tiempo establecido o se convierten en ceremonias de reporting para que alguien haga de Jefe de Proyecto y diga lo que hay que hacer.
  • Asimismo, las Reviews se usan como validación por parte del Product Owner, con lo que los elementos que no obtengan su visto bueno (Done) cumpliendo con los criterios de aceptación y la Definition of Done no pueden ser actualizados hasta el siguiente Sprint. Además, en esta ceremonia no se invita a los Stakeholders de forma habitual, por lo que se suele perder una oportunidad de inspeccionar el producto y adaptarlo para que tenga un mayor valor de negocio. Los comentarios sobre el estado actual del producto de los Stakeholders son un valor enorme para el producto que se suele pasar por alto.
  • Las Retrospectivas en muchos casos son muy coloridas, con dinámicas estupendas que hacen que todo el equipo disfrute mientras las está haciendo. Todo ello es interesante, pero no vale de nada si al terminar la retrospectiva no tenemos un conjunto de mejoras que podamos aplicar al siguiente Sprint y las hemos incluido en un lugar alto de nuestro Product Backlog para ejecutarlas, al menos algunas de ellas, en el siguiente Sprint.
  • Por último, aunque no por ello menos importante, en muchos casos se elimina o no se hace la ceremonia de Refinamiento, antes conocida como Grooming. Es cierto que Scrum no la considera una ceremonia imprescindible, pero salvo que el equipo sea muy maduro y tenga muy claro el dominio del problema es necesario realizar estas sesiones para que las Spritn Planning sean efectivas y para que el Product Owner pueda compartir la visión del producto o servicio a construir con todos los miembros del Scrum Team.

No se trata de ser una lista exhaustiva ni mucho menos, sólo un recopilatorio de nuestras experiencias que esperemos que ayuden a otros equipos a lidiar con problemas constantes que encontramos los Agile Coaches, Product Owners, Scrum Masters, Agile Developers y resto de personas que nos interesa llevar la cultura Agile a las organizaciones.

- Funcion que traduce al idioma del usuario un contenido, si no se realiza automaticamente --]

Utilizamos cookies propias y de terceros para ofrecerte una mejor experiencia y servicio, dentro de nuestra Web de acuerdo a tus hábitos de navegación. Si continúas navegando, consideramos que aceptas expresamente su utilización. Puedes obtener más información de cómo gestionar y configurar las cookies en nuestra Política de Cookies.