Eleva tus habilidades de liderazgo y negocios

Súmate a más de 52,000 líderes en 90 empresas mejorando habilidades de estrategia, gestión y negocios.


Aprender a ser ágil

Aprender a ser ágil

por Andrew Stellman y Jennifer Greene

Aprendiendo Agilidad (2015) es una guía sin rodeos sobre un concepto a menudo mal entendido: la agilidad. La razón de ese malentendido es sencilla: con demasiada frecuencia, el concepto ágil se presenta como una solución única para todas las dificultades organizativas imaginables. Andrew Stellman y Jennifer Greene, veteranos profesionales de la agilidad, no lo ven así. Para ellos, la agilidad es una gran herramienta, pero hay que saber cómo -y cuándo y por qué- utilizarla. Y eso empieza por comprender los principios subyacentes de la agilidad.

Sobre el autor

Andrew Stellman es desarrollador, arquitecto, conferenciante, gerente de proyectos y entrenador ágil. Tiene más de dos décadas de experiencia en la industria del software. Entre sus clientes se encuentran empresas, corporaciones y escuelas, como Microsoft, Bank of America y el MIT.

Jennifer Greene es gerente de desarrollo, analista de negocios, gestora de proyectos, coach ágil y experta en ingeniería de software. Greene ha trabajado en múltiples sectores, como los medios de comunicación, las finanzas y la consultoría informática.

Una introducción a la agilidad.

Los clientes no siempre saben lo que quieren -o necesitan-. Como dijo una vez Henry Ford, si hubiera preguntado a la gente qué quería, habrían dicho “caballos más rápidos”.

Por supuesto, Ford les dio coches. Pero imagínate si no lo hubiera hecho. Se habrían perdido años intentando satisfacer esa demanda. Lo más probable es que, para cuando el producto de Ford llegara al mercado, otro ya hubiera empezado a vender coches baratos y fiables. Su producto habría muerto al llegar.

En este resumen, hablaremos de desarrollo de software, no de coches. Pero nos ocuparemos del mismo problema. Ese problema puede resumirse en una sola pregunta: ¿Cómo entregar un producto valioso a tu cliente, aunque no pueda decirte lo que realmente quiere o necesita?

Una respuesta es el conjunto de prácticas y principios conocidos como ágiles. Si has oído esa palabra antes, probablemente también te hayas topado con algunos conceptos relacionados, como scrum, kanban, XP y lean. A menudo, existe la tentación de apresurarse a hablar de estas metodologías junto a las ágiles.

Para Andrew Stellman y Jennifer Greene, autores de Learning Agile, se corre el riesgo de poner el carro delante de los bueyes. Al fin y al cabo, no tiene sentido entrar en el meollo de la cuestión si no hemos demostrado por qué tú y tu organización deberíais siquiera considerar la posibilidad de ser ágiles en primer lugar. Así que eso es lo que haremos en este resumen: examinar el porqué de la agilidad.

Para ello, seguiremos un proyecto de principio a fin. Por el camino, veremos cómo los principios ágiles pueden ayudar a un equipo de desarrolladores de software a trabajar de forma más eficiente y eficaz, y a ofrecer un producto mejor.

No se puede diseñar un buen software en el vacío.

Hablemos por un momento de los lectores de libros electrónicos.

Es fácil ver por qué son tan populares. El objeto en sí es del tamaño de un libro de bolsillo normal, pero tiene capacidad para miles de libros. Y lo que es mejor, cada texto responde a ti, el lector. Puedes ampliar las palabras, cambiar el tipo de letra o saltar hacia adelante y hacia atrás entre el texto principal y las referencias. Con un solo clic, puedes acceder a bibliotecas y catálogos; con otro clic, puedes tomar prestados o descargar nuevos libros en tu dispositivo.

En resumen, es un gran software. Está bien diseñado. Cómodo. Intuitivo. Satisface a todas las partes interesadas. Los lectores lo encuentran fácil de usar, y muestra los textos con precisión, lo que es importante para los autores. También ayuda a los libreros y editores a vender y distribuir libros.

Sin embargo, los primeros lectores de libros electrónicos no hacían todas estas cosas. De hecho, se necesitó más de una década de desarrollo antes de que el software llegara a donde está hoy. A principios de la década de 2000, no estaba claro qué haría que un lector de libros electrónicos fuera valioso. Sólo lo sabemos hoy porque la retrospectiva es 20/20, lo que nos lleva a nuestro pequeño experimento mental.

