La verdadera cara del "Agile"

Llevamos años hablando de agilidad, de transformación digital, de scrum, de dailies y muchos nos empezamos a preguntar si la moda ya ha pasado y podemos empezar la deconstrucción.

Un compañero escribió sobre esto hace unos días. El manifiesto es algo que creo que todos los que trabajan con esta metodología deberían leer y reflexionar, pero yo quiero hablar de la propia palabra, desde el sentido común.

AGILIDAD

Esta no es la típica palabra que todos usamos pero no sabemos muy bien que significa. Esta palabra la conocemos todos y de reflexionar sobre ella saldrán los principios solos. En muchas ocasiones me encuentro con empresas que dicen ser ágiles pero luego parecen más encorsetadas que las fabricas de los años 50.

Os voy a proponer situaciones:

Un proyecto empieza a crecer y el ordenador de uno de nuestros empleados se queda corto, el entorno de desarrollo se le bloquea cada dos por tres... La solución parece clara, habrá que comprar otro ordenador a este empleado ya que su rendimiento esta bajando ¿Cuanto tardamos en conseguir un nuevo ordenador? ¿Y si el departamento no tiene presupuesto en ese momento? Total, días y días de bajo rendimiento, esto no parece que sea muy ágil ¿no? Como dice Tom DeMarco en su libro Peopleware: Productive Projects and Teams "The manager's function is not to make people work, but to make it possible for people to work."

Cuando vamos a realizar un deporte primero calentamos, nos cansamos un poco antes porque si no lo hacemos podremos tener problemas cuando exijamos gran rendimiento. Lo mismo pasa en nuestros proyectos. Ahora hablo de los test, quien diga que no programa más lento haciendo test miente, pero es el calentamiento, es el precio que pagamos para que luego no rompamos como cuando hacemos deporte. Es decir, a la larga iremos más rápido que si no los hubiéramos hecho, hasta el punto de que podríamos estancarnos y lo mejor de Agile era entrega constante de valor, si nos atascamos.... No parece muy ágil ¿No?

Continuando con la anterior, independientemente del si dedicamos tiempo al testing ¿Se lo destinamos al refactor? ¿O decimos lo de "cuando tengamos tiempo refactorizamos"? El refactor tiene que ser algo constante porque constantemente creamos deuda técnica o la heredamos, como los buenos estudiantes debemos ser constantes y dedicar siempre un poco de tiempo a limpiar. No hacerlo conllevara irremediablemente a la situación anterior.

Un empleado tarda unos 6 meses en empezar a ser productivo y por increíble que parezca creo que nadie hace un estudio de cuanto dinero supone eso. Y digo esto porque casi nunca he visto que se trabaje en la retención de talento, creo que si las empresas destinaran... yo que se, un cuarto de los recursos que gastan en contratar nuevo talento, el ahorro a largo plazo sería brutal. Pensad no solo en esos 6 meses que estamos pagando una nomina de alguien que no es demasiado productivo si no en que durante esos 6 meses hemos perdido un montón de valor entregado. No parece muy ágil ¿No?

Volvemos a continuar con la anterior ¿Cuánto esfuerzo realizamos en no depender al 100% de cada empleado? si los conocimientos se traspasaran entre empleados no seria tan dramático que un empleado se fuera de la empresa.

Aun hay más ¿Cuánto esfuerzo realizamos para que nuestra empresa sea más atractiva a los trabajadores? -¡Espera! ¿Trabajadores, no quieres decir clientes?- No me cabe ninguna duda del esfuerzo invertido en los clientes, pero estamos en un sector donde la demanda supera a la oferta y la escasez de trabajadores es un verdadero reto.

Juntando las tres anteriores, hay muchas formas de mejorarlo y mucho mas baratas que subir los sueldos al infinito. Jornada intensiva, teletrabajo, participar en la comunidad, preocuparte por tus empleados ¿Qué quieren? ¿Cuales son sus objetivos? ¿Que no les gusta? ¿Como se sienten?

El otro día hablamos unos compañeros de las sillas de la oficina. Algunos ya sufrimos achaques por estar tanto tiempo sentados y tarde o temprano todos los sufrirán ¿Es una inversión tan grande evitar una baja?

Esto podría ser infinito así que haré una última reflexión y tal vez continúe en otras publicaciones ¿Prefieres formar un empleado y que se vaya o no formarlo y que se quede? Estamos en el sector que más evoluciona de todos, no nos podemos permitir evitar formar a nuestros empleados, debe ser una prioridad si realmente queremos aportar cada vez más y mejor valor y ser cada vez mas ágiles.

Agile va de cosas como estas, no de hacer una reunión diaria y otra cada dos semanas. De eso también va, eso también nos aportará agilidad, pero no debemos creérnoslo. Debemos reflexionar sobre ello "Individuos e interacciones sobre procesos y herramientas" las dailies, los sprints, scrum... Son procesos y herramientas, son un medio, no un fin.