Qué es ser un desarrollador agile

Antes de nada quiero dejar claro que no hablo desde el conocimiento acreditado de la materia, hablo principalmente desde la experiencia de pasar a metodologías agile y ver cómo se ha experimentado el cambio a mi alrededor. El fin de hacerlo es dar un punto de partida al debate o al menos a la reflexión individual sobre qué implica esa forma de trabajar en lo que respecta a los desarrolladores. No cambia nuestro nombre, seguimos siendo equipo de desarrollo, pero ¿hemos pensado si cambian nuestras funciones?

En una metodología tradicional en cascada (bien entendida, no en la que se quiere todo para ayer y nadie hace una mínima reflexión) el proyecto pasa por una fase de análisis en la que hay distintas "cabezas pensantes". Generalmente, si se trata de un proyecto o empresa de cierta envergadura, el equipo estará jerarquizado y en esta fase intervendrá el jefe de proyecto, junto con un arquitecto técnico y quizá alguien del equipo de calidad o de UX o similares. Todos estos generalmente no serán luego parte activa del equipo sino que habrán generado toda una documentación, infrastructura y bases y se encargarán de dirigir o revisar los aspectos propios de cada área. ¿Que le queda al equipo de desarrollo? Picar código. ¿Que se espera de ellos? Que lo piquen.

Quiza he simplificado mucho. En esto, como en casi todo, hay mil matices, formas y circunstancias. Pero, en general, de un equipo de desarrollo tradicional, lo que se espera es que construya el producto tal cual se pensó en el tiempo que se estimó. Para ello el jefe de equipo se encargará de controlar y organizar, adquiriendo la responsabilidad última del proyecto y llevandose los palos o los aplausos segun vaya la cosa. Por otro lado cada desarrollador se responsabilizará de la parte de la aplicación que le toque trabajar.

En agile (bien entendido también, no como un simple faseo del proyecto en N proyectos cascada) las jerarquías se difuminan. El proyecto se divide en "pequeños cachitos" que no habrán pasado por esa gran fase de análisis. En el momento de planificarlos se analizarán entre todos y la idea es que todos aporten para sacar la solución más adecuada. Esto implica el primer cambio en los desarrolladores porque, para que su intervención sea real y productiva necesitan:
1. Conocimiento tanto funcional como técnico de todos los ámbitos del desarrollo para, poco a poco, ser capaces de aportar más y mejor y detectar antes las dificultades o impedimentos.
2. Habilidades sociales y capacidad dialéctica para proponer y exponer de manera clara tanto a personas del ámbito técnico como no técnico.
3. Capacidad de escucha activa, de dialogo, asertividad y empatía para que, en conjunto se lleguen a soluciones válidas y a acuerdos sobre cómo llevarlas adelante.

Evidentemente al inicio no tendrá la misma aportación un junior que un senior o una persona que lleva años trabajando aplicación que alguien que acaba de llegar. Hay que limar esas diferencias, ahora bien: ¿queremos? ¿Queremos conocer los entresijos de la facturación para hacer la aplicacion de gestión si nosotros somos seniors que estamos investigando la tecnología molona que vamos a emplear? ¿nos apetece escuchar la opinión del nuevo sobre otra librería para hacer la descarga de ficheros distinta de la que nosotros dominamos? Como junior, a mi que me digan qué tengo que hacer, que no cobro para responsabilizarme de tanto.

Ese es otro punto clave: la responsabilidad. Y es que si todos hemos aportado para dar esa solucion, la hemos estimado, la hemos analizado y nos comprometemos con ella, entonces todos somos los responsables de lo bien o lo mal que vaya, ¿no?

Cuando todo va bien, esto gusta: no hay uno llevandose las alabanzas como jefe mientras que otros son los que se han pegado con ello. Si a alguien le surge alguna dificultad no es "su" problema, es de todos y es responsabilidad de todos que salga adelante. Se tiene un equipo de verdad, en el que, como en los equipos de futbol o baloncesto, cada jugador desde sus direfencias aporta al conjunto y se siente parte de él. O todos ganan o todos pierden.

Sin embargo ¿que pasa cuando vienen mal dadas? Entonces esa responsabilidad no apetece tanto y era mejor cuando el jefe de proyecto "aislaba" los problemas o al menos volcaba el problema en el responsable de esa parte. "¡Si yo de ese tema no toqué nada!", "Yo ya dije en la planificación que eso llevaba más tiempo", "Lo tenía que haber hecho yo que me conozco mejor esa parte", "Yo hice lo que me dijisteis" y otras tantas frases empiezan a surgir. Todo son "balones fuera" y dedos acusatorios. O lo que seguramente es peor: silencios. Porque la palabra revela cosas pero el silencio vale sólo por lo que oculta. Y lo que oculta es que nos falta la característica principal del equipo: CONFIANZA. Confiar en que los compañeros son profesionales, en su compromiso, en que las criticas son constructivas y hacia el equipo y no personales y con intencion de "dejar mal". Confiar en que se puede hacer mejor entre todos. Confiar en que todos tienen algo que aportarme y quieren hacerlo. Confiar en que nosotros tenemos algo que aportar y podemos hacerlo.

Seguro que me dejo más cualidades importantes, pero como decía, esto es solo un punto de partida a la reflexión. Ahora es el turno de que, quien quiera, se mire su ombligo y el de su equipo. ¿Sois agile? ¿Creeis que se valoran estas características en vuestro equipo? ¿Echáis algo en falta?