Estado del software agile en el 2018 (traducción al castellano)

Keynote de Martin Fowler en Agile Australia, Melbourne 2018. Puedes encontrar el video de la charla aqui

A primera vista, el mundo del desarrollo del software agile es brillante, ya que por ahora es tendencia. Pero la realidad es preocupante, porque gran parte de lo que se hace es un agile-falso, sin tener en cuenta los valores y principios de agile. Los tres desafíos principales en los que debemos concentrarnos son: luchar contra el Complejo Agile Industrial y su hábito de imponer procesos a los equipos, aumentar la importancia de la excelencia técnica y organizar nuestros equipos en torno a productos (en lugar de proyectos). A pesar de los problemas, la gran fortaleza de la comunidad es su capacidad para aprender y adaptarse, abordando problemas que los autores del manifiesto original no imaginaron.

¿Cuántas personas me han visto anteriormente hablar aquí en Agile Australia? ¿Y volvieron? Wow, estoy impresionado. Si me han visto hablar antes en Agile Australia, o de hecho en cualquier conferencia, sabes que casi cada vez que doy una charla, lo llamo “Diseño de software en el siglo XXI”, o algo así: porque es una título vago y puedo hablar de lo que quiera. Y lo iba a hacer nuevamente acá, pero decidí hacer algo más específico, hablar sobre dónde está la comunidad agile en el 2018. Decidí no realizar una charla planificada con un montón de diapositivas, diagramas inteligentes y transiciones hermosas -en esta ocasión seré solo yo hablando. Lo he hecho antes, pero ha pasado tiempo, así que veremos cómo nos va.

Cuando observamos el estado de agile: a primera vista, en muchos aspectos las cosas se ven muy bien. Quiero decir, mira el tamaño de esta multitud, por ejemplo. Somos muchísimos, apenas entramos en este gran lugar de conferencias, en realidad no encajamos muy bien ya que está muy repleto. Vas a todo tipo de lugares y ves agile repartido por todo lugar. Alguien me envió una portada del Harvard Business Review con el título “agile”. Quiero decir, está por todo lugar. Esto es un gran cambio desde los últimos 10 años, o incluso más, cuando estábamos en ese lugar para esquiar en Snowbird hablando de cómo demonios deberíamos llamarnos. Esto parece un éxito, pero hablas con muchos agilistas de antaño, personas que ya estaban haciendo esto antes de que se llamará “agile” a finales de los 90, y en realidad hay mucha inquietud, mucha decepción, mucha desdicha en el aire.

En realidad, esto no es algo inusual porque casi siempre ha sido así, según tengo conocimiento. Y eso es realmente algo bueno, porque esa insatisfacción es una señal de querer mejorar. Pero nos da la sensación de: “¿por qué estamos luchando?”

Actualmente ¿Cuál es el desafío que tenemos que enfrentar? Hace 10 años, el desafío era que las personas tomen agile en serio. Recuerdo haber entrado en uno de los grandes clientes de ThoughtWorks en Australia. Me necesitaban para la rutina habitual de “Martin Fowler, ven y danos una charla”. Alguien de los clientes dijo: “Sí, queremos que hables sobre lo que quieras, pero no digas nada sobre esas cosas de agile”. Lo cual era algo alarmante a mediados del 2000 cuando hablaba mucho sobre agile, pero ese era la percepción entonces. La sensación de que esto era algo malo y que no querías hablar de ello.

Ahora agile está en todas partes, es popular, pero ha habido un cambio importante. Esto fue resumido muy bien por mi colega quien dijo: “En los viejos tiempos cuando hablamos de hacer agile, siempre existía este rechazo desde un inicio por parte del cliente, y eso generaría algunas conversaciones importantes. Ahora, ellos dicen: “Oh, sí, ya estamos haciendo agile”, pero entras allí y de repente descubres que hay diferencias muy grandes con respecto a lo que esperábamos estar haciendo. Como ThoughtWorks, nos gusta pensar que estamos muy arraigados en nociones agile y, sin embargo, vamos a una compañía que dice: “Sí, estamos haciendo agile, no hay problema”, y encontramos un mundo muy diferente al que esperamos.

