Lo que me gustaría que hubiéramos hecho...

A veces te encuentras con un post que crees que es realmente revolucionario. Eso me ocurrió cuando leí el artículo What I wish we had done … por primera vez.

Tanto me llamó la atención que no tardé ni 5 minutos en enviarle un email al mismo Ron Jeffries para pedirle permiso para traducirlo aquí, en mi blog. Me lo dio en menos de tres horas.

Espero que lo saboreéis tanto como yo. Espero haber sido fiel en la traducción.

Como siempre que hago esto, por favor, comentad sólo sobre la traducción. Los comentarios sobre el contenido del artículo deberían estar con el artículo original.

ATENCIÓN: Por lo visto no todo el mundo entendió el artículo original como yo, y Ron Jeffries, su autor original, lo ha modificado para evitar equívocos. En cuanto pueda traduciré de nuevo los cambios o borraré esta traducción, dependiendo de si soy de los que lo entendieron correctamente.

Como fiel lector, probablemente sea consciente de que creo que la palabra “Agile” debería significar “coherente con el Manifiesto Ágil”. Y, claro está, no significa eso en absoluto. En su lugar significa lo que quiera que las palabras del usuario signifiquen en ese momento. Ah, bien, la vida es dura, entonces mueres. Rápido, espero, pero no pronto. Pero estoy divagando…

Un importante colaborador a la confusión es la proliferación de marcas o métodos con nombre propio y frameworks. En el momento del Manifiesto, si no recuerdo mal, estaban Scrum, XP y DSDM. Pero al poco tiempo desde entonces, Jim Highsmith apareció con el Desarrollo de Software Adaptativo, Alistair Cockburn ideó su familia Crystal, Mike Beedle comenzó una serie de nombres como XP@Scrum. Y muchos otros.

Cuanto más popular “Ágil” se volvía, más métodos con nombre propio y frameworks teníamos. Ahora tenemos muchos más: DAD, SAFe, LeSS, FAST, y muchos más. Para una lista más completa, vean este artículo. La idea es que hay muchos.

Entonces tenemos una ingente cantidad de empresas llamando Ágil a esto y Ágil lo otro. ¡Buah!

Brian Marick sugirió en una ocasión que, en lugar de “Ágil”, deberíamos haberlo llamado Cronosynclasico Infundibulum o algo así. No, espere, era Retro-futurismo artesanal con Anarco-sindicalismo a Escala de Equipo. Parte de la idea era que el nombre pareciera tan indeseable que la gente no qusiera hondear esa bandera, y quizá se hubiera dado más atención a las valiosas ideas en lugar de la marca.

Todos estos barcos ya han zarpado, claro. Adiós, barquitos.

De todas las palabras tristes orales o escritas, las más tristes son éstas: “¡Podría haber sido!”

John Greenleaf Whittier

Bueno, no me está permitido volver atrás en mi propia línea temporal, por suerte, pero a veces reflejar lo que podría haber sido puede ayudarnos con lo que aún puede ser. Y en esto es en lo que pensaba cuando comencé este artículo:

¿Y si, en lugar de Valores y Principios, hubiéramos incluído Prácticas? ¿Y si además, en lugar de crear nombres y negocios alrededor de “Ágil”, nos hubiéramos centrado todos en descubrir, apoyar y promover las prácticas que más nos gustan y con las que mejor podemos ayudar?

Me parece que algo bueno podría haber salido de eso. Quizá aún pueda.

Cuando instruyo un equipo, o cuando en el transcurso de una experiencia de training¹, llegan las preguntas, creo en las fuerzas actuando sobre un equipo, y me refiero a cosas que ellos podrían intentar para balancear mejor las fuerzas.

A veces, las respuestas parecen claras pero de alguna forma se tienen que calcular. Quizá el equipo tenga una organización separada de pruebas. Quizá estén construyendo una lista de defectos cada vez más larga, o quizá tienen problemas para programar sus iteraciones porque no saben cuántos defectos de alta prioridad tendrán que arreglar esta vez. Algunos necesitan resolver la ecuación y obtener que si se mandan menos defectos a la gente que prueba, tendremos menos defectos que arreglar, y nos resultará más fácil saber cuánto trabajo llevar a cabo.

