La semana pasada el jefe de mi jefe me reunió para decirme que no estaba haciendo un buen trabajo como scrum master; que «estaba mimando demasiado a los desarrolladores porque les daba todo lo que pedían y no les echaba broncas» (¿dónde quedó ese peopleware del que presumíamos?).
Principalmente, ese fue el mensaje central, pero también tocó algunos otros temas para acabar mandando el mensaje de que las buenas prácticas de software, la experiencia del desarrollador, la calidad de código y el pair programming son tonterías y/o caprichos: «hace 20 años programábamos sin todo eso y nos ha ido estupendamente». Me quedé en shock mental. Hablábamos dialectos del castellano diferentes, o más bien, éramos de planetas diferentes.
¿Qué les pasa a los jefes para llegar a pensar así?
Muchas veces pienso que la escalera de poder tiene peldaños podridos. Mientras una persona va subiendo y escalando en la empresa, va perdiendo valores u olvidándolos para dejar sitio a los nuevos que tienen que venir (donde más claramente lo veo es en política, pero casi todo en la vida acaba siendo política…). Este jefe en particular, entró hace 20 años en la empresa siendo un programador más. Viene desde bien abajo. Y en 20 años ha conseguido tener a su cargo 200 personas: 30% middle managers y 70% curritos.
Imagino yo, inocente de mí, que cuando él era programador tendría necesidades a la hora de desarrollar. Tales como un entorno de desarrollo decente, un sistema para poder compilar el código, un versionado con una estrategia de ramas… Quizás también inquietudes por mejorar cierta arquitectura o pedir tiempo para mejorar un módulo que tenía muchos bugs. A lo mejor le gustaba leer y estar al tanto de las actualizaciones técnicas… ¿En qué momento se le olvidó quién era?
De repente la experiencia de desarrollo es un capricho, la visión de producto una ilusión y los objetivos a cumplir simplemente son: «aumenta tu velocidad sprint tras sprint y no cuestiones tanto la organización».
Tampoco ayuda el hecho de que el jefe pierda proyectos o clientes por tiempos complicados, que el talento se le esté escapando por momentos y que no confíe en sus empleados porque no sabe mantenernos alineados con su visión. Con todo esto a la espalda, es difícil no perder los nervios.
La realidad de las trincheras
Anyway, sea por el motivo que sea su comportamiento taylorista en momentos tensos, actualmente tiene un departamento entero descontento. Profesionales e ingenieros software que piden a gritos tiempo para innovación, formación, mejor experiencia de desarrollo y orden en su día a día. Son ingenieros, pero se les pide que sean «bomberos apagafuegos» para dar respuesta a una cantidad ingente de peticiones y proyectos diferentes. Muy buenos profesionales (y también profesionales que podrían ser muy buenos) que viven frustrados y van conformándose poco a poco, desgastándose día a día, gota a gota.
El gran problema es que el ritmo que hay que llevar para sacar todos los proyectos que se venden no es sostenible: somos muy pocos para tanto trabajo (o los proyectos se venden muy baratos, más bien). Además, todo se centra en un monolito legacy de millones de líneas de código con una lógica brutalmente compleja en sus entrañas. Los creadores originales de tal obra faraónica ahora son los jefes de los ingenieros que deben mantenerlo y hacerlo evolucionar. Hay grandes volúmenes de ego en esos jefes, los cuales impiden que se refactoricen los módulos críticos. Saben lo feo y delicado que es el código y piensan «eso que funciona es mejor no tocarlo mucho». El problema es que de repente hay que hacer evolucionar esa parte o un cliente encuentra un bug localizado ahí. Y aquí empieza el lío (bucle: «hay un bug» –> «se necesita tocar código» –> «pero no hay tests, voy a romper algo» –> «vale, voy a hacer un test» –> «uff, no puedo meterlo, necesito refactorizar» –> «¡pero no hay tests!»… y así ad aeternum).
Además de esto, esos jefes que crearon el monolito se sienten más listos que nadie. Se han criado bajo una «cultura de héroes» en la que quedarte hasta las 11 de la noche para preparar una oferta el día de antes de la entrega era algo que se aplaudía. Dedicar horas extra a preparar una demo era algo que se agradecía. Arreglar un bug en producción mientras a la vez dejabas 4 módulos de funcionalidad inservibles, era admirable. ¡Ah! Y como las situaciones de caos eran recurrentes, la comunicación violenta afloraba por los poros. Ya era normal hablarse mal y al día siguiente tan contentos todos.
Estos mismos jefes son los que ahora critican a los desarrolladores que llegan con inquietudes de cambiar y mejorar el entorno. A los que ven más allá. Los ven como niños caprichosos porque demandan trabajar mejor. Parece que no acepten o no sepan recibir estas peticiones, por lo que se limitan a responderles: «mejor mira qué puedes mejorar tú mismo dentro de tu equipo». A veces me pregunto si ¿mayormente será una cuestión de cambio generacional?. Estos jefes se encuentran con desarrolladores que ya no tienen sus mismos patrones de comportamiento, ni la visión de vida frente al trabajo de su época…
Queremos ser ágiles y contratar un scrum master
A todo esto, van y contratan a una scrum master para que con su varita mágica, haga que los equipos aumenten la velocidad. Y ¡ojo!, que la aumenten sprint tras sprint. Incondicionalmente. Da igual que este rol sirva para trabajar en paralelo varios canales: hacia el equipo desarrollo, hacia el descubrimiento de producto y hacia la organización. Solo se me pide que trabaje a nivel de equipo de desarrollo. ¿Outcomes, qué eso? ¡Lo que necesitamos son más outputs!
Y la scrum master lo intenta. Como un burro con anteojeras (que, por cierto, Panasonic ha creado unas para humanos que se llaman Wear Space. Para alucinar, jaja).
La scrum master habla de velocidad en todas las reuniones de retrospectiva. Muestra la gráfica de número de puntos historia por sprint o número de historias completadas por sprint. Miramos juntos el cycle time (tiempo que se tarda en hacer una tarea) para ver en qué historias podríamos haber trabajado mejor para ser más eficientes (sin echar broncas – no hace falta, créeme -, sin malas formas, haciendo hincapié en la autocrítica de forma adulta). Pero cuando nos damos cuenta de que tardamos mucho al debuggear porque no usamos un IDE en condiciones, cuando nos damos cuenta de que validamos manualmente cosas que se pueden automatizar o cuando nos damos cuenta de que el sistema de build es susceptible de ser reducido en tiempo, necesitamos pedir permiso al exterior. Pedir licencias, pedir tiempo, pedir espacio.
Por tanto, la scrum master se da cuenta de que trabajar a nivel local solamente, es inútil. El equipo de desarrollo forma parte de un sistema mucho más grande, el cual influye absolutamente en la productividad del equipo. Trabajar en un solo plano puede servir de vez en cuando, pero no sprint tras sprint durante años. Es necesario mirar el sistema completo para entender el desperdicio.
Y es entonces cuando la scrum master se acerca a Management y explica por qué no aumentamos la velocidad. Necesitamos un IDE, necesitamos espacio y tiempo en los sprints para mejorar nuestros sistemas de CI/CD, necesitamos formación en testing/refactoring legacy…
Y la pelota, como si chocara contra un muro de frontón, me viene devuelta con desgana y con la frase «estos desarrolladores son unos mimados».
…
Definitivamente la culpa es mía por no saber hablar el lenguaje de negocio.
Tengo mucho que aprender en ese campo.