Mi desencanto con Scrum

Hace tiempo que tengo ganas de escribir sobre este tema. Hace ya algunos años, las metodologías ágiles y mas en concreto Scrum entraron en mi vida como un huracán, me replantee el como había trabajado hasta ese momento y todo lo que no fuese gestión ágil, directamente me parecía «basura». Pero el tiempo y la industria me han puesto en mi sitio y en estos momentos tengo una gran sensación de desencanto y frustración con todo lo que tiene que ver con metodologías ágiles. Me explico un poco.

Antes de empezar y a riesgo de sonar contradictorio he de aclarar que las metodologías ágiles me parecen geniales y me siguen pareciendo, de lejos, la mejor manera de gestionar la creación de software y la gestión de los equipos que lo hacen, pero como todo en esta vida, hay que saber cuando se puede usar y cuando no, y por supuesto, usar la metodología correctamente. Y de esta última parte es de donde viene mi frustración, en como se usa y como se abusa del termino dentro de la industria, de como he intentado el cambio y como no he sido capaz de hacerlo, NUNCA.

Creo que bien usada, la metodología funciona, me consta, gracias sobre todo a gente que sigo en Twitter (por ejemplo el gran @jgarzas) que en algunos casos se esta implementando a las mil maravillas y todo lo que comento en esta entrada es muy personal y esta basado única y exclusivamente en mis experiencias, por eso digo que es mi desencanto y no pretendo generalizar, aunque no estaría nada mal leer comentarios donde expongáis vuestras experiencias, para ver si es algo generalizado o si simplemente he tenido mala suerte (o que yo no he sido capaz de evangelizar lo suficiente en las organizaciones donde he estado).

De momento no he conseguido hacer bien Scrum en ninguna de las empresas en las que he trabajado (que por supuesto se venden como empresas ágiles), y estos son a mi entender los mayores errores que se comenten y que nos llevan al «postureo Ágil» (expresión que le he escuchado a @jgarzas  en alguno de sus vídeos y que aquí tomo prestada por que me parece que viene al pelo):

• Se vende como uno de los aspectos fundamentales de scrum mayor velocidad de desarrollo.

Debido al puesto que he venido desarrollando los últimos años, he tenido la oportunidad de asistir a varias reuniones de presentación, toma de requerimientos o pre-venta y uno de los argumentos que se lanzan hacia el cliente para vender la metodología ágil, es que los desarrollos serán más rápidos. (ponte a corregir a quien toque delante del cliente… la pulla ya esta lanzada)

• Aunque se venda el proyecto con una metodología ágil, siempre tiene un alcance definido para una fecha concreta.

Ya vamos mal… si tenemos una fecha de entrega concreta, con un alcance concreto, poco margen para adaptarnos al cambio tenemos. Lo que nos lleva a los siguientes puntos.

• Se ajustan las historias de usuario a los compromisos de entrega, no a lo que el equipo dice. He llegado a ver como se re-ajustaban  estimaciones de las tareas para que entrasen algunas historias mas en el sprint.

Si, dividimos las tareas en sprints y demás, pero cuando ya tienes definidos que van a ser 15 sprints de 2 semanas desde el principio y tienes definido el alcance, ¿de que sirve esto? Tenemos un Gant disfrazado de tablero scrum.

• Reuniones diarias eternas.

Donde se discute de todo. He estado en sitios donde las reuniones diarias de media duraban las de 30 minutos… eso si no había algo técnico que discutir o alguna bronca que echar.

• El jefe de proyecto introduce nuevas historias de usuario en mitad de un sprint, por supuesto sin que ninguna de las que ya estaban estimadas desaparezcan del planing.

Otro clásico, meter mas tareas en la planificación del sprint, pero por supuesto, todo lo que ya estaba planificado hay que hacerlo, que esta comprometido con el cliente.

• Se cambia toda la planificación en mitad de un sprint, por lo que todas las reuniones que se han hecho para planificar, no sirven de nada y se han de volver a hacer.

De repente al cliente le cambia la prioridad de golpe, y hay que hacer toda la planificación de nuevo, con todo lo que ello conlleva. Posiblemente, hay que cerrar algunos de los temas que ya estaban abiertos antes de todo.

• Como consecuencia de lo anterior, se hacen horas para cumplir con el sprint.

Horas y horas…

• Los lideres técnicos asignan las tareas al resto del equipo teniendo en cuenta sus fortalezas y debilidades.

Aquí se va a tomar por saco los equipos multi-disciplinares y auto-gestionados. Al final el que sabe un poco mas de un tema, siempre toca ese tema. Arregla el bug menganito, que el fue el que toco esa parte. Se crean nichos donde ciertas partes del proyecto solo son tocadas por ciertas personas, por supuesto cuando estas personas no están disponibles se genera un embudo importante.

• Los lideres técnicos estiman solos las tareas sin involucrar al resto del equipo.

Un poco en la linea del anterior punto, no se involucra al equipo. Total, si las tareas que han de entrar en el sprint están definidas de antemano, que mas da.

• Nunca se hacen retrospectivas, y cuando se hacen, no se hace nada por implementar mejoras.

Es mas, a veces se pueden tocar egos y esto hace que en vez de buscar mejora continua, la reunión se convierta en una batalla donde unos echan la culpa a otros y viceversa.

• El scrummaster multi-tarea.

Que escribe las historias de usuario y controla que el burndown no se vaya de madre.

En resumen, tenemos proyectos gestionados al estilo waterfall, pero con tableros y post-it. Tenemos una buena metodología, que esta de moda y al que todo el mundo se quiere apuntar, pero que a la hora de la verdad no quiere asumir los cambios en la organización que esto supone, o que provoca que al final se tengan que hacer mas horas y complica la gestión al querer meter temas de agilismo con calzador. Por supuesto, luego se quiere obtener los beneficios que aporta una metodología ágil y se piden explicaciones cuando esto no pasa.

¿que opinas al respecto?