La revolución ágil

Hay ciertas historias que terminan definiendo una industria, historias que nos contamos sobre el lugar de origen, quiénes somos, lo que hacemos. En el último episodio, vimos el ascenso de Linux, una tecnología de código abierto. Sin embargo, esta historia trata de lo que sucedió después. Después de la guerra de los sistemas operativos, los desarrolladores quedaron en un lugar predominante, y esa nueva prominencia significó que iban a reinventar sus trabajos.

En este episodio, descubriremos cómo un enfoque en el desarrollador dio lugar a una metodología completamente nueva de desarrollo de software y cómo ese nuevo abordaje al flujo de trabajo está teniendo un impacto inesperado mucho más allá de la acción en la pantalla.

Esto es Command Line Heroes en español, un podcast original de Red Hat. Episodio tres: La revolución de la metodología ágil.

La historia de hoy comienza en febrero de 2001 y se desarrolla en un centro de esquí en Utah, Estados Unidos.

Fuimos a un alojamiento, con vigas de pino, chimenea y entrada principal. Llegamos la noche anterior y básicamente nos sentamos a hablar sobre qué discutiríamos. Al día siguiente, reservamos una sala de reuniones. Movimos las mesas, y simplemente colocamos las sillas en un círculo o un óvalo, de manera que quedamos todos enfrentados y daba la sensación de mayor apertura.

Ese era Dave Thomas. Dave y otras 16 personas se reunieron en el complejo de esquí Snowbird ese invierno, no para esquiar, sino para hablar sobre lo que estaba mal en el mundo de los desarrolladores en la década de los 90. Digo hablar, pero discutir podría ser una palabra más precisa. Originalmente se habían conocido en una conferencia llamada OOPSLA, la conferencia internacional sobre programación, lenguajes y aplicaciones. Y en realidad, en esa conferencia, todos estuvieron de acuerdo en que crear software era complicado. Pero no se habían puesto de acuerdo sobre lo que deberían hacer al respecto, así que la reunión en la montaña en Snowbird era donde iban a intentar determinar una solución para ese problema.

¿Y cuál era ese problema exactamente? Le pregunté a Dave. ¿Qué estaba mal con la forma en que los desarrolladores solían hacer las cosas?

¿Alguna vez, no sé, decoraste una habitación?

Lo he intentado.

Bueno. Entonces si te dijera de antemano: “Bien. Quiero que te sientes, por favor. Aquí tienes una hoja de papel; quiero que especifiques exactamente cómo debería verse esta habitación cuando termines”. ¿Entiendes? ¿Podrías hacerlo?

En realidad, hice esto con mi propia oficina. Intenté hacer una especie de bosquejo y una representación gráfica y poner todos los estantes donde pensaba que irían. Sin embargo, no funcionó. No resultó como había planificado.

Pero incluso si haces eso, ¿qué haces? Colocas los estantes y dices: “Ah, esto no va a funcionar porque está la puerta”. Así que mueves los estantes a otro lugar. O dices: “¿Sabes qué?, en realidad no puedo poner la alfombra allí porque se atascará la silla”. Lo que sea. ¿Sabes? Así que siempre vas a repetir el proceso cada vez que haya algo desconocido involucrado.

El cerebro humano simplemente no está preparado para modelar el mundo real de un modo suficientemente preciso como para poder saber lo que quiere de antemano. Lo mismo sucede con el desarrollo de software. Las personas no saben de antemano lo que quieren. Y siempre que he pasado por un proceso donde tengo la especificación de un cliente y la implemento de forma prácticamente idéntica a lo indicado, llega el final y dicen: “Pero eso no es lo que queríamos”.

Y le dices: “Pero eso es lo que pidieron”.

Y dicen: “Sí. Pero eso no es lo que quisimos decir”. ¿Sabes? Así que el proceso en el que puedes especificar y luego pasar por algunos pasos mecánicos, y luego se termina, no funciona en el software. No funciona en nada donde exista ambigüedad. No funciona en nada donde haya cierto grado de juicio. Casi como cualquier “proyecto artístico”, no funcionará. Siempre debe haber retroalimentación y ese era el paso faltante.

