¿Hemos llevado la metodología ágil demasiado lejos?
Resumen.
Agile es una herramienta muy eficaz para el desarrollo de productos, especialmente las ofertas basadas en software. Pero a medida que las empresas amplían su uso a nuevas áreas (presupuestos, gestión del talento), la metodología ágil se utiliza con demasiada frecuencia como excusa para evitar una planificación y preparación cuidadosas. En lugar de tomarse el tiempo para pensar cuidadosamente que requiere un producto innovador, los equipos se quedan atrapados en el proceso de sprints de dos semanas, pensando en fragmentos del tamaño de un bocado en función de los recursos que ya tienen. Amazon adopta un enfoque diferente, al que denomina «trabajar hacia atrás». Requiere una visión completa de un producto propuesto, plasmada en un comunicado de prensa escrito y en una preguntas frecuentes que explique a colegas, clientes y altos directivos cómo Amazon podría crear esta maravillosa oferta a un precio asequible pero rentable. Solo cuando los ejecutivos de la empresa están satisfechos con estos documentos, los equipos pueden empezar a escribir código y ensamblar el producto.
La idea de pensamiento o innovación «ágiles», junto con su primo cercano «lean», se ha extendido mucho más allá de sus raíces de desarrollo de productos y fabricación. No es raro oír hablar del enfoque ágil de presupuestación, gestión del talento, o incluso ejecutar un reunión familiar.
La metodología ágil es un proceso potente para el desarrollo de productos, pero muchas organizaciones lo están llevando demasiado lejos y lo utilizan para evitar una planificación y preparación cuidadosas. Obtendrá mejores resultados si lo combinan con un enfoque diferente que aprendimos trabajando como ejecutivos en Amazon. «Trabajar hacia atrás» puede compensar las deficiencias de la metodología ágil en las primeras etapas cruciales.
Cómo las empresas ágiles se adelantan a sí mismas
La metodología ágil puede parecer perfecta para cuando una empresa está desarrollando un producto o servicio que no existe y busca moverse rápidamente. En estos casos, es difícil entrevistar a los clientes o verlos en acción, porque no pueden responder a un producto hipotético.
La solución consiste en desarrollar un prototipo o producto mínimo viable. A través de una serie de sprints, que suelen durar dos semanas, un equipo de producto reúne algo que es lo suficientemente bueno como para mostrárselo a los clientes y obtener su reacción. Si la idea explota, bueno, al menos el equipo obtuvo esa información rápidamente y con solo una pequeña inversión, y tal vez descubran una idea mejor en el proceso. Si consigue tracción, el equipo puede iterar rápidamente para crear un producto aún mejor.
Compare eso con el enfoque de trabajar hacia atrás, que consiste en planificar. El retroceso surgió en 2004: las estrategias de comercio electrónico de Amazon habían demostrado ser exitosas y la empresa buscaba agresivamente nuevas oportunidades con un gran mercado potencial. ¿Dónde debería buscar?
En lugar de lanzarse al desarrollo de un producto plausible, lo que una mentalidad ágil podría alentar, la empresa predicó ir despacio para ir rápido. El CEO Jeff Bezos a menudo se llamaba a sí mismo el «director de desaceleración», y se involucró cuando pensó que los equipos se estaban moviendo rápidamente hacia la codificación sin definir claramente el problema del cliente y una solución de producto elegante.
El enfoque hacia atrás requiere una visión completa de un producto propuesto, plasmada en un comunicado de prensa escrito para el lanzamiento del producto. Esto se sintió mal, incluso antinatural, para los desarrolladores de software y los gerentes de productos que ya querían empezar a programar. Por lo general, los equipos pasaban semanas, si no meses, elaborando este comunicado de prensa, junto con una preguntas frecuentes que explicaba a colegas, clientes y altos directivos cómo Amazon podía crear esta maravillosa oferta a un precio asequible pero rentable. Solo cuando los ejecutivos estaban satisfechos con estos documentos, alguien podía empezar a escribir código y ensamblar el producto.
La práctica se ha estancado: hasta el día de hoy, Amazon trabaja hacia atrás en lo que cree que hará las delicias de los clientes, incluso si actualmente carece de las capacidades para fabricar ese producto. El lector electrónico Kindle, los servicios de informática en la nube de AWS y el asistente de voz Echo con Alexa surgieron de trabajar al revés, en un momento en que Amazon tenía poca experiencia en la fabricación de dispositivos o en el alojamiento de actividades de otras empresas en sus servidores. Sin embargo, estas tres ofertas se convirtieron en productos exitosos. Con el tiempo, cada uno ha atraído a competidores, pero siguen teniendo la mayor cuota de mercado.
La velocidad no lo es todo
El problema fundamental de la metodología ágil, como muchas empresas la utilizan, es que su ritmo implacable sesga a los desarrolladores. Quieren obtener un producto mínimo viable en solo unas semanas, por lo que escatiman en el alcance de lo que el producto debe lograr. O peor aún, en nuestra experiencia, hacen dos tipos de concesiones.
En primer lugar, en lugar de tomarse el tiempo y la incertidumbre para desarrollar una nueva capacidad, van con las habilidades que tienen actualmente. Aceptan sus limitaciones existentes, lo que limita automáticamente el potencial de una oferta de alto crecimiento.
En segundo lugar, reduzcan sus ambiciones sobre el producto. En lugar de ser un gran avance, tienden a introducir mejoras incrementales en las ofertas existentes. O si se ponen audaces, su producto mínimo viable no es viable en absoluto, por lo que los clientes no pueden dar comentarios realistas. Los desarrolladores no han tenido tiempo de hacer sus deberes y preparar algo que sea sostenible.
El equipo se dice a sí mismo que cualquier información que obtengan sigue siendo valiosa para algún producto innovador en el futuro. Pero ese futuro rara vez llega. Con demasiada frecuencia, el proceso de sprints de dos semanas se convierte en la cosa, y el equipo nunca tiene el tiempo y el espacio para dar un paso atrás y obsesionarse con lo que se necesita para deleitar realmente a los clientes. Los equipos piensan en fragmentos del tamaño de un bocado en función de los recursos que ya tienen; no hay tiempo para pensar detenidamente que requieren los avances.
A los defensores de la metodología ágil les preocupa que un enfoque de trabajo hacia atrás les quita autoridad y urgencia a los equipos para lanzar código nuevo, obtener comentarios de los clientes e iterar rápidamente. Pero la velocidad no lo es todo, especialmente cuando se trata de productos innovadores. No confundas escribir código con progresar per se. Al trabajar hacia atrás, puedes conseguir que un producto exitoso llegue al mercado más rápido.
Cómo hacer que la metodología ágil funcione mejor
No estamos argumentando que las empresas deban tirar la metodología ágil por la ventana. Sigue siendo una herramienta muy eficaz para el desarrollo de productos, especialmente las ofertas basadas en software. Amazon y otras empresas han utilizado con éxito muchos de sus principios y procesos. Después de todo, la mayor parte del desarrollo de productos solo implica cambios incrementales. No necesitas pensar mucho en estas mejoras. Solo tienes que juntar dos alternativas aproximadas y probarlas en el mundo real, donde obtendrás comentarios vitales.
Los equipos con productos innovadores también pueden beneficiarse de la agilidad, una vez que hayan realizado el tipo de trabajo avanzado que implica el enfoque de trabajar hacia atrás. Cuando estás en la fase de codificación y construcción de productos, quieres moverte rápidamente y evitar atascos. Los sprints te mantienen en el camino y te aseguran de que realmente llegues algo al mercado.
La mejor solución, entonces, es combinar la agilidad con algo como trabajar hacia atrás. Amazon, por ejemplo, ha aprendido a utilizar el proceso de trabajo hacia atrás para el desarrollo de ideas, pero luego sigue la metodología ágil para crear y enviar el producto. Si un gigante como Amazon puede cambiar de rumbo así, incluso las Startups pueden seguir su ejemplo.
— Escrito por Colin Bryar Colin Bryar Bill Carr
