El Scrum flácido, la agilidad flácida o la agilidad de “pinta y colorea”

La patología de hoy ha sido citada y nombrada de varias maneras desde hace años, si bien, la que me parece más acertada, y llamativa, es la de Scrum Flácido, denominación que pertenece a Fowler y que da título a este post.
El Scrum Flácido o, en general, la agilidad flácida, la agilidad de fachada, hueca, relajada, de “pinta y colorea”, etc., no es un tema nuevo, por supuesto, la denominación “Scrum Flácido” es del 2009 y, además, el tema ya lo habíamos tratado por aquí en 2012, al menos, que recuerde, en aquel post de lo siento mucho, pero sólo con Scrum… no vas a terminar un desarrollo software con éxito y, de nuevo, más recientemente en “Que la “felicidad ágil” no nos haga olvidar al “esfuerzo ágil”.
¿Por qué sacarlo de nuevo? La única novedad en el tema no reside en los síntomas, reside en la expansión de la enfermedad, que ha pasado de manifestarse en algunos casos puntuales a rozar el grado de epidemia. Lo que ha hecho que este tema, el de la agilidad flácida, vuelva a estar, por desgracia, de mucha actualidad y debate.
En parte por el crecimiento de la popularidad de la agilidad, por llamarlo de alguna manera, y por el crecimiento en número de los que propugnan y difunden la agilidad fácil, que siempre se vende mejor, frente al esfuerzo necesario que conlleva cualquier proyecto humano que termine con éxito.
La agilidad o el Scrum Flácido se caracteriza por tomar sólo un poco de Scrum, el usar un Scrum con apellidos (Scrum Relajado, Scrum Pero, Scrum en ocasiones, Scrum sin Sprints, Scrum con Cascada, Scrum con requisitos cerrados, etc.), etc., pero, principalmente, por evitar y obviar la parte más técnica que siempre debe acompañar a un “framework” tipo Scrum.
Ciertamente, vende menos hablar en una conferencia, en un curso, es más difícil de pintar en un mural, es más aburrido, hay hasta que leer libros, etc., de cosas como la importancia de un “buen diseño OO”, “inversión of control”, “del patrón state”, de “integración continua”, “prueba unitaria”, “deuda técnica”, “complejidad ciclomática” (aquí te dejo un post de 2007), “pair review”, “estrategia de control de versiones”, etc.
Ocurre muy frecuentemente con Scrum, porque Scrum está más cercano a la gestión del proyecto (no clásica, obviamente), porque Scrum no habla de aspectos técnicos, lo que no quita que Scrum requiera de un robusto conjunto de prácticas técnicas (esas que parece que se nos está olvidando explicar, y que parece que vende más no entrar en ello), en las que si que entra, por ejemplo, eXtremme Programming.
Y, ojo, porque si la epidemia del Scrum flácido, de la agilidad flácida, continua su avance, si continuamos predicando sólo la agilidad del “pinta y colorea” (digo, sólo, repito, solo, que lo “happy” está muy bien, el problema es olvidar lo otro, lo que vende menos), corremos el riesgo de matarla, al tiempo, y espero equivocarme.

jgarzas

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.

0 comentarios en “El Scrum flácido, la agilidad flácida o la agilidad de “pinta y colorea””

  1. Lamento decir que comparto el sentimiento. Hay un grupo de empresas consultoras «predicando» Scrum y en la práctica están bastante lejos del asunto, lo más triste no es que ofrecen algo que no hacen sino que además están contaminando con malas prácticas a aquellas personas que desconocen este marco de trabajo. Actualmente trabajo en tecnología y estoy en la posición de cliente, y cada vez que recibimos una propuesta no hay proveedor que no venda Scrum como «metodología de trabajo» y ninguno de los que han ejecutado proyectos con nosotros a llegado al menos a un 10% de la aplicación de Scrum.
    Soy CSM y me ha costado muchísimo como cliente trabajar con Scrum con mis proveedores de Desarrollo de software, sería interesante que pudieras escribir respecto a como hacer proyecto con Scrum Cuando es compartida la responsabilidad cliente-proveedor.
    Saludos desde Venezuela y muchas gracias por nutrir siempre a la comunidad Ágil con tu experiencia.

  2. Javier
    Lamentablemente se esta «vendiendo» Scrum por consultoras IT que no tienen idea de Agilidad y se lo recomienda a sus clientes sin pensar que estan arruinando la metodología.
    Muy buen articulo.
    Saludos,

Dejar un comentario

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