Gestión De Proyectos

¿Hemos llevado Agile demasiado lejos?

por
• Colin Bryar
y
• Bill Carr
09 de abril de 2021

Imágenes de Shaun Pettigrew / Getty

Resumen. Agile es una herramienta muy eficaz para el desarrollo de productos, especialmente
ofertas impulsadas por software. Pero a medida que las empresas expanden su uso a nuevas
áreas (presupuestos, gestión del talento), la agilidad se utiliza con demasiada frecuencia como
excusa para evitar una planificación y preparación cuidadosas.

La idea de pensamiento o innovación "ágil", junto con su primo cercano "lean", se ha

extendido mucho más allá de sus raíces en el desarrollo de productos y la
fabricación. No es raro ahora escuchar sobre el enfoque ágil para
la elaboración de presupuestos , la gestión del talento o incluso la realización de
una reunión familiar .

Agile es un proceso poderoso 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án un mejor resultado si lo
combinan con un enfoque diferente que aprendimos trabajando como ejecutivos en
Amazon. “Trabajar al revés” puede compensar las deficiencias de Agile en las
primeras etapas cruciales.
Cómo las empresas ágiles se adelantan a sí mismas

Agile puede parecer perfectamente adecuado para cuando una empresa está
desarrollando un producto o servicio que no existe y busca moverse
rápidamente. En estos casos, es difícil simplemente entrevistar a los clientes o verlos
en acción, porque no pueden responder a un producto hipotético.

La solución es 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 elabora algo
que es lo suficientemente bueno para mostrar a los clientes y obtener su reacción. Si
la idea falla, 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
obtiene tracción, entonces el equipo puede iterar rápidamente para crear un
producto aún mejor.

Compare eso con el enfoque de trabajar al revés, que se trata de

planificación. Trabajar al revés 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 trabajar hacia atrás requiere 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 ya. 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 pero rentable. Solo cuando los ejecutivos estuvieran
satisfechos con estos documentos, cualquiera podría comenzar a escribir código y
realmente ensamblar el producto.

La práctica se ha estancado: hasta el día de hoy, Amazon trabaja al revés de lo que

cree que deleitará a los clientes, incluso si actualmente carece de las capacidades
para fabricar ese 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 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 las actividades de otras empresas en sus
servidores. Sin embargo, estas tres ofertas se convirtieron en productos de
éxito. 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 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, según nuestra experiencia, 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 limita automáticamente 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 solo mejoras incrementales en las ofertas existentes. O si se
vuelven atrevidos, 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.

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 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 trozos pequeños en función de los recursos que ya tienen; no
hay tiempo para el pensamiento cuidadoso que requieren los avances.

A los defensores ágiles les preocupa que un enfoque de trabajo hacia atrás 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. Pero la velocidad no lo es todo,
especialmente cuando se trata de productos innovadores. No confunda la escritura
de código con el progreso per se. Si trabaja al revés, puede lograr que un producto
exitoso se comercialice más rápido.

Cómo mejorar el trabajo ágil

No estamos argumentando que las empresas deban arrojar lo ágil por la

ventana. Sigue siendo una herramienta muy eficaz para el desarrollo de productos,
especialmente las ofertas impulsadas por software. Muchos de sus principios y
procesos han sido utilizados con éxito por Amazon y otras empresas. Después de
todo, la mayor parte del desarrollo de productos implica solo cambios
incrementales. No necesita pensar mucho en estas mejoras. Simplemente reúna dos
alternativas aproximadas y pruébelas en el mundo real, donde obtendrá
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
trabajo hacia atrás. Cuando se encuentra en la fase de codificación y construcción del
producto, desea moverse rápidamente y evitar atascarse. Los Sprints te mantienen
encaminado y aseguran que realmente lleves algo al mercado.
La mejor solución, entonces, es combinar la agilidad con algo como trabajar al
revés. Amazon, por ejemplo, ha aprendido a utilizar el proceso de trabajo al revés
para el desarrollo de ideas, pero luego sigue ágil para construir y enviar el
producto. Si un gigante como Amazon puede cambiar de rumbo así, incluso las
empresas emergentes pueden seguir su ejemplo.

Colin Bryar trabajó en Amazon de 1998 a 2010, donde se convirtió en vicepresidente

técnico y se desempeñó como asesor técnico de Jeff Bezos. Ahora asesor ejecutivo, es
coautor de Working Backwards: Insights, Stories and Secrets from Inside Amazon.
Bill Carr estuvo en Amazon de 1999 a 2014, donde fue vicepresidente de medios
digitales, entre otros puestos. Ahora asesor ejecutivo, es coautor de Working
Backwards: Insights, Stories and Secrets from Inside Amazon.

Fuente:

https://hbr.org/2021/04/have-we-taken-agile-too-far#