La culpa es de Scrum

“Errar es de humanos, pero echarle la culpa a los demás es mas humano todavía”  

— Charles Chaplin 

De esto hará unos años, no más de dos. Yo, prácticamente, pasaba por allí, y me invitaron a dar mi opinión, pero, en cualquier caso, la suerte ya estaba echada, ya poco se podía hacer, el desastre estaba listo.

Como en otras ocasiones, según íbamos hablando, según me contaban, yo apuntaba ideas en post-it. Y, cuando llegó el momento, pegué todos esos post-it en la pared y fui explicando mis impresiones.

También como en otras ocasiones… no me corté mucho. Para estas cosas hay que ser directo, así yo expulso mejor y ellos lo asimilan más rápido.

Después de muchos años, aquella era una de las peores gestiones de «proyecto» que había visto. No era la primera vez que veía tal oscuro despropósito, uno de tal nivel (te puedo contar muchos), pero en este caso lo que más me llamaba la atención es volver a ver algo como aquello en estos años del siglo XXI. 

La cantidad de malas prácticas, de anti-prácticas, darían para escribir un libro. Que, curiosamente, no tendría sentido escribirlo, ya que todas esas aberraciones ya se cuentan en multitud de libros, desde los 80 y antes. 

La ausencia de buenas prácticas era total, pero no hablo de buenas prácticas ágiles… hablo de buenas prácticas software de toda la inmensa vida de la historia del desarrollo.

Desde todas las que cuenta el «mítico hombre mes«, las de «peopleware«, todas las del «rapid development» y otros tantos. 

No voy a enumerarlas todas, que se me va el post, pero siempre recordaré, cuando me contaban lo que había pasado, como pensaba en aquella Ley de DeMarco, aquella que dice que primera Ley del mal gestores es… añadir más de lo que no funciona.

Por supuesto, el cliente, que tampoco es que fuera nada bueno en eso de gestionar software (sino no hubiera permitido tal desastre) canceló el (millonario) proyecto.

Cuánto dinero y competitividad ganarían muchas empresas con sólo hacer que sus «managers» lean, que lean algunos viejos libros, o que se los lea alguien, el retorno del coste de que tendría contratar a alguien les lea en voz alta libros… esta impresionantemente compensado. Pero en esto tengo la fe un poco perdida, cuando muchos «managers» no quieren asistir a un curso de Agilidad… porque eso es de técnicos.

El tiempo pasó, y creo suponer que aquellos «managers» también pasarían de mis consejos (que, aparte de ser míos, de años de lucha y trinchera, son los que he aprendido de leer mucho lo que nos han dejado nuestros «antepasados», esos olvidados que sí sabían lo que había en una gestión software). Y yo olvidé aquel proyecto (a lo que ayudó estar en otras guerras y situaciones similares)…

Hasta que este año conocí a una persona, digamos un Mr. NoBody, no nos conocíamos de antes, y hablando salió aquel proyecto. Pura casualidad. Él lo conocía por referencias, no había participado (será que se hizo famosa la cosa), y entonces Mr. NoBody me dijo: «Fíjate Javier si hay que tener cuidado con la Agilidad, porque, como han contado varias veces los «managers» de aquel proyecto… el desastre vino por culpa de Scrum».

Mi breve conversación con Mr. NoBody terminó, antes de irme y, sin darle detalles porque el tema era confidencial, le tuve que explicar que aquello de que la culpa era de Scrum era una tremenda… estupidez.

Ciertamente, aún hoy, 2019, no sé como la Agilidad a aguantado tantos años, y aún sigue siendo algo demandado. Cómo puede ser con el mal uso que se hace uso de ella, el postureo de la certificación, lo mucho que muchos dicen tenerla y con lo fácil que está siendo echarle a ella la culpa de errores de «management» de base ochenteros (y previos).

Será que la comunidad Ágil es muy potente, será que la Agilidad lleva ahí realmente 20, 30 años, que tiene buenas raices, no sé, no sé que será, pero espero que siga, como pequeña y débil barrera frente al Lado Oscuro.

3 comentarios en “La culpa es de Scrum”

  1. En el proyecto donde trabajo se quieren implantar metodologías ágiles como scrum desde hace un tiempo desde el management. O eso dicen.
    Sin embargo lo que se hace realmente es renombrar viejas prácticas con nombres «ágiles», lo cual, como conocemos al menos la teoría nos molesta bastante.
    La última novedad en «agilidad» es que ya no hace falta hacer análisis ni diseño. Que para esta «agilidad» prefiero quedarme como antes.
    Esto está haciendo que los técnicos huyamos de allí como de la peste, sobre todo cuando no se aprecia nuestro trabajo.
    Eso sí, estoy aprendiendo casi todo lo que no hay que hacer 😀

  2. Como he insistido tantas veces, el problema no está en las metodologías, ni en los sistemas (¡ni siquiera en los sistemas políticos!!!), ni en los procesos, ni en las estructuras, por muy cierto que sea que los hay mejores y peores. El problema tampoco está en la definición que se hace de unas y otros, siempre ideal y sin contar con «el factor humano». El problema reside en la forma en que el ser humano tiende a utilizarlo; no al principio, sino pasado el tiempo. ¿Relajación? ¿Auto-engaño? ¿Especialización? ¿Compartimentación? Por nombras algunos factores. Que cada cual escoja los ingredinetes (no pocos) y el mix que considere oportuno. El lado oscuro, Javier, es un poliedro de demasiadas caras. Y hablar de ello demasiado claramente para no herir la sensibilidad ajena, y no perturbar este estado de somnolencia en el que vivimos, es politicamente incorrecto. Sé de tí desde hace muy poco pero tengo la impresión, por tu forma de ser, de que lo has podido comprobar en bastantes ocasiones.
    ¡Y es que es irremediable! En otoño las hojas amarillean y terminan por los suelos…
    ¡Pero que no cunda el desánimo!!! Es solo un dato de la realidad a tener en cuenta. Con un extra de energía, responsabilidad, pasión y talento no hay nada que pueda tumbar a una mente inquieta y creativa. ¡Nada!

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Share This
Ir arriba