Entonces nos toca hablar de cómo eso nos retrasará porque, no sé, quizá hasta deberíamos probar nuestro código. Entonces tendríamos que observar que estamos gastando el 45% de nuestro tiempo arreglando errores y que seguramente podría requir menos tiempo prevenirlos que arreglarlos, además de ser menos vergonzoso. Entonces y sólo entonces, encontraremos tiempo para comprender cómo probar nuestro código de forma que no sea desagradable. Lo que nos lleva a TDD, y entonces a ATDD, ambos casi divertidos y en cierto modo poco dolorosos.

La mayoría de las soluciones a los problemas de un equipo probablemente ya se conozcan. Seguramente, hay detalles y matices que habrá que descubrir. Seguramente, hay cosas que se tendrán que aprender. Pero hay que empezar buscando qué ocurre y darse cuenta de que se puede hacer mejor. Quizá se necesite “permiso” para hacerlo mejor. Nada explica “permiso” mejor que tener un caro pero extrañamente fascinante Autor del Manifiesto Ágil sentado contigo ayudando a que te des cuenta de cómo mejorar tu vida (por decir algo).

Lo que quiero decir es que no temenos que decir “Ágil” o nombrar el nombre de mi método - ¿han notado que yo ni siquiera tengo uno? - para poder ayudar a esta gente, y para tener un poco de trabajo de vez en cuando. Cuando un equipo obtiene ayuda y comienza a obtener resultados, a menudo me vuelven a llamar para ayudar a otro equipo, y se extiende boca a boca y me llaman a visitar otras empresas. A veces me llaman de empresas de tercera generación, donde la gente ha cambiado de trabajo desde un lugar al que visité.

No tengo intención de promocionarme a mí mismo con todo esto – aunque no haya problema que que me contacten. Se trata de puntualizar que basta con ser reconocido como alguien útil, y quizá ser útil en un contexto “Ágil” o “Scrum”, para encontrarse con mucho trabajo por hacer, y ser capaz de ayudar a montones de personas.

Ahora hay algunos paquetes de prácticas en los que soy indudablemente experto y soy feliz de llevarlos allá donde se necesiten. Y si alguien me pidiera que le ayudara a aplicar TDD a su JavaScript, le recomendaría a algún otro, quizá James Shore, que sabe de eso más de lo que yo sabré jamás. ¿Trabajando con empotrados? Sugeriría James Grenning, o Nancy Van Schooenderwoert, porque son expertos en ese área. ¿Preocupaciones en las relaciones humano-a-humano? Quizá Esther Derby o Diana Larsen. Y así. Conozco montones de personas y por eso no tengo que saberlo todo.

La verdad es que todo el que está por ahí, toda empresa que está por ahí, vendiendo “Soluciones Ágiles” o como quiera que las llamen, es en realidad experto sólo en un pequeño conjunto de prácticas útiles de las que se necesitan para que un equipo crezca, mejore y finalmente destaque.

¿Y si los Autores del Manifiesto se hubieran centrado en descubrir, respaldar y fomentar ciertas prácticas específicas? Pero en lugar de personas, comenzando por los Autores, se crearon Empresas separadas, ofreciendo su charlatanería como soluciones completas. Esas empresas se ven a sí mismas compitiendo con las otras, y avivan las llamas para que sus pobres clientes se engañen creyendo que deben elegir entre una u otra. ¿Por qué necesitamos elegir ésta o aquélla²? ¿Por qué no elegir ambas? ¿Por qué no elegir todas esas cosas que nos ayudarán?

¿Y si tú y yo, todos los que trabajamos con estas ideas, comenzáramos ahora? ¿Y si nos diéramos cuenta todos nosotros, de una vez, que la S mayúscula de Scrum, la K mayúscula de Kanban, la A mayúscula de Ágil, son puntos de comienzo rudimentarios para una larga jornada, y que el aprendizaje real comienza una vez que se empiezan a hacer estas cosas rudimentarias y se presta atención a lo que ocurre luego?

¿Quizá fuéramos capaces de cambiar la corriente contra el Gran Agilismo, o Ágil Sólo En El Nombre? ¿Quizá terminaríamos las guerras inútiles entre Scrum y Kanban, o SAFe y LeSS? No, probablemente no. Pero apuesto a que podríamos ayudar a mucha gente por el camino.

• Artículo original: What I wish we had done ….

• Copyright del artículo original: Copyright © 1998-2015 Ronald E Jeffries.

• Copyright de la traducción al castellano: Miguel Ángel García.

• Translated with permission from Ron Jeffries // Traducido con permiso de Ron Jeffries.