Agile resulta muy eficaz para el desarrollo de productos y especialmente el software. Debido a su popularidad, la velocidad de estas metodologías se usa como pretexto para evitar planificaciones más cuidadosas. ¿Cómo usar adecuadamente la agilidad?
En lugar de tomarse el tiempo para pensar detenidamente qué elementos requiere un producto innovador, los equipos quedan atrapados en el proceso de sprints de dos semanas, pensando en pequeños fragmentos basados en los recursos que ya tienen.
Dos exejecutivos de Amazon compartieron en un artículo de Harvard Business Review, cómo la compañía norteamericana logró integrar las metodologías ágiles con un enfoque diferente para garantizar resultados rápidos y efectivos.
Amazon adoptó un enfoque al que llamó ‘trabajo en reversa’ (working backwards). Parte de una visión de un producto propuesto, plasmado en un comunicado de prensa escrito y una pregunta frecuente que explique a colegas, clientes y alta gerencia cómo la compañía podría crear esta maravillosa oferta a un precio asequible y rentable.
Solo cuando los ejecutivos de la empresa están satisfechos con estos documentos, los equipos pueden comenzar a escribir código y ensamblar el producto. No empiezan por la solución de software, ni por el producto, sino por el propósito de éste.
Desde el principio: ‘trabajo en reversa’
Antes de lanzar una innovación para un producto nuevo, preguntar a los clientes puede dar respuestas no muy precisas, pues en ocasiones se requerirá de escenarios hipotéticos. El enfoque de Amazon sugiere una nueva forma de trabajo.
El enfoque de ‘trabajo en reversa’ 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 podría alentar una mentalidad ágil, la compañía predicó ir lento 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 de trabajo en reversa requiere partir de una visión completamente realizada de un producto propuesto, plasmado en un comunicado de prensa escrito para el lanzamiento del producto.
Esto se sintió mal, incluso antinatural, para los desarrolladores de software y gerentes de producto que querían comenzar a codificar de inmediato.
Por lo general, los equipos pasaban semanas (si no meses), analizando este comunicado de prensa, junto con una pregunta frecuente que explicaba a los colegas, los clientes y la alta gerencia cómo Amazon podía crear esta maravillosa oferta a un precio asequible y rentable.
Solo cuando los ejecutivos se declararan satisfechos con estos documentos, los equipos podían comenzar a escribir código y ensamblar el producto. El lector electrónico Kindle, los servicios de computación en la nube de AWS y el asistente de voz Echo con Alexa provienen del enfoque de ‘trabajo en reversa’.
La velocidad no lo es todo
El problema fundamental de Agile, como lo usan muchas empresas, es que su ritmo implacable sesga a los desarrolladores. Quieren obtener un producto mínimo viable en solo unas pocas semanas, por lo que escatiman en analizar lo que debería lograr el producto. O peor, hacen dos tipos de compromisos.
Primero, en lugar de tomarse el tiempo y la incertidumbre para desarrollar una nueva capacidad, utilizan las habilidades que tienen actualmente. Aceptan sus limitaciones existentes, lo que automáticamente restringe el potencial de una oferta de alto crecimiento.
En segundo lugar, reducen sus ambiciones sobre el producto: En lugar de un gran avance, tienden a realizar mejoras incrementales en las ofertas existentes. Si se atreven, su producto mínimo viable no es realmente 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.
Con mucha frecuencia el proceso de los sprints de dos semanas se convierte en la clave, y el equipo nunca tiene el tiempo y el espacio para dar un paso atrás y obsesionarse con lo que se necesita para realmente deleitar a los clientes.
Los equipos piensan en piezas pequeñas en función de los recursos que ya tienen; no hay tiempo para el pensamiento cuidadoso que requieren los avances. A los defensores de la agilidad les preocupa que un enfoque de ‘trabajo en reversa’ les quite la autoridad y la urgencia a los equipos para lanzar un nuevo código, obtener comentarios de los clientes e iterar rápidamente.
El inicio de un producto exitoso no está limitarse con lo que ya se tiene, sino en explorar nuevas oportunidades y forzarse constantemente (como equipos, cómo empresas y a nivel individual) al aprendizaje continuo.
Mejorar la agilidad
No se trata de desechar las metodologías ágiles. Siguen siendo una herramienta muy eficaz para el desarrollo de productos y software. Muchos de sus principios y procesos han sido utilizados con éxito por Amazon y otras empresas.
La mayor parte del desarrollo de productos implica solo cambios incrementales. No piense mucho en cuál enfoque será el más indicado. Reúna dos alternativas relacionadas y pruébelas en el mundo real; allí obtendrá comentarios vitales.
Los sprints mantienen el equipo encaminado y garantizan que realmente se lleve algo al mercado. La mejor solución, entonces, es combinar la agilidad con el ‘trabajo en reversa’.
Amazon ha aprendido a utilizar el ‘trabajo en reversa’ para el desarrollo de ideas, pero sigue ágil para construir y enviar el producto. Si un gigante como Amazon puede cambiar de rumbo así, las empresas emergentes seguramente podrán seguir su ejemplo.