Nuestro desafío en este momento, no es hacer de agile algo que la gente quiera hacer, lidiar con lo que yo llamo agile-falso: donde agile es solo el nombre, pero no está presente las prácticas ni valores. Ron Jeffries a menudo se refiere a esto como “Dark Agile”, o específicamente “Dark Scrum”. En realidad, esto incluso es peor que fingir hacer agile, se está usando activamente el nombre “agile” en contra de los principios básicos de lo que intentábamos hacer, cuando hablamos sobre como hacer este tipo de trabajo a fines de los 90 en Snowbird.

Así que, esa es nuestra batalla actual. No se trata de ser lo suficientemente agile como para que una multitud acuda a una conferencia como esta, es darse cuenta de que gran parte de las cosas que las personas están haciendo y que lo llaman agile, simplemente no lo es. Tenemos que reconocerlo y luchar contra eso porque algunas personas han dicho: “Oh, vamos a ‘post-agile’, tenemos que inventar una nueva palabra” – pero esto no ayuda al problema fundamental. Lo que cuenta son los valores y principios, tenemos que abordarlos y continuarlos  impulsando, incluso podríamos usar la misma etiqueta, pero debemos avisar a las personas lo que realmente significa.

Si ese es el nivel general del problema, ¿cómo nos enfocamos en cosas particulares? Quiero centrarme en tres áreas principales de problemas, que creo que son las que me gustaría destacar. Los que creo que son los más dignos de nuestra atención.

El primero de estos es lo que yo llamaría el Complejo Industrial Agile. Para ser justos, soy parte de eso, ¿verdad?, estoy de pie en el escenario hablando de agile, de hecho, todos somos parte de él, muchos de nosotros somos parte de algún tipo de firma consultora agile, probablemente con el título agile. Pero mucho de lo que se está impulsando, se está haciendo de una manera que, como dije, va realmente en contra de muchos de nuestros preceptos.

De manera particular, una de las cosas centrales que me impresionó mucho de los primeros defensores ágiles se dieron cuenta que las personas están operando mejor cuando eligen la manera de cómo quieren trabajar.

Cuando hablamos del Manifiesto Ágil y presentamos las cuatro declaraciones de valor, en la mayoría de esas declaraciones, no nos importó mucho en qué orden aparecieran. Pero tuvimos una opinión sobre la primera, que es: “Individuos e interacciones sobre procesos y herramientas”. Para mí, eso cristalizó una parte muy importante de lo que trata el pensamiento agile. Si deseas tener éxito en el desarrollo de software, necesitas encontrar buenas personas. Necesitas encontrar buenas personas que trabajen juntas a nivel humano, para que puedan colaborar de manera efectiva. La elección de qué herramientas usan o qué proceso deben seguir es de segundo orden. Pensé que esa era una declaración muy importante que viene de lo que básicamente fue una recopilación de estrategias de proceso. Quiero decir, que todos fuimos personas de procesos hasta cierto punto, pero reconocimos que de lo que estábamos hablando no era tan importante. Lo que importa es que el equipo elija su propio camino.

Pero esto va más allá, ya que el equipo no solo debe elegir el proceso a seguir, sino que debe ser alentado activamente a continuar con su evolución y cambiarlo a medida que avanza. Una de las cosas acerca de cualquier tipo de proceso o método agile es su naturaleza resbaladiza. Cambia semana a semana, mes a mes. Una de las citas que solía mostrar a la gente era “si estás haciendo Programación Extrema de la misma manera que hace un año, ya no estás haciendo Programación Extrema”. Porque si no te haces cargo y modificas las cosas para que se ajusten a tus circunstancias, entonces te estás perdiendo la parte importante. Hay varios rituales y cosas que podemos configurar para hacer que esto funcione, las retrospectivas son claramente una técnica que muchas personas encuentran realmente muy importante. De hecho, creo que Ron Jeffries dijo en broma que el enfoque de agile de Allistair Cockburn era “reunirse en paz y armonía, entregar software cada semana y hacer un retro cada vez que se descubra cómo mejorar”. La retrospectiva es realmente la parte central de la práctica.

Ahora, en realidad no importa si tienes una retrospectiva formal. No importa si tienes cuatro o cinco post-its con tareas en tu tablero de retro, o exactamente cómo haces el retro. Lo que importa es tener conciencia en lo que estamos haciendo y cómo podemos mejorarlo, y esto lo hace el equipo que está haciendo el trabajo, eso es lo central.