Tal vez hayas oído hablar de la crisis del software durante la década de los 90. El desarrollo de software en ese momento era simplemente un lío. Las compañías gastaban más dinero arreglando software que creándolo. Y mientras tanto, los desarrolladores como tú y yo estábamos atrapados. En algunos casos, solo podíamos poner en marcha un nuevo software cada par de años Estábamos atrapados con estos lentos y antiguos desarrollos en cascada, de A a B a C, totalmente predeterminados.

Así que la búsqueda de nuevos procesos, de mejores formas de crear software era implacable en ese momento. De hecho, todos los meses parecía haber alguien nuevo con una gran visión de cómo iba a arreglar el proceso de desarrollo de software. Estaba Kanban, el Proceso Unificado Racional, y la lista continúa.

En la guerra de la metodología hubo un montón de nuevas visiones contrapuestas, de nuevas correcciones. Y esa era la contienda a la que Dave Thomas y sus amigos en Snowbird se estaban sumando.

Su propio salvavidas fue algo llamado “El manifiesto para el desarrollo ágil de software”. La velocidad de producción estaba aumentando como nunca antes. El código abierto les dio más poder a los desarrolladores y, como resultado, los desarrolladores necesitaban un nuevo modo de producción más ágil. Por cierto, los chicos que se reunieron en Snowbird discutieron mucho rato de llegar a esa palabra, “ágil”. Al final, era la descripción que tenía sentido. Es como se describe a los grandes felinos en el National Geographic, una palabra que describe lo opuesto a la trayectoria predeterminada de una cascada.

A medida que surgía nueva información, se convirtió en una palabra para aquellos dispuestos a hacer un cambio radical de rumbo. Y fíjate que no es un sustantivo. Es un adjetivo. Ágil sería un modo de ser, no una cosa concreta.

Entonces, ¿qué tienen para ofrecer estos chicos ágiles? ¿Cuál fue su gran solución? El método ágil que muchos de nosotros conocemos hoy es un conjunto complejo de funciones y sistemas. Está el Scrum Master, un TeamScrum, el Product Owner, y todos hacen un sprint de trabajo de una o dos semanas.

Mientras tanto, el trabajo se va acumulando en iceboxes y sandboxes, digamos que puede parecer un proceso largo. Pero nada de eso estaba allí al principio. Los chicos que escribieron ese manifiesto apuntaban a la simplicidad y la claridad. Y la visión fue tan simple, de hecho, que tuvo el poder de definir el camino del destino de casi todos los desarrolladores de allí en más.

Y se nos ocurrió la fórmula “valoramos A sobre B” para expresar los valores. Y en realidad escribimos gran parte de los cuatro valores que ahora forman parte del manifiesto durante el almuerzo.

Cuatro grandes ideas que podrían regir el desarrollo. En caso de que no sepas los mandamientos de la metodología ágil de memoria, son los siguientes.

Individuos e interacciones sobre procesos y herramientas.

Software funcionando sobre documentación extensiva. Colaboración con el cliente sobre negociación contractual. Respuesta ante el cambio sobre seguir un plan.

El manifiesto fue diseñado para ser una chispa que inspirara algo más grande. Estos cuatro valores y algo de material de respaldo se publicaron en un sitio web, agileManifesto.org. Y directamente les pidieron a otros desarrolladores que firmaran con sus nombres para mostrar apoyo.

Creo que todos estábamos sorprendidos cuando llegamos a 1000 firmas y luego a 10.000, y luego siguieron subiendo y subiendo. Y básicamente se volvió un movimiento.

Nunca fue su plan salir de ese alojamiento de esquí con un manifiesto, de por sí. Solo era un grupo de personas apasionadas por el desarrollo de software, que tuvieron un tipo de fervor evangélico sobre ayudar a los demás a desarrollar mejor. Sin embargo, quedó claro que eso de ágil tenía potencial. Burr Sutter, Chief Developer Advocate de Red Hat, cuenta el gran alivio que fue el concepto ágil para los desarrolladores atrapados en la metodología de cascada.

Bueno, el concepto de ágil fundamentalmente tuvo repercusión porque en definitiva decía: “Mira, Nos enfocamos en las personas sobre los procesos. Nos enfocamos en las interacciones y la colaboración sobre las herramientas y la documentación.

