Por qué la metodología ágil sale mal y cómo solucionarlo

Dual Dual/Getty Images

Con el espíritu de convertirse en más adaptativo, las organizaciones se han apresurado a implementar un desarrollo de software ágil. Pero muchos lo han hecho de una manera que, de hecho, los hace menos ágiles. Estas empresas se han vuelto ágiles solo de nombre, ya que el proceso que han puesto en marcha a menudo acaba perjudicando la motivación y la productividad de los ingenieros.

Desarrollo de software ágil

Marcos para desarrollo de software adaptativo como Agile, existen desde hace mucho tiempo y se han manifestado de muchas formas. Pero en el centro de la mayoría de estos modelos hay dos cosas: formar hipótesis (por ejemplo, qué se supone que debe lograr una función) y colaborar en todos los ámbitos de la experiencia en los experimentos, todo ello con el espíritu de impulsar el aprendizaje y no ir a toda velocidad por un camino que demuestre ser incorrecto.

Cuando nació el desarrollo ágil de software en 2001, articuló un conjunto de cuatro principios fundamentales para elevar el arte del desarrollo de software y mejorar la motivación de los gerentes de producto e ingeniería.

1. Las personas y las interacciones por encima de los procesos y las herramientas
2. El software que funciona en lugar de una documentación completa
3. La colaboración de los clientes en lugar de la negociación de contratos
4. Responder al cambio siguiendo un plan

Durante los últimos tres años, en nuestra investigación sobre la motivación humana, hemos analizado las prácticas de los ingenieros en más de 500 organizaciones diferentes mediante una combinación de enfoques experimentales y basados en encuestas. Hemos descubierto que lo que ocurre en la práctica se aparta enormemente de estos principios declarados.

Por ejemplo, en la práctica común, procesos y herramientas se han convertido en el conductor del trabajo, no individuos e interacciones. En una gran empresa de Fortune 100, el director de productos digitales nos dijo: «No se nos permite cuestionar el proceso ágil». En otra organización de Fortune 500, los directores de producto y los ingenieros se comunican exclusivamente a través de sus herramientas, que se utilizan principalmente para que los primeros den órdenes a los segundos.

Del mismo modo, la documentación a menudo triunfa sobre el software que funciona. En una gran empresa de tecnología, su equipo de productos dedicó una cantidad considerable de tiempo inicial a redactar pequeños requisitos (llamados «historias de usuario»). Estos requisitos se pusieron en una cola de tickets como tareas para que el siguiente ingeniero disponible empezara a trabajar. El listón de documentación para mantener la cola en movimiento pasó a ser alto. En última instancia, este proceso pasó a ser uno de muchos «pequeños». cascadas», donde el trabajo pasa del departamento de productos a los diseñadores y a la ingeniería. Este proceso es exactamente lo que Agile pretendía eliminar. No es de extrañar que el director de tecnología de esta empresa dijera: «Mis ingenieros son como cocineros de comida corta en la parte trasera de un restaurante».

Cuando se trata de «responder al cambio en lugar de seguir un plan», a menudo se malinterpreta y significa «no tengo un plan». Por ejemplo, en una empresa de tecnología de rápido crecimiento, los equipos de Agile no intentaron entender la estrategia más amplia de la organización. Como resultado, sus intentos de iteración a menudo se centran en características de bajo valor o poco importantes desde el punto de vista estratégico. Sin un plan, los equipos no sabrán cómo priorizar las acciones ni cómo invertir en esas acciones de manera responsable. Este principio ha llegado a hacer creer a los ingenieros que no es apropiado tener plazos o hitos comunes.

Una cosa sería que estas aplicaciones erróneas mejoraran realmente la motivación y el rendimiento de los ingenieros, pero hemos descubierto que en la práctica ocurre lo contrario. La agilidad, cuando se practica como se ha descrito anteriormente, reduce la motivación total de ingenieros. Como no se les permite experimentar, gestionar su propio trabajo y conectar con los clientes, tienen poco sentido del juego, potencial y propósito; en cambio, sienten presión emocional y económica por el éxito o inercia. Dejan de adaptarse, de aprender y de esforzarse al máximo en su trabajo.

Por ejemplo, un socio de capital riesgo nos contó la historia de cómo una empresa de desarrollo de videojuegos siguió creando un producto durante un año, a pesar de que todos los ingenieros pensaban que no valía la pena jugar al juego. La empresa se dio cuenta de que habían desperdiciado mucho tiempo y dinero.

Este artículo aparece también en:

• 

  Ágil: la información que necesita de HBR

  Tecnología y operaciones Libro

  22.95

  View Details