Esta es una reacción contra todo lo indicado por Frederick Taylor, separar a las personas de los procesos. ¿Cuántas personas aquí conocen la historia de Frederick Taylor y su enfoque? [algunas personas levantan la mano] ¿Cuántas personas se han cruzado con el nombre de Frederick Taylor o incluso han oído hablar de él? [un poco más]. Muchos más deberían levantar sus manos. Probablemente sea una de las figuras más importantes en la historia del siglo XX en términos de cómo afectó a la vida cotidiana de las personas. Era fines del siglo XIX, en América, y él estaba muy interesado en que las personas fueran más eficientes en los lugares de trabajo industriales que se estaban desarrollando en ese momento. Su opinión sobre el trabajador promedio era que, estos eran perezosos, venales y estúpidos. Por lo tanto, no quería que ellos participen en la decisión de cómo se debía fabricar una máquina en particular, ya que alguien más, alguien que fuera más inteligente y educado, debería descubrir exactamente la mejor manera de hacerlo. Incluso yendo a: hago esto y luego aquello o hago aquello y luego esto. Este es un sentido de movimiento de acuerdo a un guión. Todo el tiempo y movimiento de la industria vienen de aca. En el fondo, esta noción indica que las personas que están realizando el trabajo no deberían decidir cómo hacerlo. Debería ser un grupo separado de planificadores quienes lo hagan, y eso afectó considerablemente a la manufactura y el trabajo en las fábricas durante gran parte del siglo XX.

Ello también afectó a la industria del software, la gente dijo: “necesitamos expertos en procesos de software para descubrir cómo hacer las cosas, y luego los programadores simplemente rellenan los huecos”. Pero curiosamente, al igual que la gente de software hablaba sobre, cómo debemos seguir, esta noción tan taylorista como el futuro del desarrollo de software (escuché a la gente decirlo en los años 80 y 90), el mundo manufacturero se estaba alejando de él. Toda la noción de lo que estaba ocurriendo en muchas fábricas era que las personas que realizaban el trabajo deberían tener mucho más que decir sobre esto porque realmente son ellos quienes ven lo que está sucediendo.

El movimiento agile intentó empujar esto, para tratar de decir: “Los equipos involucrados en hacer el trabajo deben decidir cómo se lo hace”, porque seamos sinceros, estamos hablando de desarrolladores de software. Personas que están bien pagadas, bien educadas, ojalá, personas bien motivadas, por lo que deberían averiguar qué es necesario en cada caso.

El “caso particular” se vuelve importante porque los diferentes tipos de software son diferentes. He vivido la mayor parte de mi vida en aplicaciones empresariales: database- backend, GUI / web frontend. Eso es lo que hace la mayoría de las personas que conozco, pero es muy diferente a diseñar switches telefónicos o diseñar software embebido. Incluso dentro del mundo con el que estoy relativamente familiarizado, los diferentes equipos tienen diferentes tipos de situaciones, diferentes entornos heredados con los cuales coordinar y diferentes dinámicas entre los individuos en un equipo. Con tantas diferencias, ¿cómo podemos decir que hay una única manera en la que va a funcionar para todos? Nosotros no podemos y sin embargo, lo que oigo es al complejo industrial agile imponer métodos a las personas, y para mí es una farsa absoluta.

Iba a decir “tragedia”, pero creo que “farsa” es la mejor palabra porque al final no hay una talla única para el desarrollo de software. Incluso los defensores ágiles no dirían que agile es necesariamente la mejor cosa para usar en todas partes. El punto es que el equipo que hace el trabajo decide cómo hacerlo. Este es el principio agile fundamental. Esto incluso significa que si el equipo no quiere trabajar de una manera agile, entonces agile probablemente no sea apropiado en ese contexto, y [no usar agile] es la forma más agile en la que pueden hacer las cosas en algún tipo de mundo extrañamente retorcido de la lógica.

Ese es el primer problema: el Complejo Industrial Agile y su imposición de la mejor manera de hacer las cosas. Eso es algo contra lo que debemos luchar.