Valoramos el software funcionando sobre todo lo demás. Y preferimos que las personas trabajen en grupos pequeños y haya una gran interacción e iteración”.

Para algunos, la revolución de los desarrolladores fue demasiado lejos. Incluso podía considerarse que la metodología ágil estaba legitimando una mentalidad irresponsable de hacker. Una de las personas más importantes que habló en contra de la metodología ágil en principio fue Steve Rakitin. Es ingeniero de software con más de 40 años de experiencia en la industria.

Cuando terminó la universidad, Rakitin comenzó a trabajar en el desarrollo del primer sistema de control digital para plantas de energía nuclear. Y durante décadas, siguió trabajando en software para plantas de energía y software para dispositivos médicos, software de seguridad crítica. Así que, sí, puedes imaginar que no es un tipo que se basa solamente en el instinto. Entonces, cuando surgió la metodología ágil al final de una ristra de metodologías, Rakitin la miró con desconfianza.

Era como, bueno, más de lo mismo. Otro grupo de personas se sentó a tomar unas cervezas y se les ocurrieron otras ideas para desarrollar software, muchas de las cuales, por cierto, ya habían sido desarrolladas y utilizadas en algunos de estos primeros métodos.

Tampoco estaba equivocado en mirarlos de reojo. Se pueden encontrar filosofías parecidas a la de la metodología ágil décadas antes de la cumbre en Snowbird.

Por ejemplo, las metodologías de flujo de trabajo "lean" como Kanban datan de la década de los 40, cuando Toyota se inspiró en las técnicas de almacenamiento en los estantes de los supermercados. Su filosofía para la fabricación lean terminó siendo reutilizada para el desarrollo de software. A Rakitin también le preocupaba otra cosa.

Fui muy escéptico cuando se publicó este manifiesto porque parecía una forma de permitir a los ingenieros de software pasar más tiempo escribiendo código, menos tiempo descifrando qué había que hacer y mucho menos tiempo documentando.

Para Rakitin, esto era más que pensar nuevas ideas para el flujo de trabajo. Se trataba de la integridad de su profesión.

Durante mucho tiempo, la ingeniería de software no se consideró una disciplina de ingeniería legítima como la ingeniería eléctrica y todas las otras disciplinas de ingeniería.

Y, en mi opinión, en parte se debía a que había una falta general de prácticas aceptadas para que los ingenieros de software utilizaran. A medida que avanzamos en la década de los 90 y comenzamos a identificar algunos de estos procesos, parecía que algunos de ellos empezaban a arraigarse y muchos de ellos tenían sentido.

Luego llega el manifiesto. Para que la ingeniería de software pudiera convertirse alguna vez en una disciplina de ingeniería legítima, se necesitaban procesos. Casi todas las disciplinas de ingeniería tienen procesos. ¿Por qué no la de software?

Estás escuchando Command Line Heroes en español, un podcast original de Red Hat.

Entonces, dejando de lado a quienes trabajan en plantas de energía nuclear y enfocándonos en el panorama corporativo más amplio, vemos que de a poco la metodología ágil fue tomando el mando, aunque con algo de resistencia corporativa, claro.

Creo que la mayor resistencia que vemos en la adopción de la metodología ágil viene de la gerencia sénior e intermedia.

Él es Darrell Rigby, socio de Bain & Company. Han estado experimentando usando la metodología ágil en compañías de desarrollo de software, pero también en desarrollo de productos, desarrollo de nuevos servicios, programas de publicidad y programas de fidelidad. Y en cada lugar que visitan, hay una probabilidad de que los gerentes se pongan un poco nerviosos.

Cambia la mera noción de cómo creen que agregan valor porque se alejan de la microgestión o la micromediación con estos equipos para empoderarlos y capacitarlos.

Ahora bien, la metodología ágil no es garantía contra la microgestión. La primera vez que algunas personas ven una junta de gestión ágil, piensan que es solo una lista interminable de tareas por hacer.

Pero luego, una vez que realmente comienzan a usar una herramienta de gestión de proyectos ágil, ven que esa herramienta los ayuda a organizar todas estas ideas y les pone nombres, orden y estructura. Los ayuda a gestionar un proyecto.