Los procesos ágiles salen mal, porque a medida que las empresas se esfuerzan por lograr un alto rendimiento, se vuelven demasiado tácticas (se centran demasiado en los procesos y la microgestión) o se adaptan demasiado (evitan los objetivos, los plazos o la colaboración interfuncional a largo plazo).

La clave es equilibrar el rendimiento táctico y adaptativo. Sea ingeniero o director de producto, estos son algunos cambios que debe tener en cuenta para encontrar este equilibrio y poder mejorar la motivación y el rendimiento de su equipo de ingeniería (o de cualquier otro).

1. El desarrollo de software debe ser un proceso colaborativo y sin transferencia.

En lugar de un proceso en el que una persona redacte los requisitos (incluso los más pequeños) y otra los ejecute, todo ello sin una estrella polar estratégica que lo guíe, un equipo que se esfuerce por lograr una verdadera agilidad debería tener un sin entrega proceso frente a un proceso en el que una persona escribe los requisitos mientras la otra los ejecuta. En un proceso sin traspaso, el director de producto y los ingenieros (y cualquier otra parte interesada) colaboran de principio a fin en el diseño de una función.

En primer lugar, el equipo, incluidos los ejecutivos, debe articular los «desafíos» estratégicos del equipo. Los desafíos adoptan la forma de una pregunta, siempre centrada en mejorar algún tipo de resultado o impacto en el cliente. Piense en ellos como la misión detallada de un equipo en forma de preguntas para impulsar un pensamiento expansivo. Los desafíos en sí mismos los desarrolla y repite todo el equipo, incluidos sus patrocinadores ejecutivos (y sus clientes). Se pide a todos los miembros del equipo (o de cualquier equipo) que aporten ideas a cada desafío cuando quieran.

Por ejemplo, en un banco, el desafío era: «¿Cómo podemos ayudar a los clientes a estar mejor preparados para las posibles crisis financieras?» Otra fue: «¿Cómo podemos hacer que sea más divertido y menos engorroso para los clientes mantener hábitos financieros saludables?» Estos desafíos generaron docenas de ideas de muchas personas diferentes.

Entonces, en lugar de que alguien escriba los requisitos mientras otra persona los ejecuta, estos equipos desarrollan y maduran una idea de forma colaborativa, desde un borrador hasta una hipótesis comprobable.

2. La unidad de entrega del equipo debería ser un experimento mínimamente viable.

Los equipos suelen perder tiempo adaptándose demasiado. Para evitarlo, no solo se deben formar ideas para un desafío estratégico, sino que también se deben ejecutar con experimentos rápidos destinados a aprender lo suficiente como para saber qué es lo que funciona para los clientes. En otras palabras, deberían maximizar su «velocidad hacia la verdad».

Para reducir el desperdicio de esfuerzos y aumentar el derecho de decisión del equipo, los experimentos deben ser breves. Si es posible, un experimento no debería durar más de una semana.

A veces esto requiere que el equipo minimice una función a lo que es absolutamente necesario para poner a prueba su suposición más débil. A veces significa que el equipo no codifica, sino que completa un experimento «fuera de línea» a través de la investigación.

3. El enfoque del equipo debe centrarse en los clientes.

El proceso de creación del software (incluso el software de uso interno) debe centrarse directamente en los clientes.

Como mucho, estos principios deberían mantenerse:

• Los «desafíos» siempre se centran en el impacto en los clientes.
• Las reuniones para resolver problemas siempre comienzan con una actualización con el cliente y los representantes de primera línea participan con frecuencia en estas conversaciones.
• Cada experimento se basa en una hipótesis centrada en los clientes. De esa manera, el equipo puede hacerse responsable ante el resultado previsto por el experimento.

Sin embargo, aún más importante es que los ingenieros vean con sus propios ojos cómo los clientes utilizan sus productos. Esto requiere que la primera línea y los ingenieros trabajen juntos para ver si el producto tiene un impacto en los clientes.

4. Utilice los plazos para centrarse en la experimentación y evitar el despilfarro.

Curiosamente, el desarrollo de software adaptativo fomenta los plazos como forma de garantizar que un experimento recibe la inversión que está justificada y de señalar el nivel de calidad aceptable de una función determinada. Por otro lado, los profesionales típicos de la metodología ágil evitan los plazos o los plazos, por miedo a que la fecha límite se utilice para crear presión emocional. Una de las peores sensaciones para un desarrollador de software es pasar unos meses trabajando en algo que acaba no siendo útil. Esto lo llena de presión emocional («He decepcionado a todo el mundo») y de sensación de inercia («¿Por qué hago esto?»).