El segundo problema es la falta de reconocimiento de la importancia de la excelencia técnica en lo que hacemos. Muchas de las conferencias agile a las que asisto no suelen hablar mucho sobre las técnicas reales de escribir software. Por cierto ¿Cuántas personas aquí son desarrolladores de software? [algunas personas levantan las manos] Algunos, pero son la minoría. El mismo problema existió durante bastante tiempo en la conferencia principal de Agile Alliance, pero se dieron cuenta que estaban involucrando a muchas personas relacionadas a la gestión de proyectos y cosas de ese tipo, pero no a personas que son técnicas. Personas que realmente hicieron el trabajo. Y eso es en realidad bastante trágico. Esto hizo que algunos desarrolladores de software dijeran algo más trágico: “Oh, necesitamos crear un mundo completamente nuevo solo para nosotros. Un lugar donde pueda ir el movimiento artesano del software, alejado de todos estos expertos en negocio, gerentes de proyectos y analistas de negocios, y solo hablar de nuestras cosas técnicas”. Pero eso es algo terrible, porque el objetivo de agile es combinar estas diferentes áreas. El programador más bajo y más joven que toca el JavaScript debe estar conectado con las personas que están pensando en los problemas de negocios y las estrategias de negocios del grupo.

Voy a decir un poco más sobre esto en mi tercer punto, pero eso significa que tenemos que prestar atención a estas habilidades técnicas, y tenemos que pensar en cómo la nutrimos, cómo crecen, cómo los hacemos importantes? He pasado los últimos dos años teniendo a la escritura como mi principal ejercicio y una nueva edición del libro sobre refactorización. ¿Cuántas personas han oído hablar de refactorización? [Muchas manos] Bien. ¿Cuántos podrían describirlo con precisión? [Menos manos] Bastante menos. Es una técnica central para la forma de pensar agile porque encaja con la forma en que podemos construir software de manera que pueda cambiar fácilmente. Cuando hago un resumen agile para las personas, generalmente digo que hay dos piezas principales. La primera, ya he hablado acerca de la primacía del equipo y su elección de cómo hacer las cosas, pero el otro es nuestra capacidad de cambiar rápidamente, para poder lidiar con el cambio fácilmente.

Siempre me gustó la frase de Mary Poppendieck: “Un cambio tardío en los requisitos es una ventaja competitiva”. Pero para hacer eso, se necesita un software que esté diseñado de manera que pueda reaccionar a ese tipo de cambio. La refactorización es fundamental para esto porque la refactorización es una forma disciplinada de hacer cambios. Es horrible cuando alguien tuitea algo como: “En este momento estoy refactorizando nuestro software, por lo que se romperá en las próximas dos semanas”. Bzzz – eso no es refactorización. La refactorización es pequeños cambios, cada uno de los cuales mantiene todo funcionando. No cambiar el comportamiento observable del software, esa es su definición. Y debería saberlo porque fui yo quien lo definió.

La refactorización es un montón de pequeños cambios, ninguno de los cuales cambia la parte visible del software, pero todos ellos cambian su estructura interna. Por lo general (refactorizas) porque deseas crear una nueva funcionalidad, y la estructura interna actual no se ajusta muy bien a esta. Así que, cambia la estructura para que una nueva funcionalidad pueda encajar fácilmente, refactorizando todo el tiempo y sin romper nada. Kent Beck resume esto. “Cuando quieras hacer un cambio, primero facilita el cambio. (Advertencia, esto puede ser difícil). Luego realiza el cambio de manera fácil”. Esa es la manera crucial de usar la refactorización, pero va más allá de eso porque la refactorización es algo constante. Usted está mirando un código y está tratando de decir: “¿Qué hace esto? Realmente no entiendo lo que hace. Déjeme pensar en esto. Lo vamos a enterrar. Ah, ahora entiendo lo que hace este código”. Luego, antes de continuar, en palabras de Ward Cunningham: “Sacas la comprensión de tu cabeza y lo codificas”: reestructurándolo, renombrándolo. El nombramiento es una parte muy importante en todo esto. Para que la próxima vez que usted o alguien más pase por ese mismo código, no tenga que pasar por el ejercicio de rompecabezas.

¿Por qué es tan importante? Porqué si deseas realizar cambios, quieres adicionar rápidamente cosas, debes comprender rápidamente qué partes del programa son importantes, qué hacen y cómo trabajan para que puedas realizar ese cambio lo mas antes posible. Esto también tiene raíces en la modularidad. Si tengo un software bien modularizado, en lugar de entender todo, solo es necesario entender una parte. La excelencia técnica consiste en poder construir ese tipo de software adaptativo.