Algunos podrían ver el efecto de esas herramientas y pensar: “Si la metodología ágil empodera a los desarrolladores, entonces debe quitarles poder a sus gerentes”. Pero esto era más grande que cualquier puesto laboral. El avance de la metodología ágil estaba creciendo y, algo importante, la metodología se estaba probando a sí misma.

Decenas de miles de equipos han utilizado la metodología ágil, por lo que hay gran cantidad de datos sobre dónde se puede usar. Y la respuesta es: siempre que pienses en hacer una innovación, un equipo ágil probablemente puede hacerlo mejor que la forma en que lo estás haciendo hoy.

Hay muchas empresas grandes y conocidas que se han transformado. Amazon es un gran usuario de enfoques ágiles, Netflix, Facebook, SalesForce, todos ellos hacen uso intensivo de la metodología ágil. Y realmente no solo ha redefinido la forma en que trabajan, sino la forma en que funciona la industria.

Cuando Rigby escuchó por primera vez sobre la metodología ágil, pensó que era solo vocabulario extraño. Estaba trabajando con los departamentos de TI en muchos minoristas grandes y los escuchaba hablar de Timeboxes, Sprints y Scrum Masters. Al principio, no tenía idea de lo que estaban hablando. Me contó que de hecho intentó ignorar cualquier mención a la metodología ágil como si fuera otro idioma que no necesitaba aprender. Después de todo, él no era desarrollador. Hoy, cree tanto en el proyecto que literalmente ha llevado la metodología ágil a su casa y a su iglesia.

No es que me siento con mi familia cada mañana y hago una reunión de scrum con ellos, pero me he vuelto muy bueno en priorizar las cosas que voy a hacer.

La metodología ágil pasó de alternativo a estándar en poco más de una década, pero la asimilación corporativa tuvo su costo. Y en algunos casos, esa asimilación incluso significó degradar las intenciones originales del manifiesto. Dave Thomas me recordó eso. Dice que cuando él y los otros 16 chicos de Snowbird lo escribieron, no había ninguna fórmula real.

Entonces, si bien el manifiesto no te dice cómo aplicar los valores, supongo que tenías alguna idea de lo que creías que sucedería o lo que la gente haría con él.

Honestamente, no.

Esto podría sorprenderte. La metodología ágil puede parecer muy prescriptiva hoy. Hay todo un mercado de libros, certificaciones, herramientas, cursos y productos que te muestran cómo “cómo usar la metodología ágil”. Pero, a pesar de los miles de manuales y profesionales que quieren enseñarte la verdadera manera de hacerlo, Dave Thomas dice: “Realmente no están captando lo esencial”.

Hay un conjunto de valores. Es como la regla de oro, supongo. Es como si estuvieras por hacer algo malvado y vil, y piensas:

“Bueno. ¿Me gustaría si alguien me lo hiciera a mí?” Se aplica la regla de oro. Bueno, es lo mismo con el manifiesto ágil. No te dice qué hacer y qué no hacer. Solo te dice cómo evaluar si lo que haces está alineado con ese tipo de forma de hacer las cosas.

Sí. Y creo que volviendo al nombre del manifiesto del desarrollo ágil de software, el término que realmente se destaca y que ha sido muy persistente y que las personas retienen es la palabra ágil. ¿Por qué se usa mal la palabra ágil hoy?

El problema con la palabra ágil es que, en el título que se nos ocurrió, es un adjetivo que describe el desarrollo de software. Pero lo que sucede entonces es que las personas dicen: “Bueno, ¿cómo hago esto de ágil?” De repente, sale todo un ejército de asesores y consultorías que miran el éxito de XP, miran el éxito del manifiesto y dicen: “Oye, esa es una mina de oro”.

Y así comienzan a decirle a la gente cómo “hacerlo ágil”. Y eso es un problema porque no puedes hacerlo ágil, ágil no es lo que haces. Es cómo lo haces.

Y, sin embargo, hay empresas que con gusto te venden ágil listo para armar. Creo que es una farsa. Las consultorías que entran a una compañía de Fortune 1000 y los ayudan a establecer el programa “ágil”, se van con 5 millones de dólares.

