Why agile fails - even when it doesn’t look that way

La primera de estas situaciones, es la que, tras introducir la forma de trabajo agile en la empresa, esta forma de trabajo se abandona en un primer momento, o tras un periodo muy corto después de su implementación.

Uno de los pilares del agile es evitar el riesgo, para lo que es necesario conocer los posibles obstáculos que pueden presentarse en el camino. Esbozaremos las posibles formas en las que la implementación de agile en una empresa puede fallar, y también, como prevenir que eso mismo ocurra. También trateremos de ayudarte, para que puedas identificar a los posibles impostores del agile.

Porque tu intento de convertirte al agile fracasó

A pesar de una planificación exhaustiva y un training intenso, convertir una organización en agile, no siempre funciona. ¿Cuáles son algunas de las razones más comúnes por las que las empresas fracasan en su intento (y cómo se pueden evitar)?

No sabes porque lo estás haciendo

Quieres que tu empresa sea la más puntera.

Cambiar todos tus procesos en la empresa, sólo por sentir que la empresa está a la vanguardia en metodologías de trabajo. No todos los equipos de trabajo o proyectos requieren o necesitan Scrum o cualquier otra metodología ágil. Puede sonar muy puntero, moderno o incluso puede molar decir que usas práctiles agile en tu empresa, o te puede parecer que todo el mundo ya lo hace, pero si tu equipo no entiendo porque tienen que hacerlo, no valdrá de nada.

Antes de comenzar el cambio a agile, asegúrate de que hay una clara definción del éxito que se pretende alcanzar, para que puedas definir los objetivos y la forma de medir el progreso. Todas las partes interesadas deben entender la razón por la que se opta por una metodología ágil, y qué significa.

Tu equipo no lo entiende

Es fácil aprenderte cuatro conceptos y concertar unas cuantas reuniones. Pero, eso no significa que tu equipo realmente entienda los valores detrás de cada palabra. Si tu equipo tiene cierta resistencia al cambio, quizás sea porque sientan que afecta su status en la empresa, o porque crean que es una pérdida de tiempo. En ese caso, usarán las palabras, pero no las pondrán en práctica.

Tu empresa o tu producto o servicio final no lo necesita

Un rasgo distintivo del agile es, la entrega continua de funcionalidades, la retro-alimentación regular y los ajustes necesarios. A veces, simplemente, no tiene sentido dividir un proyecto en iteraciones de una o dos semanas. Los managers o los usuarios quizás no quieran trabajar sobre un proyecto a medio terminar, tal y como lo requiere el agile. Estos son factores que van más allá del equipo, y suponen obstáculos significativos de cara al éxito del proyecto.

Asegúrate de que todas las partes interesadas están preparadas para trabajar en la forma requerida. Incluyéndose en partes interesadas al: usuario, cliente, equipo de gestión, y todas las personas con capacidad decisoria en el proyecto. En el caso de que se vaya a trabajar con Scrum, el poder contar con un Product Owner en el proyecto es muy importante, ya que es la persona que dirijirá el proyecto, guiará al equipo y ayudará a las partes externas a alinearse con la forma de trabajo.

Porque tu ágil no es ágil

Otro caso en el que la metodología ágil falla, es cuando en realidad no se trata para nada de ágil. Puedes hablar de metodología de trabajo ágil, controlar todo el vocubalurio, pero llevarlo a cabo, realmente, es otra historia. Asegúrata de que en la práctica realmente es ágil, y no un marco de trabajo rígido pretiendiendo ser agile.

Tus reuniones son un desastre

Una práctica común en los equipos ágiles son los daily stand-up o las reuniones diarias de sincronización del equipo. Estas reuniones cortas, están pensadas para compartir 3 cosas, y sólo 3: qué se hizo ayer, que se hará hoy, y si se ha encontrado un obstáculo mientras se hacía el trabajo. Muchas veces los stand-ups se convierten en lluvias de ideas, conversaciones sin fin, propuestas de proyectos, o en una larga toma de decisiones, que en total llevan dos o tres veces más tiempo de lo que deberían. Otro de los grandes errores, es no celebrar los sprint retrospective o retrospectiva, de forma regular. Ya que los equipos ágiles se auto-gestionan, es muy importante que tras cada sprint, entre ellos se den retro-alimentación y corrijan posibles comportamientos no eficientes.

No se tiene en cuenta tu feedback (ni siquiera se te pide)

Un error común al planificar el alcance de un proyecto y presupuestar un proyecto, es no tener en cuenta recursos necesarios para obtener el feedback del cliente y del usuario. Esta es una de las partes más críticas de procesos ágiles -- es necesario que haya no sólo un protocolo claro para regularmente pedir opinión, pero también que haya una infraestructura para ello. Sin tener esto en cuenta, resultará imposible realizar los cambios resultante del feedback. Y así, lo más probable es que el producto final no se adapte a las necesidades reales.

Tus historias de usuario están en el limbo

Las user stories o historias de usario son una herramienta fundamental en metodologías de trabajo ágil, ya que ayudarán a entender las características y funcionalidades necesarias para satisfacer la demanda del usuario. La historia de usuario no puede ser una lista de cosas por hacer. Otra trampa es, pensar que porque tengas la historia de usuario ya tengas el éxito asegurado, el foco de atención siempre debe ser la entrega continua de funcionalidades al cliente.

Un remedio para evitar este tipo de situaciones, es la planificación continua, la formación, y contar con expertos. Agile es una mentalidad, que conlleva una serie de valores, y adoptar una nueva mentalidad nunca es fácil.