Durante los últimos años, he podido conocer, compartir o aprender de algunos de los padres de la Agilidad y de algunos de los representantes más virtuosos de la comunidad Ágil. Lo que he encontrado en común con las ideas de todos ellos es la simplicidad.
Hoy nos encontramos en un mundo saturado de autores y organizaciones interesadas en vender sus métodos, entrenamientos y certificaciones; y de empresas que intentan crear sus propios métodos para entrar en la onda ágil, pero conservando el control y jerarquía, apoyándose en que están experimentando o que a otras empresas les ha funcionado.
Yo no me excluyo de este grupo: he trabajado bajo la premisa de «el cliente es quien paga, y si esto es lo que desean hacer, yo solo les diré que está mal y seguiré por el camino que me dicten». Y así, complicando las cosas, dejando al lado un buen backlog o las Historias de Usuario para poder estar trabajando para la herramienta que la empresa utiliza, cambiando el Scrum diario por largas reuniones de seguimiento/control de avance, comprometiendo entregas a 4 o 6 meses, definiendo un backlog inmutable para todo un «proyecto», y otro sinnúmero de malas prácticas que me han complicado la vida y no me han dejado generar todo el valor que sé que hubiera podido entregar. Y todo por evitar la simplicidad.
«Agile in a sentence: reduce the gap in time between an action and getting feedback».
«Ágil en una frase: reducir la brecha de tiempo entre una acción y recibir la retroalimentación».
Jon Kern
Cuando pude hablar con Jon Kern [@JonKernPA], co-autor del Manifiesto Ágil por el desarrollo de Software, le hice una pregunta: «¿cómo podemos negociar con los clientes para que nos permitan tener pruebas unitarias dentro del proceso de desarrollo?». Yo, dentro de mi caos mental, tras haber pasado muchas horas intentando convencer a varios de los clientes, en muchos de los proyectos en los que he participado, esperaba una fórmula mágica, tan compleja, tan infalible, que pudiera convencer al más duro de los clientes. Pero su respuesta, al contrario de mis expectativas, fue simple y contundente: los desarrolladores no tenemos por qué pedir autorización de hacer bien nuestro trabajo pues nuestra obligación es entregar software de la mejor calidad.
“La Agilidad se ha vuelto excesivamente decorada. Rasguemos las decoraciones por un minuto, y retornemos al centro de la agilidad”.
Alistair Cockburn
Alistair Cockburn [@TotherAlistair], creador de El Corazón de la Agilidad y co-autor del Manifiesto Ágil por el desarrollo de Software, también mantiene la simplicidad en su discurso. El año pasado, tras una charla sobre El Corazón de la Agilidad, pude conversar un poco sobre las desviaciones que vemos día a día con respecto a la agilidad, aquellas en las que yo mismo he incurrido, y nuevamente encontré que su discurso es sencillo y su opinión vuelve a lo básico. Para hacer las cosas bien, la agilidad nos da las herramientas del Manifiesto Ágil y el Corazón de la Agilidad, ambos concentrándose en hacer pequeñas cosas, colaborar con el equipo, con el cliente, y con todos los actores de nuestros procesos, y en períodos cortos reflexionar sobre la manera en que podríamos mejorar y, finalmente, experimentar buscando ser cada vez mejores técnicamente, personalmente y como equipo.
«It is not the language that makes programs appear simple. It is the programmer that make the language appear simple».
«No es el lenguaje el que hace que los programas luzcan sencillos. Es el programador el que hace que el lenguaje luzca sencillo».
Robert C (uncle Bob) Martin
Dentro de mi formación técnica, me he encontrado en algunos cursos a distancia con Robert C Martin (Uncle Bob) [@UncleBobMartin], autor del libro Código limpio [Clean code] (y de otros libros), promotor de los principios SOLID en la programación orientada a objetos, co-autor del Manifiesto Ágil por el desarrollo de Software, y nuevamente encuentro el mismo patrón de ideas: generemos pequeñas piezas de software, limpias, bien documentadas, con la calidad inmersa, fáciles de leer y de comprender, y así no desperdiciamos tiempo desarrollando funcionalidades que no serán usadas, programas que no serán comprendidos, o que tendrán más posibilidad de fallar.
«Es en serio, las historias de usuario tienen que ser pequeñas».
Jorge Abad – Lucho salazar
Jorge Abad [@jorge_abad] y Lucho Salazar [@LuchoSalazarC], autores del libro Historias de usuario: Una visión pragmática, con quienes he podido compartir varias discusiones sobre la Agilidad, coinciden en que hacer Historias de Usuario sencillas, pequeñas, y basadas en la comunicación constante, es una fórmula ganadora para asegurar el mejor resultado dentro de los Sprints de desarrollo de productos (no solo de software, sino de cualquier negocio). Y seguimos dentro de la misma línea: la simplicidad en los pedidos, y no complicarnos con extensos documentos difíciles de leer, comprender y desarrollar.
«Scrum is: lightweight, simple to understand, difficult to master»
«Scrum es: liviano, fácil de entender, difícil de dominar»
Ken Schwaber – Jeff Sutherland
Ken Schwaber [@KSchwaber] y Jeff Sutherland [@JeffSutherland], autores de La guía de Scrum, co-autores del Manifiesto Ágil por el desarrollo de Software, explican completamente el marco de trabajo de Scrum en solo 19 páginas de su guía (22 páginas en la traducción oficial al español). Algunos manuales de Scrum de otros autores, ¡superan las 300 páginas! Scrum es una metodología sencilla y muy poderosa, a menos que la compliquemos dando una interpretación compleja y alejada de lo que nos sugiere la guía.
Podría continuar mencionando autores y referentes, todos coincidiendo en la simplicidad en sus ideas y discursos: Pablo Mejía con su Minimísimo Producto Viable, Marcelo Luján con sus consejos de calidad del código y buenos tratos interpersonales, Nadia Zapata, Augusto Miní, Luis Mulato, Nicolás Paez, Martin Alaimo, y tantos otros que me han aportado durante estos años. Todos ellos, todos los que me han marcado, tienen en común la misma idea: ¡Ágil es simple!
