Demistifying Agile

A riesgo de repetirme, el último artículo que escribí ha desencadenado una ola de reflexiones bastante interesante, tanto en los comentarios como en el correo y en la creciente comunidad de Agile Spain, que recomiendo a los que estéis interesados en este tema.

Concretamente, he entendido perfectamente uno de los comentarios en el que se decía “Esa es la sensación que tenemos nosotros desde hace tiempo, que decir “ágil” es dar puerta abierta a “hago lo que me da la gana y encima tengo excusa“. Efectivamente, hay equipos e implantaciones concretas en las que uno acaba teniendo esta sensación. ¿Paternalismo de los gestores? ¿inmadurez de los equipos? ¿Mala implementación?

También ha caido en mis manos un artículo sobre el supuesto fallo de Scrum y las metodologías ágiles en “enganchar” con la psicología humana. Curioso por lo menos, tratándose de una metodología que parte de los principios ágiles y que siempre presento en los cursos como la aproximación humana a la gestión de proyectos. ¿Por qué unos la vemos como la forma más humana de trabajar y otros precisamente como lo contrario? Una vez leido el artículo, la cuestión clave es: ¿confias en el equipo de trabajo? O en algunos casos, ¿se puedeconfiar en el equipo de trabajo? Si, como defiende el artículo, vives en la creencia de que el “factor humano” consiste en que las personas siempre antepondrán sus propios intereses a los del grupo, son egoistas y nunca conseguirás que se pongan de acuerdo, pues vale, Agile no es para tí. Esto vale tanto si crees esto como si tienes la certeza absoluta aplicada al conjunto de personas que te ha tocado (o has seleccionado, en cuyo caso mucho peor y debes revisar tu proceso de selección).

Partiendo de la base de que yo no pienso así, ¿qué provoca que a veces Agile desemboque en una situación de “hago lo que me da la gana y encima está justificado”? Es más que evidente que Agile, como decía en mi anterior artñiculo, no es “hacking institucionalizado” o “buenrollismo institucionalizado”. Pero creo que se hace mucho “hype” de los aspectos más “hippies” de Agile (comunidad, equipo, personas, comunicación, autogestión, no interferencia) y bastante menos reflexión sobre los nativos de la gestión de proyectos (disciplina, ritmo constante, entregas, producto terminado, visibilidad diaria, priorización, estimación, compromiso, deadlines). Es lógico, a todos nos gustan los primeros y no a todos los segundos, por lo que la estrategia de marketing de Agile (sobre todo en una implantación up-bottom, o “golpe de estado” como la bautizó genialmente hace poco un contertulio) pasa por vender lo bonito y pasar “la pildora” con el azucar.

Lo malo viene cuando solo queremos el azucar. En Scrum, concretamente, quitas un sólo tornillo y se descuajaringa todo el método, lo tengo comprobado. Jeff Sutherland ha defendido en múltiples ocasiones que no hay nada en el método que esté ahí por casualidad, que todo tiene un sentido muy específico y que el método no necesita optimizaciones, ya que es el resultado de la experiencia directa de miles de los mejores desarrolladores del planeta, la teoría de sistemas y la aplicación de las técnicas más eficaces de gestión (Lean) al mundo del software.

Pasa también que utilizamos esta estrategia de maquillaje del método (diga lo que diga algún pope del Scrum, a mi siempre me ha parecido más un método que un marco) para, como decía, hacer una venta up-bottom y, cuando el equipo se huele algo lejanamente similar a una estructura de control, se sienten engañados una vez más por los de arriba. Decepción, desmotivación, resistencia pasiva y toda la pesca.

Así que ahí va mi consejo a navegantes: si tu scrum, tu scrum. Si tu no scrum, tu no scrum. Pero scrum “mas o menos” (también conocido como “MyScrum” o “ScrumLite” o “bueno, nosotros hacemos una versión simplificada de Scrum”)… Tarde o temprano tu aplastado como uva. Scrum Master Miyagui Dixit (long ago).

Por cierto, no es casualidad que una de las dos metáforas recurrentes en cualquier curso de Scrum que se precie se la de que Scrum no es una bala de plata. El exceso de “hype” está siendo bueno para Scrum en el corto plazo (popularización), pero a la larga puede hacer mucho daño si la gente empieza a decir “esto no funciona”.

Actualización: olvidé mencionar el magnífico artículo de Management From Scratch