Guau.

Excelente. Bien por ellos. Pero la realidad es que es como enseñarle a un tigre que sea ágil diciéndole: “Camina siete pasos y luego salta sobre tu pata izquierda.

Y luego da dos pasos más y salta sobre tu pata derecha”. Bueno, eso solo funciona si la gacela hace lo mismo. Y adivina qué, nadie le ha enseñado a la gacela a ser ágil de esa manera. Básicamente corre hacia el horizonte muerta de risa porque el tigre ha ido en la dirección equivocada. Lo mismo sucede cuando le dices a un equipo cómo ser ágil. Si les dices: “Estas son las reglas que deben seguir. Estos son los procesos que deben seguir”.

La gerencia los juzgará en base a cuán bien cumplen esos principios o esos procedimientos, no según cuán bien están desarrollando software.

Entonces, si miramos hacia atrás, cuando piensas en el rol del desarrollador antes del manifiesto y luego después del manifiesto, ¿cómo cambió o se amplió el rol del desarrollador como resultado de lo que escribieron?

A su favor, creo que la mayoría de los programadores lo comprenden. Creo que el manifiesto ha facultado a muchos desarrolladores a comenzar a seguir las prácticas que, en cierta medida, sabían que deberían haber estado empleando, pero nunca habían tenido la autoridad para hacer cosas como la realización de pruebas, por ejemplo, recopilar retroalimentaciones, iteraciones cortas. En muchos sentidos, el trabajo es más interesante y más gratificante.

También creo que los programadores se sienten un poco más asustados porque ahora tienen responsabilidad. En los viejos tiempos, yo solo seguía órdenes. ¿Por qué este programa no funciona? Bueno, yo seguí las especificaciones. Mientras que hoy en día es tu responsabilidad. Creo que el trabajo ha madurado un poco gracias al manifiesto y las personas están comenzando a darse cuenta de que tienen una responsabilidad absoluta por lo que entregan.

El éxito de la metodología ágil ha sido tan generalizado que está alterando el flujo de trabajo y las actitudes más allá del mundo del desarrollo. Sin duda, más allá de Snowbird. Tenemos que preguntar. ¿Qué significa ser un desarrollador ágil hoy en comparación con 2001 cuando se escribió el manifiesto? ¿Perdura el espíritu original de la metodología ágil? Y si cambió, ¿eso es algo realmente negativo?

Para Ruha Devanesan, Diversity Business Partner en Google, la mentalidad ágil quizás haya evolucionado hasta el punto en que ahora influye en los niveles básicos de equidad e igualdad en el lugar de trabajo.

Parte de lo que hace que los equipos sean inclusivos es su capacidad de evaluar y reflexionar sobre cómo trabajan juntos en un nivel muy primario. Y la mayoría de los equipos, cuando trabajan juntos, no tienen lugar para detenerse y pensar en la dinámica de su equipo, en si todos están pudiendo dar su opinión, si alguien está pasando por encima del otro o si alguien está callado todo el tiempo.

Y si están callados, ¿por qué lo están? Entonces, pensando en la inclusión, se me ocurrió que algunas de las herramientas que los equipos ágiles utilizan podrían ser muy útiles para dar a los equipos una estructura o un marco para ser más inclusivos. Diversidad no solo en términos de sexo, raza y origen étnico, sino también diversidad funcional. Y la diversidad funcional introduce complejidad en un equipo.

Pero hagamos una distinción aquí. Ruha no dice que la metodología ágil equivale a diversidad. Está diciendo que metodología ágil más diversidad equivale a mejores equipos. Las ideas de Ruha se cristalizaron en un artículo que escribió: “¿La metodología ágil puede abrir paso a la diversidad?” Dejaremos un enlace en nuestras notas del programa. Vale la pena leerlo. Allí, explica esta idea de que la diversidad no es solo un concepto difuso del que les encanta hablar en el Departamento de Recursos Humanos.

Realmente es un caso comercial sólido. La diversidad puede ser compatible con la metodología ágil.

