fbpx (Re)evolución de metodologías ágiles a nivel corporativo | SG Buzz

(Re)evolución de metodologías ágiles a nivel corporativo

Publicado en

Escribo este artículo con el fin de poder comentar las experiencias que he tenido en la implantación de prácticas ágiles en la empresa en la cual trabajo y poder aportar con ciertos lineamientos a aquellos interesados en la adopción de prácticas ágiles en sus empresas o áreas de trabajo.

Cada vez hay más empresas interesadas en adoptar métodos ágiles como Scrum, XP, Kanban o Agile UP, los cuales introducen nuevas formas de trabajar. Vale la pena recalcar que Scrum y XP son metodologías ágiles en particular, mientras Kanban es un sistema para gestionar mejora interna en la organización, no es una metodología de gestión de proyectos o de desarrollo.

¿Evolución o Revolución?

El uso de metodologías ágiles en una institución puede resultar en un gran fracaso si no son llevadas y gestionadas en forma paulatina y organizada. El apuro suele ser un gran enemigo, ya que nos apresuramos en cumplir con objetivos, obligando y presionando el uso de metodologías ágiles, cuestión que genera inmediatamente una resistencia al cambio.

Dentro del mundo ágil, existen múltiples y diversas prácticas, que van no solo orientadas a una metodología en particular, como Scrum o XP, sino a filosofías y hábitos de gestión y de trabajo colaborativo, independientemente de la metodología específica que se escoja. Dichas prácticas orientan a las personas (NO recursos) a un trabajo más integral, motivador e innovador; como Kanban, sistema que permite mejora continua en procesos de desarrollo. 

He podido ver que lo más importante es determinar cuáles  son las prácticas más alcanzables por la empresa o sus diferentes áreas y departamentos, es decir, cuáles de las prácticas que conocemos pueden ser implantadas de forma más inmediata y que no genere caos. También puede servir detectar prácticas ya existentes o cercanas para poder reutilizarlas.

No forzar metodologías unificadas para toda la empresa en una primera instancia

Forzar a trabajar a todos por igual inicialmente es un suicidio. Ya sea en el desarrollo de un producto o prestación de un servicio, no se puede trabajar todo de la misma manera, al menos en una primera instancia. En  mi actual empresa existen diferentes áreas de desarrollo asociadas a diferentes productos, con diferentes personas, costumbres (malas costumbres) y problemáticas particulares  que no obedecen  a estandarizar una forma de trabajo en común para todas las áreas (lo reitero, pero es importante). De ser implantado en forma forzada, generaría solo caos, resistencia al cambio y una terrible entropía.

En áreas u organizaciones donde el flujo de trabajo es continuo (mantenimientos o soporte), es dificil aplicar una metodología como Scrum, ya que el flujo de entrada es continuo e impredecible. En estos casos, el sistema Kanban es más adecuado, y de hecho se puede complementar con prácticas específicas de Scrum como planificaciones  semanales, Stand­Up meetings, reuniones de retrospectivas, junto con prácticas de XP tales como TDD y uso de historias de usuario.

Imponer Scrum en áreas en donde exista demanda continua no es saludable, para poder iniciar en la implantación de prácticas ágiles, siempre es mejor partir por algo más  sutil y menos invasivo, como  podría ser Kanban, porque permite gestionar mejora continua en cualquier proceso existente y poder llegar a un proceso cada vez más perfeccionado.

En otras áreas en donde se desarrolla un proyecto de largo alcance y no existe una demanda  continua, sí es más recomendable el uso de Scrum, ya que el trabajo es más predecible y planificable, pero en vez de hablar de Scrum, es mejor hablar de “iteraciones fijas cada ciertas semanas” o “priorizar los requerimientos continuamente para poder determinar la siguiente  iteración”  y  “visualización  de  los  requerimientos  y  de  lo  que  está  en  curso”. Claramente esto es mejor llevado y aceptado que utilizar Scrum en su totalidad en un inicio.

Lo que yo hice en el desarrollo de un producto en particular, fue orientar el trabajo de desarrollo de software con el uso de entregas continuas cada dos semanas, en donde se define el rol de Product Owner, Scrum Master y Developers, cuyo resultado ha sido notoriamente mejor que en el pasado, generando una cadencia de desarrollo continua y predecible.

No todas las áreas trabajan de la misma manera y no todas las áreas tienen el mismo tablero visual con las mismas columnas de flujo de trabajo. De no existir ningún flujo definido o nada claro, entonces es recomendable utilizar las columnas “Pila, progreso y terminado” como punto de inicio.

Cada área tiene un tablero y columnas diferentes y enfocadas al flujo de trabajo particular, no es algo estándar. De otra forma sería muy probable hablar de fracaso de implantación en vez de éxito. 