Retrocedamos en el tiempo. Imagina que nos encargan desarrollar el software para mostrar libros electrónicos en los nuevos dispositivos de mano. ¿Cómo vamos a abordar nuestra tarea?

Bueno, en realidad vamos a hacerlo de la peor manera posible, porque ésta no es la clase de empresa que explora nuevas formas de construir software. Se trata de una operación de la vieja escuela, con líderes que dirigen y seguidores -es decir, nosotros, los desarrolladores- que siguen. En resumen, esta no es la clase de oficina en la que escucharás la palabra “ágil”. Así que vamos a ver cómo se desarrollan las cosas.

El equipo de hardware ya ha hecho un prototipo. Imagínate una tableta negra y gruesa con un puerto USB para cargar libros y un pequeño teclado para interactuar con el lector. A nosotros nos toca construir el software que mostrará los libros electrónicos en este aparato.

Nuestra empresa aplica a sus proyectos lo que se conoce como proceso en cascada. Esto significa que los proyectos se cargan por adelantado. Todos los requisitos del producto se definen al principio. Como hemos dicho, los líderes dirigen y los seguidores siguen. Todas las partes interesadas -los gerentes, los representantes de las editoriales, los minoristas online, etc.- se sientan y elaboran un plan. Escriben los requisitos y elaboran un pliego de condiciones que cumpla todos sus requisitos. Todas las demás fases del proceso, desde el diseño hasta el desarrollo y las pruebas, fluyen a partir de estas decisiones, como una masa de agua fluye a partir de una cascada.

Entonces, ¿qué hay en la especificación? En una palabra, todo. Este lector de libros electrónicos va a ser revolucionario. Va a tener montones de funciones. Capturará las estadísticas del mercado para los editores. Tendrá un escaparate en Internet para que los lectores compren libros. Los autores podrán previsualizar y editar sus libros mientras los escriben. Y todo estará listo en 18 meses.

Avancemos un año y medio. Como se trata de un experimento mental, no tenemos que ser realistas, así que diremos que el proyecto está terminado a tiempo. Y todo está ahí: cada requisito de la especificación se ha implementado, probado y verificado. Todo el mundo está contento.

¿Adivinas qué pasa después? El lector sale al mercado… y fracasa. Con fuerza. Nadie lo compra.

¿Qué ha salido mal?

La cuestión es que las necesidades de la gente no son estáticas: cambian con los tiempos. Si tu única opción es un caballo, quieres un caballo más rápido. Pero un caballo, por muy rápido que sea, no sirve de mucho si todos los demás ya conducen coches. Del mismo modo, el software que la gente necesitaba hace 18 meses no es el que necesita hoy. Desde que comenzó nuestro proyecto, ha surgido un nuevo estándar industrial para los libros electrónicos. Ningún distribuidor quiere publicar nuestro formato no estandarizado: es demasiado molesto. Así que ninguna de nuestras revolucionarias funciones es compatible, lo que significa que no son útiles para nadie.

Esto también significa que hemos perdido mucho tiempo y dinero creando un software que no es muy valioso. Entonces, ¿qué deberíamos haber hecho de forma diferente?

Lanza hoy un software imperfecto y mañana tendréis un producto final mejor.

Aquí es donde nos equivocamos: fuimos insensibles. Nos pasamos 18 meses trabajando en una burbuja para poner en práctica un plan que estaba desfasado incluso antes de llegar al mercado. No hubo ajustes. No fuimos flexibles. Nuestro proyecto, en resumen, no era iterativo.

Un proceso de diseño iterativo no tiene lugar en el vacío. En cambio, lanza los productos rápidamente, haciéndolos llegar a los clientes lo antes posible y recogiendo sus comentarios. Esas opiniones son la base de las mejoras, que luego se envían de nuevo a los clientes -de nuevo, tan rápido como sea posible- para que puedan aportar nuevas opiniones. En ese momento, el ciclo se reinicia. Al fin y al cabo, iterar significa “realizar repetidamente”.

Este bucle de retroalimentación está en el corazón de los procesos ágiles. Piensa en la palabra “agilidad” tal y como la usamos en el lenguaje cotidiano. Describe una forma de moverse rápida y ágilmente, de responder al entorno y comprometerse con lo que tienes delante. Un escalador ágil, por ejemplo, responde a cada mano y punto de apoyo que encuentra. Realiza ajustes rápidos para evitar resbalones y agarres torpes. Lo mismo ocurre con el diseño ágil de software. Los equipos ágiles utilizan procesos iterativos para responder rápida y ágilmente a los errores y confusiones que encuentran. Puede que no construyan el software que se propusieron, pero eso es mucho mejor que construir algo inútil.