Así que esa introducción de complejidad con la finalidad de obtener un resultado o producto que ha sido analizado desde muchos ángulos es el mismo enfoque fundamental que adoptamos cuando decimos: “Agregar diversidad a un equipo conduce a un buen resultado, conduce a más innovación y más creatividad”, porque cuando hay varias perspectivas de un problema, trabajando en equipo para resolverlo, es más probable que termines con un resultado más sólido.

Incluso algo tan simple como una charla informal diaria, donde todos los miembros de tu equipo hablen, da lugar a que los introvertidos u otras personas a las que les cuesta ser escuchadas puedan expresarse.

Lo que realmente me gusta de la metodología ágil es que tiene algunos mecanismos incorporados para ayudar a los equipos a detenerse y reflexionar, y eso se puede deber a que la metodología ágil es muy rápida y tiene sprints cada dos semanas, por lo que si no incorporas esos mecanismos, es probable que te desvíes sin darte cuenta y no puedas volver a encaminarte.

Reflexionar sobre cómo trabajamos juntos, sobre cómo podemos corregir el rumbo, es una de las formas fundamentales en la que los equipos pueden ser inclusivos.

Ya que estamos hablando de inclusión, este podría ser un buen momento para señalar que los 17 autores del manifiesto ágil, sí, eran todos hombres blancos.

Había cero diversidad en esa sala, y esa es una crítica muy común del grupo, y con la cual coincido mucho.

Si los autores del manifiesto hubieran usado esos principios ágiles y los hubiesen aplicado a su propia reunión, podrían haber llegado a la mitad y haberse preguntado: “Oigan, ¿notaron que no invitamos a ninguna mujer a esta reunión? Me pregunto si una persona de color tendría una opinión diferente”.

Las personas tienen amigos que se parecen a ellas, así que si la primera persona que pensó en el manifiesto ágil era un hombre blanco, no es sorpresa que las personas que invitara a la mesa también fueran hombres blancos.

Tenemos la oportunidad de detenernos y decir: “Demos un paso atrás. Ampliemos nuestro lente y busquemos personas fuera de la red que tengo actualmente, que puedan aportar una perspectiva diferente y ayudarme a elevar esta metodología a algo aún mejor”.

Tiene sentido que, debido a que la metodología ágil es, bueno, ágil, podemos aplicarla a diferentes problemas e industrias. El uso de la metodología ágil y cómo se ve en la vida real cambia constantemente, se va expandiendo. Supongo que practica lo que predica. No hay respuesta correcta, no hay un punto final determinado. Eso es algo que a veces olvidamos. Las reglas estrictas son el enemigo de la agilidad. Entonces, si un equipo ágil alguna vez te dice que parte de ser ágil significa que tienes que lanzar una nueva versión cada dos semanas, o que tienes que hacer esto o aquello, entonces por definición, eso no es ágil.

El instante en que dices “Siempre” dejas de ser ágil. Los 17 hombres que se reunieron en Snowbird, Utah, finalmente se llamaron “The Agile Alliance”. Y esa alianza se convirtió en una organización sin fines de lucro, y esa organización sin fines de lucro comenzó a organizar una conferencia cada año. Fue creciendo y creciendo, generando teorías y metodologías completamente nuevas.

Y aquí hay algo que creo que es muy interesante. En la conferencia de 2008, asiste el desarrollador belga, Patrick DuBois, y emprende un camino que lo lleva a inventar una nueva práctica de desarrollo de software, DevOps. Quizás nunca te hayas dado cuenta de que la metodología ágil, un conjunto de principios, y DevOps, toda una industria, estaban relacionados. ¿Qué tan fuerte es realmente esa línea del surgimiento de la metodología ágil y la invención de DevOps?

Pero, ¿uno de los avances dio lugar al otro de forma orgánica? Vamos a descubrirlo juntos porque nuestro próximo episodio es todo sobre DevOps, de principio a fin. Command Line Heroes en español es un podcast original de Red Hat. Para recibir nuevos episodios de forma automática y gratuita, asegúrate de suscribirte al programa.

Simplemente busca Command Line Heroes en Spotify, Apple Podcasts, Google Podcasts o donde sea que obtengas tus podcasts. Luego, haz clic en suscribirte para ser el primero en saber cuando hay disponibles nuevos episodios.

Gracias por escucharnos y sigan programando.