Para evitar este resultado, debe tener claro hasta dónde debe llegar un ingeniero antes de comprobar si la dirección sigue siendo la correcta. Cuanto mayor sea la incertidumbre sobre la hipótesis de un equipo y mayor sea el riesgo, más corta debe ser la pista. Con eso en mente, el plazo no es una fecha límite. Es una restricción que debe guiar el nivel de profundidad y calidad de un experimento antes de una prueba real. De esta manera, los plazos pueden aumentar la motivación total.

5. El equipo debe organizarse para hacer hincapié en la colaboración.

Para asegurarse de que se acaba con un proceso sin traspaso, las distintas partes interesadas deben funcionar como un único equipo interfuncional, también conocido como grupo. El objetivo del módulo es impulsar la colaboración. Cada cápsula debe contener todo el conjunto de expertos necesario para ofrecer un buen producto. Esto puede incluir a altos ejecutivos. En una organización, por ejemplo, los paquetes de productos incluyen un director de producto, un ingeniero de front-end, un diseñador, un ingeniero de calidad y un representante a tiempo parcial del servicio de atención al cliente y un alto ejecutivo de una función de control.

En muchas organizaciones, hay señales reveladoras de «cápsulas falsas», equipos que se hacen llamar cápsulas pero que en realidad no funcionan de esa manera. Las señales de las cápsulas falsas incluyen:

• Los expertos están en distintos equipos «alineados», no en el mismo equipo. Por ejemplo, un equipo de producto tiene «equipos de sprints» dedicados a la ingeniería. No son cápsulas.
• El equipo utiliza herramientas que impiden una colaboración real. Por ejemplo, al preguntarle a un equipo de ingeniería por qué eligió las herramientas de software ágiles que utilizan, dijeron: «Estas herramientas impedir ejecutivos de que participan en nuestro trabajo». Lo único que hace es perpetuar un ciclo de desconfianza.
• De hecho, las funciones de ingeniería y producto tienen objetivos diferentes desde arriba. Los ejecutivos de ambas funciones utilizan su poder jerárquico para que sus empleados prioricen los objetivos de la función por encima de todos los demás, incluidos los objetivos de su grupo. Estos conflictos, en última instancia, provocan enfrentamientos en los equipos de trabajo que impiden un verdadero trabajo en equipo.
• Los procesos de talento rígidamente jerárquicos, como las calificaciones de desempeño, los títulos jerárquicos, la presión para conseguir un ascenso y los sistemas de subir o salir destruyen el trabajo en equipo necesario para que las cápsulas funcionen bien. Estos sistemas harán que los miembros del equipo estén más en deuda con su jefe que con el cliente de su equipo o pondrán a los miembros del equipo en competencia entre sí. De cualquier manera, no funcionarán en equipo.

Dicho de otra manera, cuanto más fuertes sean los silos de una organización, más personas resolverán las necesidades de su silo en comparación con las necesidades de su equipo. Esto hace que la colaboración y el consenso sean muy difíciles de lograr sin una escalada constante.

6. El equipo debe cuestionar constantemente su proceso.

Una famosa máxima del diseño de ingeniería se conoce como Ley de Conway. Afirma: cualquier organización que diseñe un sistema producirá un diseño cuya estructura sea una copia de la estructura de comunicación (es decir, de procesos) de la organización. En otras palabras, si es una organización monolítica, producirá diseños monolíticos. Si se organiza por segmentos de usuarios, su producto se optimizará para esa estructura.

Si quiere anular la Ley de Conway, lo mejor es ajustar constantemente su estructura y sus procesos para adaptarlos al problema en cuestión. Esto requiere equipos que tengan procesos y estructuras simples y ligeros que cuestionen y modifiquen constantemente.

Por lo tanto, en lugar de construir la «agilidad» como una religión que no pueda cuestionarse, los equipos de ingeniería deberían tener el hábito de diagnosticar e iterar constantemente el modelo operativo de su propio equipo. En los mejores ejemplos que hemos visto, mensualmente, los equipos diagnostican su modelo operativo y deciden si es necesario cambiarlo para producir un producto mejor.

***

La capacidad de atraer, inspirar y retener el talento en productos digitales se está convirtiendo en una misión fundamental para las organizaciones. La mayoría de las organizaciones han sido víctimas de un mensaje simple: implementar la metodología ágil como una serie de ceremonias y todo mejora. Por desgracia, este no suele ser el caso cuando se pierde el lado humano de la ecuación. Volviendo a lo básico de motivación y rendimiento adaptativo, puede crear una organización que sea realmente ágil.