Entonces aparece el principio de auto-refuerzo. Una vez que te das cuenta de que puedo cambiar el software rápidamente para agregar cosas nuevas, no trato de que el software haga todo lo que quiero que haga desde el principio. Porque no lo necesito. Ya que podré cambiar las cosas más adelante. Este es el principio de Yagni: “No lo vas a necesitar”. No agregue funcionalidades al software hasta que las necesite, ya que si lo hace, aumenta su volumen y hace que sea más difícil de entender. Pero esa estrategia es totalmente desesperada si no se tienen buenas técnicas de refactorización. La refactorización se basa en la integración continua y las pruebas, y junto con la integración continua, tenemos la práctica de la entrega continua y la idea de que podremos liberar software con mucha frecuencia. En algunas organizaciones, se libera software realmente de manera muy frecuentemente.

Ahora, por ahí existe una noción que dice que el lanzamiento rápido de software solo puede hacerse si se está preparado para soportar muchos y muchos errores. Y si quiere que el software sea confiable, se hace las cosas de una manera mucho más lenta y prudente. Incorrecto. Y estamos viendo cada vez más pruebas de que esto está muy, muy mal. Mi libro favorito del año, hasta ahora y creo que va a ser el mejor libro del año es “Accelerate” de Nicole Forsgren, Jez Humble y Gene Kim. (Y lo digo con gran tristeza porque mi libro saldrá este año, pero espero ser el número dos). En este libro, a través de muchas encuestas a organizaciones, se muestra cómo las diferentes prácticas afectan las cosas. Una de las cosas que demuestra, es que, muchas entregas al día y las tasas bajas de defectos van juntas. Porque no puede liberar muchas veces al día a menos que se descubra cómo reducir sus tasas de defectos. Eso requiere los tipos de prácticas de las que hablamos: pruebas automatizadas, refactorización, yagni: todo esto fluye en conjunto. Lo más importante de la programación extrema es que sus prácticas individuales se refuerzan mutuamente.

Lo tercero que quiero enfatizar es la importancia de deshacerse de los proyectos de software como una noción. En su lugar, queremos cambiar a una vista del mundo “orientada a los productos”, donde, en lugar de los proyectos que ejecutas por un tiempo y luego lo detienes; ahora en su lugar, decimos: “Centrémonos en cosas que son mucho más duraderas y en torno a eso organizamos un equipo de productos”. Otra forma de pensar al respecto es: cuáles son las capacidades empresariales que tiene su organización y luego organizar los equipos en torno a ellas. Estas capacidades de negocios serán duraderas y necesariamente significarán la combinación de personas técnicas y de personas de negocios en el mismo equipo.

Actualmente, una idea popular es el “equipo de dos pizzas” de Amazon: la gente habla de esto todo el tiempo: “Organícense en equipos de dos pizzas”. Tal vez como una pequeña broma sobre cuán grandes son las pizzas americanas, así que pueden ser equipos más grandes de lo que piensas. Pero cuando dan esa descripción, a menudo omiten algo que está claro cada vez que escucho a la gente de Amazon hablar de esto; que es lo que cada uno de esos equipos necesita para conectarse, de forma directa al cliente. Cada equipo está enfocado en algún aspecto de la experiencia del cliente, algún aspecto de lo que Kathy Sierra llama “haciendo que el cliente patee el trasero en lo que ellos hacen”. Esto altera nuestra idea de lo que hace ese pequeño equipo porque si ese pequeño equipo se enfoca en alguna parte de la experiencia del cliente, alguna forma de hacer que el cliente haga lo que hace mejor, entonces eso nos dice cómo debemos trazar líneas entre nuestros pequeños equipos. Ahora bien, no siempre es fácil hacer esto, pero debería ser, creo, la noción de conducción.