Ahí está el primer principio de la agilidad. Podemos expresarlo así: La máxima prioridad es satisfacer al cliente mediante la entrega temprana y continua de software valioso.

Ahora, desglosemos ese principio aún más.

El software sólo puede construirse en el mundo real: el mundo de los humanos imperfectos. Incluso los equipos que más trabajan pasan por alto detalles importantes. Los desarrolladores con más talento no consiguen anticiparse a requisitos vitales. La única forma de corregir los errores es poner el software que estamos construyendo en manos de los clientes: las personas que realmente lo van a utilizar. Como desarrolladores, dependemos totalmente de sus comentarios. Por eso tenemos que lanzar el software pronto.

Publicar el software antes de tiempo no es sólo un antídoto contra el perfeccionismo, sino que aporta valor a los clientes. Si hoy disponen de una sola función, por más que tenga errores, pueden hacer algo que ayer no podían. Al utilizar realmente un producto, pueden aclarar sus necesidades. Eso significa que podrán darnos una idea más clara de lo que quieren que haga un producto. Y una vez que estemos encerrados en este bucle de retroalimentación, estaremos en el camino de crear un producto final que realmente satisfaga esas necesidades.

Abrazar el cambio consiste en adoptar la mentalidad adecuada.

Así que ahí está la respuesta a la pregunta que hicimos antes: lo que deberíamos haber hecho es poner nuestro software en manos de los clientes, para que pudieran usarlo realmente y darnos su opinión. Si hubiéramos hecho eso, nos habríamos dado cuenta de que había un problema y habríamos cambiado de rumbo. Eso nos habría ahorrado el tiempo, el esfuerzo y el dinero que invertimos en construir un costoso fracaso.

Por supuesto, cambiar de rumbo a mitad de un proyecto es más fácil de decir que de hacer. En la práctica, suele ser una experiencia dolorosa y desagradable. Has tomado las decisiones difíciles. Sabes lo que estás construyendo. Sabes lo que esperan tus clientes. Tu flujo de trabajo está establecido. No es un camino de rosas, exactamente, pero estás progresando. Y entonces llega alguien de fuera del proyecto y dice que has estado en el camino equivocado todo el tiempo. Que toda la planificación y el trabajo no han servido para nada. Que tienes que volver atrás y empezar de nuevo. Y lo que es peor, la persona que te dice que cambies de rumbo es la misma que te puso en ese camino en primer lugar. Te dijeron que construyeras una cosa, y ahora que has construido la mitad, te dicen que hagas otra cosa. Es desmoralizador, incluso irrespetuoso. No es de extrañar que te pongas a la defensiva y te resistas a hacer cambios.

¿Comprensible? Claro. ¿Ayudable? En absoluto. Sin embargo, la pregunta importante es: ¿cómo puedes superar este sentimiento?

Bueno, es una cuestión de mentalidad, y tiene dos partes. La primera es aceptar que es realmente difícil construir un software valioso si no estás comprobando -y revisando- constantemente tus previsiones. Sí, cambiar de rumbo a mitad de un proyecto es frustrante, pero no es ni mucho menos tan desalentador como llegar al final de un proyecto y darte cuenta de que has construido una basura.

La segunda parte tiene que ver con la perspectiva, y adopta la forma de un ejercicio.

No siempre es un ejercicio fácil: requiere tener la cabeza fría y más empatía de la que querrías tener con la persona que te acaba de arruinar el día. Pero puede ser esclarecedor. Empieza haciéndote estas dos preguntas: En primer lugar, ¿tu cliente te ha enviado deliberadamente por el camino equivocado? Probablemente no, ¿verdad? Y en segundo lugar, ¿cómo se sintieron cuando se dieron cuenta de que habían metido la pata y te habían costado meses de trabajo? Lo más probable es que se sintieran bastante avergonzados. Probablemente no quisieron acudir a ti y admitir su error. Pero es bueno que lo hayan hecho: ¡te han ahorrado aún más tiempo perdido! Y no sólo se ha estropeado tu plazo. El plazo de tu cliente también se ha retrasado. Su empresa está gastando un buen dinero para construir un software que satisfaga sus necesidades, y este error significa que el proyecto no se está cumpliendo. En otras palabras, esto es frustrante para todos.