Hablar de prácticas ágiles, no de metodologías en particular

Al hablar de prácticas ágiles hablamos de diferentes hábitos y estrategias extraídas de diferentes metodologías las que pueden ser aplicadas en la gestión de los proyectos y en la gestión de los desarrollos propiamente como tal. Para poder implantar agilidad en una empresa, es crucial determinar  la problemática de cada área en particular, para poder determinar cuál de todo el universo de prácticas de todas las metodologías ágiles existentes o más conocidas pueden ser aplicadas y utilizadas en cada área, producto o proyecto.

 Mantener, Mejorar, Innovar

¿Qué ocurre con las prácticas existentes que dan resultados, o con aquellas que son un hábito dentro de la empresa pero que no son efectivas?  En cada organización existe una cultura ya establecida, pero también podemos encontrar la motivación suficiente de querer aprender y aplicar cosas nuevas en la organización. 

En la organización donde laboro, lo primero que hicimos fue generar un levantamiento de malas prácticas existentes en conjunto con cada participante de cada área. La evolución hacia la agilidad, debe partir por el área que está menos contaminada de vicios y malas prácticas o aquella que tiene la capacidad de poder generar e implementar en forma más rápida y efectiva el uso de prácticas ágiles de desarrollo.  Tal como sucede en  el  marketing  viral,  los  resultados  de  un  área  en  cuanto  a  calidad  de entregables,  uso  de  nuevas tecnologías  y motivación  de los integrantes  del equipo, se van traspasando paulatinamente a las áreas contiguas en las que se pueden utilizar las metodologías ágiles y prácticas asociadas.

Posterior a eso, realizamos un levantamiento de las buenas prácticas existentes y que tan lejos estaba la organización de llegar a ser una organización ágil. Hay que determinar si existen prácticas de entrega continua, planificación por iteración, gestión del product backlog, uso de criterios de aceptación, etcétera.

Factores para una evolución exitosa

  • Tener un líder local que apoye la iniciativa de implantación de agilidad en su área o equipo de desarrollo. Es quien apoyará y estará continuamente en el día a día con el equipo de desarrollo.
  • Tener un coach que apoye a cada líder de cada área. Una figura de guía que apoye continuamente al líder de cada área.
  • Contar  con  el  apoyo  de la alta dirección de la empresa, que esté de acuerdo con el uso de metodologías ágiles y que otorgue el empoderamiento suficiente al coach para que pueda ir generando las modificaciones e implantación de prácticas ágiles. Al presentar a la alta dirección el uso de metodologías ágiles para conseguir su apoyo, la clave está en descubrir qué es lo que a ellos más les importa: ¿calidad?, ¿rendimiento?, ¿costos?  En  cualquiera  de  los  casos,  la agilidad va a estar orientada a la calidad y rendimiento, lo que lleva a una disminución de costos en particular.
  • Contar con la visualización de las tareas en un tablero, ya sea de Scrum o Kanban (un tablero por sí solo no te hace ágil en todo caso). 
  • Aplicar consistentemente las reuniones cortas de pie entre todo el equipo.
  • Gestión de requerimientos basada en historias de usuario priorizadas, así como criterios de aceptación de las mismas. 
  • Entrega continua de desarrollos,  ya que eso permite  hablar de calidad y entendimiento desde  el  inicio  de  cada  proyecto  o  desarrollo,  permitiendo  eliminar  considerablemente  el retrabajo, disminuyendo los costos, tiempo y permitiendo un mejor rendimiento de los equipos.
  • Que cada dirección tenga objetivos en particular. Pueden variar en cada caso, pero entre los objetivos más comunes están la calidad, productividad de los equipos y disminución de retrabajo. No ser invasivo en el uso de agilidad es clave, evolución antes de revolución.

 En la vivencia que he tenido, es crucial recalcar que para poder llegar a un nivel alto en el uso de agilidad es importante ir generando una evolución paulatina. En mi caso, partí con un área  específica, que con el uso del sistema Kanban logró ser un ejemplo en cuanto a rendimiento, calidad técnica y motivación de las personas. Con ese respaldo y la inquietud de otras áreas de utilizar lo mismo, me permitió poder apoyar y guiar el uso de prácticas ágiles y metodologías como Scrum en  las  diferentes  áreas restantes  en la empresa, con lo cual se puede hablar que aproximadamente  un tercio de la empresa utiliza cierto nivel de agilidad, y esto ha traído como resultado el tener una calidad de entregables y estrategias de gestión mejores que la competencia, administrando a las personas y proyectos de una manera mejor y diferente, es decir, con un estilo ágil.