Pero de nuevo, a menudo lo vemos violado. Fui a una organización supuestamente agile. Estaba charlando con un equipo de desarrollo. Había alrededor de media docena de programadores. Solo había cuatro usuarios del software a los que estaban escribiendo, planificadores senior en la planificación minorista. Seis desarrolladores, cuatro usuarios. Nunca se habían hablado entre ellos. No se les permitió. En su lugar, había un Scrum Product Owner que gestionaba la conversación entre ellos. Bueno, en realidad, hubo cuatro dueños de productos en el transcurso de un año. Quiero decir, ¿qué pesadilla del mundo Agile es donde pueden atreverse a usar la palabra “agile” para describirlo? Cuando [en Snowbird] estábamos hablando de nombres para el desarrollo agile de software, Kent Beck sugirió “conversacional”, porque debería haber una conversación continua entre los desarrolladores de software, la gente de negocios y cualquier persona involucrada para mejorar la experiencia del cliente.

Si estuviera en ese equipo como desarrollador, me gustaría estar en términos de primera persona con todos los usuarios. Me gustaría estar hablando. Me gustaría ver lo que hacen, entender cómo piensan hacer más felices a sus clientes y ver todo el flujo. Así que tenemos que pensar en eso. Ese es mi tercer desafío.

Así que mis tres cosas, que debemos enfrentar como retos:

  • Deshacerse del Complejo Industrial Agile y la idea de imponer cosas en los equipos. Deje que los equipos trabajen de la manera en cómo deberían trabajar por ellos mismos.
  • Aumente la importancia de la excelencia técnica y nunca olvide que al escribir software, el lado de la tecnología es realmente vital y
  • Realice su organización en torno a productos.

Así que todo suena un poco negativo porque he hablado de los problemas del estado actual de agile. Me quedan dos minutos y 45 segundos para ofrecer una razón por la cual no estoy tan deprimido por la situación. Probablemente viene de mi cosa favorita del Manifiesto Ágil. Esto no ocurrió en Snowbird cuando lo escribimos, pero ocurrió aproximadamente seis meses después en Tampa, Florida, en OOPSLA, donde la mayoría de las personas que escribieron el manifiesto estaban juntas con otro grupo de personas interesadas. En este punto, el Manifiesto Ágil había despegado de una manera que nunca podríamos haber imaginado. De repente, quedó claro que había una gran oportunidad para hacer cosas interesantes, y muchas personas dijeron: “Necesitamos establecer una organización real aquí”.

Una de las preguntas fue: “¿Deberían las 17 personas originales que escribieron el manifiesto ocupar un lugar especial en este esfuerzo continuo?” De lo que estoy orgulloso, que hicimos los 17 autores, es que dijimos “no”. Escribimos el manifiesto. Hicimos un buen trabajo, seremos parte de lo que suceda en el futuro, pero no tenemos un papel especial en ese futuro. Ese papel tiene que crecer hacia adelante. Dijimos que “nuevas personas vendrán y harán grandes cosas”, que es precisamente lo que sucedió.

Una de las formas en que esto fue importante se refiere al gran problema con las personas que escribieron el manifiesto, particularmente mirándolo ahora con lentes del 2018. 17 personas: 17 chicos blancos de mediana edad. No hay un hilo de diversidad allí, pero como lo dejamos ir, el mundo agile podría incorporar a muchas personas de todo tipo de antecedentes que participaron. Mary Poppendieck fue una de las grandes líderes de los primeros esfuerzos de alianza agile. Rebecca Parsons, mi jefa en ThoughtWorks, fue la presidenta de la alianza agile durante mucho tiempo. He asistido a conferencias agile y tiendo a ver muchas más mujeres que en otros tipos de conferencias de software. Eso es bueno. Ciertamente, no fue nuestro trabajo al principio. Ni siquiera estábamos pensando en eso. Pero el punto era: porque lo dejamos ir, terminamos con una comunidad que podría desarrollar cosas por sí mismos. Eso podría abordar desafíos que ni siquiera habíamos imaginado y trabajar en ellos. Y es el aprendizaje constante, el crecimiento y el cambio como comunidad, que es nuestra mayor fortaleza.

No hablé hace mucho tiempo con alguien que llega tarde al mundo agile, quien dijo que encontraron un grado de acogida y franqueza que no era auténtico en muchos otros grupos. Eso me hizo muy, muy feliz, porque mientras podamos ser tan flexibles, mientras podamos cambiar los desafíos que enfrentemos, creo que tenemos un futuro. Gracias.


Leave a Reply

Your email address will not be published. Required fields are marked *