A fin de cuentas, ambos estáis en una situación difícil. La única forma de evitar teóricamente las meteduras de pata sería leer la mente de tu cliente. Tu cliente, a su vez, tendría que ser capaz de predecir el futuro. En un mundo ideal, ambos seríais capaces de hacer esas cosas. Pero el software no se construye en un mundo ideal; no vas a trabajar con clarividentes telepáticos. Acéptalo, y los errores -junto con los cambios que conllevan- serán mucho más fáciles de afrontar.

Los procesos iterativos te mantienen en contacto con tus clientes.

Bien, volvamos al punto de partida. ¿Cómo pueden los principios ágiles que hemos explorado ayudar a nuestro problemático proyecto de lector de libros electrónicos? Averigüémoslo ejecutando de nuevo el proyecto.

En primer lugar, recordemos por qué ese lector fracasó. Carecía de algunas características importantes utilizadas por los lectores de libros electrónicos de la competencia, como la compatibilidad con un formato estándar del sector. Sin embargo, hay que tener en cuenta que este problema no se podía prever, ni evitar. Cuando nuestro equipo se puso a trabajar, no había ningún estándar industrial. Por lo tanto, debemos hacer hincapié en la capacidad de respuesta del equipo a lo que descubra una vez que haya comenzado su trabajo.

Esta vez, el proyecto va a ser ágil. Empezaremos con una gran reunión en la que se definirán los requisitos y las especificaciones, pero no nos ceñiremos a ese plan durante 18 meses seguidos. En su lugar, dividiremos ese año y medio en sprints de un mes, un único ciclo del bucle de retroalimentación del que hablamos antes. Dicho de otro modo, vamos a actualizar nuestro diseño en respuesta a los comentarios cada mes.

No habrá mucho que probar al principio, por supuesto, así que avanzaremos hasta el cuarto sprint. Cuando el gerente del proyecto, el equipo y las partes interesadas se reúnen, uno de los desarrolladores informa de que hay una nueva norma industrial para los formatos de los libros electrónicos. El equipo incorpora esta nueva información en su siguiente sprint y construye una biblioteca compatible con el nuevo formato. En el sexto sprint, está listo para incorporar ese formato a la interfaz de usuario del lector.

Como puedes ver, cada sprint se corresponde aproximadamente con cada iteración o versión del software que el equipo está construyendo. Así que pasemos al mes once, el undécimo sprint y la undécima iteración. Ahora tenemos una versión que funciona, que puede cargarse en los prototipos que el equipo de hardware ha creado. Tiene errores, pero es lo suficientemente buena para las pruebas en el mundo real, que es exactamente lo que quiere el equipo. Cuando la gerente del proyecto habla con los primeros usuarios del software, se entera de que les gustaría poder enviar por correo electrónico artículos de prensa y PDFs a sus dispositivos. Ese es el objetivo del próximo sprint del equipo.

Sin embargo, este enfoque no consiste únicamente en probar e incorporar nuevas funciones: también se pueden descartar algunas. Por ejemplo, tal vez ese escaparate de Internet no tenga sentido. Al fin y al cabo, existe un formato de libro electrónico estandarizado, así que no tenemos que crear una plataforma propia. Eso es útil porque libera tiempo para trabajar en otras características más importantes.

Es mucho más probable que esta versión del proyecto acabe bien. Hemos estado lanzando continuamente el software para probarlo en el mundo real y haciendo cambios oportunos en respuesta a esas pruebas. La gran diferencia aquí es que estamos en contacto con los clientes y los usuarios. Cuando utilizábamos el proceso en cascada, estábamos completamente aislados de estos grupos una vez aprobados los requisitos del proyecto. Sin embargo, esta vez no hemos perdido de vista nuestro objetivo final: construir un software valioso y funcional que satisfaga necesidades reales. Y ese es el porqué de la agilidad.

Conclusiones

Hay muchas formas de trabajar de forma ágil, pero todos los enfoques se basan en los mismos principios fundamentales. El primero es la capacidad de respuesta. Los procesos ágiles se basan en la retroalimentación. No esperas al final de un proyecto para probar el software que has construido: lo sacas a la luz lo antes posible. Las pruebas en el mundo real identifican los problemas con antelación y ayudan a tu cliente a aclarar lo que necesita que haga ese software. ¿El segundo principio? No existe el plan perfecto. Cada proyecto requerirá correcciones, cambios y rediseños ad hoc. Pero eso es bueno: así es como se construye el mejor software.