Damos por sentado que todos los equipos de desarrollo van a querer ser Agile. Muchos de los Agile Coaches que pregonamos la bondad del desarrollo ágil de software venimos de programar y para nosotros nos cuadra hacerlo bajo el paraguas Agile. Sin embargo, vemos a muchos desarrolladores que reniegan de este tipo de prácticas por diferentes motivos que me gustaría analizar.
El equipo perfecto
He tenido la suerte de acompañar a un equipo de una consultora que promueve el desarrollo ágil. De hecho, firmantes del manifiesto por el desarrollo ágil de software son creadores de la empresa.
El modelo que esta empresa propone no se basa ni en Scrum ni en Kanban, sino que trabajan bajo su propio modelo de trabajo más orientado a XP. Realizan prácticas como TDD/BDD, realizan pair programming y todas las personas son responsables del desarrollo (incluido las pruebas, documentación u otra actividad que se considere para completar el trabajo). Además, siguen ciclos iterativos incrementales dónde son capaces de entregar software terminado qué aporta valor al cliente y les permita validar las hipótesis que se hubieran planteado.
Además de todo esto, realizan diferentes eventos como Retrospectiva o Daily para poder inspeccionar y adaptar su trabajo. De Kanban, utilizan la visualización y la limitación del trabajo en progreso para evitar abrir demasiadas tareas a la vez que les hicieran perder foco.
De hecho, no disponen del rol del Scrum Master sino que hacen una mezcla entre facilitador y analista funcional. Desde mi punto de vista, es de los equipos de desarrollo que he visto más motivados y más contentos por realizar su trabajo. De hecho, el producto que construían seguramente para otro equipo sería muy aburrido, sin embargo ellos fueron capaces de proponerle al cliente un reto en el cual construir un producto que realmente aportara valor.
Tras mi paso por varias consultoras había perdido la esperanza de ver equipos ágiles en un contexto cliente-proveedor, pero parece que es posible. ¿Por qué en el resto del sitio veo equipos que reniegan de Agile? Os cuento las causas que he podido estudiar.
Las expectativas no están cubiertas
El primer gran problema de Agile para un desarrollador es que sigue habiendo mucho postureo dentro de las empresas. Me comentaba el responsable de la unidad Digital de una importante consultora que, hoy día, tienes que poner en todas las ofertas que eres Agile, pero que son conscientes de que casi nadie lo hace.
Y seamos sinceros, al haber muchos Scrums, y muchas maneras de reinventarlo, acabamos por tener desarrolladores que se les marea con retrospectivas chorras o ejercicios absurdos que les quitan tiempo.
Recordemos que un principio de la agilidad es la atención a la excelencia, para poder ser sostenible a largo plazo. Si corremos haciendo “chapuzas” para adaptarnos a lo que nos pide un cliente, a la larga lo pagaremos caro por generar deuda técnica que tarde o temprano habrá que pagar. Hoy en día, la calidad se valora poco en las empresas, que se focaliza el éxito en la entrega en fecha, sobre todo en consultoría. Un buen desarrollador quiere hacer las cosas bien.
“La culpa es de los desarrolladores”
El desarrollo software sigue sin verse como una ventaja competitiva entre una empresa y su competencia. En España al menos, la mayoría de empresas ven el software como un “mal necesario” sobre el que tienen que construir web y app, pero no son capaces de utilizar el software como una arma contra la competencia. El software para las empresas más importantes está subcontratado a consultoras, y pocas tienen un verdadero ejército de talento que les permita construir productos que les diferencien.
Vemos como los equipos IT se separan de negocio, ya que se considera menos importante. Esto hace que muchos desarrolladores se frustren, ya que, detectan oportunidades que se podrían dar en sus empresas pero no se sienten escuchados.
Por ejemplo, trabajando con un equipo, el cliente les pidió una entrega “imposible” para una fecha cerrada. El comercial aceptó, y el equipo tuvo que echar muchas horas extras para tratar de llegar “como fuera”. El comercial, veía el contrato como un éxito, al facturar las horas extras, el beneficio era mayor. Para el equipo, fue una experiencia que no querían repetir, mucha tensión, desarrollo mal hecho por correr entres otras cosas.
Este tipo de situaciones aparecen más con Agile, porque se vende una imagen de “cambios gratis”. Esto hace que los clientes asumen que nos pueden pedir cualquier cosa en cualquier momento. Esto genera mayor frustración, muchos acaban pidiendo una toma de requisitos detallada para “firmar” con el cliente lo que se va a hacer. Así, garantizamos que no entren cambios. Obviamente, esto choca con el valor de colaboración sobre contrato, pero debido a que en las empresas se ha entendido como “haz todo lo que pide el cliente”.
Falta de disciplina
Gunther Verheyen nos contaba en su libro Scrum Pocket Guide que una de las cosas que introducir en un equipo de trabajo es disciplina. La palabra disciplina se sigue asociando a un modelo más tradicional, sin embargo, es clave para que un equipo Agile funcione.
La disciplina es la capacidad que tiene un equipo de decidir cómo van a trabajar y después cumplir con sus propias reglas. La disciplina permite a un equipo inspeccionar y adaptar para saber cuando algo falla y pivotar. Sin disciplina, podemos tener Sprints que varían continuamente de duración, Daily Scrum que cambian de cara cada día, o un equipo en el que sus miembros cambian continuamente. Todos estos cambios hacen que nuestro producto sea más complejo, lo que nos resta probabilidades de obtener resultados.
Muchos equipos software adolecen de disciplina, y cuando un marco como Scrum intenta introducir reglas, esto genera rechazo por querer cumplirlas. Si recordamos la película Karate Kid, empezamos con “dar cera, pulir cera”, aunque no lo entendamos. Sin embargo, tras un tiempo de disciplina, empezamos a obtener beneficios.
Para estos equipos, seguir un marco como Scrum es ser muy “talibán” y reniegan de esta forma de trabajar. El equipo que comenté antes, era muy Agile gracias a su propia disciplina. No seguían Scrum, pero se sentaban con el cliente a definir su proceso de trabajo y después cumplían con el mismo. Esto no quita que en la Retrospectiva inspeccionaban su proceso para buscar puntos de mejora.
No quieren ni la libertad ni la responsabilidad
Modelo cómo Scrum y el desarrollo ágil promueven la libertad en la toma de decisión. La autoorganización permite a un equipo experto en una materia decidir cómo van a trabajar para generar valor. Cuando tomamos decisiones, asumimos una responsabilidad, podemos equivocarnos. Muchos equipos prefieren no asumir esa responsabilidad para evitar estar expuestos. Este problema ocurre por varios factores. En algunas empresas existe la cultura de la culpa, y las personas no quieren verse perjudicadas por haber tomado una decisión: “para eso está mi jefe”. Por otro lado, venimos de un sistema educativo donde muchas asignaturas tu misión era hacer los deberes del profesor, y no pensar por tí mismo.
Por eso, algunos desarrolladores prefieren tener un jefe que les diga lo que tienen que hacer. Así, en caso de error. no asumir ese fallo. El problema de este tipo de comportamientos es que evitan la creatividad, el pensar mejores soluciones y las ganas por resolver problemas.
Los mejores desarrolladores que he encontrado en mi carrera, sí querían asumir esa responsabilidad. En parte porque creían fielmente en hacer las cosas bien y en la tecnología que eran capaces de construir. Cuando tú consideras que eres capaz de hacer un buen software, quieres la libertad para poder tomar las decisiones que consideren acertadas.
Si queremos trabajar diferente, necesitamos a los desarrolladores
El desarrollo software es una profesión muy bonita, nos permite cambiar el mundo. Cada vez que creamos un nuevo producto y alguien lo usa, le ayudamos a trabajar mejor, ganar dinero o comunicarse con un amigo. Todo esto, cambia el mundo, porque para esa persona hay un cambio en su vida.
El desarrollo software es una ventaja competitiva para las empresas que quieran apostar por ello. Y para eso, necesitamos a las personas, ya que son ellas las que crean los nuevos productos. Por tanto, tenemos que apoyarnos en ellas para conseguir ser competitivos.
Agile nos permite trabajar de otra manera, pensando en el servicio que prestamos, generando valor y siendo capaces de pivotar rápido. Sin embargo, Agile necesita de un cambio cultural. Si queremos ser competitivos tendremos que pensar diferente, Agile no es trabajar de otra manera, es pensar de otra manera. Es importante que nos apoyemos en los equipos para decidir cómo vamos a trabajar, cómo nos aseguramos que trabajamos en la buena dirección y cuáles son las expectativas de nuestro cliente. A partir de ahí, confiemos en los equipos y en su capacidad de trabajo. Si tenemos que controlar a las personas para que trabajen bien, es que hemos contratado a las personas equivocadas.
Y tú, ¿quieres Agile o no?
