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?
Aparte de la bazofia de las ceremonias. Lo que más me hierve la sangre es que no todos los días estás igualmente lúcido. También hay días que inviertes en ganar skills pero al día siguiente tienes que contar que no has avanzado en la tarea con el consecuente tocamiento de huevos,
Hola, mi experiencia con Scrum ha sido nefasta. He pasado ya por varios proyectos que la utilizan y mi nivel de frustración ha ido in crescendo, hasta el punto que en los últimos meses hasta me planteé dejar la programación y dedicarme a otra cosa si no era capaz de entrar en algún proyecto que no la utilizara.
Todo lo que comentas lo he sufrido, el hacer y rehacer trabajo, tareas poco definidas, cambios constantes porque el cliente no sabe ni lo que quiere (como somos ágiles, ya no hace su parte, que es saber qué coño quiere), reuniones constantes que nos comen las horas de trabajo y mil problemas más… todo eso se convierte en el pan nuestro de cada día. Y si fuera sólo en un proyecto, podría pensar que he tenido mala suerte con él, pero me ha pasado en todos por los que he pasado que usan esta metodología.
Para mí es algo que se ha puesto de moda, que se quiere utilizar para todo y en todo, y que no dudo que en algunos proyectos concretos podrá funcionar, pero mi realidad, la que estoy viendo, es que tanto en los que he estado como en experiencias de amigos y colegas, es un desastre.
Sólo espero que pase la moda pronto, porque los niveles de frustración a los que nos está llevando a muchos, es insostenible.
Y estaba deseando que me gustara, porque sobre el papel sonaba bien, pero luego en la realidad, está resultando ser una manzana envenenada.
Scherzo
Hola, una pena, un caso más. Como comentan en los comentarios, eso no es Agile 🙁
Yo he tenido la suerte de poder aplicar scrum de verdad y si funciona. Pero es un modelo que en mi opinión solo es aplicable para startups o empresas que venden producto y no servicio. De hecho la única vez que pude tener la ocasión de scrum de verdad fue en una startup donde su negocio era el producto.
En ningún otro caso se puede aplicar scrum pq no te van a dejar. Todos los clientes te pedirán un presupuesto y nadie te va a dar un cheque en blanco que es scrum.
Esta metodología tiene un grado de incertidumbre demasiado elevado, en el q el cliente modifica el alcance cuando le da la gana.
No existen equipos autogestionados, el equipo de desarrollo tiene q enfocarse en su labor técnica el Project Manager de los aspectos administrativos por ende, los técnicos no deben tomar decisiones q involucren alcance, plazo y coste.
El hecho de q se modifica el alcance conlleva a un efecto domino en términos de variación en el cronograma y el presupuesto, por lo cual se deben escribir en piedra los objetivos del proyecto en la reunión de inicio para evitar cambios a último momento.
La gestión de proyectos debe ser sistematica y estructurada en donde el equipo de desarrollo debe estar en constante monitoreo por parte del Project Manager, es decir, los equipos de desarrollo no deben ser juez ni parte, ese es un error fatal.
Prefiero sacrificar agilidad q calidad.
No recomiendo scrum para nada.
Más que scrum, el problema que comentas está en que no se dan las características para implantarlo: proyectos a precio y alcance cerrado, no hay mentalidad de producto vivo, ni de minimo producto viable. Es como si vendes un formula 1 para ir por un lodazal.
Por lo que comentas en esos proyectos, apliques lo que apliques suena a hostia segura, y ahora viene el dilema ¿Dices que no a esos proyectos? Si dices que no, te cuesta encontrar clientes, si dices que si, en una curva firmas algo que no puedes hacer y te toca cerrar por incumplimiento de contrato.
Por otro lado, scrum tiene demasiada ceremonia, prefiero ahorrar ceremonia, quedarme con reuniones diarias muy rapidas, reuniones de definicion de sprint, y si el proyecto / equipo es grande dividir en subequipos por area fincional (creo que a eso le llaman squads) y dejar un hueco de horas en cada sprint para para imprevistos (creo que a eso le llaman «scrumban)