Agile ¿para qué?: reflexión para escépticos

Agile... ¿es útil la agilidad? Reflexión para escépticos

No es fácil hablar de agile a quien nunca la ha experimentado, a quien lleva años trabajando en proyectos software de forma tradicional.

Yo mismo fui uno de esos. Mis primeros contactos con la agilidad, para ser exactos con Scrum, no terminaron del convencerme. Me pareció que reflejaba una serie de ideas muy platónicas, una teoría muy bonita pero que difícilmente podría extrapolarse a un proyecto real.

Recuerdo la primera vez que leí la Guía Scrum, con esos valores que pregona de compromiso, coraje, respeto, etc, y pensé que era vender humo. ¿Acaso en cualquier proyecto, esté gestionado con la metodología que sea, no debería haber compromiso? ¿o respeto?

En este post trataré de exponerte algunas razones de por qué la agilidad no es sólo teoría hueca. De hecho, fueron las razones que di hace tiempo a una persona bastante escéptica con este tema…

¿Es útil agile? Tratando de convencer a un escéptico

Os contaré una anécdota. Hace tiempo quedé a tomar un café con una amiga que pertenece también al gremio informático. Es ya veterana, de la antigua escuela, y todo esto del agile, Scrum, paneles Kanban, etc, le sonaba a chino. Por no decir directamente que le parecía una tontería eso de andar pegando postíts en la pared, como si estuviésemos en clase de manualidades…

Me preguntaba sobre esta «nueva moda del agile» que no terminaba de cuadrarle. Yo, con mi afán evangelizador, le comenté que en modo alguno se trata de ninguna moda pasajera. Se trata de una metodología que ya tiene sus añitos, que está implantada en las empresas más punteras del mundo y que, con el tiempo, tenderá a imponerse sobre la forma tradicional de gestión de proyectos.

Aun así, tras mi disertación ella seguía sin estar muy convencida. Su cara de escepticismo iba en aumento. No terminaba de comprender por qué hay que utilizar un enfoque iterativo e incremental ni por qué había que priorizar, en lugar de, como era de sentido común, planifica qué quieres hacer y una vez lo tengas ve adelante con todo.

Entrega primero lo más importante

Era comprensible la reticencia de mi amiga. El problema viene que llevamos tantos años trabajando de un forma que nos cuesta mucho cambiar de paradigma. La filosofía agile es bastante de sentido común, no requiere ser un portento para comprenderla. Pero tenemos tantos vicios adquiridos que a veces no vemos ni lo más evidente.

En este caso, es mucha la gente, como mi amiga, que no comprende que haya que ir realizando entrega de valor de lo más importante a lo menos. Es decir, que debes desarrollar primero lo imprescindible y ya irán añadiendo con el tiempo las funcionalidades más secundarias, siempre de más importante a menos.

En la mentalidad tradicional los proyectos se conciben como un todo que hay que desarrollar. O tienes todas las funcionalidades hechas o no tienes el proyecto. O todo o nada. Por tanto, ¿para qué priorizar, si tienes que tenerlo todo? No pierdas el tiempo, dirían, mirando qué es más importante o menos. Ve con todo y punto.

La importancia de priorizar en agile

Llegado a este punto le plantee una hipótesis a mi amiga:

Imagínate que vives en una gran ciudad donde nadie tuviese vehículos en los que trasportarse, una especie de mundo distópico.

Supón que va a caer un meteorito en esta ciudad y dispones de pocas semanas para alejarte lo más posible del área, si no quieres quedar hecho puré.

Imagínate que alguien plantease la construcción de un vehículo para alejarte de la ciudad lo máximo que puedas, tú junto a tus seres queridos.

Pues bien, mi pregunta fue la siguiente, ¿cómo te plantearías la construcción de este vehículo?

¿Plantearías la construcción de este vehículo vital para tu supervivencia y la de tu familia de forma secuencial, construyendo pieza a pieza hasta que esté completamente terminado sin preocuparte de tener funcionalidades imprescindibles priorizadas?

¿Dedicarías un solo segundo a trabajar sobre algo que no es realmente importante, el elevalunas eléctrico, o la radio estéreo, o el climatizador, o los detalles del salpicadero?

¿O por el contrario, consciente de tus limitaciones de tiempo y de que tienes que tener un vehículo lo antes posible, buscarías sacar de fábrica un cacharro cuyo único requisito sea que te saque de esa ciudad lo suficientemente lejos como para poder salvar tu vida?

Me imagino que, si en algo aprecias tu pellejo, te quedarás con esta segunda alternativa.

Finalmente, el vehículo que obtendrías sería un chasis con un motor, cuatro ruedas, volante y poco más. Lo justo y necesario para que ande y pueda sacarte de esa ciudad avocada al desastre.

Nadie dice que no puedas mejorar más adelante esa lata con ruedas. Con el tiempo podrás añadirle todas las mejoras que consideres (si es que el tiempo/presupuesto lo permite) pero el objetivo primordial lo habrás logrado: construir un producto que cubre una necesidad básica para un cliente, en este caso, tú y tu familia.

El Producto Mínimo Viable

Pues bien, este vehículo minimalista corresponde a lo que se conoce como MVP, el Producto Mínimo Viable, a veces llamado también Release 0.

Ojo, no confundir el MVP con otro concepto semejante denominado Walking Skeleton. El MVP, como su nombre indica, es un producto viable, mínimo pero viable. Es decir, puedes comercializarlo ya que contiene las funcionalidades básicas que el usuario puede explotar.

El walking skeleton en cambio, es un paso previo al MVP, ya que constaría de una estructura básica de la aplicación pero aún incompleta como para poder ser útil al usuario. De ahí el símil de esqueleto andante, tienes el armazón pero te faltan los músculos que lo convierten en algo funcional. En definitiva, el MVP es explotable por el usuario y el walking skeleton no.

El MVP es el mínimo producto viable, es decir, lo mínimo que puedes comercializar ya que contiene las funcionalidades básicas para que un usuario pueda explotarlas.

Reflexión final

En agile partimos de las siguientes premisas, que son las que le dan sentido a este concepto del MVP y a sus consecutivas mejoras:

  • No busques la perfección, lo perfecto es enemigo de lo bueno. Busca sacar un producto al mercado lo antes posible. Si no lo haces, otro se te adelantará.
  • No partas de la base de que no te quedarás sin presupuesto o que no te recortaran los tiempos cuando menos te lo esperes. Por tanto, más vale que lo más importante ya lo tengas hecho. Así que prioriza las funcionalidades de tu producto y construye de más prioritario a menos.
  • Lo más prioritario es normalmente lo más usado. Así que no pierdas tiempo con funcionalidades muy molonas pero que apenas se usan. Céntrate en aquellas funcionalidades que constituyen el core del producto.
  • Nadie te dice que construyas bajo mínimos. Así que de forma incremental y en función de tus necesidades, tiempo, presupuesto, etc, ve añadiendo funcionalidades de forma incremental. De esta forma tu producto será cada vez más completo y mejor.

Por cierto, finalmente mi amiga se fue convencida.

Te puede interesar:

Si te quedaron dudas puedes dejarlas en la sección de comentarios, estaré encantado de responderte.

Y si el artículo te ha resultado útil, te agradeceré mucho que lo compartas en alguna de las siguientes redes sociales. ¡Nos vemos en el próximo post!

Deja un comentario